Tag Archive for open source

FOSSGiving 2017

Long time readers of this blog and Coder Radio listeners may recall that for the last few Thanksgivings I’ve been writing up or covering on the show my list of open-source tools that I am thankful for that I feel will be significant in the year to come; if you’re curious the first year I did this was 2012.

Electron: I know this might be a little controversial, since there are a lot of strong feelings around the Electron project and how Electron apps use more resources than their native equivalents would. However, it’s undeniable that Electron has had a huge impact on the entire computing community and more specifically those of us who run desktop Linux. Doubt me? Have you used Slack, Atom, or Visual Studio Code at all this year? If so, you’ve used an Electron app. Given the trajectory of JavaScript and web technologies becoming mainstream and full-scale application development technologies with ever increasing performance, you can bet that Electron will continue its trend toward becoming the mainstream consumer and enterprise desktop application development technology for many organizations.

Node.js: I’ve spent a lot of time in the past railing against Node.js being used as a replacement for more traditional web application development technologies, such as Ruby on Rails, but I have to pass the turkey leg to the Node team this year. Over the past few years, Node has been maturing into more of an engine for writing large-scale JavaScript applications and we are really seeing the benefits of that in 2017. For example, my AI Bot Alice is written using the Microsoft Bot Framework using Node. Oh and every Electron app also uses Node as well as most Electron-like frameworks.

Typescript: Microsoft’s Typescript team came to liberate us from the complexity of managing large-scale JavaScript applications, however, Typescript has turned out to be something of a conqueror. With large-scale projects from other major tech vendors transitioning to it (think Google’s Angular), Typescript has gone from one of many compile-to-JavaScript also-rans to all but dominating that field and is now influencing the design of ECMAScript / JavaScript to the benefit of the wider community.

My three picks this year are all along one theme that I think has been emerging for a few years now – the dominance of open web technologies in just about every area of mainstream development. This makes not only practical sense for developers having to manage how they invest their training / education time, but also for business stakeholder who need to get work done as quick as they can and if possible in a cross-platform way. Native app development might make sense in some rare cases, but those are fewer and farther between. I fully expect JavaScript to continue it’s relentless march to world domination well into 2018. Let me know what you think of this list on Twitter and check out The Mad Botter INC.

MDNetworking: My Little Networking Lib

Disclaimer: This is in no way a 1.0 codebase and I strongly recommend against you using this in production.

Summary: MDNetworking is a small Apache 2.0 licensed Cocoa / Cocoa Touch library. It is intended to be suitable for use on iOS7+ and Mac OS X 10.8+ but it may in fact be possible to get it working on older version of iOS and OS X. My intention in creating this library is not to make yet another heavy Cocoa networking framework that is going to solve the meaning of life and the world’s problems. I merely want to present a relatively simple and easy to use facade of NSURLConnection and the like.

Contributing: I’m open and welcome contributions from the community, however, any contributions that don’t adhere to the present code-style will be rejected.

Happy Thanksgiving 2013 Open-Source!

turkey_in_circleHappy Thanksgiving! I hope you are all having a wonderful holiday weekend. Last year, I posted an article in which I listed and discussed the open-source projects that I found particularly meaningful over the year. Why do this? Well, the idea here is to basically say “thank you” to the open-source projects that I use and to also track year over year how the projects I use frequently change.

Last Year’s picks were ASIHTTP, JQuery, and Rails. There has been a lot of change from 2012. To start, I don’t use ASIHTTP at all anymore and have finally moved on to my own home grown solution that I hope to finally release under an open-source license before the end of 2014; basically, this is because it is no longer supported by the original author and my branch was getting a little more duct-tapped than I was comfortable with. JQuery is pretty much totally out of my toolbox these days; like a lot of developers, I’m feeling that JQuery is a little too hefty for most tasks and have moved to purer JavaScript / CSS tasks that might have been done using JQuery in the past. In a lot of ways, the only project that was listed last year that I’m still actively using is Rails; a lot of that has to do with maintaining existing Rails installs and it should be noted that I’ve cut my Rails usage significantly.

Still, let’s not dwell on the past too much. I have three new projects that have basically taken over my development tool-chain this year: Docker, Java Play, and ASP.Net MVC.

Docker: My infatuation with Dockery has been well documented on Coder Radio, so there is not a lot of need to go into too much detail on why I like it. However, it is worth mentioning that Dockery has become my go to tool for deployment to Linux-based servers. Given the relative newness of the project, it is likely that it will remain one of my “go to” open-source tools into 2014.

Java Play: Java Play Is one of the frameworks that I was evaluating when I decided I wanted to lessen my dependency on Rails. Given that Java has stood the test of time and is one of those technologies that clients don’t need to be convinced of to deploy, I can’t imagine Play not making it into 2014.

