Archive for September, 2007
I see it time and time again in comparisons of software products where one or more of the options is open source. Someone chimes in with a comment along the lines of:
Why pay for product X when I can get open source Y for free?
My response to this is simple: X != Y. Price is a very primitive way to choose software. Differences in price, even when one price is zero, are often insignificant when compared to other factors. Unfortunately, these other factors aren’t so easily boiled down to a single number, so the lazy consumer does not pay them full heed.
If we could boil the other factors down to a single number, what would it look like? Well, allow me to present a gross simplification. Suppose you are a company comparing two tools: one open source, and a commercial alternative that costs $500/seat/year. The end goal of the both tools is to make the user more productive, i.e. to save them time. For argument’s sake, say the average user’s time costs the company $100,000/year. For the commercial software to be worth the cost, it needs to improve the user’s productivity (relative to the open source tool) by about 0.5% over all. Put another way, it needs to save the user around 12 minutes each week. This is a small ask, particularly if the tool is something the user relies on heavily to get their job done.
Sure, these numbers are pulled out of the air, but they are not that far removed from reality. Skilled workers can easily cost more than $100,000/year, and a heck of a lot of software is priced under $500/seat/year. The real point is that an increase in productivity is far more important than saving on licensing costs (except perhaps for software priced “by the enterprise, for the enterprise”).
There is also a sad flip side to this: open source has a whole lot more going for it than the price. Factors such as transparency, community and extensibility are usually far more important than saving a few dollars up front. Not to mention the fact that the most productive tool for you may be an open source alternative. By no means am I saying to avoid open source. But do yourself a favour: put in a bit more effort and make your choices for the right reasons.
Yes, I’m whining, but I can’t be the only person to notice that job ads are taking over the internet. More specifically, every tech news site seems to have its own job ads, including:
- Slashdot and related sites like Freshmeat, NewsForge etc
- Joel On Software
- DZone and related sites like Javalobby, EclipseZone etc
- Worse Than Failure (man, that new name sucks)
I guess the reason is that good people are hard to find, and our industry is no exception. I do wonder at the viability of these boards; it will be interesting to see if this spreads even further. Are the advantages of a centralised board offset by the differentiating factors offered by each site (in particular the ability to target a niche audience)? Perhaps a combination of the two ala the Google Adwords Content Network is our final destination?
Server applications can often benefit from exposing a remote API. Such an API enables users to both automate tasks and integrate with other systems. In the case of Pulse, we expose an XML-RPC remote API that allows remote control and monitoring of the Pulse server.
Apart from being a great feature, a remote API has another significant benefit: it enables us to control Pulse through a (relatively) fast interface during acceptance testing. The primary Pulse UI is accessed via a web browser. Although it is possible to automate web UI testing using tools such as JWebUnit and Selenium RC, the resulting tests are slow. Where we are not testing the web UI, or are testing only an isolated part of it, the overhead of driving the UI causes a huge blowout in testing time. This leads to slow builds: the enemy of continuous integration.
Thus, in many of our acceptance tests, a lot of the peripheral work such as setting up suitable data is done using the remote API. We also use the reporting functionality of the remote API to assert the current state of Pulse where possible. Tests only drive the web UI when they are testing the operation of the UI itself. The resulting tests are a lot quicker, enabling us to run our acceptance test suite more frequently. In Pulse 2.0, where the remote API has been extended to support full configuration, we are beginning to enjoy even faster acceptance tests.
So, if you are struggling with slow acceptance tests, consider adding a remote API to your application. As a bonus, your users get a great new feature!
I recently ran across this post advocating Python. This made me think about why I prefer Python over the rest of the scripting crowd. And I realised that there is just one key reason:
Python is easier to read
That’s it. For all the joys of programming in dynamically-typed languages, I think there is one major problem: in many ways these languages favour writers over readers. I covered one example of this problem back in my post on Duck Typing vs Readability. This is why it is so important that a dynamic language is designed with readability in mind.
In my opinion, Python really shines readability-wise. And this is no accident — if you follow design discussions about Python you will see that Guido is always concerned with code clarity. A feature is not worth adding just because it makes code more compact; it must make the code more concise. Features have even been removed from Python because they were seen to encourage compact but difficult to comprehend code (reduce being a classic example). Even controversial design choices like significant whitespace and the explicit use of “self” are actually good for readability.
The philosophy behind Python also extends beyond the language design. Clever tricks and one-liners are not encouraged by the community. Rather, the community aims for Pythonic code:
To be Pythonic is to use the Python constructs and datastructures with clean, readable idioms.
This is surely refreshing compared to the misguided boasting about how much can be crammed in to a few lines of [insert other scripting language]. Certainly, if I ever have to pick up and maintain another person’s dynamically-typed code, I hope it is Python. And since I know I will have to maintain my own code, when I go dynamic I always pick Python.
You are currently browsing the a little madness blog archives for September, 2007.