David Rupp's Blog

clj-json breaks when running 'lein javac'

2011-12-10T18:24:00.006-07:00

I'm working on a potential patch to Mark McGranaghan's excellent clj-json library for converting Clojure data to JSON. Unfortunately, I can't test my changes right now, because of an incompatibility between Leiningen version 1.6.2 and clj-json version 0.4.3, which causes lein javac to throw an exception.

It looks like clj-json has a dev dependency on an old version of a lein-javac plugin for Leiningen, which itself depends on ant-launcher version 1.6.5. It also looks like modern lein is smart enough to use its built-in javac task in preference to the old plugin, but it gets tripped up on the old version of ant-launcher.jar. The specific exception is:

Exception in thread "main" java.lang.NoSuchMethodError: \
org.apache.tools.ant.launch.Locator.fromJarURI(Ljava/lang/String;)\
Ljava/lang/String; (NO_SOURCE_FILE:0)

I've submitted an issue on the clj-json project, but for now a simple workaround is to delete the dev dependency from clj-json's project.clj file, remove everything from its lib/ directory, and run lein deps to refresh dependencies.

Pro Tip: Fullscreen-ness of Apps Seems to be Sticky in Mac OS Lion

2011-11-13T16:58:00.002-07:00

I've had a lot of fun the past couple days working with the Terminal app in fullscreen mode. Having entered fullscreen, I can work without distraction, but I can also switch freely back to my desktop or other running apps. Best of all: when I quit Terminal and restart it, it automatically restarts in fullscreen mode. Good job, Apple!

Installing Java on AWS EC2 Instances with Pallet

2011-11-11T09:30:00.003-07:00

I have recently been spinning up a lot of t1.micro instances on Amazon's EC2 service. I'm deliberately using minimal / default images, and I need to install Java on them from scratch. There have been reports (and I have experienced myself) that the Java install process hangs indefinitely when installing either Oracle's JRE/JDK or OpenJDK on a t1.micro running Ubuntu. I have been able to install Java successfully by explicitly requiring a 64-bit version of the OS.

Here's how you can do that in your Pallet node-spec:

Starting an EC2 Instance with an Admin User Using Pallet

2011-10-25T17:35:00.002-06:00

At my new day job today, I learned the hard way that if you're using Pallet to create an EC2 instance, and you want to use its automated-admin-user crate (which authorizes the user running the crate to login on the new instance via SSH using your RSA key), you really *really* want to run that crate during the :bootstrap phase. Running during the :configure phase does not seem happy using my current configuration of Pallet version 0.6.4 and jclouds version 1.0.0. Here's the relevant Clojure snippet:

(require 'pallet.core)
(require 'pallet.phase)
(require 'pallet.crate.automated-admin-user)

(def server-spec
  (pallet.core/server-spec
   :node-spec node-spec
   :phases {:bootstrap (pallet.phase/phase-fn (pallet.crate.automated-admin-user/automated-admin-user))}))

P.S.: LonoCloud is hiring Clojure developers! Join us!

Implementing Continuations in iOS Using Blocks

2011-07-22T20:29:00.002-06:00

Came up with a neat use for blocks in iOS at my day job today: continuations!

Like this: I'm working on a native iOS app that occasionally shows data from a Rails website in a UIWebView. When it does so, it has to make sure the user of the iOS app is authenticated to the web app. This way we should never have to see the web app's login page in the native app, which has its own login screen.

Of course, all of this reeks of asynchronicity. Which usually means callbacks. Which usually means implementing one or twelve protocols. We've tried to encapsulate all of the authentication logic in a custom class that's used by the controller that presents the UIWebViews, but we've also recently come up with a need for multiple controllers, controlling multiple web views. And the code is already (ahem) not as attractive as it could be.

Our original workflow looks something like this:

* Render a UIWebView and invoke its loadRequest: method with some URL.
* Have the controller implement the UIWebViewDelegate protocol.
** In particular, implement webView:shouldStartLoadWithRequest:navigationType:.
** Ask the authenticator object if we need to refresh authentication.
*** If not, just load the request (happy path).
*** If so, tell the authenticator object to refresh authentication and return NO.
*** This may require collecting new authentication credentials from the user, which means another controller and view (and asynchronous request cycle) entirely.
*** It certainly requires a separate asynchronous call to the web app, to verify authentication and set the timeout for this session.
*** Oh yeah -- we need to have remembered the original request and restart it when the dust settles.
* Insanity ensues, in the form of delegates with delegates and very hard-to-follow callback trails and state management.

Enter: blocks.

With blocks we can streamline, thusly (starting with webView:shouldStartLoadWithRequest:...):

* Tell the authenticator object to make sure we're authenticated, passing in a block to execute once we are.
** This block closes over all the state we need to "do the next thing". It can refer to methods in the current controller and access the current controller's instance variables, even though it'll be executed by the authenticator object.
* If the authenticator decides we're already authenticated, it simply executes the block (the happy path).
* If we're not authenticated, but we already know our credentials, open a NSURLConnection to the web app, using the usual callbacks. When that connection finishes successfully, execute the block we were given from the original controller.
* If we're not authenticated and we need new credentials, push the login screen controller on the stack, passing *it* a block that does the NSURLConnection stuff, followed by executing the block from the original controller.
* The login controller presents a modal dialog, accepts the user's input for authentication credentials, then calls its block (the one passed from the previous step, which encapsulates "what to do next" at two levels).

When we can implement this strategy pervasively, every entity will simply ask its collaborators to do whatever they need to do, however they need to do it (including asynchronously), and know that once the task of e.g., login, is accomplished, whatever is supposed to happen next actually does.

This idea was inspired by Continuation Passing Style in compiler theory, in which every function is called with the data it needs to perform its own business, *plus* information about what to do next. When programs are expressed in this style, there is no recursion, no nesting of routines; there is only "do what you're supposed to do, then jump to the next thing". It's not a perfect analogy, but it has been surprisingly effective in making some pretty complex and ugly code easier to understand.

You're Going Down, Emacs!

2011-07-22T19:16:00.001-06:00

Time to get serious, yo:

[david@davids-MacBook-Air-3 ~]$ cat .aliases
alias vi='emacs'
alias vim='emacs'
alias nano='emacs'
alias mate='emacs'

iOS Pro Tip: Know Thine API!

2011-07-16T11:56:00.004-06:00

I was reading through some code at my current project (P.S.: ThoughtWorks is hiring! Contact me if you want to submit a résumé!), when a good old-fashioned C-style for loop caught my eye. You know the kind:

for (int i = 0; i < someArray.length; i++) {
  // do something with someArray[i]
}

It turns out that if someArray is an NSArray, there is API defined to help with this:

[someArray enumerateObjectsUsingBlock:^(id obj, NSUInteger idx, BOOL *stop) {
  // do something with obj
  // set stop to true if you want to skip the remaining objects for some reason
}];

Note: Yes, I'm aware that there is also syntax for this in Objective-C 2.0, in the form of fast enumeration. The code I was converting was specifically interested in returning the index of a particular object in the array, which is why I went with this form.

Anyway, further reading in the NSArray API led me to another fun method: indexOfObjectPassingTest. It also takes a block, which returns a boolean value indicating whether or not the current object passes the test. If it does, you get the index back and move on with your life. This turned out to be exactly what I needed to port the original bit of code to full modernity.

I also came across an example of code that was using NSString +stringWithFormat. It would create the original format string, conditionally modify it based on the presence of some optional data, then pass all available data in to format the final string. Something like this:

NSString *formatString = @"required: %@";
if (optionalData) {
  formatString = [formatString stringByAppendingString:@", optional: %@"];
}
NSString *result = [NSString stringWithFormat:formatString, requiredData, optionalData];

This seemed potentially error-prone to me; I didn't like the idea of always passing in the (potentially nil) optional data, even if I was convinced there would be no placeholder for it in the format string.

A quick read through the NSString class reference led to the instance method stringByAppendingFormat. This allowed for a workflow more like the following:

NSString *result = [NSString stringWithFormat:@"required: %@", requiredData];
if (optionalData) {
  result = [result stringByAppendingFormat:@", and optional:%@", optionalData];
}

This way I did not have to dance around getting the format string just right before populating it; I could tack on the extra bits on the fly, which just seems cleaner.

iOS Pro Tip: textFieldShouldClear

2011-07-03T17:51:00.006-06:00

If you're using UITextFieldDelegate to manage the state of a save button (e.g., to disable saving if a field is empty), you're probably implementing the textField:shouldChangeCharactersInRange:replacementString: delegate method and checking for the field being empty. This will handle the case where the user causes the text field to become empty by deleting all characters, or selecting and cutting them. In this case, you should probably also implement textFieldShouldClear:, to handle the case where the user clicks on the text field clear widget (if it exists). It turns out that action does not call the ...shouldChangeCharacters... callback.

Versioning Core Data Models and Unit Testing with Xcode 4

2011-06-27T15:53:00.013-06:00

Today at my day job I got to create a new version of a Core Data model. The Good News: automatic migration really does Just Work in the simple case of adding a new attribute (column) to an entity (table). The Bad News: Unit Tests do not necessarily automatically get the new version of the model.

For reference, I'm using Xcode 4.0.2, build 4A2002a. Also using Google Toolbox for Mac and OCMock for unit testing.

For some reason, my unit test target (we're using Google Toolbox for Mac and OCMock for unit testing) was originally set up with the following files targeted for various build phases:

Compile Sources: MyModel.xcdatamodel (the original version, underneath the .xcdatamodeld directory)
Copy Bundle Resources: no model

After creating the new version of the data model, we really want the .xcdatamodeld (the whole directory structure that knows about all versions) to be what gets compiled / bundled.

Compile Sources: MyModel.xcdatamodeld
Copy Bundle Resources: MyModel.xcdatamodeld

So I had to delete MyModel.xcdatamodel from the Compile Sources build phase and add MyModel.xcdatamodeld. The really weird thing was I could not get Xcode to add the file using the add dialog in the "Choose items to add" dialog that the plus sign brings up.

Note: to see the "Choose items to add" dialog I'm referring to in Xcode 4, do this:

Click on the Project name in the Project navigator
Click on a Target
Click on "Build Phases" at the top of the project info section
Expand the "Compile Sources" phase
Scroll to the bottom of "Compile Sources" and click on the "plus" sign (+)

Using this dialog, Xcode will allow you to select any of the .xcdatamodel files, but not the .xcdatamodeld. The only way I could get the .xcdatamodeld file in "Compile Sources" (and "Copy Bundle Resources") was by clicking on the file in the Project navigator and dragging it into the build phase. Then it worked like a charm.

One other bit of weirdness: A lot of blogs that talk about versioning Core Data models don't mention how to set the selected version in Xcode 4. To do this:

Select the .xcdatamodeld file in the Project navigator
Open the Utilities pane (in the upper right corner of Xcode; see image)

Select the current version from the Versioned Data Model section of the File Inspector (see image)

Final note: The app pictured in the images, TripCents, is not my current client's app; it's one of mine.

Mac Pro Tip: macerror

2011-06-23T17:14:00.002-06:00

Ran across an obscure error code working on an iOS app at my day job. It turns out there's a utility on the Mac that will give you a little more to go on than some random negative integer: simply run

macerror [error code]

to get a (slightly) more descriptive version. For instance, I was getting error code -25299 trying to add an entry to my app's keychain; macerror reports that as errKCDuplicateItem.

[app next]: TripCents is now in the iTunes store!

2011-06-23T16:46:00.006-06:00

My latest app, TripCents, is now available. It lets you store a collection of named trips and calculates the approximate cost of gas, given the distance for each trip, your car's estimated gas mileage, and the current local cost of gas. I wrote it to help me gauge how much to budget for gas each month, and also to educate my kids as to how much money we actually spend shuttling them around town.

I'm particularly happy about the chance this gave me to flex some new iOS developer muscles. Where TreadCalc was essentially a single-screen app with no persistence, TripCents uses CoreData for persistence, has actual multi-page navigation and editable forms, and it renders its views using custom UITableViewCells. It also offers a lot of opportunity for incremental improvements, such as adding the ability to use Google's APIs for geocoding and directions, and MapKit to render geocoded destinations nicely.

You can read more about TripCents on my RuppWorks, LLC website, or if you just can't wait you can go straight to the store.

Mac Pro Tip: Preferences .plist files

2011-06-03T15:15:00.003-06:00

I love my new MacBook Air 11". Used it for most of my flight from Atlanta to Chicago today (about 1.5 hours flying time), and for once didn't have to worry about the guy in front of me leaning his seat back all the way into my lap. Also had a reported ~5.5 hours of battery time left when I had to shut down. The only thing I would do differently next time is get maximum RAM (currently sporting 2GB versus a potential max of 4GB).

When I'm at home, I run the MB Air in clamshell mode connected to a 20" cinema display (old school, baby; that's how I roll). Works great, everything displays where it should in either mode.

Except ...

There's this one app, RSA SecurID, that I occasionally need to connect to ThoughtWorks' sites. And it is decidedly not smart about repositioning itself. I usually have it dragged down out of the way, to the bottom right corner of the cinema display, but today while traveling I found out it always stays off the screen, even without the cinema display connected. Exposé will show it to me when I switch to the app and Show Application Windows, but when I click on it, it zips back off to the (now non-existent) bottom right corner of the cinema display. Restarting does not help, nor does gathering windows nor detecting displays in the Displays settings panel.

Bummer.

So I had to resort to opening the .plist file for the app (located for me at ~/Library/Preferences/com.rsa.Software Token\Desktop.plist) and manually updating its two properties: LastXPosition and LastYPosition. Supposedly, .plist files can be edited with any text editor (e.g., TextEdit), but this one seems to be in some binary format; I ended up have to use Xcode's plist editor to be able to make my changes.

Further Pro Tip: Make sure to tab or click out each field that you've edited. If you just type your change in place and save, it will not take.

First App: TreadCalc!

2011-04-07T10:22:00.003-06:00

My first app for iPhone -- TreadCalc -- is live in the iTunes store! It's a little utility I developed for when I have to run on a treadmill and want to know what speed to set to run a given distance in a given time. There are other apps in the store that do this, of course, but I think mine is the only one that does it all on one screen -- no settings, no info; nothing but you, a few buttons (for switching between miles, kilometers, and time entry), and a couple of dials. As a bonus, you can use it as miles-to-kilometers conversion calculator, at least for distances up to 26.9 miles (just over the length of a marathon).

Check it out, yo!

Mac Tech Tip: chflags

2011-03-16T14:42:00.002-06:00

I'm in the throes of my very-nearly-annual clean install of Mac OS X to my MacBook Pro (just to generally de-gunk; no other pressing reason). Of course this means I have to reinstall a lot of software (note to self: Hey self! You still need to restore World of Warcraft from your backup, stat!). Dropbox is helping me a lot this year; this time I don't have to recreate e.g., all of my password manager entries. That would be bad.

One of the more obscure things that I take for granted, always lose when I reinstall, and immediately miss is my symlink to /usr, which I like to create so I can use Finder to browse it. This year I decided to see if there was some better, native way to expose /usr to the Finder, and it turns out there is: chflags. One quick call to sudo chflags nohidden /usr, and I'm happily browsing. No muss, no fuss, no stretchmarks.

First Clojure Patch (ding)!

2010-10-25T19:34:00.004-06:00

In celebration of the awesomeness that was ClojureConj The First, I just submitted my first patch to the Clojure core codebase! Still waiting for the Lumbering Wheels of Bureaucracy to turn the Massive Gears of Pending Assembla Membership to open the Gates to the Kingdom of Those Who Have Had a Patch Accepted. But the hardest part is done!

I'm just giddy with excitement. Or sleep deprivation. Or both. Probably both.

Using Haml with Rails 3.0

2010-05-02T15:23:00.003-06:00

One of the things I [heart] about being a Ruby/Rails developer for ThoughtWorks is that I occasionally get asked to do something really cool on the side, like being a technical reviewer for an upcoming book on Rails 3.0.

In this particular book, the author uses Haml instead of Erb for templating views in the sample code. When I'm reviewing a book, I like to actually exercise as much of the sample code as I reasonably can, as it tends to be among the hardest stuff to get right, and among the easiest ways to discourage a reader when it's not right. But Rails defaults to Erb for templating, and I'm not exactly Haml-enabled.

What's a geek to do?

Well, my friend Google had a thing or two to suggest, but the process is slightly non-trivial so I thought I'd collate it here, thusly:

NB: All commands are entered from your Rails 3.0 application's root directory.

Edit [your_app]/Gemfile, and add the line gem 'haml' somewhere convenient.

Edit [your_app]/config/application.rb, and add the line g.template_engine :haml to the config.generators block (uncommenting the block if necessary).

gem install haml

bundle install

haml --rails .

git clone git://github.com/psynix/rails3_haml_scaffold_generator.git lib/generators/haml

That last bit is particularly important for allowing Rails' scaffold generators to Do The Haml Thang^(TM) when generating view templates.

Now back to my regularly scheduled tech review ...

P.S.: The book is going to be awesome. Reserve your copy now!

Enter the Lich!

2010-05-01T16:19:00.001-06:00

So I've finally spent a little bit of time unpacking and bookshelving my trove of geek books from my move last summer. Among many that I want/need to read Real Soon Now (TM), the book "Lisp in Small Pieces" by Christian Queinnec caught my eye and reminded me that I need to actually do something about learning Clojure.

So I've set out to implement Lisp in Clojure, following Queinnec's book. I've put the shell of the project -- featuring 100% test coverage; go me! -- on GitHub, at http://github.com/davidrupp/lich. For some reason I haven't taken the time to obsess about (yet), lein repl doesn't include the project's src directory on the CLASSPATH, so you can't really require your code and play with it in the REPL. So I've included my own in script/repl. I suspect that once I really get the hang of unit testing I won't need/want to rely on it so much, but at least it's there for now.

This should be fun ...

Review: Pragmatic Clojure Studio

2010-03-21T18:11:00.004-06:00

Executive Summary: If you are a developer looking to get into Clojure programming, attend this studio.

Executive Summary (for executives): If a developer who reports to you wants to attend this studio -- let him.

Even if you're at a shop that doesn't allow development in anything as exotic as Clojure -- yet -- you will benefit from this view of a language that embraces the JVM-as-a-platform as richly and effectively as Clojure does. You will learn what Java-the-language could (should?) have been capable of. You will even learn what Java-the-language actually *is* capable of. Much of Clojure is implemented in Clojure itself (homoiconicity FTW!), but a good chunk of it is implemented in Java.

The value of this studio is not the standard nuts-'n'-bolts / grammar / syntax / now-do-some-labs dance of most technical training. The value of this studio is that it's co-taught by Rich Hickey, the creator of Clojure. You will get to hear him talk about the design decisions he made in the evolution of Clojure. More importantly, you will get to hear him talk about the design decisions he *avoided*. You may not agree with all of those decisions, but you have to respect the man's process. Language philosophy aside, Rich's talks on "State and Identity", "Modeling State and Time", and "Protocols, Reify, and Datatypes" will blow your mind, and cause you to think differently about the act of programming whether or not you ever write a line of Clojure outside the studio.

Other not-quite-as-mind-blowing-but-still-pretty-cool topics include functional programming, web development with Compojure, Java interoperability, macros, and method dispatch.

And it's not just Rich who is fun to watch. The studio is co-taught by Stuart Halloway, owner of Relevance, LLC -- a working Clojure shop -- and author of the Pragmatic Programmers' "Programming Clojure". The two complement each other nicely. Stuart is very impassioned, a bundle of energy when it's his turn at the projector. Rich is much more laid back (though still impassioned), and expresses volumes with the arch of an eyebrow or a quirky half-smile at Stuart's antics. Both are eminently accessible and happy to answer questions and interact with students during breaks.

Remember Java in 1995? Ruby in 2005? I went into this studio a skeptic, and I came out convinced that Clojure is going to have a place -- and ultimately a prominent one -- in the landscape of our profession.

Go to this studio. Spend a few days learning from the masters. You'll be glad you did.

Why Should You Want To Work For ThoughtWorks?

2010-01-18T09:53:00.004-07:00

Note to self: the next time you're watching Roy (Roy Singham, the founder of ThoughtWorks) give his "How I Founded ThoughtWorks" pep talk to a batch of candidates, stand far off to the side and far enough away that he can't read your name tag.

What brings this up?

I spent a couple days in Chicago this past weekend helping out with our Super Saturday hiring event. And I watched Roy give his pep talk too closely and too directly in his line of sight. Because in mid pep talk he looked straight at me and said, "David, you're a ThoughtWorker, what do you want to add? Why should these people want to work for ThoughtWorks?"

Umm...

I managed to blurt out an impromptu, off-the-cuff, early draft of something like what follows.

Here, after time to think and embellish and re-word and clarify, is the full response I wish I'd given:

Why should you want to work for ThoughtWorks?

If you're like me, you've spent a fair amount of time (over 20 years, in my case) developing software for 'The Man' -- a series of nameless, faceless, soulless corporations. You've worked primarily for managers who fear what they don't understand, and what they don't understand is primarily two things: software development, and you.

At each of the places you've worked, you were led to your cube; isolated, walled off -- but not so much that The Man and his lieutenants can't walk by and easily keep tabs on you. Penned up so that human interaction happens on The Man's terms, not nature's. Guaranteed that every human interaction will require a hard context-switch in interface from keyboard and mouse to whiteboard and mouth.

And you're told 'you're Just a Java Developer'. By which The Man means: don't hassle me with your Ruby, or your Clojure, or your [cool technology here] that you've actually spent some time on your own learning about that could make a difference.

The Man doesn't want you to make a difference. The Man wants you to sit in your cube and write code. It doesn't even have to be working code; at least not at first. The QAs will figure out whether it works in due time. You're Just a Developer. And The Man has a whole raft of inefficient and degrading processes to manage the interactions between the QAs and the Developers.

When you chafe at being Just a Java Developer and you advocate for making a difference -- using force multipliers like Ruby, and Pair Programming, and Test Driven Development -- you're branded a troublemaker. And the guard on your cube doubles. And the degrading processes get more degrading, especially for you.

And then you find out that ThoughtWorks is hiring, and that we need smart people. People who voluntarily spend their free time getting better at what they do, looking for ways to make a difference. People who understand that there is more to software development than Just Java and The Man's inefficient and degrading processes.

And you realize that it's a win-win -- if you work for ThoughtWorks, ThoughtWorks gets another smart person, you get to be that smart person, and The Man fills your pen with a willing sheep and has one less troublemaker to guard.

If you take the plunge and apply, you get a chance to convince us that you can make a difference. And when I say 'us' I mean ThoughtWorkers, people who do what we would be hiring you to do. Not ThoughtWorks HR. Not ThoughtWorks Management. The very same ThoughtWorkers who will be your co-ThoughtWorkers if you're hired. We are not easily convinced. But we are aching to be convinced.

And if you make it through the gauntlet of code samples and assessment tests and ThoughtWorkers, within a couple days of signing the paperwork your butt is in a chair at a client site and you're pairing full-time, ten hours a day, four days a week, writing mission-critical code with people who are smarter than you ever will be.

And here's the coolest part. Not only do you *get* to make a difference (you do). Not only are you *required* to make a difference (you are).

The coolest part is this: you're *expected* to make a difference.

Because you're a ThoughtWorker.

That's why you should want to work for ThoughtWorks.

Learning Japanese, I Think I'm Learning Japanese ...

2009-11-22T12:32:00.003-07:00

The gauntlet is thrown.

In my prior blog post about the disappointing contents of some of the sessions at day one of RubyConf 2009 (which is a great conference overall, btw; try to go next year!), I mentioned that some of the presentations were below a standard that I would have expected at the premier international conference for this language/community. As it happens, all of the presenters of the sessions I called out speak English as a second language, and they are all in fact Japanese.

In my defense, I was not talking about the presenters' English skills. Lord knows their English is better than my (heretofore non-existent) Japanese. As an American who has made a point of learning and trying to function in the native language of the countries I've visited (Germany, France, and Italy to-date), I have nothing but respect for anyone brave enough to go anywhere and speak in a non-native tongue to an audience of native speakers.

That's why I've accepted John Mettraux's gentle challenge to gain full perspective by submitting a proposal to RubyKaigi 2010, Japan's version of RubyConf. John assures me that I would not be expected to present in Japanese, but that strikes me as being less than "full perspective". So I'm going to try to learn enough Japanese to not make a total fool of myself (assuming my proposal is accepted). If any of the three of you reading this blog (hi, Mom!) has any ideas for good learning resources, please do let me know.

Ah, but a man's reach should exceed his grasp, Or what's a heaven for? -- Robert Browning

RubyConf Day Two: I Have Seen The Future, And It Is ...

2009-11-20T16:37:00.002-07:00

MacRuby.

So day two of RubyConf went much better for me, content-wise. Caleb Clausen gave a subdued, but very interesting, presentation on Ocelot, his version of a Ruby compiler. Yehuda Katz brought down the house with his presentation "Polishing Rubygems", which was primarily about his project, Bundler. Andy Keep had a different take on the topic of partial evaluation to make Ruby more amenable to compiling. And Charlie Nutter was very engaging in his presentation with Thomas Enebo on the status of JRuby, including a cool demo of jirb running on an Android phone (simulator).

But my favorite talk by far was Laurent Sansonetti of Apple, talking about MacRuby. Laurent, who is clearly not a native English speaker -- are you reading this, jmettraux? -- gave a professional, content-laden presentation on MacRuby, which is pretty much his baby at Apple. He had some cool demos -- one of which was nearly thwarted by the hotel's abyssmal internet setup -- of MacRuby's integration with Cocoa/Objective-C, which also demonstrated that MacRuby has already solved the problem of compiling Ruby. XCode will build executables with the MacRuby framework embedded, and it will ship the MacRuby code as binary .rbo files, not Ruby source files. No need to obfuscate or simply give your code away; MacRuby takes care of it all.

Now if only we could get Apple to open up the iPhone to this. Or perhaps build a tablet of some sort ...

RubyConf 2009: Day One

2009-11-19T21:57:00.003-07:00

In a word: disappointing.

Oh, the venue (the Embassy Suites at the San Francisco Airport) is nice enough. And yes, there are problems finding power and getting on the internet, but that's to be expected. Anyone who attends a gathering of more than about ten people and actually believes the claims of abundant power and speedy WiFi for all is asking for a let-down. So it's not that.

Maybe it was just my bad luck in the sessions I chose to attend. I was very much looking forward to hearing some of the Ruby core team speak, so I made sure to catch Matz's keynote, "East meets West", and "Hacking parse.y", the latter being interesting to me in its own right since it was about Ruby implementation internals.

Matz has decent presence as a speaker, and the crowd dutifully laughed at all his good-natured, pro-forma digs at other languages' foibles (Java is lame. Lisp has too many parentheses. Et cetera.). But he didn't have anything particularly new or interesting to say about Ruby or language design, just that there can be no "one true" programming language, that the best we can hope for is one that's "close enough", and in his opinion Ruby is currently the best candidate. Go figure. Still and all, the man did invent the language that I currently use to make a living, so major props to him.

The other two were just not up to any reasonable standard for a conference at this level.

Look -- I know the Ruby community prides itself on being edgy. I get that RubyConf is deliberately kept small and scruffy and non-RailsConf-y. But is it really asking so much that the people who present talks at The Premier Conference for their language/community have some basic skill in the art of talking to an audience?

I did find the talk on using Ruby to write DSLs and code generation tools for hybrid systems simulation and scientific computing pretty interesting. And tomorrow's schedule looks good on paper.

Here's hoping it goes better than today.

Dear RVM: It's Not Me. It's You.

2009-11-18T20:08:00.008-07:00

Dear Ruby Version Manager,

It's over. I tried. But I just can't do it any more. I though I could let you back into my life after that unfortunate 'sudo gem install rvm' spat we had on our first date. That's on me. But even after I moved you into my home directory, you still couldn't make it work.

I wanted it to work. Really, I did. I mean, a chance to have an open relationship with multiple Ruby's, all painlessly and seamlessly installed and switchable through you? Who wouldn't want that?

But you just couldn't handle my prior relationship with my self-compiled, self-installed /usr/local/bin/ruby, could you? I mean, you ... you ... it hurts just to type it ... you hijacked my $PATH, RVM! You locked me out of my gems! I mean, they weren't all switchable and fancy and all, they were just plain gems, but they were my gems, you know? How was I supposed to trust you after that?

Was it jealousy? Was it ignorance? I guess I'll never really know.

But -- for now at least -- I have to give you up. I have to lash myself to the mast of my virtual Argo, and forego your sweet, seductive siren song.

It's a pity. We could've been something, you and me.

Ruby's inject(): Putting the 'Fun' in 'Functional Programming' Since ... Oh, About 4:15 This Morning

2009-10-14T06:03:00.001-06:00

Yesterday at work, I ran across the need to convert a number of seconds into its equivalent in days, hours, minutes, and seconds. The canonical imperative way to do this is something like:

seconds = 356521
days = seconds / (24 * 60 * 60)
seconds = seconds % (24 * 60 * 60)
hours = seconds / (60 * 60)
seconds = seconds % (60 * 60)
minutes = seconds / 60
seconds = seconds % 60

N.B.: This relies on Ruby's integer division -- dividing an integer by an integer results in an integer, with any fractional remainder discarded.

My pair and I ended up implementing something very much like this, but it left a bad taste in my mouth. I mean, it works and all, but it feels kind of ... non-functional. Ya know?

So, after much fretting and sleeplessness last night ... behold:

seconds = 356521

days, hours, minutes, seconds = 
  [1.day, 1.hour, 1.minute, 1.second].inject([]) do |acc, unit|
    quotient, seconds = seconds.divmod unit
    acc << quotient
  end

This version needs to be run in a Rails script/console rather than irb, because it makes use of the Rails shortcut definitions of the number of seconds in various units of time. You could easily convert to plain irb-able Ruby by replacing 1.day et al above with their numeric equivalents.

The resulting code is both (more) functional, and more quintessentially Ruby-ish. divmod and multiple assignment let us figure out the quotient and the remainder of the division in one go, and inject lets us accumulate the results and ultimately multiply assign them to their respective units.

Neato.

I'm a little bummed, though, that this version has the side effect of destroying the original contents of seconds, as well as requiring seconds to be defined outside the scope of the inject. What would be really cool would be to have a version of inject that allowed for multiple accumulators (or, really, a 'decumulator' in this case) such that all side effects could be contained within the inject.

Fun With Metaprogramming: hash_initializer()

2009-09-09T20:27:00.003-06:00

Earlier this week I was doing a code review for a candidate for ThoughtWorks. One of the bits I ran across was an object constructor that looked something like this:


class MyClass
  def initialize(name, price, is_cool, is_neato, is_rad)
    @name = name
    # et cetera
  end
end

Not so bad, really, when you're looking right at the signature for the constructor. But when it's called from another file...


MyClass.new("bob", "1.00", true, false, true)
MyClass.new("fred", "2.00", false, true, true)
# et cetera

... the purpose of the first two parameters may be easy to infer, but the last three? Which order were those descriptors in anyway? To really be sure, one has to keep referring to the class definition. In my review, I opined that perhaps the constructor should take a single argument -- a hash with keys named after the objects instance variables and their corresponding values. Thusly:


class MyClass
  def initialize(args)
    args ||= {} # in case MyClass#new is called without any args
    @name = args[:name] || ""
    # et cetera
  end
end

This frees things up a bit, and allows for parameters to be specified in any order, with reasonable defaults for any that might be left out. It also makes calls to the constructor a little more self-documenting.

But what would really be nice would be not having to write out this boilerplate code for everything that we want this kind of constructor for.

Enter metaprogramming, in the form of hash_initializer -- a nifty little class extension I found in Brian Guthrie's Awsymandias library (as used at my current ThoughtWorks gig). Behold:


 1. module ClassExtension
 2.  
 3.  if !Class.respond_to?("hash_initializer")
 4.    def hash_initializer(*attribute_names, &block)
 5.      define_method(:initialize) do |*args|
 6.        data = args.first || {}
 7.        data.symbolize_keys!
 8.        attribute_names.each do |attribute_name|
 9.          instance_variable_set "@#{attribute_name}", data[attribute_name]
10.        end
11.        instance_eval &block if block
12.      end
13.    end
14.  end
15.
16. end
17.
18. Class.send :include, ClassExtension

Lines 5 through 12 correspond pretty much to my second version of MyClass#initialize above. Line 6 does the same defensive guard against a nil first parameter. Lines 8 through 10 pull each attribute, create an instance variable with the same name, and set it to the desired value. The extra bits? Line 7 does something I should have done in my "improved" version -- it forces the keys of the params has to be symbols, avoiding the awkwardness of blowing up when a key is a String when it should be a symbol or vice versa. Line 11 allows for the execution of a block along with initialization, if you're into that sort of thing. And the rest just opens up the class Class and makes Class#hash_initializer available to all objects.

With Class thus extended, the boilerplate for MyClass becomes simply:


class MyClass
  hash_initializer :name, :price, :is_cool, :is_neato, :is_rad
end

And instantiating a MyClass stays what you would expect:


MyClass.new :name => "bob", :price => "1.00" # et cetera.

I like it.


irb(main):001:0> Class#hash_initializer.is_neato?
=> true

Code Artistry: The Negative Space

2009-08-10T20:11:00.007-06:00

So I've been reading The Merb Way this week. I like it so far -- Foy Savas does a pretty good job of making his discussion of the technical internals interesting to read, and generally elevates the material above today's standard grind-it-out, dress-up-the-man-page-or-the-public-API-docs, tech book farce. Fare. I meant "fare".

One of the standout features of this book, though, that I'm finding myself drawn to is a marked lack of comparison between Merb and Rails. I can't tell if Savas intended this, but I find reading about, say, Merb's routing architecture easier to follow than if it were interrupted every other paragraph by an "as compared to Rails, which does this..." interlude. I'm not sure many other authors would have avoided that trap as neatly.

If you think about it, it's a sensible approach to take, although maybe not the most obvious one. If I'm reading a book on Merb, what I want to read about is ... you know ... Merb. I may already know some of the internals of Rails. I may not. If I do, chances are that I will make those comparisons myself. If I don't, chances are a constant barrage of interruptions would just turn me off of Merb, and possibly Rails too. Either way, interleaving a discussion of Rails within a discussion of Merb would be counterproductive.

Reading this book makes me wish more of us technologists would learn the value of the artistic concept of the negative space -- the bizarre and intriguing shapes formed *between* the familiar ones that are the nominal focus of the picture. That what the artist leaves out can contribute as much to the picture as what he puts in. Sometimes more.

I was going to write out a list of how this concept applies to and enhances other artistic and quasi-artistic disciplines like architecture, music, literature, and film-making.

But now I'm not. :-)

A Gem Is Born: Announcing Gemviz

2009-01-10T21:11:00.019-07:00

Final (potentially) update: Now appearing on github:

git://github.com/davidrupp/gemviz.git

Update to first update: I realized that I did not specify a gem dependency on ruby-graphviz in my hoe-generated Rakefile. This is in place as of version 0.1.2.

To quote Groundskeeper Willie in The Simpsons - Treehouse of Horror V: "Och, I'm bad at this!"

We now return you to the first update.

Update: Peter Cooper correctly points out in his comment that Gemviz has a hard dependency on Graphviz, which isn't installed by default on Macs. I tend to take it for granted because it's one of the first things on my checklist to install when breaking in a new Mac. I use The Mac OS X Edition of Graphviz, as referenced on the Graphviz home page.

We now return you to the regularly scheduled original post.

Original Post: I can't really call myself a hotshot Ruby programmer until I release a RubyGem, now can I? Well, I still won't call myself a hotshot Ruby programmer yet...but, as of today -- and the release of versions 0.1.0 and 0.1.1 (for documentation purposes) of my new gem gemviz to rubyforge.org -- at least I'm one step closer!

Check it out, yo:

[sudo] gem install gemviz

Now you can do e.g.,

gemviz rails

(assuming you have Rails installed as a gem which, if you don't by now: huh?), which produces this graph on my system:

In fairness, I should disclose that Gemviz is only about 30 lines of code, and makes heavy use of other people's work to do its magic. Here's how it works:

* it scrapes the output of the system command gem dep gem_name --pipe.
* for each dependency thus listed, it adds that dependency to the list of dependent gems.
* it does the same recursively for each dependent gem until it finds that the current gem has no dependencies, or that some (recursively) dependent gem is not installed on the system.
* it builds a Graphviz graph from the graph so built.
* it runs the awesome tred utility on the resulting Graphviz graph, which translates the original messy graph into one that properly represents all of the transitive dependencies.

If you're not sure what that last bit is about, don't feel bad: I didn't either at first. So here's the picture that's worth a thousand words (give or take):

The difference is subtle, but telling. The second graph shows that the rails gem has dependencies on activesupport and actionpack. Which is true, as far as it goes, and is reflected in the output of the gem dep command thusly:

gem dep rails
Gem rails-2.2.2
 rake (>= 0.8.3, runtime)
 activesupport (= 2.2.2, runtime)
 activerecord (= 2.2.2, runtime)
 actionpack (= 2.2.2, runtime)
 actionmailer (= 2.2.2, runtime)
 activeresource (= 2.2.2, runtime)

But it turns out that gem dep doesn't tell the whole story. rails does depend on those other gems, but only through its dependencies on activerecord, actionmailer, and activeresource, as shown in the first graph. That's what the tred utility (part of the Graphviz package) does: reduce the second graph to its minimal equivalent representation in the first graph.

Here's another more fun example, for merb, prior to transitive reduction:

And post tred:

This implementation owes much to the existing DepGraph, especially its use of Graphviz and tred. I basically just extracted the simple use case of graphing a gem at a time, and neglected to implement a bunch of DepGraph's options. For instance, the output of gemviz is always a single .png file per requested gem, named after the gem and placed in the current directory.

Keep in mind that this is a very simple initial release. Please let me know if you find it useful, and especially what improvements you can think of.

QOTD: Hans Küng

2008-12-30T20:58:00.002-07:00

From The Catholic Church: A Short History:

Those who deliberately step in all the puddles should not complain too loudly about how bad the road is.

Bad RSpec! BAD RSPEC!!

2008-12-22T20:18:00.003-07:00

My first gig as a consultant for ThoughtWorks has been a whirlwind of security lines, flights to Texas, and Ruby on Rails. I'm very pleased that they were able to make me billable so quickly; to be getting paid to work on Rails again after two years in the Java mines is an extra added bonus.

My pair and I spent today upgrading one of our apps to Rails 2.2, as a sort of trial run for eventually upgrading all our apps. This involved the usual amount of concomitant upgrades to plugins, with no shortage of "great, this is broken...now something else is broken...not that too!" hijinks. The best part of the day, though, was the RSpec tests that kept failing no matter what we tried to throw at them.

Long story short, we have a controller that uses a rescue_from handler to redirect in the event of a connection error. Works like a charm when we're clicking through the app. But after upgrading RSpec and RSpec-Rails it simply refused to pass the specs that verified the redirect behavior.

It turns out that the latest version of RSpec has some secret sauce that defeats rescue_from, instead going directly to raising the exception that needed rescuing from in the first place. I guess I wouldn't mind so much if we didn't have several behavior-driven tests that, you know, tested behavior.

Not too cool, Rudy.

There is, of course, a workaround. Simply add controller.use_rails_error_handling! to your test and you can defeat RSpec's defeating of rescue_from. But, just as double negatives fail to not clutter English prose (see what I did there?), having to demand that RSpec get out of the way of Rails' standard and -- in this case -- reasonable behavior just uglies up my code. I would much rather the maintainers of RSpec had elected to make the ability to bypass the rescue handler and skip straight to the underlying exception an "opt-in" behavior.

One of These Things is Not Like the Others...

2008-12-01T09:15:00.003-07:00

I (heart) Amazon's recommendations service, but...

...I'm not entirely sure what the message is here. For me or any other fans of programming languages and/or algorithms.

QOTD: Donald Knuth

2008-10-17T23:07:00.002-06:00

Ripped directly from this interview:

...I trust my family jewels only to Linux.

I'm a Mac guy myself, but...respect, brother. Respect.

Regarding Ruby, instance_of?, kind_of?, and ===

2008-08-15T23:45:00.011-06:00

So I was reading through some Ruby source code tonight -- primarily because I haven't in a while, thanks to a busy stretch of Java work -- and I ran across an idiom that I found a little confusing at first. The Ruby source code belongs to Why the Lucky Stiff's Shoes project, "a very informal graphics and windowing toolkit" (according to the official website).

One of the first files I looked at, lib/shoes.rb, opens right up with this interesting bit of interestingness:

class Range 
  def rand 
    conv = (Integer === self.end && Integer === self.begin 
        ? :to_i 
        : :to_f)
    ((Kernel.rand * (self.end - self.begin)) 
        + self.begin).send(conv) 
  end 
end

Okay. So we're defining a rand() method on the built-in Ruby class Range, which will return a random value from within the begin and end values of the Range. Neato. And apparently the use of conv is meant to produce a result of a float or an integer, depending on the nature of the endpoints of the Range. Again: neato. But I hadn't seen the use of the === operator in this context before.

The docs and the Pickaxe book are a little obtuse on this, so I did some irb spelunking:

>> r = (1..27)
=> 1..27
>> r.class
=> Range
>> r.begin
=> 1
>> r.begin.instance_of? Integer
=> false
>> r.begin.class
=> Fixnum
>> r.begin.kind_of? Fixnum
=> true
>> r.begin.kind_of? Integer
=> true

Hmm. So instance_of() doesn't mean quite the same in Ruby as, say, the instanceof operator in Java does. (That, or Fixnum doesn't truly inherit from Integer in Ruby.)

Also, as it turns out:

>> Fixnum === r.begin
=> true
>> Integer === r.begin
=> true

So it would seem that the [class] === [value] syntax is syntactic sugar for [value].kind_of? [class]

It's the bit about:

>> r.begin.instance_of? Integer
=> false

that surprised me most, being the pathetic Java programmer that I am. And being that (according to the documentation for Integer on ruby-doc.org):

Integer is the basis for the two concrete classes that hold 
whole numbers, Bignum and Fixnum.

Apparently "is the basis for" != "is a superclass of".

Or is that "!==="...?

Fixing Eclipse's Workspace Dialog: A Unix One-Liner in Only Three (Okay, Four) Lines

2008-07-07T15:16:00.005-06:00


cd /Applications/eclipse_3_3/configuration/.settings 
  && sed '/RECENT_WORKSPACES/d' org.eclipse.ui.ide.prefs 
    > org.eclipse.ui.ide.prefs.fixed 
  && mv org.eclipse.ui.ide.prefs.fixed org.eclipse.ui.ide.prefs

I usually (heart) Eclipse, but sometimes I just want to smack it upside its virtual head. One of those times is when it's starting up and I change focus to some other app and start typing something and Eclipse at some point grabs focus and inserts whatever I thought I was typing somewhere else and prepends it to its "which workspace do you want to use?" dialog and promptly creates a new workspace with a name of whatever nonsense text ended up in the dialog box. You know?

So I now have this little bit of bash magic saved as zapEclipseWorkspaceSelection.sh in my home directory. The downside is that it zaps all of your prior workspace selections, not just the smack-Eclipse-upside-the-head ones. You could maybe modify it to, say, ask for input on what invalid workspace names it should delete. Not me, man. Subtlety is not one of my vices.

HOWTO: Display a Custom Boot Message for Your VMWare Appliance

2008-06-20T11:57:00.018-06:00

So I'm building a VMWare appliance for Stratavia's Data Palette data center automation application, and I want it to be like all the other cool appliances that print out some system-specific configuration information (e.g., IP address) when it finishes booting. This is useful for when, say, your appliance runs a webapp via an HTTP server like Apache or Mongrel or Tomcat and you want to tell the user where to point his browser to see it in action.

I happen to be using the latest Ubuntu JEOS as the base OS for this appliance. As such, in order to hook in to the boot process, I am adding my changes to the /etc/rc.local file.

(Author's Note: The exact location and name of this file vary -- sometimes wildly -- between Linuxen. Some flavors use /etc/rc.d/rc.local. Gentoo uses /etc/conf.d/local.start. I paraphrase the immortal Daffy Duck in "The Scarlet Pumpernickel": "Fancy, thy name is Linux. To coin a phrase.")

Let's say you want your user to visit http://[whatever the IP address ends up being] following bootup to get the virtual ball rolling. But you don't know what that IP address will be when you bundle your appliance; it's going to be assigned dynamically at bootup (as it should be). No problema. Simply write a bit of script to scrape the IP address in your Linux flavor's version of rc.local, thusly (Note: The following bit of awesome is directly ripped off from the rc.local file of the MindTouch Deki Wiki appliance):

IP=`ifconfig eth0 | grep "inet addr" | awk -F ' ' '{print $2}' 
  | awk -F ':' '{print $2}'`

If you're Richard Stallman or some other Unix guru and you already know what the heck all this does, you can just smile smugly and skip the next few paragraphs. For the rest of us:

ifconfig eth0 -- Run the system command ifconfig to print out the general networking information for this box (specifically, the first ethernet interface), and send ("pipe") its output to the grep command. The output for ifconfig eth0 will look something like this:

eth0      Link encap:Ethernet HWaddr 00:0c:29:2d:f7:73
          inet addr:172.16.139.130  Bcast:172.16.139.255  Mask:255.255.255.0
          inet6 addr: fe80::20c:29ff:fe2d:f773/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          [et cetera]

There are several more lines, but all we care about is the second line. The next command in the chain, grep "init addr", will filter out all the stuff we don't want, leaving us with just the second line. This is then fed to the first of two awk scripts.

The first awk script uses a field separator of "space" (-F ' '); this splits the inet addr line into its constituent "words", like "inet" and "addr:172.16.139.130". We just want the "addr:" word, so we print it as the output of the first awk script and send it to the second ({print $2}).

The second awk script splits its input using the colon as its field separator (-F ':') and prints the second word, which is -- tada! -- the IP address of the virtual machine. Whew.

The Rubyistas reading this blog (assuming I have any left) may have downloaded Ezra Zygmuntowicz's way-cool EngineYard Express VMWare image. Its bootup a little more involved, asking for input from the user on initial boot, and displaying several bits of information after every boot thereafter, such as the randomly-generated root and express user passwords. EY Express is running on Gentoo, so its startup hook is in /etc/conf.d/local.start.

EY being EY, they delegate all the heavy lifting to Ruby via some custom Ruby Gems: ey_reporter, config_system, and system. You have to do some serious filesystem spelunking to get there, but you can find the Ruby code that figures out the IP address (the equivalent of the bash script above) in

/usr/lib/ruby/gems/1.8
  /gems/system-[version]/lib
  /system/info/info.rb

WWDC Keynote 2008: Are You Kidding Me?

2008-06-09T12:54:00.007-06:00

iPhone and the .Mac replacement: About two full hours.

Next-gen Mac OS (10.6 -- "Snow Leopard"): About 10 seconds (a brief announcement that it's being discussed in an afternoon session with Bertrand Serlet).

New Mac hardware (e.g., the rumored Mac tablet): 0 seconds.

Mac hardware updates (e.g., the rumored laptop redesign/s): 0 seconds.

"One-More-Thing": 0 seconds.

I'm just waiting for this announcement from Cupertino:

Apple Inc. (formerly-and-clearly-no-longer Apple Computer Inc.) proudly announces the obliteration of any computer-related product from its catalog. Going forward, the laptop computer formerly known as the "MacBook Air" will be known as the "iPhone Maxi"^*. And the segment-dominating laptop computers formerly known as the "MacBook" and "MacBook Pro" will be renamed the "iPhone Big-n-Bulky"^* and "iPhone Bigger-n-Bulkier"^*.

^*iPhone cell phone functionality not included.

[Mac] pbcopy == Brilliant

2008-05-21T22:32:00.005-06:00

For Mac users only (as far as I know):

cat filename | pbcopy

This bit of magic, as I just discovered, will copy the contents of the cat-ed file to the clipboard, for easy pasting wherever you need to paste it.

Macs. Rule.

[OT] Out of the Mouths of Babes...

2008-05-11T21:10:00.004-06:00

I promise I'm not going to turn into one of those bloggers who turns his blog into a blog about blogging every precious blogging word that comes out of his three-year-old son's mouth. But I'm submitting this to the Interbits in the hopes that some day when I'm old and grey and he's graduating from high school I'll be to retrieve it and *really* get some peoples' eyes rolling.

So we're celebrating Mother's Day and my wife gets to the card that "he" gave her. It's got a Winnie the Pooh theme, with a typical "you're the best mommy ever" verse. Inside is a picture of Kanga (also a mommy) giving Roo (also a little boy) an affectionate hug. So Angela points to the picture and says, "Look, Alex, it's me and you!". And he looks at her with his eyes wide, then he looks at the picture again, and says in a tone that implies that he's a little concerned about how she's not keeping current with her medication, "Yeeeaaahhhh........and we've turned into kangaroos!"

The Java Process That Ate My MacBook Pro

2008-05-09T14:37:00.005-06:00

Gotta love the Phenomenal Cosmic Power of virtual memory (the next-to-last column in the following ActivityMonitor screen capture):

Debugging a Remote Java VM with Eclipse

2008-05-08T22:31:00.014-06:00

I (heart) the internet. Why? Well, among other reasons, I ran across this blog post today, which totally saved me a good several hours of frustration and swearing whilst tracking down a thorny problem.

You see, at my day job, I help to develop this webapp that points to a number of Java VMs, running in various combinations of in-Eclipse/not-in-Eclipse. The not-in-Eclipse bits are not run in Eclipse for a reason (read: "I don't care to jump through the hoops necessary to force them to."); however, lamentably, sometimes I get to (read: "have no choice but to") debug those bits too. And so, on the advice of the aforementioned blog post, I added these options to my startup scripts for the to-be-remotely-debugged VMs:

-Xdebug -Xrunjdwp:transport=dt_socket,address=8001,server=y,suspend=n

did some Eclipse magic ('Run | Open Debug Dialog... | (right-click) Remote Java Application | New | (fill in the details)') to point my debugger at the appropriate host and port, and I was off to the races.

The moral of the story: some days you just can get rid of a bomb.

(Author's Note: Bonus points to any commenters who can identify that seriously obscure reference!)

In Which I Reconnect With Ruby Just in Time to Finish My Master's Degree

2008-04-29T22:53:00.028-06:00

The fates have conspired to force me to end my graduate school career with a bang. Fortunately, the bang is not the sound of my head exploding, as I feared it would be at the beginning of this semester. I'm taking two classes -- Theory of Complexity (about P vs. NP, BPP, #P, complexity of quantum computing...you know the drill; if you don't know the drill, try The Complexity Petting Zoo for an introduction) and Applied Graph Theory. Each is fascinating in its own right, but the graph theory class has really made an impression on me. So much so that I think if I'd taken it earlier on, I probably would have been tempted to do a thesis in that area. As it is, I'm stuck with my lame default choice of the "coursework-only" option for the Master's degree I'll be finishing come mid-May (the 17th, just in case anyone wants to send a present).

However, to my credit, I did manage to complete a significant semester-long project in graph theory, using Ruby as the implementation language. Why Ruby, and not Java (which I use professionally right now) or Scala, or any of the other possibilities I blather about on this blog?

Well, if you're a seasoned Ruby user you'll know why -- there's not much else (that I'm accustomed to) that's suited to the kind of rapid development/iterability I needed to get this thing done on time. My primary concerns throughout were a) to be able to complete the implementation with enough time left over to write up my results and prepare my in-class presentation, and 2) see concern a) above. Sure, Java's static typing or Scala's functional orientation might have given me some (nominally) safer code, but here, speed of development was of the essence. Advantage: Ruby.

The actual project? It's an implementation of an algorithm due to Hermann Stamm-Wilbrandt of the University of Bonn (Google is your friend...) to draw a maximal planar graph in linear time. Actually, the intent of the core algorithm is to "embed", not "draw" the graph; although I also implemented an optional enhancement to assign x-y coordinates to the vertices of the embedded graph for drawing purposes. Using Ruby, I was able to implement the entire project in less than 500 lines -- including blank lines, comments, debug, and other cruft -- of gloriously unoptimized, un-statically-typed, un-refactored, un-IDE'd-to-within-an-inch-of-its-life Ruby code.

I shudder to think what the LOC count would have been for Java.

Even in Ruby, the bulk of the code was either utilitarian in nature (e.g., a Line class and a Triangle class to help with the geometry of deciding where vertices should lie in the plane; some vector math for seeing if two points are on the same side of a line), or was wrapped up in simple one-to-two-liner convenience methods to support the main objective. This stuff accounted for about 120 lines. And the <500 lines of code also includes my from-scratch graph data structure (typically of the adjacency list variety), along with about 35 lines of code to emit the output in displayable format. The guts of the actual implementation of Stamm-Wilbrandt's embedding algorithm took about 130 lines of Ruby code (including blanks and comments), plus another 70 or so to handle a complicated special case of the optional x-y coordinate assignment.

My only regret is that I don't know Python well enough to have done the entire implementation in that language. I say that primarily because I used the totally awesome NodeBox as my drawing solution. NodeBox is written using PyObjC (Mac only -- sorry Windows/*n[i|u]x users!), and uses Python as its scripting language. My Ruby implementation actually emits a Python script which I then open with NodeBox to draw the final graph. If it were implemented in Python, then it could just be a NodeBox library.

The Good News: Now I have an excellent excuse to learn Python...

IE Misbehaving? Fix It With Prototype!

2008-02-07T20:51:00.000-07:00

Disclaimer: Since I specifically make reference to where I work in this post, I thought I should also specifically make reference to the fact that on this blog in general, and in this post in particular, I do not speak for my company in any way shape or form. My opinions are mine. Mine, mine, mine! If my company wants to express its opinions, it can get its own damn blog!

So at my day job we're converting the front end of our product from a Java thick client to a Struts 2 / JSP / several-other-buzzwords webapp. We officially support three browsers (in no particular order other than my blatant preference): Firefox, Safari, and Internet Explorer. We're using a fair amount of Ajax via Prototype and Scriptaculous. Again, no big surprise.

One of the problems we've encountered with our Ajax stuff is that anything we return from a normal Ajax call is subject to caching by the browser. Now I know the standard tricks to defeat caching are to a) submit the request as a POST; and 2) submit as a GET, but append a random string (e.g., a timestamp) to the request string to force the browser to fail on the cache lookup.

Unfortunately, being the curmudgeonly programmer and language maven that I am, I object to both of these approaches. Sometimes (most times) GET is the proper verb to use for my request; it's not changing state on the server, just retrieving it. POST should be used for changing state. The random string hack is just that -- a hack. If the browser is going to cache the results of a single request, it's probably going to cache the result of each "unique" request we create by tacking on this otherwise-irrelevant snippet of "data". I don't want all that unnecessary cruft in my customers' caches if I can help it.

There must be a better way.

Fortunately, there is a better way as of HTTP 1.1, in the form of the Cache-Control response header. See Section 14.9 of the HTTP 1.1 spec for all the gory details. Suffice it to say, including a response header of Cache-Control: no-cache with all of our Ajax responses worked to defeat caching of our Ajax-GET snippets.

Except on IE.

Are you surprised? I was, but only because Cache-Control: no-cache actually works on IE, to a point. So it wasn't obvious at first that IE was screwing up. Fortunately, we have the world's best quality engineering team, so they caught the problem when we lowly developers weren't seeing it.

Long story short: it turns out that (in our application at least; YMMV) the Cache-Control: no-cache response header actually works to prohibit caching in IE. Until the response is > ~8K in size. At which point IE caches it anyway. Which leads to all kinds of fun "but I saved my edits, I know I did" debates between QE and development when the browser returns the cached results instead of the latest and greatest.

This is where Prototype comes in. You see, Prototype already has a set of headers it adds to every Ajax request submitted through it. For example, it sets the header X-Requested-With to XMLHttpRequest. We use this in our app to distinguish between Ajax GETs and non-Ajax (NAjax?) GETs. Comes in handy sometimes. (Note: See Prototype's source file prototype.js, specifically the Ajax.Request.setRequestHeaders() function for the details on this; ~ line 1241 in Prototype 1.6.0.2.)

So the trick is to get Prototype to include another header with its Ajax requests: If-Modified-Since. Set If-Modified-Since to some datetime in the past, and the browser should always go to the server instead of the (expired) cache. I could do this by hacking my prototype.js file to include this new header in Ajax.Request.setRequestHeaders(), but then I'd have to remember to re-hack every time I upgrade Prototype. Not fun. I could also submit it as a patch, I suppose, but I don't know that everyone needs this behavior by default.

Enter The Next Best Thing: Functional Programming! Prototype has a wonderful FP-ish function called wrap(), which is defined on Element.Methods (prototype.js, ~ line 1652 in 1.6.0.2). wrap() lets me extend the existing setRequestHeaders() function from the outside thusly:

Ajax.Request.prototype.setRequestHeaders =
Ajax.Request.prototype.setRequestHeaders.wrap(
  function(original) {
    // do my stuff first; e.g., set 'If-Modified-Since'
    original() // then call the original version
})

In case this isn't clear, I'm replacing the original definition of the setRequestHeaders() function with a new (anonymous) function that does my stuff first, then does whatever the original was defined to do. To Java programmers circa 2004, this looks kind of like "before advice" in Aspect-Oriented Programming. Without the new-language-compiler-tools-runtime-stack baggage. To functional programming types, it looks like function composition. Without the lambdas and general my-thesis-is-bigger-than-yours snootiness.

To me it looks like a pretty nifty hack, one that plays by everyone's rules.

Well. Except IE's.

But I'm okay with that.

From the Bonehead File: Pragmatic Programmers Books And "Save As PDF"

2008-02-01T12:06:00.000-07:00

I (heart) my MacBook Pro.

One of the main reasons I (heart) my MacBook Pro is Mac OS X's built-in "Print... | PDF | Save as PDF..." feature. I've been reading a lot of papers from various online sources recently for my schoolwork, and I love being able to "print" them to a file on my local filesystem for offline reading. HTML, postscript, whatever format you care to publish your paper in, if I can browse it, I can PDF it.

Unfortunately, though, I've gotten so much in the habit of printing to PDF that I've unwittingly given away some of the functionality of some of my documents.

You see, I buy a lot of PDF versions of books from the excellent Pragmatic Programmers catalog. Their PDFs are, without serious exception, among the most informative resources I have at my disposal. But because my browser renders them, and because I'm so used to "printing" my PDFs, I've gotten into the habit of browsing to them and saving them as PDF from the browser. Which, of course, totally wrecks the internal (and external) hyperlinks they have built into the books.

D'oh!

The good news is, the Prags allow one to regenerate purchased PDFs at will (Note: sorry for the spike in regeneration requests this morning, guys! Give the gerbils an extra pellet or two for me.), so I'm back in business, pragmatic-hyperlink-wise.

Fox/FXRuby/Leopard, Part the Second

2008-01-19T21:50:00.000-07:00

As a follow-on to my previous post, I discovered that there's a little more work to be done to actually be able to use my freshly installed FXRuby. I tried using the listexample.rb program from the aforementioned Pragmatic Programmers book, and promptly found that the 'fox16' library couldn't be required. Grumble.

Fortunately, this post on the fxruby-users mailing list (again, courtesy of Lyle Johnson, lead programmer of FXRuby and author of the PragBook) was able to get me going:

a workaround is to use the "gem env" command to identify your Gems installation directory (usually something like /usr/local/lib/ruby/gems/1.8) and switch to the "gems/fxruby-[version]/ext/fox16" directory underneath that:
cd /usr/local/lib/ruby/gems/1.8/gems/fxruby-1.6.0/ext/fox16
and then type:
make

Note: Since RubyGems comes installed with Leopard, your gem installation directory is more likely to be something like "/Library/Ruby/Gems/1.8", at least if you did a fresh install as I did. YMMV.

But here I encountered the same architecture problem I referenced in my previous post. This time I ended up editing the Makefile and deleting all references to "-arch ppc"; setting the ARCHFLAGS environment variable before running make didn't cut it for me.

Once you've re-made the gem, you should be able to verify your installation in irb:

>> require 'fox16'
=> true

Two final caveats:

I had to modify the PragExample with the line "require 'rubygems'" at the top of the file, right before the "require 'fox16'" line. This was because I haven't yet set my RUBYOPT environment variable in Leopard to require rubygems automatically for me.
The example program worked fine for me after all this (try holding the shift button to do multiple selections), until I quit, at which point I got:
```
X Fatal Error.
Abort trap
```

So this FXRuby thing is not an exact science yet. Sigh.

Installing Fox and FXRuby on Mac OS X Leopard (Intel)

2008-01-19T18:00:00.001-07:00

I'm planning to start playing with some of the GUI toolkits available for Ruby, and I know there's a Pragmatic Programmers book (currently in beta) for FXRuby, so I thought I'd get the fixin's in place to be able to play with it. Unfortunately, the standard sudo gem install fxruby alone didn't get the job done for me. Even using MacPorts to install Fox first (sudo port install fox) let me down. Here's what (eventually) did work:

Download and Install Fox:
- Download the source. I picked the current stable version from the "Downloads" section, "Linux/Unix" subsection.
- Set the LDFLAGS environment variable as described in Lyle Johnson's (author of FXRuby and the book) very helpful post:
```
export LDFLAGS="-dylib_file \
/System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib:\
/System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib"
```
  Note: There's a typo in Lyle's instructions that will trip you up if you just cut and paste from there; there should be a space between the "-dylib_file" and the first "/System/Library/...". And, in case you're cutting and pasting from here, there should be no space between the colon and the second "/System/Library/...".
- cd to the expanded Fox source folder.
- ./configure, with whatever options you would normally use. I didn't specify anything in particular.
- sudo make install, again with your typical options. The vanilla command worked for me.

Install the FXRuby gem:
- sudo env ARCHFLAGS="-arch i386" gem install fxruby
- The extra bits about the ARCHFLAGS are a workaround for a problem in ld (and/or lipo) trying to build this gem for both PPC and Intel architectures. As you might guess, this will work for you only if you're on an Intel Mac.
- From the Credit-Where-Credit-Is-Due department: I cribbed the "env ARCHFLAGS" trick from the most excellent Hivelogic website, specifically this post.

Write a cool GUI! (Haven't gotten that far on this item yet...)

Oh, and I'll be looking at Shoes too. No weird Unix/Linux project dependencies for that one, thank goodness. Just a regular .dmg to download and install. Nice.

Required Reading: The Role of the Study of Programming Languages...

2008-01-17T13:57:00.000-07:00

Via the always excellent Patrick Logan -- Daniel Friedman: The Role of the Study of Programming Languages in the Education of a Programmer.

Some key quotes:

On the lack of tail call support in Java:
Guy Steele...was promised back in 1997 that this flaw would be fixed. Here it is 2001 and there is still no resolution of this problem on the horizon.
Emphasis mine. The more things change...

On Friedman's own background and educational goals:
Later, I wanted to be able to implement a language per week.
Followed later by:
I want the student to be able to implement (perhaps crudely) every language that they study...
Now that's Thinking Different.

Friedman quoting Jonathan Sobel, a former student who successfully used (uses?) these concepts in practice:
Efficiency comes from elegant solutions, not optimized programs. Optimization is just a few correctness-preserving transformations away.

Finally, and perhaps my favorite, Patrick Logan's cogent take:
Probably programming in C itself (or Java or Scala) is a kind of premature optimization.

WARNING: Refers to -- and poses some examples in -- the lambda calculus. Implementations in Scheme. Don't let either of those put you off, though. I don't understand every line of code (yet), but I've seen enough to be inspired to figure it out.

Challenge yourself.

Java Generics Broken? We Report, You Decide.

2008-01-04T12:46:00.000-07:00

Since I've been taken to task in the past for my cogent observations of Java's, um, shall we say "unintuitive" behavior, particularly in the era of generics and autoboxing, I'm just going to put this one out there without making any (public (explicit)) value judgments.

So it seems that if you define a method thusly (note: requires Java 5 ("Gangly Geek") or ~~better~~ ~~greater~~ having a numerically higher version number):

public void doSomethingGenerically(Collection<Supertype>){...}

and you attempt to call it thusly:

List<SubtypeOfSupertype> bogus = new ArrayList<SubtypeOfSupertype>();
doSomethingGenerically(bogus);

you get a compiler error saying you can't call that method with those arguments.

So my question here is: why the heck not?

Inheritance 101: a List isa Collection, right? A SubtypeOfSupertype isa Supertype, right? So why am I being told that an instance of type List<SubtypeOfSupertype> isn'ta Collection<Supertype>?

Paging Dr. Liskov...

Blast From the Past: HP 11C

2007-11-12T21:00:00.001-07:00

Whilst doing some major cleaning up / throwing away of some of my accumulated junk this weekend, I came across my scientific calculator from college.

"Big deal", you say? Maybe so. But this thing is 23-24 years old, which is about 2400 in computer years, which puts it close to the technical definition of "antique". (Author's Note: We won't get into what that makes me...)

Still not impressed? The thing still works. With the original batteries.

You read that right. After a year or so of use, every time I turned the thing on I would wonder if this was the day I was going to have to change the batteries. Nearly 25 years later, that day still hasn't come. Now granted, for the past several years I wasn't even sure I still had it. But when I came across it in my junk-cleaning I couldn't resist the temptation to try it out. I suppose I should've been surprised, but I wasn't really.

I'm telling you, this is the Calculator That Time Forgot. This is the Calculator of Dorian Gray. I'm going to have to hold some kind of ceremony when it finally does give up the electronic ghost. But I'm not holding my breath.

Strike!

2007-11-06T08:26:00.000-07:00

Dear Striking Writers Guild of America People,

First off, let me just say that I in no way want to impede your constitutionally protected right to effectively quit your jobs and be guaranteed that you'll get them back once your demands are met. That is some constitutionally protected right, right there. Anyways, God love you and I hope you get your residuals. Power to the proletariat, and all that.

But I do have a favor to ask. You see, the only new thing on TV for a while is going to be news footage of your picketing, and I think you owe it to yourselves (not to us, don't get me wrong here; you're on strike, I get that) to punch up your picketing chants a little. Maybe it's just me, but I kind of expect your strike chants to be more...I don't know...pithy? Trenchant? Heart-wrenchingly but ultimately stirringly observational of the Human Condition?

I mean (this is an actual WGA picket line chant): "Why make the viewers wait? Why won't you negotiate?". Really? That's the best the WGA -- the WGA! -- could come up with? I realize you're doing what you do best -- rehash old material -- but come on. You have so much better old material to work with. Some suggestions:

We won't write another role! *bleep* you, *bleep*hole!

More new films for Jean-Claude Van Damme? Frankly, my dear, I don't give a damn!

Did Tony Soprano's family get whacked? We won't tell you, 'cause we're so hacked!

No more Die Hard on Blu-Ray! Mother *bleep*er, yippie-ki-yay!

Won't give us the money we lack?! Then the Terminator will never be back!

You could go the nostalgic route, and remind us of everything you've done for us in the past, and what we'd be missing without you:

Star Trek! Numb3rs! Stand By Me! No Wil Wheaton on TV!

Or, and this is my favorite option, you could go beyond the traditional chant-based approach and actually stage your picket lines like the different genres you write for. You guys are writers, for pity's sake! You need to keep your chops up. Everyone who isn't actually walking a picket line at the moment could meet in the bullpen:

Fade In. Cue cutesy beginning-of-scene jingle. A group of writers are sitting around a table.

Head Writer: Okay, people, we've got a strike to write here. Who's got some ideas? Let's shoot it around the room!

Writer 1: We could get the cast of Friends to sit around on some comfy chairs on the picket line and make wisecracks about how lame it is that the producers won't give us any more money! David Spade could guest star, which will eventually get us Heather Locklear! And Jerry Stiller could walk in and start yelling his lines incoherently until Jason Alexander gets so worked up that he has to leave. Let's leave what's-his-name-the-guy-who-played-Kramer out of this one, though, huh?

Writer 2: Oooh! Crime drama! We could get David Caruso to do that thing he does in, like, every SINGLE SCENE where he has any dialogue! You know -- he stares moodily into the distance while delivering the line and then, at the very end, just when you think he's not going to, HE SWIVELS HIS HEAD to look directly at whoever he's talking to! It's brilliant, I tell you!

Smash cut. David Caruso is standing at the counter at a Starbucks.

Perky Starbucks Babe: (perkily) Can I take your order, sir?

David Caruso: (staring moodily into the distance) Yeeessssssss. I believe I'll have a (swivel) latte.

Wipe transition. We are back in the bullpen.

Other Writers: (all at once)...Caruso...brilliant...NYPD...movie "career"...hahahahahahahahahahahahahahahahaha!

Writer 3: How about a reality TV angle? We could have one of the picketing writers get ragged on by all the others until he snaps and puts Billy's hand in warm water while he's sleeping and then schemes with Maggie and Amber to get Chuck and Bruce voted out of the picket line only to double-cross them by "accidentally" tripping Maggie during their mambo and telling Amber she's too fat for him to marry her so she bursts into tears and can't do her Billy Idol tribute number so she runs off to build houses and stuff for the poor until she gets noticed by Donald Trump who makes her his new wigtender! Simon Cowell could be the judge!

Writer 4: I've got it! Let's get the writers for Saturday Night Live! They've been on strike for, like, eight years now, only no one told Lorne Michaels so they still get paid...

Fade out. Mercifully.

Remember now, I'm asking this favor for your sake, not mine. I'm not going to be affected one way or the other. You think you're "hunkered down for a long one"? Kid, I've got all the Harry Potters and the Lord of the Rings trilogy on DVD. Extended Director's Cut Version With Commentaries and Making-Of Featurettes. You won't be seeing me for months!

LaTeX For The Win!

2007-11-05T22:16:00.000-07:00

Yeah, yeah -- I feel a little silly making a big deal about having just now become a convert to LaTeX. It's like wandering into a room of World-of-Warcraft-playing geeks and bragging about "this super-cool game I found; it's called 'NetHack'!"

But dang! I can't believe I made it through two-thirds of a Master's degree in computer science without even trying this brilliant tool. I mean the quality of the output (okay -- the quality of the typsetting; the actual semantic content is still GIGO) makes even the most mundane homework assignment look like something that's going to be published in some major journal any day now.

The key was in resolving to take the first step. I was dreading it, but I found that forcing myself to do that first assignment in LaTeX let me pick up probably 80% of the formatting tricks I'll ever need. Definitely worth the effort.

LaTeX strikes me as a perfect example of what Kathy Sierra used to blog about (Author's Note: Hi, Kathy! Come back! We miss you!): software that lets you (me) KICK A**! It's a software tool, but it has one key characteristic of the best physical tools as well -- it takes a modest force as input (your (my) typing), and amplifies and concentrates that force to shape an output that you (I) could not have achieved with your (my) bare hands.

Simply put: LaTeX rocks.

I just hope TeXShop -- which is the front-end I use on my Macs -- plays well with Leopard. There aren't a lot of issues I can think of that would keep me from upgrading, but losing LaTeX/TeXShop would definitely be a showstopper.

Fun With Scala: Reading Scala

2007-11-01T22:53:00.000-06:00

No, I haven't given up on my quest to learn more about Scala by perusing the guts of the liftweb source code. It's just that Iteration 3 at work, along with Hallowe'en with my two-year-old and Exam Two in Theory of Automata have all combined to kick my butt for the past couple of weeks. Not to mention all of the other life stuff that's intervening.

But no excuses! Let's have a look at some specific Scala code and see what we can figure out in general from it.

Today's snippet of Scala code is brought to you by net.liftweb.util.Helpers.scala, for those of you following along in the book. I've elided a lot of it, for the purposes of this post. Here are the relevant lines of code, suitable for entering into your scala interpreter:


import java.text.SimpleDateFormat
import java.util.TimeZone
val utc = TimeZone.getTimeZone("UTC")
def internetDateFormatter = {
  val ret = new SimpleDateFormat("EEE, d MMM yyyy HH:mm:ss z")
  ret.setTimeZone(utc)
  ret
}

Besides the lack of semicolons (yea!) and the use of some standard Java classes (likewise yea!), one of the first things to notice is that utc is declared as a val, while internetDateFormatter is declared as a def. You can probably intuit the difference, but we'll see some examples in a moment of just how they're different. Also, notice that neither utc nor internetDateFormatter is given an explicit type. Each has a specific type, determined by the type of what's on the right hand of the assignment, but the compiler doesn't need to see the type declared on the left hand side. This has some consequences that we'll see too.

Finally, the definition of internetDateFormatter ends simply with the line ret. This idiom will be familiar to the Ruby programmers in the audience, as it simply declares what the ultimate value is of the block that constitutes the right hand side of the assignment to the variable internetDateFormatter. That is, in Scala, as in Ruby, the value of a block is the value of the last statement executed within the block.

Try entering the above code, line by line, in a scala interpreter. The imports aren't that interesting, but notice what you get as a result of entering the declaration of utc:


scala> val utc = TimeZone.getTimeZone("UTC")
utc: java.util.TimeZone = sun.util.calendar.ZoneInfo[id="UTC",
    offset=0,dstSavings=0,useDaylight=false,transitions=0,lastRule=null]

Which says that utc is of type java.util.TimeZone, and in particular it is equal to a sun.util.calendar.ZoneInfo with the corresponding id, offset, etc. Whereas when you finish declaring internetDateFormatter, you simply get:


scala> def internetDateFormatter = {
     | val ret = new SimpleDateFormat("EEE, d MMM yyyy HH:mm:ss z")
     | ret.setTimeZone(utc)
     | ret
     | }
internetDateFormatter: java.text.SimpleDateFormat

Now you can start using internetDateFormatter as you would any instance of SimpleDateFormat. For example:


scala> internetDateFormatter.toPattern()
res8: java.lang.String = EEE, d MMM yyyy HH:mm:ss z

Even more fun is this: now you have a result (res8, or whatever pops up for you), which is a java.lang.String, and can be treated as such:


scala> res8.split("\\s")
res9: Array[java.lang.String] = [Ljava.lang.String;@66718

scala> res9.toString()
res10: String = Array(EEE,, d, MMM, yyyy, HH:mm:ss, z)

(Author's Note: Have you ever wanted an irb (the interactive ruby interpreter) for Java? Download Scala, and get one for free today!)

So what about the difference between declaring with val and declaring with def? Let's find out:


scala> utc = TimeZone.getTimeZone("GMT-7")
line19$object.$iw.$iw.utc = TimeZone.getTimeZone("GMT-7")
:6: error: assignment to non-variable 
  val res12 = {utc = TimeZone.getTimeZone("GMT-7");utc}
                   ^

Uh-oh. Looks like Scala considers vals to be constant. Although:


scala> val utc = TimeZone.getTimeZone("GMT-7")
utc: java.util.TimeZone = sun.util.calendar.ZoneInfo[id="GMT-07:00",offset=-25200000,dstSavings=0,useDaylight=false,transitions=0,lastRule=null]

It also looks like some constants are more constant than others. But before you start thinking you can just reassign internetDateFormatter with impunity:


scala> internetDateFormatter = "impunity"
:5: error: value internetDateFormatter_= is not a member of object $iw
  val res13 = {internetDateFormatter = "impunity";internetDateFormatter}
               ^

Whatever that means. I'm going to have to track that one down and report on it later. Right now it's time for more life (read: "sleep") to intervene.

Fun With Scala: Things I'm Learning From Lift #2

2007-10-22T13:55:00.000-06:00

Thanks to astute reader Ken (Author's Note: I have a reader! An astute one! Who knew?!), I learned something about a feature I was bragging about in my last post; namely, the ability to import members of a class. As it turns out, not only is this feature present in Java 5 -- see the documentation for static imports -- the Scala version of it is pretty much equivalent.

Ken points out that my example of lift importing the members of the net.liftweb.util.Helpers "class" maps exactly to the corresponding Java import. I waved my hands around the fact that Helpers is actually an object, which is, simultaneously and at the same time, Scala's way of denoting a singleton and providing static members (all of the members of an object are effectively static). But it turns out that the import syntax I was bragging about works precisely because Helpers is an object and not a class.

Here's some lame, contrived, forced-example, somewhat-minimal Scala code to demonstrate:


Mixee.scala

package bogus;

class Mixee {
 def weird: String = {"Weird Al!"}
 def twentySeven: String = {"27!"}
}

Mixer.scala

package bogus;

import Mixee._;

object Mixer {
  def main(args: Array[String]): Unit = { Console.println(weird); Console.println(twentySeven) }
}

As described here, Mixer.scala will refuse to compile, with the error: "not found: value Mixee". This is because Mixee is defined as a class. Change class to object and it compiles (and runs) just fine.

Bonus Discovery: While researching this, I also learned that Eclipse with the Scala plugin is not as smart as it should be about building my bogus project. If I start with a clean compile (i.e., defining Mixee as an object), Eclipse is happy. If I then change the definition of Mixee from object to class, the error doesn't show up until I force a rebuild by selecting Project -> Clean... If I then change class back to object, the error goes away without my forcing the rebuild.

Anyone got a line on that? Ken? Anyone?

Anyway, just for the record, my purpose with these posts is not to bury Java, but to praise Scala and learn how it's different. I'll leave the determination of whether Scala is "better" than Java up to you, my readers. Both of you (hi, Mom!). ;-)

Fun With Scala: Things I'm Learning From Lift #1

2007-10-16T21:55:00.000-06:00

So I'm starting somewhere around the very beginning with the Liftweb framework: LiftServlet.scala, which is in the net.liftweb.http package. This looks like Lift's answer to a Rails controller, or a Struts Action (Author's Note: probably with some caveats that I haven't found yet; (pleasant) comments welcome if I'm wrong about this).

Fun Thing #1: The very first import is

import javax.servlet.http.{HttpServlet, HttpServletRequest , 
          HttpServletResponse, HttpSession}

How's that for interoperability with Java? I haven't gotten that far yet, but this tells me that whatever Lift uses for its request/response implementation is going to conform to the usual Java interfaces. And how do you like the syntax for this style of import? I like it a lot, because it lets you do the equivalent of:

import javax.servlet.http.HttpServlet
import javax.servlet.http.HttpServletRequest
import javax.servlet.http.HttpServletResponse
...et cetera...

...on a single line (it's a single line in the original source; I've split it here for friendlier rendering). Without resorting to importing everything in the http package with a wildcard. This way you get to see exactly what you need. Yeah, I know a good Java IDE will manage the imports for you, so it's not as much of a pain as it used to be, but I like the compactness of this syntax. As it happens, the current version of the Scala plugin for Eclipse doesn't have the equivalent of "Organize Imports", so this syntax is definitely a boon.

Fun Thing #2: There's a syntax for importing not just classes, but members of a class. Like so:

import net.liftweb.util.Helpers._

This basically says "make everything in the Helpers class (actually it's a singleton object, but think of it as a class for now) available to this class without my having to qualify it with 'Helpers.' all the time".

For example, there's a bit of code in LiftServlet that goes like this:

val md = parseInternetDate(mod)

This makes it appear that parseInternetDate() is defined in the LiftServlet class. But it's not. It's defined in Helpers. If you're used to modules/mixins in Ruby, this should seem very familiar to you. If not, now might be a good time to get used to them, because they're way cool.

Fun Thing #3: No, the lack of semicolons at the end of the code samples is not a typo. The Semicolon is Dead! Long Live the Semicolon! No, scratch that -- Long Live Scala!

Fun With Scala: Liftweb Getting Started

2007-10-14T22:25:00.000-06:00

Job one: checking out and Eclipsify-ing lift.

The instructions at the CircleShare lift blog are still current up to a point, at least as far as the prerequisites are concerned. I'm running from trunk, so my source code checkout was a little different:

svn co http://liftweb.googlecode.com/svn/liftweb

After that, the available instructions need a little (ahem) updating.

For a quick look at the kinds of things you can do with lift, run mvn install in the liftweb (top level) directory to build everything. When that's done, cd sites/project_name, where project_name is one of example, hellolift, or skittr. From there, run mvn jetty:run to start a Jetty web server running on some port on localhost. At this writing, example and hellolift run on port 8888, while skittr runs on 8889. Don't ask me why.

You can also mvn install individual projects if you want, but I don't see any harm in building them all in one shot.

To Eclipsify, make sure you have the Scala Development Tools plugin installed, then run mvn eclipse:eclipse in the project you want to be able to work with in Eclipse. You can do this for the lift source code itself (under the liftweb/lift subdirectory), or any of the example projects (liftweb/sites/project_name where project_name is as above).

Happy Lifting!

Fun With Scala: Liftweb

2007-10-14T22:09:00.000-06:00

In my last post, I poked some serious fun at a bunch of mainstream languages (actually, their Internet communities), but left Scala pretty much alone. I chose Ruby and Java as my main characters because those are the languages I read the most about, and whose pundits' positions I felt like I could parody most accurately.

I've been interested in Scala since I first came across it, but I haven't really had to time to do much with it. I like its functional leanings, and I am intrigued by its ability to run on the JVM and interoperate seamlessly with existing Java libraries. Although when I say "interoperate", I have to acknowledge that it's a one-way street, as far as I know. Scala code can certainly invoke methods on Java classes. I have yet to figure out how to make the reverse happen (not that I've tried very hard). If I can, I will definitely try to make use of that capability.

So I've decided to do something real with Scala, to force myself to get to know it better. I've chosen Liftweb as my target project, largely because it's there and it's the only substantive chunk of Scala code I've found. You may have read about its claims to be able to implement a full-on Twitter clone in less than 1000 lines of code, with the capability of handling one million or more users on a single commodity PC.

Attention has been paid.

The Last Language War / Language Trolling Post You'll Ever Need To Read (Hopefully)

2007-10-03T22:05:00.000-06:00

Moderator: Greetings, and welcome to the First-And-Possibly-Last-Ever Pan-Computer-Programming-Language Conference (FAPLEPCPLC). I am joined on stage tonight by many distinguished, high-profile computer programming languages. Each is highly regarded by its devotees, and I for one look forward to hearing what each has to say.

Ruby (grabbing the microphone): Um so yeah I'd just like to kick this bad boy off by saying that THE REST OF YOU SUCK A**!!! Yeah, I said it! The A-word! A**! Oh yeah! Boom, baby! Woo! Ruby FTW!

Java (rolling its eyes): Oh, real mature. I, on the other hand, would like to state that I have important work to get done in the Enterprise, so let's not waste everyone's time. I suggest we proceed using the Computer Programming Languages Discussion Pattern as implemented in JSR-6942, the Java™ Absolutely Void-of-Acronyms Talking About Languages at Konferences (JAVATALK™ which by the way is not an acronym for anything) specification.

Ruby: Dude! I just wrote a full working clone of Google while you were giving your riveting little speech there!

Moderator: Oh, bravo, Ruby! I'd like to see that. Where is it deployed?

Ruby: Umm....

Lisp: In the beginning, there was the Lambda. And John McCarthy saw the Lambda. And John McCarthy saw that the Lambda was very good.

Ruby (rolling its eyes): Here we go...

Lisp: And John McCarthy spake, and lo! the tongue he spake was sexp...

Ruby: He said sex! Heeheeheeheehee!

Erlang: If I may, I've been running some ideas by the other panelists, all at the same time of course, not that that's any big deal...

Ruby (rolling its eyes): And here we go with the concurrency...

Java: Gosh darn it, Ruby! There's no need to pooh-pooh everything someone else says, eh?

Ruby: He said poo-poo! Heeheeheeheehee!

Java: Ruby, I swear, one of these days...

Ruby: Hey, don't give me any of your static! Heeheeheeheehee! See what I did there?! "Static"?! 'Cause I'm so dynamic?! GET IT?!!! DAMN, where's my BAWLS Guarana...?

Ruby (seconds later): I said balls! Heeheeheeheehee!

C#: Developers! Developers! Developers! Developers!

Erlang: ...I'd share my results with you, but it's going to take a while to retrieve them from the filesystem...

COBOL: keels over, only to be frantically revived by about three banks.

Basic: Actually, I have a question for Ruby...

Haskell: Me too...

ML: Hey, Ruby, what's your answer to...

Ruby: Hey, hey, hey now! Not too many at a [segfault]

Java: smiles

bash: kill -9 self

The Lambda Calculus: Actually, if we could all just take a moment to reflect on the implications of the Church-Turing thesis...

Everyone Else: Oh, SHUT UP!!!!!!

Scala: says nothing, but sits quietly observing, taking notes, and learning a lot.

Moderator: Well, I think it's about time to bring some closure to this, um, lively...discussion...

Java (sharply): Hey! We're working on it!

Lisp: ))))))))))))))))))))))

