Microsoft apparently hops on the dynamic languages train and releases IronRuby, a Ruby interpreter for the .NET platform which is also supported by Microsoft’s counterpart to Adobe Flash, the all new silvery Silverlight (which by the way also supports Python). I’m not exactly a fan of Microsoft, but I like the idea that web applets can now be written in Python and Ruby. How great would it be if these languages could once replace JavaScript on the client side as well. For now, I’ll stick with RJS templates for that purpose.
Posts Tagged: ruby
26
Apr 07
APIs and DSLs
Today I stumbled upon Josh Bloch’s talk How To Design A Good API and Why it Matters at Google Tech Talks. Its loaded with profound wisdom and advice from one of the masters of API design.
He explains that API design is very similar to language design, and I immediately thought that this particularly holds for APIs which are designed as domain-specific languages, which is one of Ruby’s strengths (read this article from Oreillynet.com to learn more about DSLs).
A few slides later he talks about characteristics of good APIs:
- Easy to learn
- Easy to use, even without documentation
- Hard to misuse
- Easy to read and maintain code that uses it
- Sufficiently powerful to satisfy requirements
- Easy to evolve
- Appropriate to audience
To achieve all these properties for an API is certainly non-trivial, but at least some of them get easier if you design APIs as a domain-specific languages: As the term says, a DSL provides a language that is tailored for a particular domain, in addition DSLs are generally declarative and hide language aspects that are irrelevant. Such a language is obviously easier to learn, use and to read than a mere API, and is more appropriate to its audience. In the end, these are known strengths of declarative languages. Here’s an example taken from the Capistrano manual (Capistrano is a Ruby DSL for remote software deployment):
[ruby]
desc “Start the spinner daemon”
task :spinner, :roles => :app do
run “#{current_path}/script/spin”
end
desc “Used only for deploying when the spinner isn’t running”
task :cold_deploy do
transaction do
update_code
symlink
end
spinner
end
[/ruby]
Though this doesn’t hide imperative aspects completely, I think it’s a good example of how a DSL feels – just as if it wasn’t Ruby but a different language.
So, is it safe to conclude that DSLs are the better APIs?
24
Apr 07
iCal meets Google Earth
Some days ago I had this idea of a calendar browser showing my upcoming events in a 3D perspective, i.e. events of next week are close by while events some months away are far in the distance. The purpose is that I get an intuitive impression of things to come, their sequentiality and relation – something I miss in the typical grid-like calendar views offered by iCal and Outlook. I talked about it to some of my colleagues and when I tried to explain the idea, I said something like “It should be like looking at Google Earth from a tilted angle, events placed on a sphere which I can roll back and forth“. It took me some moments, then it hit me: It’s easy to place markers on Google Earth by using KML files – and by using Google Earth as a platform, I get all the UI features I need for free.
Fast forward to one and a half days later: A very basic implementation of the “iCal meets Google Earth” mashup is ready, which I call einstein, well, because what it does is some kind of joining space and time. I used Ruby (of course), employing the vpim library for extracting iCal data and XML builder templates for creating the KML output. In the end it was almost too simple.
And this is what it looks like (by now):
22
Apr 07
Lightweight Developers
Maybe I like Ruby because I’m a lightweight developer? See for yourself:
via RedHanded.
22
Mar 07
Java and/or Ruby
Currently I am working on a small prototypical application involving lots of webscraping, a database and some sophisticated term indexing and search query expansion. Since some parts of the app are quite independent from the others, sharing data only via the database, I decided to code as much as I could in Ruby. There is nothing better for getting into a new language than working on a real project.
For web scraping (which I always did with Python, my absolutely favourite scripting language to date, and the fabulous BeautifulSoup library) I decided to switch to Hpricot (silly name), which does the job of scraping untidy HTML pages good enough for me.
So, what do I use as a cost-effective, well-maintained search and indexing framework? Of course Lucene, because I have grown up with Java and the bold faith that there is a library for everything under the sun – written in Java. But lately I found that there is in fact a Lucene-lookalike implementation for Ruby named Ferret. And it is even faster than Lucene. So off to new pastures.
All that is left in Java will be the RDF handling, because there is nothing as sophisticated for RDF/OWL ontology handling as the Jena library in Ruby.
Tune in next time to hear me talk about the pitfalls of weakly-typed scripting languages …
Links:
- The Python Language
- BeautifulSoup – a “dirty” HTML parser for Python
- The Ruby Language
- Hpricot – a “dirty” HTML parser for Ruby
- Apache Lucene – the de-facto open source searching standard
- Ferret – Lucene for Ruby
- Jena – a semantic web framework for Java
13
Mar 07
Ruby & Me: No More Static Typing Zealotry
Note: This is part II of an ongoing series on the programming language Ruby.
In August 2005, I wrote in my personal blog (german):
Now, after hacking PHP for virtually twelve hours a day the last three weeks (with a few exceptions), I know that this language isn’t suited for people with a sensitive mind like mine. Its a particularly bad idea to begin by dumping out some quick & dirty code and then refactor this into a clean Model-View-Controller application (I think I have to read up on agile software development). PHP’s type-free variables together with my own web framework, which uses HTTP request and session as a shared hashtable for beans (like Model 2/Struts, naive, I know, …), lead to sheer debugging horror. After this I resolved to return to the world of static typing.
So I actually wanted to get back to Java — or any other statically typed language offering a sufficiently powerful and elegant (!) web framework. Because, yes, I was a static typing zealot, and I wanted to get home and snuggle up in the comfortable warmth of the static typing safety net. But this didn’t happen (for web development), for two reasons.
The first reason is that by developing MyVeryOwnWebFrameworkTM in PHP I learned an important lesson about scripting dynamically typed languages: under particular circumstances the flexibility of these languages can actually support elegance in a way statically typed languages can’t, e.g. for following the convention over configuration principle. And this is one of the areas where Ruby and Rails just excel, as we will see later in this series. What *I* did was developing PHP code in an idiomatic style borrowed from Java — what did I expect?
The other reason is that I discovered the concept of modal web frameworks which appealed to me as a very elegant approach and, again, couldn’t be done in Java. So after doing some research and taking sneak peeks into several languages and frameworks, such as Seaside for Smalltalk and some other framework I can’t remember for Haskell, I decided to learn Ruby because it has a rapidly growing base of supporters and there’s already a modal web framework for Ruby called Wee.
So actually Rails wasn’t even my main reason to making the switch to Ruby, yet it was the first thing I played with, perhaps due to the mass of training material available on the web. And I got stuck with it, because Rails immediate me taught me what makes Ruby cool. Thus, in the next episode of this series I will point out some of Ruby’s features that make me love this language.
7
Mar 07
Humane Interface Design
Martin Fowler writes on his view on humane interface design, i.e. APIs that are designed for convenient use, in contrast to minimalist APIs. He states that
The essence of the humane interface is to find out what people want to do and design the interface so that it’s really easy to do the common case.
For example, Ruby’s arrays have convenience methods such as first, last, flatten, etc. which tend to be omitted in minimalist interfaces, because they can easily be implemented by clients. And Ruby also aliases method names, i.e. using multiple names for the same functionality, such as length and size of arrays. As an example for a minimalist interface, Fowler mentions the Java API for collections.
I wonder where Python falls in this spectrum. The Python folks state explicitly that
There should be one — and preferably only one — obvious way to do it.
Which sounds like a minimalist approach to me, in the meaning of “reduce stuff to the things that are canonically necessary”. But if you look at the APIs, you’ll find aliases there as well. I don’t know Python terribly well, so perhaps some Python guru can enlighten me on this?
Wrapping things up I don’t think that one approach – humane or minimalist – is necessarily better than the other. Both have their benefits and drawbacks, but like Martin Fowler I prefer humane interfaces.
Via One Man Hacking
5
Mar 07
Ruby & Me: The Beginning
Note: This is part I of an ongoing series on the programming language Ruby.
It all started when I was fed up with developing web applications with PHP or Java (i.e. Struts). I had a rather complex web project ahead and just called it quits with PHP and Java (for web development), because, well, PHP is the shortest path for a web developer to the sanitarium and Struts was simply to cumbersome for my taste. And of course there was Ruby on Rails this super productive new web framework everybody was drooling over, I just had to try it. So I got myself a printout of Rolling with Ruby on Rails to read. And it annoyed me almost from the beginning.
The main reason I didn’t like Rolling with Ruby on Rails is that it praises Rails to the skies while almost completely failing to mention any of the framework’s cool, elegant or productivity-boosting features. The whole article is mainly concerned with scaffolding, a feature which automatically provides a web-based interface for creating, editing, browsing and deleting objects. Its nice to get a first look into the thing, but in my opinion its almost useless for serious development. In my Rails projects, for example, scaffolded code amounts to about 1% (or less) of the overall code, because the application interfaces just don’t have much in common with the interfaces provided by scaffolding.
Yet there are a lot of cool things to tell about Rails: Its domain specific languages, the powerful ActiveRecord framework, its builtin support for AJAXification, to name a few. Rails owes the ease of using these features mainly to the Ruby programming language. So what makes Rails cool are basically the same things that make Ruby cool, applied masterly.
Thus, in the course of this series, I will present the distinctive language features of Ruby that are key for frameworks like Ruby on Rails and made me fall in love with Ruby almost instantly.