Geek Smithology

October 22, 2005

MP3otW – Baby Got Back by Jonathan Coulter

Filed under: MP3 of the Week by Nathan @ 9:29 pm

By now it’s no secret that I am a sucker for covers that go in completely different directions than their originals. And while you could argue that it’s possible to get farther away from Sir Mix-A-Lot’s infamous ode to big butts (but it still takes a back seat to Spinal Tap’s Big Bottom) than the easy listening, almost folksy cover put down by nerdcore folk artist Jonathan Coulter, I have my doubts. I mean, c’mon – it’s got a banjo and background singers.

If you liked Nina Gordon’s Straight Outta Compton, I think you’ll dig this.

October 15, 2005

Not using an ORM tool? Leave the SQL in the code.

Filed under: Craft of Dev by Nathan @ 12:45 pm

Rick blogs about taking the property file Lysol to some repetitive code smells, and while I can dig on the HashSet idea (was he a Perl hacker in a previous life?), I’m not sold on putting the SQL into property files unless you’re using some kind of tool (or you are some kind of tool… just kidding. I haven’t been too cynical lately, so give me a break!)

Anyway, the reason I’m not sold is that in your classic DAO pattern, you will have two parts – a DAO interface and then an implementation of that interface. So let’s address Rick’s issues one by one with that in mind:

1) It is inflexible

It’s the exact opposite. By programming to the interface, you can reimplement it at any time. One could even think of the implementation as your properties file (I, of course, would not be that one.) There is nothing to gain by making the implementation “more” flexible by externalizing your SQL. How often do you think you’ll be able to meaningfully alter that query without changing at least a little bit of code?

2) The code is not abstract

I’m not exactly sure how externalizing the SQL makes the code more abstract. If you have a tool and you are making generic “persistence” calls, then I could (grudgingly) see the point. But if you need to know about bind vars or ResultSets or Statements, or hell, even that you are eventually calling SQL, the abstraction leaks through. On the other hand, if you program to a well defined contract (read: interface) it is very abstract.

3) It is not generic

Once again, I don’t think making your SQL calls go through a common wrapper makes your code generic in the way that the interface/implementation pair does. As long as all of your data access code uses interface references, you can switch from flat files to an Oracle database to an LDAP directory, all without changing anything other than your interface implemtation and a factory call (and that is something that would be worth externalizing) Also, having an interface makes your DAO layer a lot easier to mock for unit testing.

4) It obfuscates your code and it’s underlying logic

If you call a persistence method, you shouldn’t know anything about the underlying logic. You should just be calling a method like “getFoo(name)” without even knowing it’s persisted. On the other hand, if you’re in the implementation class, it’s obfuscation to not have the SQL in the class file. If you’re worried about performance, declare all of your PreparedStatement SQL as private static final and away you go.

And there is one dangerous piece of code in the blog entry that I want to make sure everyone steers away from, and that is this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
// Iterate through the Enumeration of keys.
while (preparedStatementsBundleKeys.hasMoreElements()) {
    // Each PreparedStatement has a name ...
    statementName = ((String)preparedStatementsBundleKeys.
        nextElement()).trim();


    // The value associated with the key will
    // be used to create a PreparedStatement.
    statementSQL = (preparedStatementsBundle.
        getString(statementName)).trim();


    // Prepare the PreparedStatement, and put
    // it into the HashMap along with its
    // statement name.
    statementsHashMap.put
        (statementName,
        conn.prepareStatement(statementSQL));
}

It’s that last bit that’s scary – that means you have to keep the connection you used to prepare that statement open for the life of the map, rather than properly scope it within the method (you know the old adage, you should be able to see the open and close statements for a resource on the same page.) What happens if somebody starts a transaction and doesn’t commit it. That is not a fun bug to track down. Trust me, I’ve had to.

In the end, if you’re using something like Hibernate or stored procedures, then go wild pretending that programmers don’t need to know SQL to be good web developers. But if your dev team is implementing the persistence layer, than please, please, leave the SQL in the code

October 13, 2005

When Obvious != Elegant, Trust Your Gut

Filed under: Craft of Dev by Nathan @ 8:40 pm

As I was working on pawnzilla (the Ruby chess game I’m currently working on as my hobby), I wanted to write a utility function that could tell me if a given square was white or black. Now, there was the ridiculously obvious solution of just using the board object:

1
c = board.squares[x][y].colour

