rc3.org

Strong opinions, weakly held

Month: April 2008 (page 3 of 4)

Links for April 14

Best $50 I ever spent

Last year Anil Dash participated in the Donors Choose bloggers challenge. I had heard of Donors Choose before but I had never donated. I wound up donating $50 to help a band class somewhere buy a new tenor saxophone.

After going through the experience of finding a grantee and making my donation, Donors Choose was my new favorite charity. I wound up giving Donors Choose gift certificates as Christmas presents, and making a couple more donations on my own.

Last week, I came home from work one day and found an envelope in my mail box from Donors Choose. It contained a thank you letter from the teacher who requested a grant, photos of the kids in her class, and individual hand written thank you notes from kids in the class as well. It also included an itemized breakdown of how the grant was used.

I already loved Donors Choose before getting the package in the mail, but I was completely overwhelmed afterward. If you have a chance, give Donors Choose a try. You won’t regret it.

Links for April 13

Links for April 9

Links for April 8

Analyzing Git

Evaluating tools is sort of like judging art. The two questions you should have about a work of art are, “Do I like it?” and “Is it important?” They’re completely separate. You may not enjoy the music of The Beatles, but that doesn’t change the fact that they were hugely important in the evolution of popular music.

When I’m looking at tools, I try to keep both of those questions in mind. I don’t care for Enterprise Java Beans, but it was important for me to know what they’re used for and why they’re important. Git, the distributed version control application, has been getting a lot of attention lately. I haven’t had a chance to take much of a look at it myself, and I’ve been wondering whether I would like using it. The excess hype has awakened my inner skeptic, but I’m still very curious.

In the meantime, Ryan Tomayko has written an outstanding piece of analysis that answers both my questions. It explains why developers might enjoy using Git, and its significance. What’s important about Git is that it allows you to adapt your version control usage to your working style rather than adapting your work style to Subversion or whatever system you use, in that it allows you to manage exactly which changes you check in at any time, including multiple changes to a single file. Ryan explains how this works by describing the “Tangled Working Copy” problem and how you go about solving it in Subversion and Git.

I never run into Ryan’s “Tangled Working Copy” problem because I have adapted myself to be a creature of Subversion. I am always very mindful of what’s in the current change list and when I want to commit it. But I shouldn’t have to work that way, and it’s very cool that Git lets you escape that model. It seems that’s the important thing about Git.

I wanted to flag Ryan’s article not just because it demystifies some of the Git hype for those of us who are still using Subversion, but also because it represents what blog posts that purport to provide analysis should aspire to.

Links for April 7

  • Scott Horton: Worst. President. Ever. What interests me most about the list is that every President other than Bush (43) who could be described as the worst ever was a single termer. Bush’s main competition, Millard Fillmore, was not elected in the first place (he took over for Zachary Taylor, who died after 16 months in office) and did not receive his party’s nomination when his term expired. With Bush, we’ve had two terms and the Republican nominee wants to continue all of his worst policies.
  • Bruce Schneier: The Liquid Bomb. Some details of the liquid bomb plot are revealed. Could the plan have actually worked? Based on an extremely interesting stream of comments, I’d say that the particular plans hatched by the would-be terrorists could not have worked in a million years (they didn’t even test the explosives they planned to use), but that the general plan could have potentially worked (maybe) in the hands of terrorist masterminds.
  • The College Board has eliminated one of the advanced placement tests for Computer Science. There are two exams, and the more difficult of the two is to be discontinued. Unsurprisingly, Wikipedia has a lengthy article that describes the composition of both exams.

My rules of thumb for developers: less code

I was discussing basic coding philosophy today and realized that I have a few rules of thumb that I bring to my programming. I guess you’d call them a basic sensibility of how to write code. The four big rules are:

  1. Write less code.
  2. Use less indentation.
  3. Write more methods.
  4. Externalize everything.

I’ll write separate posts for each of these rules, starting with this one.

The “less code” movement has gained a lot of attention over the years, mainly with people migrating to scripting languages (like Ruby and Python) from Java. Using languages that encourage concise coding is helpful, but you can adopt less code as a philosophy regardless of the language you use.

