jutopia

gotAPI is simply amazing. Give it 5 mins you won’t regret.

I will never have to hit “api.rubyonrails.com” and use Cmd-F to find methods again.

Ward has changed the world more than any other person I have met: XP, FIT, the wiki. Now his moving on again. I hope he finds rest at last. Ward, maybe big companies isn’t for you?

If you’re doing any sort of JavaScript development you have to check out the Firebug extension. A-fucking-mazing!

Creating Domain Specific Languages in Ruby, by Jim Weirich

Did you know what “3” means in the domain specific language for juggling? Jim starts off by showing us just this with three balls on the stage. He also tries to show us “15” (also three balls but in a shower) but ends up dropping one of the balls. He then goes on to show us the DSL for Rubik’s cube moves and guitar tabulature. Jim is the author of Rake which is the standard Make tool for Ruby. Rake is an example of an internal DSL dealing with build tasks and dependencies. The great thing with DSLs in Ruby is that you can construct them inside the language and still be able to use the full power of Ruby which is not possible in Make or Ant. A nice feature of the Groovy language is the builders (AntBuilder and XmlBuilder for example) and Jim shows a way of doing the same thing in Ruby. Other examples of DSLs: Declarative DB tables (coming in next version of Rails), Temporal Expressions, Dynamic Expression Parsing, Parsing, State Tables, Business Rules (Nat Pryce Higher Order Messaging), Testing.

System Testing in Ruby with Systir, by Karlin Fox

Systir has a very cool way of having automatic test scripts that can be written and verified directly by the end-user. A test would look something like this:

Login as "Jon".
Choose Make a pizza.
Add ingredient "Ham".
Add ingredient "Pineapple".
Name pizza "Hawaii".
Make the pizza.
Check "Hawaii" is in pizza queue.

This test is placed in a simple text file and executed. Each line gets munged into a valid method name which is executed on a “driver” which is a simple Ruby class that extends Systir::LanguageDriver. This is a very cool approach to creating what Karlin calls “Executable requirements”, somewhat of a holy grail in agile methodologies (especially XP).

Keynote address (Wild and crazy ideas): Yukihiro “matz” Matsumoto

In the keynote address Matz is talking about moving Ruby forward in the future. He’s specifically delegated all the infrastructural stuff like threading, reentrancy and so on to Koichi the creator of YARV, so he’s focusing primarily on new language features. Here’s a couple of examples: Keyword arguments, Class constants, “Real” Multiple values (like Common Lisp), Lambdas (real anonymous functions), Annotations (like .NET and Java 5, still a very young idea), treating modules more like “traits” (allows operations on modules like unions, subtractions and renaming methods), Namespaces (which is a safer way of doing open classes), Multilingualization. Someone asks: “When will it be ready?”, Matz answers “When it’s ready.”.

Refactoring No Clergy, by Kevin S Baird

Kevin is a composer of contemporary music. He presents a “musical piece” named No Clergy that he has written which actually let’s the audience influence what the performers are playing through a type of voting system in a web browser. He recently converted the “piece” from Python into Ruby and he explains the various refactorings he’s employed to clean up the codebase. He’s using a system called Lilypond which accepts a TeX like language and generates really good looking musical sheets. This is generated as the piece is performed based on the audience votes and some algorithms.

Embedding Ruby into a Robotic Marine Laboratory, by Brent Roman

It’s funny to see all the weird places that Ruby ends up. In this case Brent has been using Ruby in an robotic laboratory. The laboratory is deployed in the sea and automatically analyzes samples from the ocean water. Ruby was initially only supposed to be used as a scripting language by scientists which designs the different experiments and analysis. Brent assumed that the actual device drivers needed to be written in C but actually ends up using Ruby through most of the system. He also goes into a deep discussion on how the threading model in current Ruby has various problems and the different work-arounds he’s used. An interesting little detail is that NASA is considering using the laboratory for analysis of any fluid they might encounter on planets in the future. They suspect they might use it to find proof of existing or dead life such as plancton or bacteriae. Imagine if Ruby would be used to find the first proof of extraterrestrial life!

Presentations with PDF:Writer, by Austin Ziegler

PDF:Writer is a library for generating PDF files. Austin kicks of the talk by running a Ruby script which actually generates his presentation. PDF:Writer currently supports around 50% of PDF and has a very nice “humane” API.

Polishing Ruby: Power Tools and Toys, by Ryan Davis

I had to take a nap because of my jetlag so I dropped in a bit late into this very cool presentation. Ryan of ZenSpider has written all these small interesting libraries. Here’s a selection: unit_diff diffs output from Test::Unit in order to easily find out what went wrong. RubyInline allows you to write inline C functions in Ruby which automatically gets compiled and executed as you run the program. RubyInline also has a very open architecture which Ryan demonstrates by writing inline Perl in Ruby (to the audience’ dismay). Ruby2c translates a subset of Ruby into C, completely with type inference, converting idiomatic iterators into while loops and so on. ZenProfile is a performant profiler. RubyOptimize is incredibly cool: it uses ZenProfile to find bottlenecks in the code, at a certain treshold it compiles the method using Ruby2C thereby speeding it up. And lots more…

