Entries Tagged 'Java' ↓

I’ve been working at Intent Media for a while now and I’m just getting some time to come up for air to talk about what we’ve been doing while building our software platform.

This will be the first in a series of articles about what I’ve learned over the last year.

For a little background, our engineering team is currently 9 people strong (in a 20 person company). When I joined the company to help build the team, there wasn’t a line of code written and I was the only technical member of the staff.

Over the last 9 months we’ve built what I consider one of the finest pieces of software that I’ve ever worked on. It’s scalable, it uses the right languages for the right jobs, and it does exactly what it needs to do.

It’s also remarkably bug free.

I credit a large part of that (on the tools and good decisions side, that is; I credit most of it to our team) to Cucumber.

One of the first decisions we made (after writing a unit test and our first bit of code) was to write our first Cucumber test. One of the things that I learned while working at Collaborative Drug Discovery was the importance of automated functional tests.

I, for one, will never do another project without them.

At Intent Media we use Cucumber to drive Celerity across our entire software stack. Currently, this consists of 3 Java applications and a Rails application that interact with MySQL and a HDFS data store. Every single time we check in new code we build the entire stack in TeamCity and run our entire suite of functional tests against it.

As of today, I’m currently greeted with this on our TeamCity server:

Each of those “Tests passed” is a step in a Cucumber scenario. For example:

Given I login as “admin@intentmedia.com”

Over the last 9 months we’ve slowly built up a library of steps that encapsulate everything that we need to do with our apps so far. We’ve also found that we’ve gotten a huge amount of reuse out of our existing steps as we’ve grown the app. So far, there haven’t been any scenarios that we couldn’t tackle in an automated manner.

This suite of tests gives us the best safety net I’ve ever had on a project to try large refactorings. In fact, we often do refactorings across the data model that affect several pieces of software in the stack, often in unexpected ways. Cucumber (along with our unit tests) lets us immediately surface any problems in both our applications themselves and the communication between the apps.

If you haven’t checked out Cucumber yet, you owe it to yourself to do so. It’s one of those life-changing pieces of software that’s amazingly simple to get started with, but quickly becomes one of the most important tools in your toolbox.

Quick update on the last 6 months:

• Moved back across the country to NYC
• Took a job as Head of Engineering at Intent Media (We’re Hiring! We’re funded!)
• Been working in Java and Rails

I’ve got plenty of things to write about, so I’ll try to get back on the horse soon.

A long time ago, I did a more than a little bit of open source work. Unfortunately, I always found the process of being a part of an open source project to be a pain.

The process usually went something like this:

• Fix a bug in the code.
• Post patches to the dev list.
• Bug people to get your patches accepted and committed.
• By the time they are accepted, someone else has committed something that breaks them.
• Wash, rinse, repeat

Once you do this enough times, you get commit rights and you don’t have to deal with the process anymore.

I’ve never enjoyed it. Far too much overhead and bullshit.¹

So for the last (more than a) couple of years I’ve taken to forking code when I needed to and then never bothering to give the patches that I wrote back to the maintainers.

Clearly not the best situation, but it worked for me.

GitHub changes all of that.

On GitHub, I can fork anyone’s code, patch it, push my changes back, send a pull request, and then not worry about it.

I can share my code with no overhead.

Example: I fixed a bug in the merb cucumber bindings last week. I pushed my changes to GitHub and sent a pull request to the maintainer. My changes haven’t been pulled into the main tree yet, but I don’t really care.

One look at the GitHub merb cucumber network graph should show any prospective users of the library that development has happened on my tree beyond that of the original tree. Hopefully they’ll take the time to look at it and use the most up-to-date code.

Either way, I don’t have to worry about it anymore.

Also, I love that GitHub lets me share my half finished projects.

I recently posted a partially done Merb based blog called Gutenberg on GitHub.

Will I ever finish it? Who knows.

At the very least it’s a simple Merb example project for people to learn from, and I already know people who have looked at it to learn more about how Merb works. That already makes it worthwhile to me.

Again, no overhead.

Just push code onto GitHub and it’s live to the world.

No pain. No overhead. Just code.

1. As an aside, I really like commit policies like one that Rubinius has, namely, “anyone who submits a patch for some part of the Rubinius project and has the patch accepted will be given commit rights to the mainline repository.” We need more projects with commit policies like that.

(Or, How I Spent My Martin Luther King Day Weekend)

Here are the web app frameworks I’ve been reading about and playing with for the last few days. As usual, they’ve got a bunch of cool ideas that we’ll be seeing in mainstream frameworks in 4 or 5 years.