ASP.Net MVC: Thanks to Microsoft’s liberal treatment of Azure credits, there had need good amount of demand for MVC from cost conscience clients. MVC was a pretty big part of about half of my year, but as the free Azure credits have dwindled, so has demand. There has been a lot to like in MVC, though I’ve seen a lot of issues with migrations not working the way I would expect them to; still, those migration issues probably have more to do with me expecting it work like migrations in other platforms.

There has certainly been a lot of change from last year’s list and, if I was pressed to find a theme, I’d say that this year I’ve focused on more mature tools, though Dockery is of course very new — still, from a coding perspective I’ve gone a lot closer to “enterprise” (Java / C#) than 2012. Hope you all have an awesome holiday weekend and please leave any comments on Twitter.

Open-Source: Parenthood or Charity?

Recently, there has been some debate regarding what sort of responsibility we have as developers when we open-source our software. There has been some suggestion that when you open-source something you are obligated to maintain and care for it, as a parent would a child.

This parenthood argument is usually made by developers who want to use your software but need it tweaked and feel you should be obligated to do the tweaking for them. Basically, they’d like some free contracting. Sadly, it seems these folks don’t read they licenses to the projects they enjoy, since every open-source software license worth its salt has an “As is” clause, meaning the software it covers is provided as is and with no warranty of guarantees of any kind and the author is not required to support you and your use of his software in any way.

I’ve always viewed open-sourcing software as a form of charity — I usually open-source packages that are utilities for commonly performed tasks or tasks that were just plain annoying for me to do. One example of this is my little Ruby script SizeHunter. SizeHunter was something I wrote when I became a contractor to search a directory and make sure that I had both regular and retina resolution assets for iOS projects. Clearly, a very limited script and a naive implementation of what I wanted to do. I have since moved on to the more full featured, but a little pricey Slender Mac App. However, that doesn’t mean that another developer couldn’t take SizeHunter and either use it as is or build it out for a more sophisticated needs. I don’t feel obligated to that developer at all and don’t think I should. That doesn’t mean that I’m not happy that someone is using my software.

Let’s treat open-source software less like an obligation or child and more like what it is — a charitable contribution to the software development community. Questions? Comments? Dogmatic rage? Find me on Twitter and Google+. This post was brought to you by Code Journal and Fingertip Tech, INC



Happy Thanksgiving 2012 Open-Source!

I had a wonderful Thanksgiving this year and, as is common this time of year, friends and family made the normal mentions of things, places, people, or any other sort of noun that they are thankful. Of course, I agree with the most common objects of gratitude: friends, family, etc. However, I got to thinking about work and how thankful I am for the proliferation of open-sourced software. So, I’ve compiled this list of software libraries that I am most thankful for this year.

ASIHTTPRequest: Admittedly, this is a bit older than some of its more popular competitors and there are reasons that one might choose an alternative, but you just can’t be a simple networking interface that includes easy to use caching support. AFNetworking may be the hot new kid on the block, but ASI is still more than adequate for the job. I can’t promise that ASIHTTPRequest will still be my networking framework of choice in 2013 but it has served me well for the last two years and is even a joy to maintain on older apps.

jQuery: Compared to most client-side development, web development is awful. jQuery aims to take pain out of web development and, for the most part, does the job. In the last year, I don’t think I worked on any sites or web apps that did not use at least part of jQuery. I’m sure jQuery will continue to be the ‘go to’ tool for web developers everywhere in 2013.

Rails: Rails has been all over the place this year. I’m very thankful to have had the opportunity to work with it and for it to be introduction to Ruby. For me 2012 was the year of Rails on the backend, however, I doubt that will hold true for 2013. From a consulting perspective, Rails seems to be losing ground to Python-based alternative such as Django and the upstart Node.js. From a more personal perspective, Rails is solving problems I don’t seem to have or rather I have those problems but there are also other issues that it chooses to ignore. Additionally, Rails is going, as is true to its nature, in its own direction (think SASS and Coffeescript) and, in more and more cases, those just aren’t paths I am interested in taking. I have been evaluating alternatives and have come to a decision stay tuned for another post later next week.

There are other projects that I’ve used or use frequently, but these are three that stick out most prominently. Will they all be on next year’s list? Doubtful. Still, I am thankful for them and all the open-source work that makes my job easier and, in some cases, possible. Do you have your own three? Share them with me on Google+ or Twitter. This post was made possible by Code Journal and Fingertip Tech, INC. If you are Github user please check out Code Journal and if you are interested in having an Android, iOS, or web app developed please contact me.

My Open Source Initiative

I’ve been looking at some of the older code I’ve had sitting on my various hard drives and Dropbox accounts and realised something: a lot of this code is not that novel. There is nothing wrong with it, but a lot of just solves problems that I find myself having to solve over and over again.

So, I am going to try to open-source as much of this code as possible. There are of course a few conditions to this: I will of course only be open-sourcing code that I actually own (file that under ‘duh’), the code must be theoretically useful in a very general, and I will need to be able to use the code again in proprietary projects.

Basically, what that all boils down to is that I’ll be using the Apache license for most if not all of the code and there won’t be full applications open-sourced.

You can find all of my open-source on my Github. I’ve already started by open-sourcing a simple Ruby script that I use for Mac and iOS development.

Dependency Anti-Patterns

Open source frameworks are great and I encourage you to use them when appropriate. However, there is a such a thing as too much of a good thing. There is a point where your project becomes more a stitched together Frankenstein’s monster than an elegant well crafted piece of software. Of course this doesn’t just happen by magical fairies adding dependencies; there are warning signs that you may be in a bad spot with your use of open-source before it becomes a real issue.


In no way do intend to criticize the proper use of open-source software. In fact, I still use ASI and similar plumbing tools in many of my projects. The trick is that I always have an exit strategy; for example, in the case of ASI, if the time ever came to switch I’d probably move over to the more modern AFNetworking.  On the web side of life, I tend to use JQuery fairly heavily but always keep an eye out for smaller (possibly leaner) alternatives.


If you don’t have an exit strategy, things can get very bad very quickly for you if the project you rely on is either canceled or stops being updated and becomes too out of date to easily use in your domain. But why? Why do we do this ourselves? Why do we keep inheriting projects with huge and in many cases unneeded dependencies? Aren’t there warnings? There are warning signs and I’ve seen some common patterns in the (often flawed) logic of some of the worst offenders.


Pre 1.0: Lately, I’ve been seeing a disturbing quantity of pre 1.0 software being used in production. This is madness. Pure madness. If the creators / maintainers of project don’t think it is production ready, then you simply should not be using it in production. If you do and run into issues, you pretty much deserve what you get.


Fear: This has to be the most common reason that I see developers take huge dependencies that are more than a little questionable. Many developer fear technology that they don’t understand or don’t have experience with and attempt to abstract it away with clunky frameworks.   This is pretty common in the Apple space (iOS / Mac OS X), since many developers fear Core Data and go through some pretty silly hoops to avoid using it directly. These ‘hoops’ tend to be large frameworks that your entire project ends of being written around, making removing them later a costly and painful endeavour. In the example of Core Data, the irony is that Core Data is itself an abstraction designed to simplify working with datastores.


Closed Mindedness: This is another area where the Core Data example comes into play. There are a number of newer iOS developers who feel that Core Data should be just like Rails / Activerecord, so they turn to dubious frameworks to get that. Again, this is particularly questionable since Core Data already supplies a style of object relational mapping and is in itself an abstraction. Not to pick on Rails folks too much, but I’ve been seeing a scary number of ‘Rails-like’ frameworks popping up. The issue with this is that Rails already exists and  does a good job solving the problems it was designed to solve, however, it was not designed to solve all problems; other approaches and tools would be more appropriate for other problems. Of course this issue can go all the way down to the language level. For example, I’m often forced to work with Objective-C that has been written as though it were Java by people who seem to have no understanding of the messaging paradigm in Objective-C and are more than happy to force Java concepts / practices on the language whether they fit or not.


Budget: This is the most understandable reason for taking on large dependencies.  Today’s project managers are severely constrained in terms of budget available per project and there is a real need to cut costs. I have a lot of sympathy for this one. However, you should remember that there is more to a project’s cost than just the initial development cost; there is also maintanence.  If you do take one of these large dependencies make sure you have a roadmap for you will maintain and grow with the dependency itself; there is nothing worse than building an app on framework A and realising a year later that it needs to be substantially rewritten in framework B to adapt to your changing needs or scale.



That’s all for me. Let me know what you think on Google+, Twitter, or App.net. Buy Code Journal!

Thanks JB Community

If you listened to Coder Radio this week you would have heard toward the end that I have been working on a project targeted for the Ubuntu App Store. You will have also heard that I ended up choosing Mono as the development stack for the project; I plan on writing a post in a few weeks on my overall experience with Mono on Ubuntu and plan to mention it on a future episode of the show.

Needless to say I had some problems, but that’s not really the point of this particular post. The point of this post is to thank all the Jupiter Broadcasting community members for all their help. I have received countless e-mails and messages on Google+ regarding the issue. All of them offered suggestions of how I might solve my issue. Some even offered to either help me write a solution or offered to share how they had solved similar issues.

I’m floored. I wish I could write you all back individually but there are simply too many of you. So, please take this post as a thank you letter. Furthermore, in the spirit of community, I am going to open-source whatever solution I end using and will be posting it on Github as a more substantial way to say “thank you.”