Category: Programming

A big part of my work has to do with code. I’ve worked as system administrator – installing, patching, and configuring someone else’s code. I’ve worked as independent programmer, writing code on my own. I also programmed as part of the team. And on top of that, I worked as Team Leader and Project Manager, where I had to interact a lot with programmers. Programming world on its own is as huge as the universe. There is always something to learn. When I find something worthy or something that I understand enough to write about, I share it in this category.

Semantic Versioning

A lot of my work these days is all around web projects, where versions aren’t particularly used. Code is written, tested, and deployed multiple times a day, rather than once in a while. But if you are doing scheduled releases with major and minor changes, backward compatibility and so forth, please consider using Semantic Versioning.

In systems with many dependencies, releasing new package versions can quickly become a nightmare. If the dependency specifications are too tight, you are in danger of version lock (the inability to upgrade a package without having to release new versions of every dependent package). If dependencies are specified too loosely, you will inevitably be bitten by version promiscuity (assuming compatibility with more future versions than is reasonable). Dependency hell is where you are when version lock and/or version promiscuity prevent you from easily and safely moving your project forward.

As a solution to this problem, I propose a simple set of rules and requirements that dictate how version numbers are assigned and incremented. For this system to work, you first need to declare a public API. This may consist of documentation or be enforced by the code itself. Regardless, it is important that this API be clear and precise. Once you identify your public API, you communicate changes to it with specific increments to your version number. Consider a version format of X.Y.Z (Major.Minor.Patch). Bug fixes not affecting the API increment the patch version, backwards compatible API additions/changes increment the minor version, and backwards incompatible API changes increment the major version.

Readme Driven Development

If you’ve ever had a project without a README file hosted at GitHub, you know the recommendation message to create one. When I first saw that message, I thought it was a bit weird, but, I guess, fine. It never bothered me enough to search for any explanation – I just ignored it, or created a README file. Apparently, there is an explanation – Readme Driven Development by Tom Preston-Werner, one of the GitHub co-founders.

By writing your Readme first you give yourself some pretty significant advantages:

Most importantly, you’re giving yourself a chance to think through the project without the overhead of having to change code every time you change your mind about how something should be organized or what should be included in the Public API. Remember that feeling when you first started writing automated code tests and realized that you caught all kinds of errors that would have otherwise snuck into your codebase? That’s the exact same feeling you’ll have if you write the Readme for your project before you write the actual code.

As a byproduct of writing a Readme in order to know what you need to implement, you’ll have a very nice piece of documentation sitting in front of you. You’ll also find that it’s much easier to write this document at the beginning of the project when your excitement and motivation are at their highest. Retroactively writing a Readme is an absolute drag, and you’re sure to miss all kinds of important details when you do so.

If you’re working with a team of developers you get even more mileage out of your Readme. If everyone else on the team has access to this information before you’ve completed the project, then they can confidently start work on other projects that will interface with your code. Without any sort of defined interface, you have to code in serial or face reimplementing large portions of code.

It’s a lot simpler to have a discussion based on something written down. It’s easy to talk endlessly and in circles about a problem if nothing is ever put to text. The simple act of writing down a proposed solution means everyone has a concrete idea that can be argued about and iterated upon.

Consider the process of writing the Readme for your project as the true act of creation. This is where all your brilliant ideas should be expressed. This document should stand on its own as a testament to your creativity and expressiveness. The Readme should be the single most important document in your codebase; writing it first is the proper thing to do.

HTML5 splits into two standards

Just when web developers got a little bit of hope, Slashdot reports on the bad news.

Until now the two standards bodies working on HTML5 (WHATWG and W3C ) have cooperated. An announcement by WHATWG makes it clear that this is no longer true. WHATWG is going to work on a living standard for HTML which will continue to evolve as more technologies are added. W3C is going the traditional and much more time consuming route of creating a traditional standard which WHATWG refers to as a ‘snapshot’ of their living standard. Of course now being free of W3C’s slower methods WHATWG can accelerate the pace of introducing new technologies to HTML5. Whatever happens, the future has just become more complicated — now you have to ask yourself ‘Which HTML5?’

Even if it sounds good, it is actually really bad. HTML5 is already complicated enough, and all major browsers support a different subset of it, and even those things which are supported do differ in the way of how. Splitting the standard just complicated things further. The fact that this is not exactly new, doesn’t really matter. Saying that it won’t be harmful, is silly. As is the whole point of a “living standard”. Like a few people mentioned in Slashdot comments, “living standard” is an oxymoron. The whole point of standard is to provide a static point of reference. Splitting is not a solution to the problem. It’s quite the opposite. Consider this xkcd comics for illustration, which is nothing but the truth.

SL4A – scripting layer for Android

Scripting Layer for Android (SL4A) brings scripting languages to Android by allowing you to edit and execute scripts and interactive interpreters directly on the Android device. These scripts have access to many of the APIs available to full-fledged Android applications, but with a greatly simplified interface that makes it easy to get things done.

Scripts can be run interactively in a terminal, in the background, or via Locale. Python, Perl, JRuby, Lua, BeanShell, JavaScript, Tcl, and shell are currently supported, and we’re planning to add more.

Adobe PhoneGap 2.0 Released

We’re excited to announce the following major new features in PhoneGap 2.0:

Cordova WebView – This allows for the integration of PhoneGap, as a view fragment, into a bigger native application.

Command Line Tooling (CLI) (Android, iOS and BlackBerry) – CLI tooling brings a standard nomenclature to common tasks across platforms such as project creation, debugging, and emulation. Normally, these are different incantations for each platform vendor making cross platform development workflow inconsistent and jarring; we’ve fixed that.

Enhanced documentation – Getting-started guides, plugins, migration guides and more to help accelerate the development of mobile applications and make it even easier.

Web Inspector Remote (Weinre) ported to nodejs – The availability of a node module means easy installation using Node Package Manager (NPM).

Cordovajs (Support for unified Javascript across platforms) – We’ve seen dramatic advancements to performance, security, and API symmetry across platforms thanks to the herculean effort of unifying our JS layer.

Transition to Apache Cordova and nearing graduation from incubation

Windows Phone support

Improvement to iOS app creation – We’ve implemented significant changes for the iOS platform. Get a deeper dive into all the changes from Shaz, our PhoneGap iOS lead developer.