But I wanted to have a class method that could be called independently of an initialized board object. So I sketched a small chessboard to look for patterns:

2               
1               
0               
  0 1 2

By taking a look at the coordinates I was quickly able to cobble together the following table:

row column colour
even even black
even odd white
odd even white
odd odd black

By simply following the pattern, here’s one of several equivalent implementations:

1
2
3
4
5
6
7
def get_colour(x, y)  
    if (y % 2) == 0
        ((x % 2) == 0) ? BLACK : WHITE
    else
        ((x % 2) == 0) ? WHITE : BLACK
    end
end

Now, I don’t know about you , but I don’t like the look of the two expressions in the if/else – it’s the exact same logic, only in reverse. It’s funtional, even efficient, but is it elegant? Not really. So I decided to look for some other patterns. One that struck me right away was the way the diagonals run on a chessboard. Start at any square, and every square on any of the four diagonals will be of the same colour. So how can we express that pattern as something we can program? Well, one way is to add up the x and y values for each square:

2  2   3   4 
1 1 2 3
0 0 1 2
  0 1 2

I’m sure it jumped out at you – all of the black squares contain even values and all of the white squares contain odd values. This leads to method 2:

1
2
3
def get_colour(x, y)
    (((x + y) & 1) == 0) ? BLACK : WHITE
end

Aaaaah. Now that’s elegant. It’s clean, concise, and efficient. It’s unrealistic to take every piece of code and polish it to perfection (you’d never release that way!), but sometimes as you read an obvious solution your gut tells you “That doesn’t quite look right, does it?”

Listen when this happens! Strong developers rely on intuition, so never be afraid to trust yours. Sure you’ll make mistakes, but overcoming them is how you get to be strong in the first place.

October 11, 2005

Why CVS commit messages suck

Filed under: Craft of Dev by Nathan @ 10:36 pm

You envisioned the perfect feature. You designed it with an astounding mix of elegance and innovation, and implemented it so cleanly, with illuminating comments and not a single superfluous line of code. Overwhelmed, you print the code just to admire its beauty.

Then you check it into CVS with a commit message of

1
latset revision

.

I understand the fact that many developers (some would say most, but that’s too scary for me to even contemplate) don’t use version control, by why do the ones that do write such crappy commit comments? It’s because they see it as a convenient place to put code, not as the invaluable resource it should be.

Next time you commit, don’t think of the comment as an annoying popup you have to dismiss as quickly as possible; think of how you would describe your change in the release notes for your next production build.

“But you can just get a diff”, you say? That’s naive and perhaps even ignorant. You know how comments in code should help give an overview, maybe explain the why instead of the how? Your CVS comments should act the same way – I should be able to browse the changelogs in FishEye and get an overview of what’s been going on. If I want some detail, I can drop in and check out a diff, but that should be at my discretion, not yours.

Commit messages are your chance to tell the world what you were thinking at the time you wrote your code. Are you sure you want to say

1
*** empty log message ***

?

October 9, 2005

Hockey Night in Canada

Filed under: Sports by Nathan @ 9:44 pm

The first post-lockout season started Wednesday, which means yesterday was the first episode of Hockey Night in Canada in a loooong time (Movie Night in Canada kinda sucked.) It was also my first look at the new NHL, and my friends, it looks sweet.

Montreal beat the Leafs 5-4 (hey Eskimo Bill, Sundin lasted what, seven minutes?) in the quick paced first game. The second game was another all Canadian affair – Vancouver @ Edmonton. It looked like Vancouver was gonna eke out a 3-2 win when Ohlund flipped the puck over the boards, getting a penalty in the process (this is one of the new rules.) Edmonton threw six guys out for the power play and managed to tie it up with 23 seconds left. Overtime solved nothing, so I got to see a shootout, something I was looking forward to. They cleaned the ice for the shootout so that the players had a good surface to make things happen. Edmonton won when Torres and Hemsky scored (while Naslund and Bertuzzi were stoned), putting an exclamation point on the new look.

The commentators made a good observation that unlike last year, when fans started streaming out of the building during overtimes, everybody stuck around to see the shootout. Maybe the NHL is onto something.

For what it’s worth, I think that the new two line pass, the bigger offensive zone, and the obstruction crackdown have made for a far more exciting game. There were a few penalties that would’ve been strategies last year, and I think the rule changes will keep the game exciting even if the referees get lax on obstruction later in the season.

