This Developer Hates Mobile

There’s a common misconception that mobile is the future of software development. Mobile, in this context, means a touchscreen device like your phone or tablet.

I’m not picking on this particular author — he is simply regurgitating a common assumption — but this is the type of sentiment I’m writing about:

The era of the laptop and personal computer will eventually come to an end, but not until they allow developers and power users to do everything they can on high-end devices as easily on mobile devices. Before this can happen professionals of all sorts, the power users of the various platforms will need as much memory and processing power as they are currently using. (Source: grack.com)

I disagree with this mindset, almost entirely.

I do agree that most software development will happen for mobile devices, but I do not believe that software development will be on mobile devices, at least for quite a while, if ever.

There are two types of users: creators and consumers. The creators among us are the ones who tinker, who take things apart, who build things “just because.” Their needs are entirely different from the consumers, who enjoy having things “just work,” and do not need to know (or want to know) how it does that. Simply, consider the difference between a person who watches a movie and a person who makes a movie.

The problems with being a creator on mobile platforms are not related to the amount of performance we can get from them. Indeed, some of the higher-end tablets are very fast and quite capable of handling software development (my field), at least from a hardware point-of-view. It’s not the performance of mobile hardware, it’s their draconian software licenses and their sick culture of walled gardens which prevent us creators from doing our work.

The number one issue holding software development back on mobile devices is the operating systems which they run. Android, iOS, BlackBerry, and Windows Phone, all require “rooting” before most of the software is even available to a developer. As a developer, I don’t want to work on a device that does not obey my commands, nor do I want to work on one that requires a hack in order to obey my commands. This sort of device might be great for your mom and dad to watch things on, but it’s certainly not designed for creators to build things on.

Right now, the ideal development machine is the one in which I use: a PC laptop, running Linux and Windows. It lets me build anything I want quickly and without hassle. I don’t have to deal with any sort of bogus license agreements or ask for permission to build software for it.

In Canada, cell phones are sold locked to a certain carrier. This means that before you can switch providers, you have to call and pay to have your phone unlocked. Who really owns the phone, then? Can you imagine having to do that for your car if you wanted to buy gasoline at Shell instead of Esso/Exxon? It’s outrageous and a huge overstepping of authority by cell phone providers.

The most exciting parts of building hardware or software come from the freedom to explore, to scratch your own itch, then share that solution with your friends, who will go on to use it and change it to scratch their own itches. Mobile is heading in the opposite direction: locking everything down to keep the technical bits hidden away, and the fun of creation along with it.

There is a place for consumers. After all, the market cap of consumers is many times that of creators. But the place for consumers cannot come at the expense of the place for creators. Maybe the two never meet? Would that be a problem? Is there a solution which solves both needs? Does there have to be?

Until things change course and mobile device manufacturers start selling devices with open and libre software set, including operating system, and offering sane license agreements, this creator will stick with his laptop and Linux + Windows, thank you very much.

Coffee and Code in Guelph

If you’re a developer looking for something to do on Tuesday nights, look no further: Coffee and Code has come to Guelph. We meet between 7:30pm and 9:30pm to network, discuss relevant programming topics, and get some work done. It’s a great opportunity to meet some like-minded individuals and work in a setting other than your usual lair. Bring your laptop and whatever else you’ll need to do your thing.

Cory Fowler began the Coffee and Code event in Guelph a few weeks ago and has been diligently building up some momentum with it. I think it’s been going for 5 weeks now. I started going on the third week.

Next meeting place: The Albion on Gordon St. Hopefully we’ll see you there!

Leaving for Michigan… Excited about Yahoo! BOSS.

Every year during the second week of July our family has a reunion in Michigan, USA. I’ll be gone for three days but I’ll have the laptop and wireless. While it’s unlikely there will be a blog post during that time it’s possible! (who can stay away from blogging when it’s so addictive, huh? Didn’t think so!).

In the mean time I’ve been given (along with the rest of the programmers around the world) a new nugget to chew on and that is Yahoo! BOSS. In a nutshell, their new API will allow you to retrieve their search results and practically let you do anything you want with them. Re-order them, put ads next to them and generate revenue, mix them with your own results, you name it. It’s really intriguing and it’s definitely ballsy.

I’ve been thinking about Yahoo!’s potential return on this investment… Why would they give away the one thing that’s made them who they are? Well first, by taking the lead they are doing a few things such as increasing their standing with developers around the world as a partner to have and to stick with, they might also be looking for Google to follow suit or come up with a comparable system (gotta love competition), and finally they might also be looking for startups and unique talent to pluck from when all us developers start really using this thing in unique and interesting ways.

Just think: Yahoo! has basically said “Here’s our search results. Show us what you think you can do with them.”

Pretty cool!!

Source Control – svn + ssh (subversion to the rescue!)