The rest of the sessions for the day later…

Linus seems to have not chosen any of the established change-oriented SCMs (Arch, Monotone, Darcs) and have instead chosen to implement his own: Git.

Does anyone know more about this Git? Would it be suitable to use for projects other than the Linux kernel?

I can’t even find any documentation for it…

Man! This is cool: check out the lib directory of the latest IntelliJ EAP drop: “picocontainer-1.0.jar”!! They’re using PicoContainer internally! That is so cool!

IntelliJ IDEA has given me so much during the years, I’m so happy to give something back.

I’m not saying that simple designs by some divine judgement are better designs (I do believe so, I just don’t want to start that particular debate again). There are other much larger problems with complicated designs when it comes to implementing maintainable systems: complicated designs usually become poorly understood and therefor poorly implemented.

I’ve seen this many times in the field: Some hot-shot architect works for an intense period early in a projects lifecycle and produces some really hot-shot, ultra-cool, super-slick design that solves everything that the system would ever be conceived to do and then some. Job done, the architect leaves for his next hot-shot assignment (he holds himself too high for such profane tasks as, bah, implementation).

Left on the project are a bunch of more junior people who are up to the task of actually delivering the system. If they ever understood the design in the first place they are certainly not understanding it good enough to be able to maintain it when exposed to realities such as time-pressure, performance problems, inconsistent requirements and so forth. The design starts to break down and technical debt accumulates. The biggest problem now is that not only has the design broken down, they are also dragging around a massive framework hampering their every step.

I have been to places that had frameworks of hundreds and hundreds of classes that when it came down to it did the equivalent functionality of about two mid-sized classes work. I kid you not.

Some warning signs to look out for:

“We’re building a generic framework so it will take a little longer to deliver the first project. But then we will be able to reuse all this stuff so we’ll save time in the long run.” (Building reusable software is many, many times more difficult, expensive and time-consuming than one-off software. Is there really a business case for a reusable framework?)

“Let’s build it so that all this functionality can be accessible from any possible client.” (Technologies like web services or CORBA has a huge up-front cost in terms of complexity. It’s better to build the remote interfaces when the client actually exists.)

“Make the customer disappointed the first time, because they will be more than happy the next time.” (Are you sure you will get a next time?)

“We want to use a rules engine so that the business can easily extend the system in the future.” (Even a rules engine requires programmers to write the rules.)

“It might seem a little complicated for this simple project, but if we stick to a standard technology we can be sure to find developers that can maintain the system in the future.” (Nobody can maintain an unmaintainable system, standard or no standard.)

If I see another DTO in a non-distributed webapp again I think I’m going to throw up.

Data Transfer Objects are meant for one single thing, transfer data over a distribution boundary. Extremely few webapps benefit from being distributed (as opposed to clustered which is an entirely different thing). Everybody seems to know this by now. So why do I still see all these completely non-distributed webapps with DTOs all over the place!?

You would think that people start thinking something just gotta be wrong when a significant portion of their system is just about shuffling data in and out of DTOs. Or when the domain model is left completely atrophied and looks more like a relational database schema expressed in an awkward Java syntax. Or as their carefully crafted architecture just falls apart in a mumbo jumbo of completely unmaintainable procedural code.

Oh nooo. They are the perfect excuse for creating objects completely without behaviour or responsibilities, approved and signed by the uber guru of enterprise architecture himself. “Hey, if Martin Fowler says I can do objects without behaviour then I can bloody hell do them all the time!”

Martin, you’re a great bloke and I don’t mean no disrespect but couldn’t you just have left this bastard of a pattern out of your books! People just can’t handle it responsibly.

I’ve used AOP more or less actively for almost two years now, and I think I’m really starting to get it. Given that it took me almost 5 years to really master object-orientation I would say AOP is quite a lot easier. (Granted, I learned OOP through C++ which made it a lot harder).

Anyway, there’s an important design characteristic of AOP that I’ve been starting to appreciate more lately. Most people talk about AOP as it’s all about moving things that has been implemented in several places into one place, and separating things that has been cramped up into one single place into several places. I think there’s a different important part to it though. I call it Dependency Inversion on Stereoids.

The Dependency Inversion Principle is basically the old OO principle for managing type dependencies in an object-oriented system. Given you have a dependency:
A -> B
If you want to minimize dependencies and separate A and B, you would introduce an interface or baseclass that B implements and A depends on (“implementation” is a type dependency where the implementation depends on the interface). So you would get:
A > I < B
Voila! You have inverted the dependencies and separated A from B!

But with AOP you have a much more direct and powerful dependency inversion (it’s on stereoids!). So from:
A -> B
If you make B an aspect you can completely and directly invert the dependency:
A <- B
B would depend on A in this case, but you could completely eliminate the extra luggage in A that makes it call into the interface I in the right places.

This is a new powerful design construct, you wouldn’t use it all the time but it allows you a new degree of freedom. For example, you could let one team develop a domain model and another team bolt on undo or persistence on it (I know Crazy Bob is doing this).