Java 1, Intuition 0

2007-10-03T18:13:00.000-06:00

Pop quiz: If you were given the following snippet of code:

"".split("\\s");

...what would you expect the result to be?

If it helps, the contract for String.split() is that it takes a regular expression (in this case \s means "anything that could reasonably be considered whitespace, like spaces, tabs, et cetera"), and returns a String[].

My intuition was that it would return an empty String[]. (Author's Note: which would have been better than a null, but even that's not what I got.)

I mean think about it: what does it mean to split the empty string, on any character? The empty string has length 0, so what can you split it into? Two strings of length 0? But then you could do that ad infinitum, which would be silly.

So what Java actually does is return an array with one string: the empty string, or one string of length 0. Which implies that Java thinks the beginning of a string -- represented by the regex \A, or ^ if you know the string you're regex-ing doesn't contain newlines -- is significant, but the end of a string (\Z or $) is "whitespace". I guess you could make a case for this making sense, but it doesn't match up with my intuition.

What do you think?

There and Back Again: PHP to Rails to...PHP?

2007-09-22T22:01:00.000-06:00

Well this is going to generate some controversy. CDBaby's adoption of Rails was touted as a major coup for for the switch-to-Rails, it's-not-just-for-green-field-projects movement.

Please note that I don't have a dog in this particular fight. I spent last year developing Rails webapps, and I enjoyed it. I've never done any non-toy PHP development, but I would if the occasion were to arise. Right now I'm back squarely in the Java camp for the foreseeable future. If I were inclined to switch to anything else, it would be Scala, which is shaping up to be a (much) better Java than Java.