There comes a point in any developer’s life where he/she must work with one or more people on the same project. What’s the correct procedure? How is this done? There are a number of different ways. Some good, some bad.

The Bad: You may have a method in place where only one person can be working on a file at one time. You have to notify the other developers that the file is free when you’re done with it. They download the latest copy every time and so do you so as to not overwrite the work that was just completed.

Some of you may say “Well, why is this bad? We’ve done this for months! It’s worked out pretty well so far!” There are a number of different answers to this question, which I’m going to deal with right now.

This is a bad method because time is money and this method is much, much slower. What is a programmer to do while he or she is waiting for the file to be free for editing? Read blogs?

Time is money.

If the company had source control, both programmers could essentially be working on the same file at the same time. I say essentially because technically they both have their own versions of it and the source control program (Subversion is the one I would like to write about today) will merge their changes together intelligently. Oh wait, this isn’t good. Now you won’t have time to read my blog because you’ll be working!

The second reason the “one person, one file, one time” method is bad is because it’s extremely risky for accidentally deleting work and wasting hours of productivity. As a developer, you should be constantly using and building work methods that prevent failure at any level you are involved with.

How would you feel if you worked on a function for two hours, then because someone overwrote the file with their copy all your work was lost? The reverse is also true: How would you feel if when you saved your work you accidentally overwrote a day’s worth of work and changes?

Time is money. Again.

“But before you save your file you can make a backup of the original file!” I hear you saying, way in the back. Of course you could, but how far do you want to take that methodology? Will you remember every time? Will everyone who works on the project remember, every time? What if it’s a one-line fix? “Oh, I’ll just log in quickly and fix that typo.” and the like are sentences that run shivers down my spine when thinking about using this method.

So the person logs in and fixes the typo. Because it was a small fix, they never checked to see if anyone was working on the file. So now we’ve got two changes that need to be merged somehow. I’m sure that person will be wondering the next day why the typo has reappeared after you save your file!

Okay. So what’s the solution then, smarty-pants?

The good: The solution is source control. It’s not new. It’s been tested and proven multiple times in the computing industry and there are some big players that use it. There are a multitude of different kinds that do some different things, but to the layman the simplest way to look at it is to use a common source control program called Subversion. Everyone’s heard of it, a ton of people use it. Nerds of different flavors will tell you there are better ones out there, and that may be true, but Subversion works. For a lot of folks.

The concept is simple: A project is set up in the Subversion software. Two programmers “check out” (think of checking out at a grocery store) a copy of the project on their computer or development server and work completely independently.

Programmer “Jane” and “Jack” are both working on the same project. Jane is building a module not related to Jack but in a few cases they may modify the same files. That’s no cause for concern, deliberation, or communication. They happily keep on working until their particular task is complete.

Jane finishes first and “checks in” her work by “committing” her work to the Subversion server. Everything goes as planned and her work is then “committed” to the main project files. Jack finishes his work a few minutes later and attempts to check in his work. Uh-oh! Jack’s copy of the project is slightly out-of-date! No big deal, he issues the “svn update” command and all of the files Jane edited are updated on Jack’s computer. Any changes to the files that they both worked on are merged automatically.

After he has updated his copy of the project he commits his files and goes home for the day.

Wow! Sounds great. But what happens if Jack deletes parts of the source code that Jane edited?

This sort of thing is called a conflict. They’re pretty rare and in most cases you can resolve the conflict in a few minutes. When you edit a file that is marked “in conflict” by Subversion, it shows the added and removed portions. You can make adjustments based on which is correct and issue the “svn resolve” command to consider the issue resolved then commit the correct version.

Cool beans. How do I start?

First, you install Subversion on your server. Programmers will connect to this machine, “check out” a copy of the project, and begin work. In most cases, installing Subversion takes less than 10 minutes. You should check with your particular Operating System documentation to see how to install Subversion, but in Mandriva Linux you can do it through the command-line with this command (logged in as root):

# urpmi subversion

After installing Subversion, you will need to pick a spot on your hard drive where you want your project files to be located. For me, that’s almost always /home/svn. Change directory to your project directory and type:

# svnadmin create <projectname>

This will create a directory and place the important Subversion bits inside it for this all to function. Make sure the directory (and all subdirectories) are writeable by the group of users that will be working on the project by first first changing the ownership to a particular user and group with this command (run as root):

# chown -R user:devgroup <projectname>

This command makes the project directory and any directory inside of it owned by user and associated with the devgroup group. After this you will need to set the permissions on the directory so that the devgroup has read, write, and execute access to this directory. We do that by executing this command (run as root):

# chmod -R 775 <projectname>

Great! Our project is ready to roll. Note that this assumes you have ssh enabled on this server (very likely by in Linux, FreeBSD, and in fact most others *nix variants).

Next, we’ll need to check out a copy of our project. Stay tuned for that tutorial, coming soon!