obfuscated.org

I’ve never been a huge Philip Greenspun fanboy, but anybody who disses Java and SUV’s in one fell swoop deserves a link. Yeah, the quotes is as old as the hills (2003), but it’s new to me. And now I’m subjecting you to it, probably again.

A project done in Java will cost 5 times as much, take twice as long, and be harder to maintain than a project done in a scripting language such as PHP or Perl. People who are serious about getting the job done on time and under budget will use tools such as Visual Basic (controlled all the machines that decoded the human genome). But the programmers and managers using Java will feel good about themselves because they are using a tool that, in theory, has a lot of power for handling problems of tremendous complexity. Just like the suburbanite who drives his SUV to the 7-11 on a paved road but feels good because in theory he could climb a 45-degree dirt slope. If a programmer is attacking a truly difficult problem he or she will generally have to use a language with systems programming and dynamic type extension capability, such as Lisp. This corresponds to the situation in which my friend, the proud owner of an original-style Hummer, got stuck in the sand on his first off-road excursion; an SUV can’t handle a true off-road adventure for which a tracked vehicle is required.

I experience this first hand every day. All the Java code I work with could be done just as well if not better in maybe 1/10^th as much code in any of the much-maligned “scripting” languages. Plus it would be easier to test and maintain. What does the “strength” of Java buy? Nothing.

When I put a new hard drive in my computer, I decided to reinstall the operating system and install applications and data from scratch. Unfortunately, I had a small mishap and accidentally imported two copies of my iTunes library. Removing duplicates by hand would have been possible, but it would have been tedious as well. Mercifully, I stumbled on to RBOSA, so I was able to let the computer do it.

RBOSA is basically Applescript for people who never got around to learning Applescript. The interface to things like iTunes is very simple, so it didn’t really take a lot of work to get something to find duplicates up and running.

The strategy I used was to look at songs in the main library (the method I used for finding the “main library” looks kind of suspect, but it worked. Use caution if you try this at home) and put all duplicates in to a new playlist. Once they were there, I was able to check them over to make sure that they were dups and delete them.

Now, if you’re playing the home game and you know the secret trick for finding and deleting large groups of duplicates (around 8,500 tracks in this case) without busting out the programming: please tell me. I’m pretty sure that I’ll need to do this again at some point, and I’m all about doing things the easy way.

Follows is the script. I used Ruby 1.8.6 and RubyOSA 0.3.0.1 (installed via gem.)

require 'rubygems'
require 'rbosa'

itunes = OSA.app 'iTunes'

dups = itunes.make OSA::ITunes::Playlist
dups.name = 'Duplicate Tracks'

class OSA::ITunes::Track
  def eql?(o)
    artist == o.artist &&
      album == o.album &&
      track_number == o.track_number &&
      name == o.name &&
      time == o.time
  end
  def hash
    to_s.hash
  end
  def to_s
    "#{artist}/#{album}/#{track_number}/#{name}/#{time}"
  end
end

seen = Hash.new
itunes.sources[0].playlists[0].tracks.each do |track|
  seen[track] ||= Array.new
  seen[track] << track
end

seen.values.each do |tracks|
  if 1 < tracks.length
    # Keep the file with the largest bitrate.
    tracks = tracks.sort { |a,b| b.bit_rate <=> a.bit_rate }
    keep, rest = tracks[0], tracks[1..-1]
    rest.each { |t| t.duplicate dups }
  end
end

So I’ve got this XSD file that describes some data that I need to generate. This pleases me. Having a schema is always Martha Stewart. However: Damn do I hate reading XML. I don’t know why those Java people get in to it quite so much.

So what I want to know is this: Has anybody written a tool that will go from XSD to something BNF-ish and back again? I would love to be able to edit (or even just read!) a grammar in a way that makes sense (i.e., not XML) but still have the computer be able to easily do its thing with the XSD file.

A project I’m working on using Ruby has a bunch of functions that are usually run in groups but from time to time will need to be run individually. My initial solution to this problem was to create a whole mess of shell scripts to run the individual pieces. However, that looked like it was going to require a lot of typing, and I don’t much like to type.

Faced with actual work, I remembered the Rails console. This struck me as the ideal solution. It does command completion, so I wouldn’t have to remember the specifics of every little command. It turns out that the console is nothing more than irb with a few flags. Specifically:

 irb -r irb/completion --simple-prompt

Given this, I created a file with shortcuts for the pieces of code that I would want to run:

 #
 # shortcuts.rb
 #
 require 'project/important_stuff'
 require 'project/other_stuff'

 def do_thing_a
    ...
 end

 def do_thing_b
    ...
 end

 def something_else
    ...
 end

 def whatever_more
    ...
 end

And created a shell script to wrap the whole thing up:

 #!/bin/sh
 #
 # console.sh
 #
 exec irb -r irb/completion -r shortcuts --simple-prompt "$@"