Weblocks: Weblocks is a continuations-based web framework written in Common Lisp. Think Seaside, in Lisp.

Ramaze: An MVC framework written in Ruby. Like Rails without all of the garbage and magic.

Check them out. Pretty cool stuff going on.

My coworker Krishna, inspired by Giles Bowkett’s post Rails Debugger: Use RCov With Selenium, Watir, Or Just In Real Life, whipped up a little rake task that automates the process of checking code coverage using your Selenium tests:

desc "Measure coverage of selenium specs"
task :coverage do
  FileUtils.rm_rf "selenium_coverage"
  mongrel_pid = fork { exec("rcov script/server -o selenium_coverage --rails -- -e test -p 4000") }
  sleep(6) # wait for mongrel to start

  begin # selenium will call "exit 1" if there are failures
    Rake::Task["selenium:spec"].invoke
  rescue SystemExit; end

  Process.kill("INT", mongrel_pid) # triggers generation of rcov report
  Process.wait
  system("open selenium_coverage/index.html") if PLATFORM['darwin']
end

While we don’t agree that this task, in any way, shape, or form, constitutes a debugger, it has been useful in showing us areas of our code base that our Selenium test cases aren’t hitting.

This should work for just about anyone that has a rake task to run their Selenium (or Watir, or other in-browser testing tool) tests. Just replace ’selenium:spec’ in the block above with whatever task you use to run your in browser functional tests and have at it.

My friend Jay published a blog post today entitled Despised Software Luminaries and, for once, he got it all wrong. I know Martin and Obie , his examples in the post, from my time at Thoughtworks, and they’re not software luminaries. They’re software pundits.

Both of them spend a lot of time telling people how they think the software world should operate. Whenever you tell people how they should do something, it naturally leads to disagreement. It’s that simple. People despise them because they disagree with them.

When I think software luminary, I think of people like Alan Kay, Fred Brooks, and Edsger Dijkstra. People that made fundamental changes to the way that we write software. People like Obie and Martin are smart, talkative guys, but they’re not quite in the same league as those guys.