While Java is playing catch-up to features the designers deliberately left out in early releases, Martin Odersky and team have quietly built up a nice little language that leverages all of the strengths of the Java platform, while neatly sidestepping the weaknesses of the Java language. It is easy to learn if you already know Java, and extremely powerful if you know functional programming. Toss in an abundance of well-written, well-thought-out documentation, and you have to start thinking that we just might be looking at the Next Big Thing in programming languages.

Scala Alert: bootclasspath/a Considered Canadian

2007-09-20T22:53:00.000-06:00

Author's Note: Please forgive what is, essentially and unfortunately, a very bad pun. It's late, and I've had a long week, what with my Automata exam coming up and all. And, for the record, I have nothing against Canadians. James Gosling is Canadian. So is William Shatner. I once lived in Vancouver. Please don't hate.

So I was looking at bin/scalac and bin/scala, the Scala toolset equivalents of javac and java, and I found myself learning some stuff. For instance, scala (which executes a Scala, um, executable) is simply a shell script that sets a bunch of shell/environment variables and finally runs this command:


${JAVACMD:=java} ${JAVA_OPTS:=-Xmx256M -Xms16M} -Xbootclasspath/a:"$BOOT_CLASSPATH" -cp "$EXTENSION_CLASSPATH" -Dscala.home="$SCALA_HOME" -Denv.classpath="$CLASSPATH" -Denv.emacs="$EMACS"  scala.tools.nsc.MainGenericRunner  "$@"