So now I can run “console.sh” and type things like “do<tab>a” or “wh<tab>” and have an easy way to run my code. This pleases me.

Dear software developers everywhere,

If your code is in a version control system, you can go ahead and delete those old bits of code that you would comment out otherwise. I’m talking about things like this:

// BUFFER_SIZE = 1024;
// BUFFER_SIZE = 2048;
// BUFFER_SIZE = 4096;
BUFFER_SIZE = 8192;

That’s what version control is for.

Good day.

Because I have a little mind and I need my hobgoblins, I’ve created a service_mongrel_rails Wigwam package. The wiki writeup of it is super-incomplete for the time being, but it should be useful if you already know wigwam and you want to play around with ruby on rails. Some time soon I’ll do a more complete writeup and try to address some of the questions that I have about this setup, including but not limited to “Why not just use Capistrano.” (I don’t currently have an answer for this better than “I know Wigwam and I don’t know Capistrano.”)

Once I’m satisfyed that these packages, you know, work, I’ll talk to the folks at Idealab and see about getting them in to the “official” package archive.

Lightbox, Thickbox, GreyBox and iBox all aim to provide modal dialogs and popovers for HTML/Javascript applications. The things you can do with HTML and Javascript amaze me more every day.

Scott Sehlhorst writes a rather fine article on strategies for testing software that’s difficult to test. Telling is that he leads with a Kent Beck quote: “If testing costs more than not testing then don’t do it.” This certainly goes contrary to the “test everything!” mantra that — usually correctly — goes around the software world. I think it’s important to consider that sometimes you just can’t test everything, but even then there are ways as described in the article to mitigate that.

Have you ever been on a project where the manager said something like, “I demand full testing coverage of the software. Our policy is zero tolerance. We won’t have bad quality on my watch.”?

What we struggle with here is the lack of appreciation for what it means to have “full coverage” or any other guarantee of a particular defect rate.

There are no absolutes in a sufficiently complex system–but that’s ok. There are statistics, confidence levels, and risk-management plans. As engineers and software developers, our brains are wired to deal with the expected, likely, and probable futures. We have to help our less-technical brethren understand these concepts–or at least put them in perspective.

It’s funny because it’s true.

JavaOne marches ever onwards. Yesterday was a pretty busy day. I had a huge block of classes in the afternoon, some interesting, some… otherwise.

Effective Java

Joshua Bloch from Google, who I gather writes a book called “Effective Java,” gave this one. It was fast paced, informative and in general a really good talk. He spent a lot of time on the various dangers of Java 1.5’s generics, delving deeply in to wildcard generics and their various ins, outs and what have you’s. Java’s generics always throw me off because they’re just different enough from C++’s templates to not quite make sense to me. This talk helped clear much of my confusion up, though.

EJB + AOP + NIH = Interceptors

At a bunch of the EJB 3.0 talks, “Interceptors” have been touted as the elegant solution for this, that and the other damn thing. Which, ok, fine. It’s good to have a way to solve a lot of different types of problems. I applaud this.

Interceptors are basically Aspect Oriented Programming constructs. The fun part is that instead of just going out and using one of the existing AOP frameworks, EJB built its own. Yeah yeah yeah, EJB is a big and complicated environment and you probably couldn’t just throw J-random AOP tools in there to make it all happen and you need to be able to make it work elegantly with all their different deployment techniques. Whatevers. This is why I try to stay away from EJB.

Also, memo to presenter: “Aspectizing” isn’t a word.

Groovy

I totally misread the abstract for this one and thought it was going to focus on porting scripting languages to the JVM. Turns out that Groovy is an entirely new — well, relatively new at three years old — scripting environment running natively on the JVM.

This really put me out at first and still sort of does. There are plenty of good scripting languages out there and people are pretty good at using them. Why write another one? Their reasoning was that they wanted something that would work like Java, make sense to Java developers, and play real real nice with existing Java code.

I was skeptical until I saw the demo. In maybe fifteen lines of code, the presented fired up an ActiveX proxy, fiddled around with an Excel spreadsheet, and created an admittedly small Swing GUI to control it. This is all stuff that you could do with regular Java, but it would take dozens and dozens of lines of code.

The Groovy folks have done really nice work using Java reflection to implement a Do What I Mean idiom — for example, you can pass a list of two integers to a window constructor, and it will figure out that the window has a constructor that takes a Dimension which has a constructor that takes two integers. Good stuff — that could make a lot of tedious tasks in Java not nearly as bad. This is definitely something that I need to look in to.

Lions and Tigers and more EJB, oh my!

I signed up for a bunch of EJB presentations because that’s one of the areas where I’m most behind. Holy shit was this a mistake. With the “Java Blueprint for the Simplified EE5 programming model,” they definitely started repeating themselves. I couldn’t take twenty minutes of this before I had to bail. Oh well.