devgrind

Maybe I like Ruby because I’m a lightweight developer? See for yourself:

via RedHanded.

Filed by Arne at 2:01 pm under humor, languages, ruby, video
No Comments.

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

Filed by Magnus at 4:59 pm under development, java, python, ruby
No Comments.

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 MyVeryOwnWebFramework^TM 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.

Filed by Arne at 6:45 pm under languages, ruby, scripting, typesystems, web
1 Comment.

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

Filed by Arne at 12:46 pm under design, java, languages, programming, python, ruby
No Comments.

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.

Filed by Arne at 6:28 pm under languages, rails, ruby
No Comments.