So, the "Ruby way" is to use underscores to delimit most identifiers, e.g. "add_months_to_date", as opposed to the Java camel-case way of "addMonthsToDate". This was initially something that irked me about Ruby, mostly because typing an underscore is kindof a pain (shift with the left hand and pinky with the other).

Now that I've started working, I've been reading a lot of code and realizing that code is more often read than written. Ultimately, camel case is a just lot harder to read (especially if you create meaningful method names like myself and my co-workers seem to do).

It's pretty hard to defend:

Date calculatePersonDataUsageHistoryStartDate() {}

def calculate_person_data_usage_history_start_date()
end

// Calculates the start date of the

// person's data usage history

time_ prsn_dt_uhst_st_dt(){}

This would never fly with Java (and, honestly, look a bit weird), but I'm no longer gonna curse the Ruby convention.

Though I'm no longer working for Gliffy, I'm excited to see that they updated their site with some of what I worked on! Awesome!

Specifically, I worked on the folder organization system that they added to replace the tagging system. This fell out of the API work that I did (which I'm assuming is in private beta right now, but I'm not sure). I also worked on a feature that, while painful as a developer, is my favorite new thing about Gliffy: the basic account no longer has a five-diagram limit! That means for free, you can create unlimited diagrams. The catch is that your diagrams are all public, but I think it's a great way to enhance the functionality while subversively getting their name out to more people.

Although RCov makes code coverage in Ruby dead simple, I wasn't sure how easy this would be to achieve with Java. The first free tool I found is called EMMA and it was surprisingly easy to setup, especially since the documentation isn't geared toward getting coverage during tests (but getting it during execution).

EMMA works by instrumenting the classfiles to analyze coverage. Although it can do just-in-time instrumentation, that didn't seem to work for recording coverage via TestNG. The offline instrumentation makes is pretty easy to use with anything. Basically, you want your ANT file to:

1. Compile your code
2. Use EMMA to instrument your classes to a different directory
3. Run your tests, using the instrumented classes first in your classpath
and passing a few system properties to your running code
4. Run EMMA's report generator on the output

Here's my test.xml I'm using in my fork of ImportScrubber that shows it all working together. All in all, it only took about 15 minutes to set up and debug. Of course, now, the tests that came with ImportScrubber provide almost no coverage, but that's another story....

So, I am finally employed and I didn't even have to settle. After a refreshingly protracted and detailed interview process, I'm finally schlepping myself to a job that I'm more or less excited about. That's saying something, since I've spent the last 8 months at home (6.5 of them working for Gliffy) in my perfect environment: waking up whenever, using my dual-monitor mac, Rudy close by. My first day was a net win, despite having to bring in my own computer, and overall I'm not complaining because I get to use a Mac at work thank GOD.

Pluses so far:

• Smart people I can have a conversation with
• Meaningful product (i.e. not another CRUD app for a government agency [not that there's anything wrong with it])
• Not only have they heard of javadoc, they use it!
• Database migrations!
• Clean looking code and tests that actually pass on a fresh checkout!
• No M$ exchange server or other shitbox mail system (they use Google Apps)
• Damn close to home; I should be biking in real soon
• Relaxed environment
• I'm one person away from a bonafide window with the shades open!

Negatives so far:

• Kinda noisy office (fortunately few people seem to have phones)
• Subversion (it looks like they aren't going nuts with branches, so git-svn should preserve my sanity in this regard)

On the fence so far:

• Maven - The only reason this isn't a negative is that it's better than the pile of shit ant script everyone else uses, and the build does work pretty painlessly.
• Spring - I haven't used Spring for anything real, and I can't say it gets me excited (nor have I ever thought it sounded all that great), but I'm optimistic about it. I figure if it, in fact, is great, I'm happy. If it sucks, I have fodder for ranting. It's a win/win. I do fear the XML situps tho.

While packaging my resume creator/formatter as a Ruby Gem, I noticed my command line parser was preventing my code from running. It has this hook that sets up an "auto run" sequence (your code just defines a main method):

def self.inherited(child_class)
  @@appname = caller[0][/.*:/][0..-2]
  @@child_class = child_class
  if @@appname == $0
    __set_auto_run
  end
end

Not feeling like overhauling the command line interface code and not being able to patch OptionParser, I opted instead to use the dangerous-sounding ruby feature of replacing the method with my own implementation:

class CommandLine::Application
  class << self
    alias old_inherited inherited

    def inherited(child_class)
      @@appname = caller[0][/.*:/][0..-2]
      @@child_class = child_class
      normalized_appname = @@appname.gsub(/^.*\//,"");
      normalized_dollar0 = $0.gsub(/^.*\//,"");
      if normalized_appname == normalized_dollar0
        __set_auto_run
      end
    end
  end
end

It's been a few weeks of job hunting and I haven't once had to make a decision that my post on interviewing would've helped resolve. The fact is, you get a feel almost immediately for a place, and the reasons you say "yes" or "no" have more to do with who you'll be working with than the number of monitors you get. Usually, a place that's using ancient COTS products has put up red flags far earlier in the process. And the jobs I get excited about have nothing to do with their use of Git.

Some lowlights:

• Left waiting for so long, I had to walk out of the interview in order to meet an appointment. The receptionist explained "Well, they have a lot of work to get done!" Good luck with getting it done.
• A guy giving a tech interview (for a J2EE position) couldn't understand how a Swing front-end to an EJB/JPA backend could possibly be called J2EE.
• Being asked a logic question and, as soon as I used the right word while thinking out loud (in this case "tree"), was cut off and we moved to the next question. After 10 minutes of this, he walked out without telling me anything about the company or job.
• Being offered a job after having No technical questions asked of me. Gee, who else is working there?
• Interviewing in a place where every single aspect of the work environment was crappier than the crappiest house I've ever lived. If I can afford a fresh coat of paint every few years, shouldn't some "global enterprise solution consulting firm" be able to swing it?
• A Java development shop using....Visual Source Safe. I think cp Foo.java Foo.java.bak might be better

• Being asked some challenging questions about concurrency and data structures. You may not ever have to implement a linked-list, but anyone should know it and when I'm asked, it's a definite plus that the people on the other end know what they are doing
• Being asked to write code. So far, exactly two positions have asked me write code in the interview. Thank god for them, or my faith would be shaken; seriously. I'm always very nervous when I'm applying for a job where I have to write code and no one seems to need any proof that I can do it. It makes me wonder who else is working there
• Solid explanations of the business or project. I used to think this was a no-brainer, but more often than not, I come away from a second interview with NO IDEA what I'd be doing if I took the job.

Criteria is only useful when you have to narrow down a lot of choices. I'd love to have so many great opportunities that I could just pick the one where I can develop on a Mac, or the one with the nicest office (all other things being equal). Sadly, that is not the case around here. It seems very few of my colleagues are being too particular, and I can't help wondering what effect it might have on, well, the world if clueless developers were not as employable as it seems they are.

• Subversion - Git is so much better in so many ways (it goes without saying that CVS should be allowed to die)
• JUnit - TestNG does all that JUnit does and more; what does JUnit even have to offer these days?
• Java 1.4 - Java without generics is just so much pain
• Java Web Frameworks - As far as I can tell, none of them adequately address one of the fundamental problems in web development, which is to simplify the creation of the UI.
• Ant - Ant has always been the world's worst build automation language; who creates a build tool without variables, loops and conditionals? We can do better (and Maven doesn't appear to be it)
• Checked exceptions - java.lang.Exception is possibly the worst class in the Java library; should never be caught nor thrown¹
• Misuses of XML - XML has a purpose, and it's not as a programming language or configuration file format. Any notion that XML is anything other than a binary format is misguided

¹API developers should be allowed to declare that they throw Exception to allow subclasses to throw whatever they want with impunity, however Throwable is the preferred thing to catch for catch-alls, and the entire exception mechanism in Java is woefully broken.

I haven't used a code coverage tool for Java, but in my spare time I've been working up some Ruby code (mostly to learn the language). I'm using Test Driven Development, which is slightly simpler with Ruby than with Java (mostly due to Ruby's interpreted nature).

I had heard about rcov and decided to give it a shot. Within literally 5 minutes I had it installed and a report showing my tests were not covering all my code! Amazing. I could then easily see exactly where I need to to test and, sure enough, found some bugs that would've gone unnoticed.

Even the best tool with Java would've required some painful ant tweaking (not to mention hopes and prayers that it worked with TestNG). I already cannot imagine writing tests without being able to view the coverage....

Sad to say, my time at Gliffy is at an end (:sniff:), so I'm heading back into the job pool. I was lucky to get some time in at Gliffy, because, living in Washington, DC, my opportunities for sexy cutting-edge jobs are about zilch. Instead, I'm facing a huge market of "Senior JBoss Portal Maintenance Archiect" type jobs.

I guess I should feel lucky that there's lots of positions out there, but I really don't want to be the cog in a huge machine. Gliffy has shielded me from the Horror That Can Be Consulting, so I need to keep my perspective in such trying times. So, calling on my experiences before Gliffy, I've made this handy rubric to make sure I explore all facets of a potential position.

I don't expect anyone to get all positives and no negatives (I've certainly never been anywhere that perfect), bit it's always good to know. For example, if I have to put up with PVCS, I better be sitting on an Aeron chair and be using a normalized database. Further, this is obviously in addition to standard questions regarding what the project is about (i.e. is it interesting) and what the people are like. A whole lot of this can be forgiven by being part of a great team or working on a really cool product.

What else am I missing?

Time and time again, users complain about an application crashing on them or otherwise not working. They don't provide you any info and it's hard to repeat. You check out the log, but there's thousands (or millions) of entries and you have no clue where their error occured. Worse, if you are deploying a RIA, the log may be on their computer and not available.

On my last project we experienced this scenario so much that we instituted two things

• All messages logged with Level.ERROR in log4j would be emailed to us
• All exceptions caught on the client would be packaged and sent back to the server and logged at Level.ERROR level (thus emailing them to us

At Gliffy, they are doing the same thing. Right now, we're testing a bunch of new features and the stage instance just sent me a bunch of emails, all indicating configuration problems, which is the exact kind of thing that can be hard to track down.

Setting it up using log4j is dead simple:

log4j.appender.mail=org.apache.log4j.net.SMTPAuthenticateAppender
log4j.appender.mail.SMTPHost=@SMTP_HOST@
log4j.appender.mail.UserName=@SMTP_USER@
log4j.appender.mail.Password=@SMTP_PASS@
log4j.appender.mail.Authenticate=true
log4j.appender.mail.From=errors@gliffy.com
log4j.appender.mail.To=@SMTP_LOGGER_FAILURE@
log4j.appender.mail.Subject=Errors from @SMTP_DESC@
log4j.appender.mail.BufferSize=1
log4j.appender.mail.Threshold=ERROR
log4j.appender.mail.LocationInfo=true 
log4j.appender.mail.layout=org.apache.log4j.PatternLayout 
log4j.appender.mail.layout.ConversionPattern=%d %p%n%t%n%c:%M:%L%n---%n%m%n---%n%n 

If you aren't doing this, you should be. Now.