Spreading the gospel

Notes after the jump.

Aside: They brew insanely strong coffee at the Sheraton…

Continue reading →

This morning session rocked my world. The afternoon session was better than yesterday but, for me, dragged a lot toward the end of the day.

I suspect that my less enthusiastic response to this class vice the Rails class has more to do with my significantly greater experience with Ruby the language than Rails the framework.

That said, I am still finding this class worthwhile to fill in the gaps in my understanding of Ruby to date.

Notes after the jump.

Continue reading →

Notes after the jump (as I write them)

Review of the day: Morning session was excellent and intense. This afternoon has been theory. As of 3:45pm, it hasn’t felt so “advanced”.

Continue reading →

The day starts with a list of potential topics. The class body votes on the topics that they want to cover. All of my votes went to ‘file uploads’ for work reasons — and fortunately this pushed it over the top!

And the results in order are:

1. AJAX
2. File Uploads
3. Perf & Scalability
4. Deployment
5. AR with unsupported DBs
6. Debugging

Notes after the jump:

Continue reading →

Notes follow after the jump.

Continue reading →

Lovely start to the day. 2 miles from the hotel, my Prius breaks down and won’t start. WTF?! FAIL! Oddly, 30 minutes later (after perusing the sample app that we’re going to discuss during the class), the car starts again with a warning light. During the class, I’m fucking Grand Central Station: my cell phone rang 4 times before lunch. Again, WTF? I’m not a popular guy. Yeesh!

Hehehe… and Twitter went down just before lunch. Sometimes it’s nice to remember that I’m not the only one who is living in interesting times.

Regarding my notes, it’s worth mentioning that I’ve done a bit of Rails 1.2.x development but haven’t touched Rails 2.x until today. That said, as of this morning, I was comfortable with the theory of REST but not the Rails implementation.

Anyhoo, my notes from Day 1 of the class follow after the jump.

Continue reading →

I know, I know. Java. Blech!

But if you have to work in Java, instead of something more elegant like Ruby, wouldn’t you like some of the same awesome mocking power that you have come to know and love in Java? Yeah, me too.

Toby DiPasquale turned me on to jmockit. It’s a little framework that provide RSpec-like mocking in Java. To those familiar with RSpec: jmockit allows developers to mock constructors as well as individual method on live objects. It accomplishes this courtesy of the java.lang.instrument package that was added in Java 1.5.

I was curious to see if it is possible to mock boot classloader loaded classes (i.e., java.lang.Integer, etc.). After a few minutes of tinkering, I found a way but it’s none to pleasant…

Continue reading →

Giles Bowkett brought us Pastie of the Mac clipboard from IRB via the Utility Belt gem. If you aren’t using it already, ’sudo gem install utility_belt’. I highly recommend it.

That said, I’ve since longed for the same capability but from the command line.

Continue reading →

Chris Sepulveda recently wrote a great article discussing why he believes that Ruby and Rails will ultimately topple Java in the enterprise development space.

He’s not the only one. I’m often hearing Rubyists talk about how, once the Java community “crosses the chasm”, we’ll rule the world. I seem to recall that Smalltalkers had the same notion at one point…

And yet Chris drew an analogy that caught my eye: “Rails is not unlike other early-technulogies in this regard (consider Java in 1996-98).”

I often use a similar analogy when attempting to introduce Ruby and Rails to other Java old-timers: “Remember Java way back in 1997? Yeah, that’s Ruby right now” implying that fame, fortune, and glory await but a few years away for those who hop on those Rails now.

To an extent, the analogy holds. Between ‘96 and ‘98:

• Java was slow as a dog. (Ruby: check)
• Java was immature. There were few class libraries available. (Ruby: hrmm… let’s come back to this)
• Sun/Java struck gold with J2EE v1.0 in ‘98-’99. (Ruby: Rails - check)
• Arguably, Java web development didn’t achieve “maturity” until early versions of Struts appeared on the scene and provided structure that was sorely lacking within the typical J2EE app pre-’99 (Ruby: Rails - check, Merb as well)

However, I still have some reservations about this analogy. As of ‘98:

• Java had been around for 3 years. As of today, Ruby has been around for 13 years. It wasn’t until recently with Rails that Ruby came out of the Sinai and found its land of Milk and Honey — maybe.
• Java had Sun vigorously evangelizing Java like the snake oil of the millennium whereas Ruby, instead, has several small consulting firms and a vocal community of passionate developers (myself among them).
• Java had a pittance of available libraries whereas there are a plethora of available Ruby libraries today.

Let’s face it: in the enterprise, more often than not, it’s not the engineers who pick the technologies: it’s the pointy-haired morons who wear ties to work every day, have stock in the company, a sizeable six-figure income, drive a BMW (bullshit on the inside), and pick technulogies that are “safe” (i.e., they cost lots of money — like Oracle or Microsoft) instead of technologies that can save money (like Linux or Ruby or other OSS).

Of course there are small pockets where sanity reign. One of Chris’ commenter’s henpecked Relevance’s Streamlined framework; however, Stu will tell you that they often submit two bids for their contracts: one to be implemented in Java and the other Ruby. Do I really need to tell you which bid most of his customers pick? What does Relevance use to implement many of their web apps? Stu told me that they built Streamlined to help them quickly develop web apps that, while they won’t win beauty contests for web design, handily get the job done and can be constructed in short order.

At the end of the day, to the enteprise, shouldn’t that be what matters? More value for less money? We engineers often tend to be idealists. If one technology does something better than another and can easily be adapted to play well with the technologies of the past, we deem it a winner. Sadly, the best ideas often lose despite technical merit.

  class Robot 
  { 
    def type 
    def height 
    def width 
    
    def access(location, weight, fragile) 
    { 
      print "Received fragile? ${fragile}, weight: ${weight}, loc: ${location}" 
    } 
  } 
  
  robot = new Robot(type: 'arm', width: 10, height: 40) 
  println "${robot.type}, ${robot.height}, ${robot.width}" 
  robot.access(50, x: 30, y: 20, z: 10, true)

Republished from Venkat Subramaniam’s Programming Groovy (Beta, p. 39)

…outputs the following:

  arm, 40, 10
  Received loc: ["x":30, "y":20, "z":10], weight: 50, fragile? true

If you’re a Ruby programmer, the second line is going to look seriously bizarre. If you’re not, I’ll explain why. In Ruby, you can pass a Hash (think java.util.Map) inline in a method call with the following syntax:

  foo("param1", param2, :hash_key1 => val1, :hash_key2 => val2)

According to Groovy, when a Map is inlined as a argument to a function, by convention, it is the first parameter on the method. If it is not passed in as the first argument then it is coerced into becoming the first argument. The Ruby interpreter will error if you pass an inlined Hash as any argument other than the last. Forgive me but Groovy’s coercion of parameter ordering is just fucking weird.