I have to say, I’m really glad hockey’s back, and so far even I am finding it difficult to be cynical (unless I’m talking about the Flames – 1-2 and outscored 13-9 after three games — ouch.) Just taking a look at some of the scores last night (8-1, 7-6, 5-4) makes me really look forward to what’s coming. Death to the trap!

October 8, 2005

MP3otW – Do Not Go Gentle Into That Good Night by Dylan Thomas

Filed under: MP3 of the Week by Nathan @ 10:35 pm

(Editor’s Note — Yeah, I know; the MP3 of the week has become the MP3 of whenever Nathan feels like it. But I’ve been busy – last week I was at NFJS and the week before I was hanging out with the family. But I haven’t forgotten, and it’s back. I hope to do this every week, but it might end up being every second week. Sorry.)

When people ask me who my favourite poet is (admittedly, this happened infinitely more often when I was an English major than it has in my professional programming career), I almost always answer “Dylan.” Not Bob Dylan, but Dylan Thomas. I was first drawn to Mr. Thomas through one of the oddest poem titles I had ever seen in a book of classics: A Refusal To Mourn The Death, By Fire, Of A Child In London. I wasn’t sure what to think, but it was a touching ode to the authour’s inability to find adequate words to pay tribute to the death of a child (can anyone? This is heavy stuff, folks.)

Like so many artists, Dylan died young (before he was 40 – his last words were reportedly “I’ve had 18 straight whiskeys, I think that’s a record.”) So, going in a completely different direction, today’s MP3 is Dylan Thomas reading what is probably his most famous peom, Do Not Go Gentle Into That Good Night. Maybe it’s just me, but it doesn’t get much cooler than this.

Eskimo Bill Says… (5 in a series)

Filed under: Eskimo Bill by Nathan @ 12:32 am

…you aren’t a real geek unless you have a linux box.

October 7, 2005

N-Tiered sucks for high values of N

Filed under: Craft of Dev by Nathan @ 12:58 pm

Read this post over on the code monkey blog, and it reminded me of a conversation I had with the mayor of fuchietown. Code Monkey says the following:

Following a framework like this (tiered or layered — ed.) makes applications much easier to develop and support. Every object has it’s place and is easier to reuse. This also allows for easily adopting to new technologies. Since each tier does not know the implementation of the other, changing that implementation will only effect the tier being changed.

Now, I don’t want to sound like I’m spanking the code monkey here, because in some circles this is considered common wisdom. But there are trade offs that you have to consider.

Are these apps easier to develop? Sometimes. Are they easier to support? Naw.

Tiering is great for horizontal concerns (i.e. replacing your Oracle DAO implementation with a PostgreSQL DAO implementation), but a pain in the ass for vertical concerns. For example, let’s say that something in our controller needs to be modified to take another parameter into account. We’re agile, and as such didn’t think of every single parameter that we might want to pass, so we have to code it from scratch.

I have to modify the data interface, the data implementation, the business implementation, possibly the business interface, and the presentation, which could consist of multiple files. Add a BusinessDelegate to the mix and I could be editing more than 8 files just to add a parameter.

Not knocking the teired approach – I’ve used it, and if it’s done properly it works. But for the love of #{deity} don’t charge into every single project with your J2EE design patterns book and your 3 tiers or bust t-shirt, because there is no one true path of web application architecture.

Consider the problem, consider the alternatives, weigh the tradeoffs.

October 5, 2005

No Fluff Just Stuff – Calgary 2005

Filed under: Craft of Dev by Nathan @ 11:29 pm

I have been to the mountain. And the future of Java is…Ruby? Perhaps. One of the enduring themes from the Western Canada Java Symposium was that Java is becoming old and bloated (oh, sorry Sun – Java is mature) and is in need of a “rebirth.” There are hard to ignore the parallels to the birth of Java, a subject which people were more than willing to discuss.

Tell me if this sounds familiar “C++ is ten years old. It has become too complex and heavy, and will collapse under its own weight. Java is cleaner.” Well, assign that last sentence to

1
s

and run the following code (in Ruby[1], hardy-har-har) and you’ll get what people are saying now:

1
2
s[/Java/] = "Ruby"
s[/C\+{2}/] = "Java"

During the expert panel, most of the speakers had some interesting ideas (when they weren’t talking about Ruby, that is), including:

