Category Archives: Software Development

Posts about software development. Generally I use Java, PHP, and Python for development but occasionally I delve into other things as well.

Java, Software Development

Mac, you’ve got a friend in Java. Now be nice.

I have recently rediscovered the joy of programming in Java for desktop Applications. Mac OS X provides a perfect deployment system for Java applications since Java 1.6 comes standard, so you don’t have to worry about directing your users to download Java for your applications to work. What’s more, since your application is written in Java it can easily be adapted (and perhaps unchanged) to run on Windows and Linux. So what is so great about Java:

  1. It is multi-threaded from the ground up.

Although threads can be used in many other programming languages, Java presents by far the cleanest and complete implementation I have ever come across. The language is built for threads at its very core with locking and monitor capability on any object.

  1. Namespaces and packaging

Between Java’s rich namespace support and it’s native packaging JAR format Java allows you to build applications component by component with minimal hassle when it comes to putting the components together. Unlike interpreted languages like Ruby, Python, and PHP, you are able to build your sky-scraper of an application without worrying about the size of it affective the speed of it. When you’ve completed a library, you can package it up an wrap it in a bow and feel confident that this component will serve you well for many projects to come.

  1. Garbage Collection

Most of the time, honestly, I don’t want to have to worry about mundane details like deleting objects that are no longer being used. Garbage collection does add a bit of overhead to an application, but it is well worth it 99% of the time.

  1. Swing

Say what you will about Swing, but it still stands up as one of the most powerful and portable GUI toolkits available on any platform. With only a few lines of code you can have yourself a full-fledged application with the look and feel of the native operating system, and have it run on Mac, Windows, and Linux without the need for any form of recompiling. It gives you the building blocks that you need to have a rich application, and allows you to extend quite far also.

There have been some troubling trends over the past few years as they pertain to Java. New dynamic languages like Python and Ruby have gained a lot of attention at the expense of Java. Windows has stopped shipping with Java and the IPhone and IPad don’t support Java and likely never will. My website stats indicate that only about 85% of Windows user have Java installed – this is definitely less than 10 years ago when virtually all Windows machines were equipped with Java. If you do a Google search for “Java OS X” or “Java for Mac Desktop Apps” you’ll find a plethora of articles circa 2002. There is scarcely anyone talking about using Java on the Desktop in the past 3 years. Has everything worth writing been written, or is this just the writing on the wall.

I hope this does not foreshadow and end to the glory days of Java as a development platform on OS X. It would be tragic if, one day, Apple decided to leave Java out of the default install. That would force users to install Java before running any software dependent upon Java – which would make Java a much less attractive platform to develop on.

Software Development

Open Source Business Models

Looking at open source business models, it can be difficult to find something that looks viable. Here are a few models along with my assessment of their pros and cons.

1. Pay for support and Consulting

In this model you provide the software for free and open source, but charge for consulting and support.

Pros:

  • Easy model to understand – you just charge an hourly rate for consulting and support.

Cons:

  • Since you don’t get paid for the 90% of your time that you spend developing the software itself, you are forced to charge 1000% of your required hourly rate just to make ends meet.
  • You would be better off finding another open source project that someone else is sweating over and just charge for support on that one. Don’t waste your time developing anything new.
  • If you insist on this business model, you’ll be in direct competition with anyone else that wants to set up shop to do consulting on your software – and they can charge 10% of your price since they don’t have to spend time developing the software.
  • This only works when your software is something that people generally require support for. If your software is too well made, then people won’t need support or consulting.
  • Gives incentive to make software that is complicated and hard to work with .

Conclusion: This one’s a big loser.

2. Charge for add-ons

With this model your primary product is free and open source, but you charge for add-on modules.

Pros:

  • If you have a large user base this is a good way to give you a relative monopoly on the market for your add-on.

Cons:

  • The open source culture may resist attempts at monetization of this sort. Users of free software often resist or resent attempts to add pay software into the mix.
  • You must have a very large user base for the market to be big enough to support add-ons.

Conclusion:
This model has potential if done the right way.

3. Charge for Documentation/User Manuals

With this model you provide the software free and open source but you charge for access to the documentation. This model could work well for software that requires documentation to take advantage of (e.g. software frameworks, libraries, or complex systems that are managed by an administrator). In fact, in certain cases this has the same effect as charging for the software while keeping the software itself open and freely distributable per the spirit of FOSS.

This is because those people who are explicitly using your software and its features will need to purchase the documentation (so it’s kind of like purchasing a license for the software itself), but they can still freely distribute the software itself as part of their own projects (so it retains the basic freedoms that sit at the core of the FOSS movement).

Pros:

  • Could work well for technical projects or software components that rely heavily on documentation.
  • Acts like commercial software for revenue (1 documentation license per user).
  • Software remains freely distributable.