This points out some interesting interestingness. First off is: Scala executables are ultimately run by...java! Or what passes for it on your system. Pretty neat, huh? Although it makes total sense if you think of java as the command that starts up a JVM on some arbitrary .class file, not the command that runs a Java(TM) language program.

(Author's Other Note: Scala code gets compiled to JVM-compliant bytecode. Which is proof that real closures are theoretically possible in Java(TM). Although they are not likely to happen in your lifetime. But I digress.)

Second off is: buried amongst the options to java is the non-standard -Xbootclasspath/a:"$BOOT_CLASSPATH". Unlike plain ol' -Xbootclasspath, this option lets you append some arbitrary jars to the regular bootclasspath (hence the /a). In this case, what it appends is $SCALA_HOME/lib/scala-library.jar if it exists, which gives the executable access to the Scala standard library. Which includes among other things the package that implements Scala Actors.

P.S.: It turns out there's also a -Xbootclasspath/p, which stands for "prepend", but is not as funny when applied to Canadians.

P.P.S.: I like the option to provide a default value for some environment variable that may not exist on a given system (e.g., ${JAVACMD:=java}).

P.P.P.S.: EMACS??? What the heck does that have to do with running a Scala executable? Time for some more research, eh?

Scala: The Next Next Java!

2007-08-17T11:32:00.001-06:00

Yeah, yeah. I know. It's only been recently that Erlang has started being touted as "the next Java". I just thought I'd get a jump on crowning the next next Java. Oh, sure, no one gets to officially be The Next Anything without a Pragmatic Bookshelf book backing it, but I'm sure it's just a matter of time before a Scala book is announced.

After all, Scala shares a lot of the advantages of Erlang -- principally, its support for Actor-based concurrent programming and hence its powers of super-scaling. But it also has a secret weapon that Erlang doesn't have: it runs on the JVM! Yes, that JVM! It also has access to the multitudinous multitudes of existing Java libraries out there, making for a (potentially) easier migration path.

No need to wait for Java 7 (or (possibly much (much)) greater) for closures in Java! Write some Scala scaffolding around your existing Java classes and have them today!

Le roi mort! Vive le roi!

The Good, The Snide, and The Ugly (More on Autoboxing)

2007-08-09T09:21:00.000-06:00

Wow. You know you've hit the big time when famed Java geek author Norman Richards gets all snarky on your sh*t. I would like to point out, though, that I never said autoboxing was "evil". I just said it was !cool. And no amount of Richards' sarcastic aping of my (deliberately) satirical-yet-lighthearted take on it is going to convince me otherwise.

The problem, of course, lies in the fact that, pre-autoboxing, there was no question of an assignment to a variable of type int throwing an NPE. For the first 87% of Java's numerical-version-life you just couldn't do it. The concept had no meaning, like the questions "what is north of the North Pole?", or "what color is up?". Or "can I borrow your copy of 'XDoclet in Action'?" (Author's note: because no one in my office has one).

Pre-autoboxing, Eclipse would have flat out disallowed the assignment of an Integer to an int. And here's the important point: Eclipse would have disallowed it, because the compiler would have disallowed it. Because you couldn't assign an object reference to a primitive type, inadvertently or advertently. It wouldn't be a legal assignment, so it wouldn't compile, so there would be no way for it to throw an NPE in production. That's what static typing is supposed to ensure.

In true famed Java geek author style, though, Richards totally misses the pedagogical point when he uses as his sarcastixample the potential NPE-ness of code that deals with String. Which is an object type. Which has since the beginning of Java time been subject to NPE's. As opposed to primitive types. Like int. Which have not. Until autoboxing rocked our world and broke static typing.

I've actually been waiting for someone to snark on my (deliberately) satirical-yet-lighthearted insinuation that I rely too much on my IDE. That was the first point I took away from this whole exercise, and believe me I will be more wary in the future. I'm pretty sure I'm not the first to be burned by such an over-reliance. But in this case, even if I were using Emacs and the command line, I would still have fallen victim to this problem. The fault lies in the language, not in my reliance on any tool.

Bottom line: I don't think it should be too hard to excuse someone who, when seeing an NPE in his stack trace, doesn't leap immediately at the assignment to the int variable.

But maybe that's just me.

Autoboxing == !Cool

2007-08-07T15:23:00.000-06:00

So you're finally getting used to the idea of Java 5's "feature" of converting between primitive types and their corresponding object wrappers (e.g., int -- Integer). You're getting to the point where you kind of trust it. You're even getting to the point where you kind of rely on it. Life is good.

Then you go too far and try something weird and exotic like, oh, I don't know:

int sucker = thisMethodReallyReturnsAnIntegerNotAnInt();

No squiggly red line in your Eclipse editor. Cool! That must mean this will work! Because Java has static typing, and you can count on that! Yea you!

The problem is, it will work. It will work very nearly all the time. It will work until your method returns a null instead of an actual Integer. At which point you'll get a NullPointerException buried in your Struts 2 / OGNL / JSP project's Eclipse console stack trace, followed by a two-hour detour into the debugger wondering what the heck is going on. I mean after all, your code compiled, right? It worked for the first hour, right? Static typing is good, right? Autoboxing works, right?

Not that you're bitter.

Starting up a VPS on Slicehost

2007-07-09T10:16:00.001-06:00

Author's Note: None of the following is intended to portray any of the companies named in an unflattering light. There were good things about all of them, along with the not-so-good. They all have their fans and their detractors. However, you know that phrase we geeks use when talking about our experiences with things technical? YMMV? Well, my mileage varied, considerably. To the point where I changed vehicles.

My first experience with running Rupp Consulting Services, LLC on VPS (Virtual Private Server) was with Rimuhosting. This was after some, shall we say, sub-optimal experiences with, in chronological order, Yahoo!, Textdrive, and Dreamhost. I went to VPS primarily to relieve the pain of memory/resource constraints/contention, and the inevitable shared downtime that comes with running a shared server.

Rimuhosting, I must say, were great about functionality and support. I left them only reluctantly, having decided to farm out my email and my blog to Google, and not seeing the need to pay for my web presence. Well, that lasted about a month, and I've decided to jump back in. I considered going back to Rimu, but something I read on a blog convinced me to give Slicehost a shot. So far I'm glad I did.

For $20/month, I get root access to my very own "slice" with 256MB memory, 10GB storage, and 100GB bandwidth/month. This compares to 96-128MB / 4GB / 30GB bandwidth on Rimu for the same price. You have to move up to Rimu's $40 plan to even get close to these specs (224MB / 4-8GB / 60GB). So space and bandwith are not a problem. However I do expect to bump up against my memory limit once I start doing any serious Rails development, which is my primary reason for getting back in the VPS game.

One of the reasons for this post, in fact, is to document some of the extra work I had to do to get Ruby and Rails going once my slice was up and running. First, I followed the instructions here to lockdown logins and SSH ports and stuff.

This is one of the first chances Slicehost had to shine. You see, I stupidly locked myself out after the last step (installing the iptables firewall). Slicehost provides an Ajax-based console for just such an occasion. Unfortunately, that wasn't working for me (note to self: enable cookies in Safari next time!), so I needed an even more drastic solution: rebuilding my slice. Fortunately, I was only backing out 10 minutes of work, so this was a viable option. Again, Slicehost really shines here by letting you rebuild automatically from an option on their management screen. A few clicks of the mouse and five minutes of waiting and I got to start fresh, this time being more careful with iptables and actually proofreading my changes and stuff. Amazing what that will do.

Then it was on to installing Ruby, et al. The yum package manager is your friend here. I considered downloading and building everything from source, but that takes a lot of time, and I'm actually becoming a fan (thanks to MacPorts on my home machines) of the whole package management concept. So a quick yum install -y ruby got me started.

Apparently, though, Slicehost installs a very slimmed-down version of Fedora, as I discovered when I tried to yum install -y rubygems. I had problems with missing libraries, which I was able to cure with yum install -y ruby-devel. Which exposed some other missing goodies. Rinse, lather, repeat.

Long story short, here's what I ended up having to yum install to be able to build native extensions for gems and do other *nix hackery I'm used to being able to do out of the box:

wget
make
which
tar
gzip
gcc

I've also installed nginx (vice Apache), mongrel, subversion, and mysql - the usual suspects. nginx works as advertised, and one Mongrel instance handles my Mephisto-generated site traffic nicely. Just that, though, is enough to get me close to 200MB, and that's without the Trac instance I plan to install later. So I may be upgrading my plan even sooner than I expected.

On the Importance of Being Multi-Lingual

2007-06-27T11:32:00.001-06:00

My day job is currently focused on porting an Eclipse RCP ("Rich Client Platform") Java application -- essentially a WORA desktop app -- to a Struts2/JSP/Hibernate webapp. We're using a fair amount of JavaScript (via Prototype and Scriptaculous, along with some home-grown code) for the things you'd normally use JavaScript for. Nothing out of the ordinary there.

One of the home-grown JavaScript bits that I've been working with recently is a text-box filter. You type in the text you want to filter on in a text-box, and the table rows (or li's, or what-have-you) that don't contain that text get hidden, leaving only those that pass the filter. Again, pretty standard stuff.

The fun started when I wanted to add the ability to filter not just on text, but on a time range chosen from a dropdown menu, like, say, "show me only the results that were posted within the last two hours". I wanted to re-use the existing filter code as much as possible, because a lot of it is exactly what I need, but I needed a way to specify comparing two times (the time of each post versus the time range selected) instead of the default behavior of checking for a match on the input text.

(Author's Note: Those of you who are familiar with Ruby probably already know exactly where I'm going with this. Bear with me while I build the suspense a little longer).

If the filter were written in Java (pre-closures Java, anyway <wink/>), I would have no choice but to jump through some serious refactoring hoops -- implement the new behavior, probably as a new set of methods, and then add in some way to designate which behavior I wanted either by introspecting on my arguments, or by an explicit switch, or...yuck. And if I were only aware of Java idoms, there would be nothing stopping me from taking the same approach in JavaScript.

Fortunately, I spent the bulk of last year doing some serious Ruby programming, which forced me to get used to the idea of blocks. Equally fortunately, I've taken some time to get familiar with idiomatic JavaScript programming, and learned that functions are first-class datatypes in JavaScript, which means they can work pretty much like blocks do in Ruby.

And so I was able to solve my problem with minimal impact to the existing codebase, by adding a parameter to the constructor (an optional block/function, defaulting to the existing "match" behavior), and making the code that does the actual filtering call that anonymous function rather than explicitly calling "match". One optional parameter and one (tiny) layer of indirection later, and I've got a solution that will never need extending again. The next time I come up against a type of filter that I haven't already implemented, I can do so on-the-fly, by building a function that implements the exact comparison behavior I want and passing it to the generic filter.

Do yourself a favor: stop hating on Ruby because you're irritated by all the attention it gets. Stop assuming that if you learn idiomatic Ruby you're going to have to turn in your "Java ROOLZ, Ruby DROOLZ" badge and your "I (heart) static typing" secret decoder ring. Free your mind, and the rest will follow. And whatever other inspirational pop lyric you care to apply here.

Learning another language (doesn't have to be Ruby; could be Python, or Lisp, or Erlang, or Scala, or...) can only increase your problem-solving capability. And, after all, isn't that what we're all about? Solving problems?

meme.lolcats.die.die.die

2007-06-25T09:26:00.001-06:00

The title says it all, really. But I hate one-liner blog posts, so here are some other "memes" that I'd really, really like to see go away:

`meme.edgy.job.posting.die.die.die`

Whenever I see a job posting like this:

SELECT * FROM applicants WHERE knows_php=1 AND has_life=0
ORDER_BY tattoo_count DESC;

I simply:

DELETE FROM jobs_i_am_interested_in WHERE employer=that_loser;

I mean think about it. If you're that darn clever, what do you need me for? And what happens if you do hire me and I turn out not to be clever enough for you? Why should I leave my current position (which is at a pretty awesome startup, btw) for the eventual:

INSERT INTO ranks_of_the_unemployed VALUES(that_chump_who_answered_our_lame_job_posting);

Same goes for any company looking for any kind of "programming god", "rock star", or "l33t hax0r". In fact, if any part of your job post is ultra-snarky, ultra-hip, or smacks of leetspeak, there's a good chance I will sprain my finger deleting it. I know you're trying to be, like, all Web-Too-Oh and everything, but who do you think you're fooling? In RL (author's note: "Real Life") you're in your late 40's, and the closest thing you have to "l33t cr3d" is the time you virtually hit on that brooding emo chick whose profile you happened across while prowling MySpace. (Which, by the way -- ewww).

However, we both know that at the end of the day, you're still going to be a clock-watching, interchangeable-human-resource-administrating, two-martini-lunch-taking, office-chair-warming executive type with a pathological distrust of technology. And I'm still going to be a code monkey. So let's just call a spade a spade, shall we?

`meme.verbing.die.die.die`

"Incentivize". "Monetize". "Reify".

Gagize me.

Verbing weirds language -- Calvin, of Calvin and Hobbes

`meme.meme.tag.die.die.die`

Look, if I really want you to know about my third lung or the time I gave CPR to that baby seal in Alaska, chances are you're my wife or my physician and I've already told you. Otherwise, buzz off.

Hear, Hear! (A Postscript to My Take on Closures in Java)

2007-06-19T15:08:00.001-06:00

From Revised Report on the Algorithmic Language Scheme, Introduction, Paragraph 1, Sentence 1:

Programming languages should be designed not by piling
feature on top of feature, but by removing the weaknesses
and restrictions that make additional features appear necessary.

P.S.: This was written 'way back in 1998. Another fun quote:

Those who cannot remember the past are condemned to repeat it. -- Santayana

Hacking JRuby: More on Method Arguments

2007-06-13T14:05:00.001-06:00

I closed my last post with this observation:

"...JRuby does not have an equivalent for rb_scan_args(), or at least not one that is called on a per-method basis."

In the comments, Ola Bini -- ThoughtWorker and JRuby committer -- graciously pointed out that there are, in fact, two static methods that we can use to simulate the function of rb_scan_args(), both found in the org.jruby.runtime.Arity class: checkArgumentCount(), and scanArgs().

checkArgumentCount() does just what it says. You pass it an array of argument values, along with the minimum and maximum number of all arguments, and it verifies that the actual number of arguments falls within that range (inclusive). So this provides some basic sanity checking of the number of arguments passed to the method you're implementing. If the number of arguments is valid, checkArgumentCount() returns the actual number of arguments passed. I guess you could argue that this isn't very useful, since you already know the number of arguments you expect, as well as the number given to you. But it is used in a number of places in the JRuby source code.

scanArgs() will do a little more work for you. It will do the same sanity checking (it actually calls checkArgumentCount() to do so), although you specify the numbers slightly differently, passing the number of required arguments along with the number of optional arguments. If the actual number of arguments passed is valid, scanArgs() then creates a new array of length required + optional, copies the values of any arguments passed in (all required arguments plus any provided optional arguments), sets the values of any non-provided optional arguments to nil, and returns the new array. This actually is useful, as it transforms a variable-length array of arguments into one of fixed length, where the fixed length is always equal to the maximum number of arguments your method will accept.

As Ola points out, this still is not quite the equivalent of MRI rb_scan_args(), in that it doesn't handle "rest" or "block" arguments. But it does offload from us some of the burden of handling variable length argument lists.

I do plan to use scanArgs() to finish up my implementation of BigDecimal.mode(), but in order to so meaningfully I'm also going to have to change mode()'s method definition from taking a fixed number of arguments to taking a variable number of arguments (the first argument is required, the second is optional). That's going to involve digging into JRuby's mechanism for defining Ruby methods, which I've researched and found to be pretty cool, but it's going to take another few blog posts to sort out. Stay tuned...

Hacking JRuby: BigDecimal and Ruby Internals

2007-06-12T12:45:00.001-06:00

I've submitted another patch for JRuby (viewable here), to implement the BigDecimal.mode() class method. In doing so, I learned quite a bit about JRuby's implementation strategy, as well as the internals of the C source code for MRI (Matz's Ruby Implementation) Ruby.

`BigDecimal.mode()` explained

BigDecimal.mode() is a funky little method in the BigDecimal module, which is not part of the core API but part of the standard library that ships with Ruby. It's kind of multi-variate -- what it does, exactly, depends on how it's called.

The first parameter to BigDecimal.mode() is required, and it must be a Fixnum representing either the constant BigDecimal::ROUNDING_MODE or the exception mode to be set (more on that later). If it's BigDecimal::ROUNDING_MODE and there is no second argument, then mode() just returns the current rounding mode. If a second argument is present, it must also be a Fixnum, and it must equate to one of the seven rounding modes Ruby recognizes (e.g., BigDecimal::ROUND_UP, BigDecimal::ROUND_FLOOR, etc.). In this case, mode() sets the rounding mode (for all BigDecimals, remember, since this is a class method) to the value of the second argument.

If the first argument is a Fixnum that is not equal to BigDecimal::ROUNDING_MODE, then it is expected to have one of its bits set to correspond to one of the known exception modes (e.g., BigDecimal::EXCEPTION_INFINITY). Again, if there is no second argument, mode() simply reports the current exception mode(s) (each bit in the returned value corresponds to a single exception mode set). If there is a second argument, it must be one of 'true' or 'false'. If 'true', mode() sets the mode passed in the first argument. If 'false', mode() unsets (i.e., turns off) the mode passed in the first argument.

Simple, huh?

Not So Fast...

When I picked up this task, mode() was just a default stub that printed a message to the console and returned nil. Not a lot to go on there. So I turned to the MRI source code to figure out just what it was supposed to do.

Introducing: `rb_scan_args()`

One of the first things MRI does (in a lot of methods, as it turns out) is to call the function rb_scan_args()), which is implemented in the file class.c with the following signature:

int rb_scan_args(int argc, const VALUE *argv, const char *fmt, ...)

It takes the number of arguments passed, a pointer to a structure containing the values of those arguments, a format string of some sort, and...some other stuff. The number and values of the arguments are self-explanatory, but the format string and the trailing "other stuff" are decidedly not, so let's take a look at them.

The format string consists, minimally, of two digits. The first digit is the number of required arguments, the second is the number of optional arguments. rb_scan_args parses the format string to find these numbers, then it walks the list of argument values and stuffs each value into its corresponding reference (which is what the "other stuff" in the signature actually is: a group of references to store the values of the arguments in).

For example, BigDecimal.mode() makes this call to rb_scan_args:

if(rb_scan_args(argc,argv,"11",&which,&val)==1) val = Qnil;

In English:

get one required argument and store its value in the variable which

get the optional second argument if it exists and put its value in val

if rb_scan_args returned 1 (i.e., only one argument was provided), then set the value of the optional argument to its default of nil

So this is how MRI Ruby (as implemented in C) handles variable/optional arguments in a general way. There's more to it, of course, including an astonishing bit of hackery with C macros that actually implements putting the argument values in the right place for return. But I won't go into that until I understand it better. Also, the format string allows for the Ruby constructs of "rest args" (indicated by an '*' in the format string) and finally a "block arg" (indicated by an '&').

Meanwhile, Back in JRuby...

This has gone on a bit long, so I'll just close by saying that JRuby does not have an equivalent for rb_scan_args(), or at least not one that is called on a per-method basis. The runtime is responsible for bundling arguments and calling the appropriate Java method based on the number of arguments actually present. This causes a bit of a problem right now for class methods that take optional arguments (as BigDecimal.mode() does), but that's a subject for another post.

Umm, What Exactly Is Google Trying To Tell Me Here?

2007-06-07T11:41:00.000-06:00

Dear Google,

Look, I know this is a weblog about programming and Java and stuff, and I know you're just trying to help out with the targeted, "relevant" ads. And I'm okay with that. Really, I am.

However...

I think the whole "help out the poor, socially inept Revenge of the Nerds rejects" vibe is a bit much, huh?

Love,
David

Kickin' it Old School: Inspecting $CLASSPATH with sed and grep

2007-06-07T11:01:00.001-06:00

Here's a fun sed one-liner that I used today to break up the entries in my $CLASSPATH:


echo $CLASSPATH | sed 's/:/\<return>
/g'

Note that the <return> above means to actually hit the return key following the backslash. This bit of awkwardness is sed's way of specifying a literal newline as part of the substitution string (how literal can you get?). The net effect is to replace the colon characters with newlines, resulting in a display of my classpath with one entry per line.

I needed this in the context of figuring out a broken Ant build while testing some changes I'm making to JRuby. Unfortunately, even the pretty-printed version of my Ant classpath was too long to sift through with the naked eye, so I turned to grep to look for exactly what I needed:


echo $CLASSPATH | sed 's/:/\<return>
/g | grep jruby.jar'

That is, break up the classpath into one line per entry, and show me only the entries for jruby.jar. With this, I was able to determine that I had an older version of jruby.jar on my classpath that is incompatible with the current trunk. Problem solved!

I love a happy ending.

Rant: JSP + OGNL + Collections == Train Wreck

2007-06-05T14:49:00.001-06:00

The Story So Far

In my day job I'm using Struts 2, with JSP as the view templating mechanism. I have a collection whose size I'd like to report on the page. Unfortunately for my sanity, I have recent experience with Ruby on Rails, in which such a thing is as simple as:

<%= @myCollection.size %>

But no.

Problem #1

Struts 2 exposes properties on the Action class via OGNL, which has a nice, clean, property-based syntax, much like RHTML (which is what Rails uses for its view templates). So I should be able to ask for something like this:

${myCollection.size}

Assuming, that is, that I have a method getMyCollection() defined on my action. Which I do.

The problem here is that I also have to have a method called getSize() defined on whatever getMyCollection() returns. Which is a java.util.Set. Which, for some reason, does not have a getSize() method. It has a size() method instead. Apparently the designers of the Java 2 Collections API were feeling a mite saucy when they went a-designin', and were daring their overlords to punish them for ignoring the Java Beans method naming convention that, as it turns out, OGNL relies on heavily.

D'oh!

No problem, though. OGNL doesn't require method names to be bean-compliant, it just prefers it in its chain of figuring out what the heck you're asking for. You can invoke any method directly, as in:

${myCollection.size()}

Problem solved! Let's save everything and reload:

Struts Problem Report
Struts has detected an unhandled exception:
Messages: 
view.jsp(40,109) The function size must be used with a prefix when a default namespace is not specified
org.apache.jasper.JasperException: view.jsp(40,109) The function size must be used with a prefix when a default namespace is not specified

What the...?! Oh. The JasperException must mean that the ${...} expression is being interpreted as JSP EL instead of OGNL. Bummer. Oh well. I'll just let the EL engine handle it.

Which brings me to:

Problem #2

The JSP EL engine can't handle it. Neither the property syntax nor the method syntax works. The property syntax wants to use the (non-existent) getSize() method too (go figure). And the method syntax doesn't exist.

So. Since it looks like JSP EL trumps OGNL when the page is rendered, I'll just turn off JSP EL evaluation (in web.xml) and let OGNL handle everything.

Or not. That results in a ton of errors from pages in my app that rely on JSP EL.

Solution

I'll try to wrap this up. It turns out that the answer is JSP functions. "All" I have to do to get the number of items in my collection is write a public function class and implement a static method -- which I get to name anything I want! Just like the Collections API designers! -- that takes the collection as a parameter and returns its size.

Oh, and I have to write a snippet of XML in the form of a .tld file that tells the JSP where to find this function.

Oh, and I have to declare the .tld as a taglib at the top of the JSP. And that's all I have to do.

Sheesh.

Conclusion

Fortunately, it turns out that the hardest part of this work has been done for me, in the form of the JSTL implementation (documented here) of several useful JSP functions, including length().

It doesn't help my mood any that in Ruby -- if the problem existed to begin with, which it doesn't -- I could have solved it simply by adding a getSize() method, aliased to the size() method of the Set class, and everyone would be happy.

Grumble.

Required Reading: Enforcing Strict Model-View Separation in Template Engines

2007-06-04T12:14:00.001-06:00

So I've been reading Terence Parr's excellent addition to the Pragmatic Programmers catalog: The Definitive ANTLR Reference. This book is a lot of fun for me (I recommend it highly, btw), because it's gotten me thinking again about languages and language implementation issues in a way that I haven't had to since my first compilers class. Dr. Parr has a relaxed and informative writing style that can make you forget you're reading about some pretty hardcore computer science.

I wanted to do some more reading on StringTemplate, the templating engine ANTLR uses to emit the results of its translation, because I read that it can be (is) used to build websites as well. My searching led me to Dr. Parr's paper from 2004: Enforcing Strict Model-View Separation in Template Engines. In it, Parr explains -- and most importantly formalizes -- his ideas about the need for strict separation in view templating mechanisms, and how the vast majority of existing solutions (e.g., JSP, Velocity) fall far short, ironically because of the Turing-complete power they provide.

We Java programmers who have been around since the introduction of JSP have already been informally exposed to some of these concepts, in the form of the Model 1 -> Model 2 architecture evolution. One of Dr. Parr's key points, though, is that it's not enough simply to recommend avoiding using the full computational power available in (for example) JSP scriptlets. The temptation to use that power, even in seemingly innocuous ways, is simply too strong to be resisted for long. Parr's insight that having full access to the Turing-complete power inherent in JSP/Velocity/what-have-you actually gets in our way as developers reminds me of the 37Signals take on embracing constraint.

Mind you, I don't expect to be organizing a revolution around replacing my company's use of JSP with StringTemplate anytime soon. But I do plan to develop the personal discipline of following Dr. Parr's advice and embracing constraint by voluntarily avoiding the constructs that violate strict separation. That statement may seem to contradict the statement above about temptation being too strong, but I think that if enough individuals had the same resolve, we could improve the situation somewhat until a move to StringTemplate or its equivalent became politically feasible.

Closures in Java: Continued

2007-06-04T06:00:00.000-06:00

In the comments section of my last post, user sanity makes the following astute observation, re: my closing remark about Java being a Turing complete language:

Well, pretty-much every programming language is Turing complete, so by that argument, why bother adding any feature to any language?

To which I reply: "Bravo!" and "Well said." I'll even take it one step further: anything that can be done in a high-level programming language can be done in assembler language, or even machine code. I know from hard experience, having implemented an encapsulation/data-hiding scheme using IBM mainframe assembler language, and having patched code using the raw machine opcodes in the same environment. Ah, the good old days!

So I'll go back to programming in assembler language, and the rest of you can either join me or take a well-earned break. Thanks for playing.

All right -- as much fun as the reductio ad absurdum game is, all it does is reduce the argument to an absurdity. It doesn't really point to a constructive resolution. Although, in this case, it does raise the question (note: notice I did not say, "begs the question," which is a solecism that I will reserve for another post) of the degree to which the effort involved in constructing a higher-level language offsets the effort involved in writing code in a low-level language.

I think we can all agree that programming in C or C++ is more pleasant and more efficient in terms of our time than programming in assembler language. You give up some flexibility (e.g., the ability to stuff a specific value in a specific register, direct access to all non-protected memory), but you gain recursion, stack management, register coloring -- all that good stuff.

Move up to Java, or Objective-C (version 2.0; coming soon!) and you get the added relief of automatic memory management (allocation and garbage collection). With Java and its ilk, you also get checked exceptions, which you may or may not appreciate.

Move up to Ruby (JRuby), or Python (Jython), or LISP, and you get dynamic typing and language/runtime-level support for first-class functions/blocks/closures.

So switching between these flavors of Turing-completeness makes sense. If you need close-to-the-metal performance with some measure of portability, use C. If you need rapid prototyping, use Ruby or Python. If you need to justify spending $300+ on IntelliJ IDEA, use Java. (Sorry, couldn't resist).

My point (and I do have one) is that the difference between Turing-complete-Java and Turing-complete-Java-now-with-closures! is just not worth the effort it looks like adding this nice-but-not-essential feature to the language will require.

Closures in Java will muddy an already-dense syntax even further. They will require more code butchery and internal gymnastics on behalf of the compiler. They will be devilishly hard to add in a way that makes sense, given Java's baked-in typing restrictions and flow control. And, in the end, they're going to satisfy the demands of a vocal minority. The masses will still take the path of least resistance, and will probably avoid closures like the plague. And those of us who make a point of being aware of non-Java programming idioms will appreciate the differences between the many available languages, and will continue to strive to use the best tool for the job at hand.

Closures in Java: Why Bother?

2007-05-30T23:16:00.001-06:00

Yes, I know Closures are Cool. All the "cool", "new" dynamic languages, like Ruby (which is actually older than Java, BTW), have them, so if Java is going to be "cool", Java needs closures.

Or does it?

My original title for this entry was "Closures in Java: Lipstick on a Pig?", but I decided against that because I don't want to imply any disdain for Java. I've programmed professionally in everything from IBM mainframe assembler language to (shudder) COBOL to Java to Ruby. I spent most of last year developing websites in Ruby on Rails. I currently develop client and server-side solutions in Java.

Professionally, I can't afford to be a language - or even a language-feature - snob. There are things I used to be able to do in assembler language that I can't do in Java, or even (gasp) Ruby. Do you see me writing proposals to add BALR functionality to the Java language? Of course not. Java is not IBM mainframe assembler language. It was never intended to be.

Nor was it intended to be Ruby. Or Python. Or ML. Or LISP. Or whatever your particular favorite non-Java programming language happens to be.

I wish the Java Powers That Be would leave well enough alone, be happy with the success of Java and the JVM, and stop trying to be Everything To Everybody.

Enough with the inferiority complex, already.

So Java doesn't have first-class functions (which some would say aren't essential for closures, but if you're not going to have first-class functions, why bother?). Big deal. It has a large install-base. It has Tomcat. It has the JVM. It has static typing, which is great if you're into that kind of thing. In short, it has everything you need to develop useful, useable, functional programs.

Could Java be a better language? Probably. But could it be worse? Certainly (yes, I'm talking to you, C++).

So why not just let Java be Java? If you really need first-class functions/blocks/closures, use Smalltalk. Or Ruby. Or Python. Or Lisp. If you really need first-class functions/blocks/closures on the JVM, use Smalltalk/JVM. Or JRuby. Or Jython. Or Armed Bear Common Lisp. Or any of the (astonishingly large) number of non-Java languages that have been implemented to run on the JVM.

Here's a thought: look at how JRuby or Jython implement blocks in Java code, and abstract that code into a new library for Java. Or use the existing Jakarta Commons Functor project. There are enough options available that hacking the language spec beyond recognition and bastardizing a decent language in the name of Keeping Up with the Language Jones-es should not have to be considered the only viable option.

Java is a Turing complete language -- by definition, you can do anything in Java that you can in any other Turing complete language. Which means that adding closures to Java, while an interesting theoretical and mental challenge, is not necessary.

So why bother?

Hacking JRuby

2007-05-29T17:04:00.000-06:00

I recently got to contribute to the JRuby project -- issue #JRUBY-914: "JRuby's BigDecimal needs to round". In doing so, I got to learn a bit about Java's BigDecimal -- particularly how it differs from Java 1.4 to Java 5, implement a bit of code in the JRuby codebase, and test my ideas conveniently and interactively using Jython. Not a bad way to spend a couple hours hacking and contributing to the community.

In a nutshell, java.math.BigDecimal allows you to specify a scale, which is the number of digits to the right of the decimal place. So a BigDecimal with an unscaledValue of 1 and a scale of 1 would evaluate to 0.1. Java 5 allows the scale to take a negative value. So a BigDecimal with an unscaledValue of 1 and a scale of -1 would evaluate to 10. This is significant for rounding because it allows you to round a number to any digit, right or left of the decimal. But Java 1.4 does not allow a negative scale, so we need another approach to allow the same behavior on both versions.

My solution was to use the movePointLeft() and movePointRight() methods of the BigDecimal class to achieve the same result. It turns out those methods do permit a negative offset, so moving the decimal point "right" by a negative number actually moves it to the left, and vice versa. This turns out to be all we need to achieve the desired behavior: moving the decimal point to the right scale times positions the digit to be rounded to just to the left of the decimal point. We can then round normally, using whichever Java rounding mode suits our needs. Then we shift the decimal point left scale times to restore the (now rounded) number.

Note that this algorithm works for both negative and positive values of scale. It's a little bit of overkill when scale is non-negative, though, so I just implemented it for the interesting case of scale < 0.