devgrind

Created by OnePlusYou

I named those codes, and boy, what a miracle - one hundred percent right. Try it yourself!

Filed by Magnus at 4:27 pm under humor, languages, quiz
No Comments.

I want a Firefox Plugin that recognizes that the page I’m looking at contains Java, does syntax highlighting and, most of all, inserts links to the classes and methods referenced in the code. The plugin (or a server it can ask) should know where the source code of a class like org.springframework.beans.factory.BeanFactory can be found.

First I thought that such a plugin would need (or could at least profit from) sem***ic web technologies (no dirty words on this blog, please), but it probably wouldn’t. All we need is a global registry that maps package names to the URLs of the web interfaces of the respective source repositories. (Maybe Google Code Search could be such a repository, but its results are often pretty bad.) The plugin would also have to include a reasonably good Java parser, and maybe a heuristic to distinguish betweeen Java and non-Java text.

Why would I want such a thing? Well, I often have to dig through the code of some open source library in order to understand a bug, or just to figure out what I can do with it, and how, because the documentation is incomplete or wrong. Usually I create an Eclipse project and import the code from the source repository, but that’s quite a lot of overhead if I just need to browse the code for ten minutes or so. On the other hand, digging through source code on web pages, without the help of links between the pages, is just a nuisance.

And wouldn’t it just be so cool to have one of the most important features of an IDE as a browser plugin, enhanced by the power of the world wide web?

P.S.: Or maybe I don’t want a browser plugin - maybe I just want Google to put some more effort into Code Search? Come on, guys, you’ve got all it takes - the global repository, the parsers, the heuristics…

Filed by chrisahn at 9:55 pm under development, eclipse, java, languages, programming
3 Comments.

In the recent weeks, both of my co-bloggers told me independently of each other about Groovy, the new hipster language which brings the scripting goodness of dynamic languages like Ruby and Smalltalk to the JVM Sweet JVM, so I finally couldn’t resist but take a look at it. To be honest, I didn’t like its Java-like syntax from the beginning, with all the parentheses, lowerCamelCaseIdentifiers and such, but that was just because I prefer Ruby’s very lean syntax. Its concepts are very close to Ruby (modification of objects and classes at runtime, blocks/closures, etc.) and of course it integrates well with the Java platform and its rich libraries, since this is the purpose for which it was created, to add a scripting facility to the Java platform. Groovy scripts are compiled into bytecode before execution and thus run on a normal JVM.

A crucial part for dynamic languages today (at least in my eyes) is the creation of domain-specific language, which Groovy also supports. Gant, for example, is a Groovy DSL for Ant scripts. Another example (take from the Tutorial Domain-Specific Languages in Groovy, PDF) I find very practical is a DSL for creating query criteria for Hibernate in the Grails framework (formerly known as Groovy on Rails, so its purpose should be clear):

def c = Account.createCriteria()
def results = c {
  like("holderFirstName", "Fred%")
  and {
    between("balance", 500, 1000)
    eq("branch", "London")
  }
  maxResults(10)
  order("holderLastName", "desc")
}

A good thing, but looks too java-y for my taste, I miss the feeling I get when using a Ruby DSL, such as SQL-DSL, for example:

statement = Select[:column1, 'book', 10].from[:table1, :table2].where do
  equal :column1, 99
  not_equal :column1, 100
  less_than :column2, 'foo'
  less_than_or_equal :column3, :column4
  greater_than :column1, 0
  greater_than_or_equal :column2, 'bar'
  like :column1, 'any'
  is_not_null :column1
  is_in :column1, [1,2]
  is_not_in :column2, [3, 4]
  exists 0
  not_exists 0
end

But maybe that’s just personal preference.

From a few first glance I get the impression, that Groovy is quite successful as a scripting sidekick to Java and I’m curious to learn more about it.

Filed by Arne at 1:51 pm under development, dsl, groovy, java, languages, learning, ruby, scripting
No Comments.