Cons:

  • Only works if the software is heavily dependent on documentation to use.
  • Gives incentive to create software that is difficult to figure out (non-intuitive).

Conclusion:
This is a good model for technical software.

4. Donation-ware

This is the model where you offer your software up for free and ask (beg) for donations. This is a ridiculous model. It is not even a model so it isn’t worth a pro-con matrix. There are no Pro’s. I am philosophically opposed to the concept of donation-ware. I am a software developer, not a charity. If someone feels compelled to donate money to a cause, there are thousands of good causes: Cancer, Haiti, etc.. But don’t donate it to a software developer (unless he’s creating software to cure cancer).

You will NOT make any money by asking for donations. At most you will make a few people feel good about themselves for donating a dollar or two.

5. Advertising

With this model you treat your software as a means to generate traffic to your website and you try to turn that traffic into money either through selling another product, or through sponsorships.

Unless you get a ton of traffic, this model likely won’t make you enough money to pay for your webhosting plan.

News, Software Development

Why the iPad will succeed / Why I’m excited about it as a Software Developer

To me (as a software developer), the most exciting thing about the iPad is the fact that it is integrated with the App Store. On the iPod and iPhone, the App store has proven to be a fantastic commercial success, opening a new distribution channel for software developers. There have been a few attempts to create similar type app stores for the desktop (or laptop), but none have been wildly successful. I think this is due to the culture. We are too used to downloading our software through the web browser – we don’t really see the need for an app store. If there was single app store for the desktop that allowed users to purchase /install software as easily as the iPhone app store does, I’m sure that the software industry would double or even triple in revenue in a short amount of time.

The iPad, being closely related to the iPod/iPhone in user interface makes it far more likely the at users will embrace its apps in the App store. This means that software developers who develop for the iPad will have an easy and automatic distribution channel for all of their works, where they can get paid in a simple and secure fashion. And the possibilities for application development on the iPad would appear to far exceed the possibilities of iPhone apps – nearing the level of desktop applications (or even beyond).

This simple fact is why developers will embrace the iPad. And when developers embrace a platform, historically, so too do users.

Software Development

@fido.ca vs @pcs.rogers.com

I was trying to set up server monitoring to send a text message to my cell phone when my server goes down. Since I’m on fido I first tried 0123456789@fido.ca (replace 0123456789 with my phone number), but found this to be terribly inconsistent. Sometimes I received the messages, but usually I didn’t. It didn’t seem to matter how long the messages were. This would not work.

So, since Fido is actually rogers now, I tried 0123456789@pcs.rogers.com, and found that this is very consistent. At first it prompted me to subscribe to the rogers email to sms service. Once I did that I was able to receive email. When an email comes in it tells me who it’s from. If I want to read it I reply back with the text “read”. Then it sends me the message.

This will work fine for now.

(Update an hour later some of the messages I sent to …@fido.ca are starting to trickle into my phone in no particular order….. obviously xxx@fido.ca is not a reliable way to send text messages to fido phones).

News, Software Development

Why piracy must be stopped

I wrote this in response to a number of “pro piracy” or “piracy rationalization” comments to a CNN article:
http://scitech.blogs.cnn.com/2009/04/20/a-turning-point-for-online-piracy

This appears to be a culture war, and one that is being lost – and will eventually cost us dearly. Many of these comments are consistent with my anecdotal experience with friends and acquaintances. People who are involved in theft, be it digital or material, always try to rationalize their behavior. Nobody actually believes that they are a bad person. I have known people who earn a living by stealing car stereos. Their justification will generally include such points as “insurance will pay for it – and big insurance companies deserve to be robbed..”, or “the guy who owns the car is obviously rich and can afford to get a new stereo”. Either way there is some justification or rationalization that allows the thief to sleep at night.

Digital piracy is no different. There seem to be many well-articulated arguments to justify digital piracy, but all seem to predicated on the assumption that since “stealing” digital content does not deprive the original owner the content, it isn’t really like stealing at all. You wouldn’t steal your friend’s car because then your friend would be without a car (and you would be without a friend). However if such a thing as a car replicator existed that allowed you to duplicate your friend’s car for free, then you probably wouldn’t think twice about “replicating” your friend’s car.

So for pirates who otherwise are not thieves, it seems to boil down to an internal rejection of the notion that digital piracy is, in fact, theft. Fair enough. It is different enough from material theft that we might as well distinguish it from material theft and give it a different name. So piracy is not “stealing” it is simply “piracy”.

Now that we have distinguished it, let’s look at some of the implications of piracy.