(See also: http://en.wikipedia.org/wiki/Turing_Award)

Ever since I started writing Ruby code I’ve used Textmate as my editor. Recently, however, I’ve found myself using Netbeans more and more, to the point where I usually have Netbeans and Textmate open next to one another. Netbeans’ refactoring support, ability to jump to method definitions, and ability to autocomplete code is just too good to ignore.

However, a couple of features have kept me from switching to Netbeans full time, namely its lack of Haml support and the fact that it couldn’t run a focused Rspec example.

Well lo and behold, I just checked the Netbeans Ruby Recent Changes page and found the following:

• October 12
  • Lots of bug fixes
  • RSpec module (not part of 6.0 but available in the continuous builds on deadlock)
    • TextMate RSpec snippets
    • “Run Focused Test” action which runs test under the caret. Locate the action in the Keybinding options (see the “Other” category) and bind to something convenient.
    • “Debug Focused Test”, which starts the debugger on the test under the caret.
  • Preliminary support for HAML and SASS – see announcement

They solved both of my issues on the same day!

I did have to install the Haml plugin from here, but it looks like I no longer have a compelling reason not to switch to NetBeans fulltime.

And the obligatory screenshot:

Awesome!

In his post The Business Advantage of Rails, Giles Bowkett writes:

What makes programmers happy? Elegant systems which make them productive and take tiresome, tedious bullshit out of their daily lives.

People who get tiresome, tedious bullshit out of their way forever are great people to work with. Conversely, tolerating tiresome, tedious bullshit without ever fixing it is absolutely not a character trait you want your hiring process to be biased in favor of.

which sounds like a good idea, except that a lot of programming on a real application, no matter if you do it in Ruby, or Visual C, or COBOL, ends up being a lot of tiresome, tedious bullshit.

Which brings me to something that I’ve been thinking a lot about lately. At CDD we have a pretty complex Rails app, (as one of the consultants that we’re working with said, “I’ve worked on a dozen Rails apps, and this is about 4 times bigger and more complex than any of them”) and as our application gets bigger and bigger I’m starting to see more and more complexity and problems crop up. I feel like we’re walking up the same old curve to all of the standard problems you run into when programming a webapp in any language (object model too big to be easily understood, code is getting less and less cohesive, etc). It may have taken a little longer to get there, but I’m pretty sure that we’re going to end up in the same place.

Which leads me to another problem. The easiest solution to a lot of these problems, in my experience, has always been to refactor the code. That’s what I always ended up doing with Java apps of this size back in the day. Unfortunantly, the state of Ruby refactoring tools, and I’m putting this as nicely as I possibly can, sucks. Even something as simple renaming a class tends to be far more painful than it needs to be.

So the big question now is, have we (and perhaps we’re the first team to do this, as I haven’t heard much about it from others) finally hit the point where the cost of maintaining our code in Ruby is higher than the savings by writing it in Ruby in the first place? I’m not willing to answer yes to that question yet, but I am starting to see more and more places that have me pining for for the good old days of IntelliJ, with all of the great things it does to make your life easier. It’s easy to forget about the amount of tiresome, tedious bullshit that great tools can help us avoid, at least until you start running into that same old bullshit.

Seaside does not have a marketing problem!

Everyone I know in this business knows about Seaside and its super productive powers. We’ve all seen the demos and the screencasts and the awesomeness that is DabbleDB. For god’s sake, Avi gave a keynote at RailsConf this year.

I think it’s safe to say that people know about Seaside.

The problem at this point isn’t a marketing one. It’s the same problem that Squeak has always had. Namely that when you download Squeak and start it up, you’re presented with this:

When most programmers I know see this, they have the same reaction, “What the fuck?”

This is usually followed quickly by the question of, “Can I edit this using Vi or Emacs?”

Let me answer this now. No and No.

If you’re the type of person that can’t imagine giving up writing code at the command line, then Squeak isn’t for you. (Although there are Vi and Emacs keybindings.)

And that’s usually the end of it. People play with Squeak for a few minutes and then go back to doing their real work in Ruby or Python or Java or C#. A lot of the power and magic of using Seaside is directly derived from the power and magic of using Smalltalk, which unfortunately (or fortunately, depending on your point of view) means that you’re going to have to learn Smalltalk if you want to use it .

And Smalltalk is, at least in the case of Squeak, a whole different world. You have to unlearn a lot of what you know in order to use it. Editing is different, class creation is different, version control is different. Basically everything you know as a programmer gets thrown out the window.

But you know what? At some point, once you do that and really start to immerse yourself in Smalltalk, you’ll suddenly realize that it’s hard to go back to the old way of doing things.

You’ll realize how much easier it is to just ask the system what method you should use to get something done instead of going to a PDF document somewhere to look it up. (Yes, in Squeak you can just type “‘class’. 3. ‘cla’” into the the method finder and tells you that “contractTo” and “truncateTo” are the two messages in the system that give you that result.)

You’ll suddenly come to the realization that this is simply better.

That this is how things are supposed to work.

Unfortunately for most of us at this point, we’ll have to go back to our real jobs, (I asked Avi after his keynote how many people in the world are actually making money using Seaside and he said that he figures about 20) but even if you get this far you’ll learn enough to to have a whole new outlook on how coding should work.

It’s not a marketing problem, it’s the the same old problem that people are scared of things that are different then what they’re used to. Hopefully someday we will be able to overcome this fear, and then Seaside and Smalltalk will finally take over the world. But for now this new outlook on development will have to be good enough.

If Ruby is a step up from Java in productivity and power, and Smalltalk is a step up from Ruby, then we should all feel a little ashamed when we read the following from The Early History of Smalltalk by Alan Kay:

In January 1976, I took the whole group to Pajaro Dunes for a three day offsite to bring up the issues and try to reset the compass. It was called “Let’s Burn Our Disk Packs.” There were no shouting matches, the group liked (I would go so far to say: loved) each other too much for that. But we were troubled. I used the old aphorism that “no biological organism can live in its own waste products” to please for a really fresh start: a hw-sw system very different from the ALTO and Smalltalk, One thing we all did agree on was that the current Smalltalk’s power did not match our various levels of aspiration. I thought we needed something different, as I did not see how OOP by itself was going to solve our end-user problems. Others, particularly some of the grad students, really wanted a better Smalltalk that was faster and could be used for bigger problems. I think Dan felt that a better Smalltalk could be the vehicle for the different system I wanted, but could not describe clearly.

I know that they went on to implement Smalltalk-76 as the follow-up to this, and that what we use today is a closer ancestor to that then the Smalltalk-72 that he is discussing here, but it was really just anther evolution. How is it that we haven’t had a revolutionary advance in programming languages in the 30 years since then?

I don’t have a solution, but I think that all too often we forget that there’s even a problem to be solved.