Never write code in Java when a Perl script will do. Never write Perl when a simple shell script will do. Never write a shell script when a single shell command will do. When you’re programming, the relentless pursuit of simplicity nearly always serves you well.
The specifics of the lesson were that by using curl and cron you can successfully avoid the use of Quartz, Commons HttpClient, and LWP, along with a vast horde of other dependencies.
The New York Times has a long article on the Netflix prize and collaborative filtering. Very interesting to anyone who’s obsessed with collaborative filtering, as I am. What I found particularly interesting is that customers who pay Netflix but don’t regularly send back movies are bad for the company:
For Netflix, this is doubly important. Customers pay a flat monthly rate, generally $16.99 (although cheaper plans are available), to check out as many movies as they want. The problem with this business model is that new members often have a couple of dozen movies in mind that they want to see, but after that they’re not sure what to check out next, and their requests slow. And a customer paying $17 a month for only one movie every month or two is at risk of canceling his subscription; the plan makes financial sense, from a user’s point of view, only if you rent a lot of movies. (My wife and I once quit Netflix for precisely this reason.) Every time Hastings increases the quality of Cinematch even slightly, it keeps his customers active.
Even though Netflix spends less money shipping movies to them, those customers are at much greater risk of canceling their accounts. Making sure customer queues are full of things they are eager to see is important.
I also thought this was really interesting:
As the teams have grown better at predicting human preferences, the more incomprehensible their computer programs have become, even to their creators. Each team has lined up a gantlet of scores of algorithms, each one analyzing a slightly different correlation between movies and users. The upshot is that while the teams are producing ever-more-accurate recommendations, they cannot precisely explain how they’re doing this. Chris Volinsky admits that his team’s program has become a black box, its internal logic unknowable.
It reminds me of some work I’ve done in the past.
Microsoft stopped selling licenses for Windows 3.1 on November 1. It was originally released in March, 1992. Consider this a reminder to developers that the crappy code you’re writing today may go on to live for decades.
As an interesting side note, Windows 3.1 has been around longer than Raymond Chen has been at Microsoft.
I’m looking for a first selection for a book club for programmers. The two books I’m considering to start are Code Compete, the classic Steven McConnell book on software development, and The Pragmatic Programmer, by Andy Hunt and Dave Thomas.
Anyone have an opinion on which to choose? I’m looking for something that both experienced and relatively new programmers will enjoy and benefit from, and that isn’t language specific. Are there other books I should consider as well?
As a software developer, I love version control, and I love bug tracking systems. I honestly don’t know how anyone got any work done without them. I’ve got Subversion set up with a post-commit hook that reports my commits to FogBugz. This enables FogBugz to keep track of which code changes are associated with each issue. If, a year from now, I want to go back and see exactly which changes I made to fix a certain bug, FogBugz has that information. It’s really cool.
But, as usual, there’s a catch. I also use svnmerge to keep track of changes between branches. It makes it trivial to merge changes from the trunk to a release branch, or vice versa. When you merge changes from one branch to another, svnmerge makes a nice file with the descriptions of each change included in that merge so that you can use it as the log message when you commit the changes associated with the merge.
What I’ve just realized is that my post-commit hook is finding all the references to bugs in that message and updating each of the bugs in FogBugz with a link to the commit associated with the merge. This has two effects. One, it causes the commit to take a really, really long time. (The post-commit script calls FogBugz once for every bug reference in the commit message.) And the other is that now every bug referenced in the merge is going to have a link to this giant commit that’s not really associated with any of them.
Sometimes all of your brilliant individual ideas combine to produce a bad outcome. In the future I won’t be using the commit message that svnmerge provides.
Despite growing interest in other storage media, relational databases are still the dominant data storage medium for Web applications. Indeed, as SQLite and other databases that can be embedded in applications grow in popularity, we’re seeing the use of relational databases expand even further.
It seems to me, though, that actual knowledge of SQL seems to be falling. I blame this on the growing popularity of persistence frameworks that abstract the database away, allowing developers to interact without databases without writing much (or any) SQL. Ruby on Rails has ActiveRecord, Django has its own persistence components, and there are many ORM frameworks for Java that work very well. There are even a number of persistence frameworks for PHP. As developers come to rely on these frameworks, their SQL skills grow rusty. Many developers don’t even learn SQL in depth, period.
This is a big liability. Even if you don’t have to produce SQL to include in your application, you still need to know it to write ad hoc queries. Knowing SQL lets you write a single query to answer questions like, “What’s the average total for orders received from customers in Texas over each of the last six months?” I’ve seen developers try to take care of those kinds of questions by pulling back individual records and aggregating the results in code. They ought to be using SQL efficiently instead.
In the short term, the answer for me is that I’m going to be asking more SQL questions in interviews. If you’re a developer and you’re not incredibly comfortable with SQL, you should probably hit the books. The other thing I’d add is that languages and frameworks come and go, but SQL, CSS, HTML, and JavaScript are going to be with us for a long, long time. Any investment you make in those areas will certainly pay off.
Steve Yegge talks about touch typing in today’s rant. I’m linking to it only because it reminds me that I love to tell people that typing is the most valuable class I took at any level of education. I took one semester of typing in high school, and it was the best thing I ever did.
Most IDEs will format your code for you these days, making sure that your braces are always where you want them to be, and that everything is indented properly. Some will do even more for you. Eclipse provides save actions that will make sure that you always include braces around blocks, and even sort your methods and declarations for you.
How much control do you turn over to your editor? Lately I’ve been inclined to let the editor do as much as it can. Aside from aesthetics, I’ve decided that the single most important advantage offered by consistently formatted and organized code is high quality diffs when you’re reviewing your code history.
If you enforce the same formatting and organization on your code, theoretically the revision history for a file will contain only substantive changes. That provides real value as far as I’m concerned.
The only disadvantage I’ve found so far is that if you use save actions to organize your code and you save a file that has conflicts marked, the save action will make a huge hash of it. (Maybe Eclipse should have an option for disabling save actions when saving a file that has errors.) That’s easy to reverse, though, with an Undo.
Anyone else have an opinion on this? I’m finding myself wishing that I had a tool that does as good a job organizing and formatting Ruby code as Eclipse does with Java.
The other day we had an interesting discussion at work about when the overhead of using a framework is justified. Incorporating a framework into an application has costs in terms of performance and complexity. In this case, we have a few JavaScript features that we wind up using on most Web sites, and the question was whether or not to use jQuery to reimplement those features, or to just use some simple home grown scripts that we already had.
The argument against was that we already have scripts (even though they need some updates), and that the compressed jQuery file is still over 20 kilobytes. Plus it’s an additional dependency that could introduce conflict with other choices we make later on.
In the end, we wound up choosing to include jQuery, for a couple of reasons. The first is that it makes the framework responsible for most of the code that’s likely to require more maintenance due to browser inconsistencies. When Internet Explorer 8 is released or Firefox 3.1 comes out, jQuery contributors are likely to find most of the bugs and inconsistencies and release an update that fixes them. Even if I have to fix some of those bugs, I’ve found that the frameworks still save time. I had to fix an Internet Explorer 5 bug in Prototype once, and I didn’t find it that difficult, even though most of Prototype’s source looks like magic to me.
The second is that incorporating the framework lowers the bar for adding new features to the Web site. If jQuery is already available, the barrier to writing new features is much lower than it is when writing those features from scratch, and I don’t have to revisit the decision whether or not to add a framework at that point. It becomes a tougher decision when you already have non-framework code in place.
I’ve become a fan of using a framework from the start, especially if the framework adds at least some value to even simple tasks. For example, JavaScript frameworks like jQuery make almost everything you do a little bit simpler, from binding events to altering styles on the page. They may not save you much time in your initial efforts because you’re doing something simpler, but you’ll be prepared to reap more efficiency as you add features to the site in the future. And you’re then not forced to make a tougher decision about when to add the framework later (especially if it would require writing non-framework code).
There’s probably an economic argument to be made here about marginal costs. Adding a framework increases the fixed costs of an application in terms of time and complexity, although the simplest frameworks make these fixed costs almost negligible. There’s a cost involved with setting up the framework and learning enough about how it works to employ it effectively. However, the right framework will lower the marginal cost of new features.
My thought is that it’s almost always worth it to eat the fixed costs of using a well-chosen framework to gain the marginal cost benefits when writing new features.
© 2025 rc3.org
Theme by Anders Noren — Up ↑
Beware excessive abstractions
jQuery creator John Resig warns developers away from libraries that hide JavaScript behind other programming languages, and makes a great point about relying overly much on abstractions to make your life “easier”:
This is a problem I often run into with developers who rely on persistence/ORM frameworks. They’re great, but if you’re dealing with relational databases, you really need to know SQL. These frameworks make a nice supplement, but they’re no substitute.
Update: Be sure to read the comments for a well thought out counterpoint.