1. If a product is freely available via piracy, and in our culture, piracy is considered OK, then anyone who decides to “purchase” that product is really engaging in a form of charity because they believe in the cause of the product or the person who created it. This is why 10 years ago you thought it was OK to pay $20 for a DVD movie (because you were purchasing a product), but now you think that $20 is a rip-off, because you are now engaging in $20 or charity – more difficult to justify (people spend up to 10% of their income on charitable donations, and the other 90% on themselves – by the same formula you’d think that a pirate who likes a movie would be willing to donate $2 to the movie-maker, even though he would have been willing to purchase it from the movie maker for 10 times that).

2. Based on the economic assumption that people are inherently greedy, most people won’t choose to “purchase” a product when they can get it for free.

3. The marginal value of any product that can readily be pirated will approach zero.

4. At a value of zero the product is not worth making, so the supply of good digital products (e.g. music, movies, software, e-books) will also approach zero – you won’t be able to get them anymore.

If, as a culture, we want to preserve our rich climate of art and ideas, it is imperative that we address this issue. Simply lowering prices to reflect what “pirates” perceive as reasonable prices would result in artificially low prices (because a pirate’s perceived value of content is based on how much he would donate out of altruism, not how much the product should actually be worth to him). If we completely eliminated piracy, only then could we find out what a digital product is really worth. If prices are too high, people won’t pay them, and they will come down. If prices are too low so as to deter artists from producing product, then prices will go up until they reach equilibrium.

They cannot reach equilibrium as long as there is a free alternative to every digital product.

Attempts such as Apple’s DRM are certainly a step in the right direction, but have been met with much resistance from the “pirate” community, as they want the ability to copy anything that they buy freely. Unfortunately we’ve seen that people are not responsible enough to handle this privilege, so it is unrealistic to think that any solution without some form of DRM will solve our problem and produce a proper equilibrium.

Given the facts and the implications of those facts, it is imperative that we proceed with whatever reasonable acts are necessary to curtail piracy. It may not be stealing, but it is still bad for society.

Software Development, Xataface

Application Versioning & Synchronization with Xataface

2 Comments

One of the more annoying challenges involved with managing production web applications is keeping the development and production versions in sync. Verson control systems such as Subversion and CVS make this task trivial for source code and file system changes, but changes to the database schema between versions still need to be handled with care, as these changes fall outside the watch of any version control system.

For example, suppose I am running an application that stores user profile information, and I want to add a column to the “users” table to store the user’s postal code. I add the column to my development database but I don’t want to add it to the production database until I am finished with the rest of my changes.

The old way: Copy & Paste – text files

The old way managing these changes was to make the change in the development database, then copy and paste the SQL query that I used to perform the update into a text file. I would repeat this process for each change that I made. When it came time to move the changes to the production application, I would just execute these statements manually one by one on the production server.

The down-side of this approach is that it didn’t scale very well. It works OK if I only have one production installation and one development server. But what if I have dozens of production servers all running the same application, and perhaps running different versions. It would become cumbersome if not impossible to keep track of all of these changes and manually apply them across all installations.

The new way: Xataface Application Versioning

Xataface allows you to track the version of your application with a text file named version.txt stored in your application’s directory. This file should contain one line like with two numbers separated by a space:

1.0b1 345

This example means that the application version is 1.0b1, and that the build version is 345. The build version must be an integer that is incremented every time there is a change to the source code. It is used by Xataface to figure out whether the file system version matches the database version. A good practice is to just use the SVN revision number for the build version.

On every page request, Xataface checks the version.txt file to see what version of application is currently in the file system. It compares this with the version of the database. If the database version is lower, it will execute the necessary queries to update the database to the current version.

The conf/Installer.php file

Xataface looks for a class named conf_Installer located in your application’s conf/Installer.php file to find out what it needs to do to update between versions. You can define methods in this class of the form:


function update_##(){}

Where ## is the build number of the update.

Xataface will execute all functions update_XX() to update_YY() in your conf_Installer class automatically if it finds that the database version is XX and the filesystem version is YY. This is where you can place your database updates that need to be performed between versions.

For example, suppose the production server is running build version 345. That means that the version.txt file in your production server might look something like:

0.5.1 345

Now you want to add a postal_code column to the users table in the development version, so you’ll increment the version number on the development server:


0.5.2 346

And add a method to your conf/Installer.php file to perform the database change:

<?php
class conf_Installer {
  function update_346(){
    $sql[] = 'ALTER TABLE `users` ADD `postal_code` VARCHAR(32) AFTER `phone_number`';
    foreach ($sql as $q){
      mysql_query($q, df_db());
    }
  }
}

Then you can just update the source files to the production server using subversion. The first time you run the production app after updating the source files you’ll get a message saying that the application has been updated to version 346.

That’s all it takes. You just keep on adding these methods for each update. Then even if you have an instance that is a couple of versions behind, all you need to do is update to the latest source revisions, and it will automatically update the database to the correct version.