Pick 7 great people and ask them to develop the next big thing — Jason Hunter
Adopt the closet clause: don’t add anything without removing something else — Dave Thomas
Java needs to increase the capabilities of the JVM, not just bolt onto the language — Bruce Tate
Deprecate Java – Venkat Subramaniam (only half-jokingly)

First reaction: ouch. Second reaction: true, all true. Let’s fact it, when this many big thinkers in the Java space are converging on some other technology, you can’t ignore it. Java (or more specifically, J2EE) does feel heavyweight and bloated next to Ruby on Rails and there are powerful ideas that other languages, like C#, are adopting. Some people tried to comfort themselves with the “Java will always be around” argument, but hey COBOL will always be around, too. Do you want to be in that boat?

Java is definitely not 0xDEAD, but Ruby is a pretty sharp knife to keep in the block. But enough about greatly exagerated reports of the demise of Java: let me talk about the conference.

First, NFJS was an amazing show with amazing speakers that blew my mind.

Repeatedly.

A key reason I wanted to hit this show was that Dave Thomas was there, and he did not disappoint. My favorite bit of the show was when he sat down at my table for supper on the first night. I had a conversation with one of my heroes[2] about Agile and Ruby and how we need to shift focus away from writing code to adding value. On day two, I had him sign my copy of The Pragmatic Programmer. Pretty sweet.

I had another food moment when Jason Hunter. The conversation was about Sun and open source and Open Office – he was a supremely cool guy. I also chased Bruce Tate down the hall to discuss why the Java community would come up with Struts, a web framework with a heavy object model and scads of XML, while the Ruby community came up with Rails (startlingly elegant in its austerity, the presentation on Rails was a revelation). We basically came to the conclusion that it was because that’s how Sun was doing J2EE. While there are parts of Rails that would be difficult or impractical to replicate in Java, I see no reason why I should have to map a path /login.do to a class called LoginAction; can’t the framework take care of that? I’m sure there are going to be Rails clones for Java, by why did Ruby have to lay the track?

Dave Thomas gave a talk called Open Source Ecosystems where he discussed using some techniques from Open Source on commercial projects. I came away with 2 ideas that I’d love to see implemented at my company:

1) Have developers apply for projects, rather than just grabbing whoever’s on the bench and throwing them into the fray. I think that whis would create a greater sense of ownership and give a team a fighting chance at having a shared vision.
2) Don’t give devs write access to CVS on their first day – they earn it by passing through 3 or 4 code reviews without any significant defects (you are doing code reviews, right?)

Another favorite was Dave Thomas’ talk Herding Racehorses and Racing Sheep where he expressed one of my beliefs: outsourcing is good. If you’re sitting at your desk, waiting for your BA to throw a spec over the wall for you to code, you deserve to be outsourced. You must find ways to add value outside of just your coding skill, and then you’ll always have a job.

Venkat Subramaniam wowed the crowd with a demonstration of AspectJ in Action. I think that Aspects (and AOP) are an incredibly powerful new paradigm, on par with the introduction of Objects and OOP. In fact, Aspects are such an elegant solution to a certain class of problem, that they feel like they should be a first class concept (AspectJ even introduces a completely new syntax for them.) I’m excited to see the first language where Aspects are fully integrated from the start. In the meantime, I’ll keep AspectJ in mind while I’m developing.

Finally, Jason Hunter had two talks I really enjoyed: first was Forgotten Algorithms, where I learned all about skip lists, Boyer-Moore, incrememtal hashing, and the Google Page Rank algorithm. Second was Open Source from the Inside, where he talked about developing Tomcat, JDOM, and life in the Apache Foundation. He made a comment about how we were the truly hardcore crowd because we attended the last session on the last day, and I said “We heard Hunter brings beer to the last session.” Geek laughter was heard and I think Jason might seriously consider it the next time.

At any rate, it was a truly revolutionary experience. Not just the presentations, or talking to the presenters, but it was awesome to talk to other developers about what they’re doing and how they’re doing it. One of the best feelings is “I am not alone!” If the sessions and speakers look good next year, I am guaranteed to be there, and I can’t recommend it highly enough if you haven’t been.

[1] Here’s the Java for the Ruby-impaired

1
s = s.replaceAll("Java", "Ruby").replaceAll("C\\+{2}", "Java");

[2] Like every good dev I know, The Pragmatic Programmer is among my favorite books about the craft of programming

Powered by WordPress