I would like to point you to a study a professor of my university (i.e. my workplace) did with his team. One goal, nine teams, thirty hours, three platforms - J2EE, Perl and PHP. Why they did not evaluate Ruby or Python is far out of my knowledge (and why anyone would do actually web devopment in Perl), but the setting is interesting enough. A rather lengthy report can be found here.

Update: I did not read the document thoroughly enough. The answers to my questions:

“We had some contact with potential teams from the Python arena, but there were not sufficiently many who were qualified enough. In the end, only one formal request for participation was submitted, so we did not admit Python into the contest.”
“It was impossible to find Ruby-on-Rails teams (“we are too busyâ€?). “

Filed by Magnus at 2:20 pm under development, java, languages, perl, php, web
1 Comment.

A while ago, Mike Clark wrote two blog postings on how to learn Ruby by writing tests (#1, #2). He explains that he wrote a test for each bit he learned about the language, over the years collecting a set of more than 200 tests which act as his personal knowledge base on the Ruby language:

Through trial and error they taught me how Ruby and its rich set of libraries really work. Not surprisingly, typing in code and running it makes you remember. Indeed, writing learning tests is a fun way to poke and prod any new language or API. And with every test you write you’re investing in an executable knowledge base.

Unfortunately I never tried this myself, but I like the idea. According to him, the benefit is twofold: The tests assist in acquiring and checking knowledge (by what he calls “asking Ruby”) and act as a knowledge base that manifests itself in code (and some documentation, where needed, I’d like to add).

Yet I am a little bit skeptical about “asking Ruby”. In his second posting, he suggests to “make a guess” in a particular case where he doesn’t know the result of a method invocation (“Rick”.index(’t')). Maybe I’m a bit hypersensitive here, but I have some reservations when it gets to using tests to find out how things (could or should) work. I’d think it would it be better to just look it up in a reference and write the test afterwards. The main reason is that using one test case (or a few) will give you one (or few) results, from which you will have to draw conclusions and generalize—the semantics of the index method in this case. What if your conclusions are wrong for some exceptional cases? Is it possible/feasible/desirable to write tests for each and every combination of parameters for a method? Why not trying a “read first” approach?

Nevertheless, the basic idea of using test cases for playing around with a language and collecting them as a reference is a nice idea. I’ll almost certainly try this the next time want to learn something about Ruby or a different language.

Filed by Arne at 2:57 pm under languages, learning, programming, ruby, testing
No Comments.

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.

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.

This will not be another programming language comparison frenzy. I had just some semi-serious thoughts about something I would call “language marketing”:

If you are starting to design a new programming language, start thinking of language identity. I do not know whether this term existed prior to this posting, but language identity is for programming languages what corporate identity is for enterprises. Of course, the scope of the language and all the nifty little features and whether it is compiled or interpreted and for which platforms the language is available is of some importance - but to make your language known, you need a lot more sexiness. This language sexiness is made by (but necessarily limited to):

• A logo. Or better, an allegory. As we see in successful languages, this does not have to be an animal (although this helps a lot with O’Reilly). Java has the coffee, Python has the snake (although the name comes from the British comedy group), Ruby has the gem.
• The name. C++ is a notable exception, taking its fame mostly from its predecessor C, which did not need a fancy name because it was the programming language sent to us from above in the Old and the New Testament. But most popular languages have names which are good to remember. Ask five developers how they are pronouncing “C#” and you will get six different answers.
• A web site. This serves as a hub for everything about your language. The Python page, for example, is so resourceful that keeping a local documentation for the language should never be necessary. There is even a Firefox sidebar for easy access to all the information on the pages.
• A figure head. At best, someone as strange and bearded as Larry Wall (PERL), at least some guru whose name is not even mentioned in full (like DHH instead of David Heinemeier Hansson, Rails/Ruby), or only by first name (”Bjarne said …”).

Filed by Magnus at 11:19 am under design, humor, languages, programming
No Comments.

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.