My command line interface for Gliffy is relatively complete. It works pretty well, though the error handling isn't very clean. It's written in Ruby (RDoc here) and can be used as a Ruby client for Gliffy.

I decided on Ruby since that would be the most fun and didn't require learning a new programming language. I initially tried to make an ActiveRecord-style domain-based interface, but it was just too difficult and it was hard to see the real benefit. At the end of the day, I think integrating Gliffy into another application is a relatively simple thing, and a procedural interface would probably be the easiest way to do that. So, I modeled it after the PHP client library, more or less.

The command line interface uses the Ruby client library and provides just the basic functions I need:

> gliffy ls
321654 Some Diagram
987654 Some Other Diagram
> gliffy edit 321654
# Takes you to your browser to edit the diagram

I'm already feeling like providing access to the folders via the command line would be helpful (they are exposed in the Ruby client of course). Not sure how much the API will ultimately change (it's in private beta now), but hopefully not too much.

GitHub Pages (explained here) is yet another awesome feature of GitHub. You can publish, via git, arbitrary web content (even piping it through Jekyll for Textile markup and syntax highlighting). They have been keeping a tremendous momentum of late; introducing new features on a regular basis. I hope they keep it up. GitHub is, IMO, crushing SourceForge and Google Code in terms of simplicity, ease-of-use, and overall functionality.

Gliffy hooked me up with access to the private beta of their API (which I helped design and implement). I create a PHP client and experimental MediaWiki plugin to validate the API while working for them, and now I want to get something else going in my spare time.

My first thought was to make a Ruby client, because I think it would be fun and relatively easy. But, I have to admit that a Wordpress plugin would be more useful to me personally. That being said, A Trac extension would be useful at work, since we are using Trac (which is python based, and I can't say I'm too interestedin Python at the moment). I think if GitHub allowed git access to project wikis, it would be cool to allow easier integration of Gliffy diagrams to GitHub project wikis.

At any rate, I don't have tons of time outside of work, so I want it to be something easily achievable, and also something Chris and Clint are not likely to work on themselves....

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