Why less code? When I talk about my work as a programmer, I put it in two categories–problem solving and typing. I want to spend as little time as possible on the typing so that I can spend more time on the interesting stuff. Nothing agitates me more than starting a new project that’s going to require lots and lots of typing with very little problem solving. I consider less code to be an absolute good in this regard. Less code means less typing.

The second reason for “less code” is that it means there’s less code to maintain. I spend a pretty fair percentage of my time explaining why code works the way it does to other people. The more code I have to slog through to answer questions, the more time I spend on the answering. The ideal application would consist of nothing but clear, simple business logic. Declarations, error handling, database infrastructure, logging statements, and network code are required to make the computer work correctly, but in most applications they tend not to be very interesting. Less code of this type is always good. If you can make your application better by spending time on this stuff, do so, but usually there’s no reason to write it and maintain it yourself.

Here are some general approaches that can enable you to avoid writing code you don’t need.

Use Economical Code Constructs

The first is to use the most concise language constructs you can. For example, you can take Java code that looks like this:

Iterator it = someCollection.iterator();
while (it.hasNext()) {
    String foo = (String)it.next();
}

into a block like this:

for (Iterator<String> it = someCollection.iterator(); it.hasNext();) {
    String foo = it.next();
}

That saves you a line of code and a bit of pollution in your local namespace. If you’re using Java 5 you can write even less code:

for (String foo : someCollection) {
    // Do stuff
}

Using the enhanced “for” loop saves you lines of code and leaves you with less namespace pollution and more readable code. This example isn’t very exciting, but it’s the sort of economizing you ought to be doing.

Avoid Redundancy

A second and more important way to write less code is to avoid redundancy. What I mean here is that if you’re using copy and paste when you’re editing code, there’s a very good chance that you’re doing something wrong. It’s almost always the case that rather than copy and pasting, you should be creating a new method and calling it from both places. Two classes that are mostly the same should probably extend the same base class. In cases where subclassing is not the right answer, you should be using composition to share functionality among classes rather than duplicating code.

Obviously code duplication means you have more code, but it also makes your applications much more likely to contain hard to find bugs. When those two methods that do the same thing get out of sync, problems are almost certain to ensue. It’s funny that DBAs understand this incredibly well but many programmers do not. The entire point of database normalization is to avoid storing the same piece of information in more than one place. Programmers should adopt this philosophy as well.

As an example, one of the danger areas for code repetition is in input validation. Redundancy often occurs because validation code is written in two different languages–JavaScript and whatever is used for back end code. I oftentimes find the same redundancy within back end code. The Web layer has one implementation of validation, and there’s also lower level validation that takes place in the business layer. “What describes a valid instance of this object?” is a question that, ideally, will only be answered once.

Pick Your Libraries Wisely

It’s perfectly reasonable to choose libraries in part based on how little code they force you to write. One compelling reason to use Spring (a Java dependency injection library) is that it enables you to avoid writing lots of code that does nothing more than wire your objects together. One of the most compelling advantages of jQuery among JavaScript libraries is that lets you get a whole lot done in a very small amount of code.

This is also the primary advantage of persistence frameworks like Hibernate. They eliminate the need to write code to manage database connections, construct prepared statements and do all of the other database-related chores that lead to more code in an application.

Enabling you to do more with less isn’t the only reason to pick a library, but it’s a big reason to choose one library over another.

Some Other Tips

  1. If you use version control, quit commenting stuff out, instead just delete it. I’m talking about that method you commented out six months ago. Get rid of it. You have a copy in version control and it’s just taking up space.
  2. If you’re a Java programmer, your IDE will probably warn you if you have a variable or a method that’s not referenced by anything. Either that’s a bug or there’s some code you can get rid of.

There’s a whole additional article to be written on this same topic about JavaScript, CSS, and HTML and how you can use them together to produce less code. I’m not sure I’m the best person to write it, though.

Links for April 6

  • Daring Fireball: Firefox 3 vs. Safari 3. The main sense I get from this review is that I could be getting more out of my Mac.
  • Jason Kottke: Getting into Momofuku Ko. How this small but incredibly popular New York restaurant handles reservations using a Web application. It sounds like the basic model works like Ticketmaster.

There would have been more links in this post, but I’m too old for dangerous sweatshop blogging. Also, people get paid to do this?

Links for April 3rd

Older posts Newer posts

© 2017 rc3.org

Theme by Anders NorenUp ↑