jan.varwig

That Object-Relational-Mapping is a difficult Problem is not news.

The usual criticisms are all valid, but what occured to me, after thinking a while about this, is that all approaches I’ve seen so far seem oriented to the object-oriented modeling, trying to map the OO-models to database relations.

What about tackling the problem from the other side? Relations can have huge benefits over object graphs, why not leverage their strengths and, instead of mapping OO to relations, just try to use OO to make dealing with relations easier and more natural in OO languages?

Relational logic is powerful and relatively easy to understand. There are just a few annoyances that should be addressed:

• Validation
• Mapping relations to forms
• Keeping track of associations

This wasn’t in any way thought through by me, it just came to my mind. Maybe there are already some solutions that go this route, maybe someone even proved this to be impractical. The approach seems worth investigating.

…as soon as I find the time :(

Last night Zed Shaws Rails is a Ghetto Shitstorm was brought to my attention. Zeds rant provides enough meat for a post of its own but it’s not what I want to write about today. Following some comments on Zed article on Technorati I stumbled (again) into one of those evenings full of great discoveries.

Git

Shortly before Git became really popular some months ago, I had become interested in darcs and distributed revision control systems in general. The topic is kinda difficult though and none of the texts I was reading at the time could really communicate the benefits of DRCS to me. I always had some gripes about svn but it wasn’t clear to me how DRCS were able to solve them.

I lost interest, following posts about git only loosely until last night a colleague pointed me to Randal Schwartz’ Git presentation at Google Tech Talks. Holy crap, I need to check this out. What appeals most to me:

• The ability to have the entire repository available locally
  I was extremely sceptical when I first heard about this, but when Schwartz claimed that the entire repository of the linux kernel is half the size of a checkout I was sold.
• Subversion interoperability
  Didn’t know about this before. Makes the transition much easier.
• Having local-only repositories inside your working dir
  I have many smaller projects that I’d love to keep locally contained. In Subversion I always had to create a repository on my server for everything.
• Other small things
  High compression, the simple database system behind git, the optimization for speed, staged commits, the ability to completely erase files from a repository (e.g. stuff not intended for publication, something that was very hard to do on subversion), the placement of all metadata in a single directory (opposed to littering every dir in the working copy with .svn directories)

Despite some shortcomings that was enough to make me install git on my mac (sudo port install git-core). I’m eager to check it out later today.

Smalltalk and Seaside

Ever since watching Evan Phoenix Rubinius Presentation at RubyConf 2007 and listening to Avi Bryants Smalltalk’s Lessons for Ruby Keynote from RailsConf 2007 I’ve been curious about Smalltalk. I mean, I was curious about it before, after all it’s probably the language that has the most influence on what I’m doing today (through its promotion of object-orientation and through providing key principles behind ruby), but since listening to Avi and Evan I’ve become really interested in VM implementations (see Smalltalk-80: The Language and Its Implementation for an excellent in-depth description of the orignal Smalltalk-80 interpreter) and real world usage of smalltalk.

To be honest, as much as I love Ruby as a language, its implementations all suck. And Evan explained why: Implementing most of the base language on another Platform (C for MRI, Java for JRuby) turns out to be a leaky abstraction when you want to extend the language. Additionally, as pure and beautiful the Ruby language is in concept, as ugly is its implementation. On the one hand, what I like so much about Ruby is its conceptual purity, its very limited set of axioms, syntax and exceptions from its own rules, on the other hand, this purity is not present in the interpreter when high-level data structures (like arrays and hashes) are implemented in C for performance reasons. Smalltalk has always had a strong philosophy of implementing as much as possible in Smalltalk itself and only resorting to C for a minimal subset (“Turtles all the way down”).

Rubinius aims to implement a Ruby interpreter on the design principles of smalltalk. I love the project and there seem to be only the most brilliant people working on it (Evan Phoenix, Eric Hodel, Ryan Davis and others, full time). As many others have said already, Rubinius is likely to become the main Ruby implementation if they manage to take off (and they will undoubtedly).

Yet, something was bugging me: If Ruby and Smalltalk are so similar, if Smalltalk has been around, specified and stable for 25 years in many different, compatible implementations, commercial and open source, why take the long route and bend Ruby to look like Smalltalk? Why not use Smalltalk directly? These questions became even more nagging after reading Randal Schwartz’ (yeah, the guy who sold me on Git earlier) Transcript show: ‘Hello, world!’, cr and Fabio Akitas excellent Interview with Avi Bryant (part 1, part 2). Listening to yet another chat with Avi (linked in the second part of Fabio’s interview) at Floss Weekly (with Randal Schwartz again, highly recommended) before falling asleep I finally decided to check out Squeak, the (most popular?) opensource Smalltalk implementation. I was amazed at the simplicity of the installation: Download the VM, Download the Squeak image, load the image into the VM, done.

I have read about Seaside, Avi’s web development framework, before, mainly in reagard to it’s clever use of continuations, but some of the stuff he described at Floss sound almost too good to be true. Live debugging of your app in the browser ? With hot code swapping over the wire? And I thought Rails’ rdebug integration was great.

Well, at 2am I was finally falling asleep but the stuff I’ve been discovering will probably keep me occupied for quite some time. As I explore and discover more about the topics mentioned, I’ll report my findings here on my blog.

In Ajax vs. REST I wrote about my ideas for a RESTful inplace editor.

Well, after a day playing around with jQuery, I present REST in Place Read the rest of this entry »

A small shop I’ve been writing for for fathers pharmacy was a welcome playground for modeling my domain RESTful. During my ventures, two big issues had me thinking quite hard for a while and there’s still no proper solution available. One of them was a DRY implementation of controllers for nested resources which I’ll describe later, the other one was the outdated inplace editor plugin in Rails.

Read the rest of this entry »

Quick, why does this give me a compiler error?

The compiler complains that the else in the second line does not belong to any if. Read the rest of this entry »

Since I wrote about F# in August, my progress has been rather slow.
There was a lot of work to do for Uni, almost all involving final touches to Pavel, the data-analysis tool me and a few other students have developed as a student research project. We’ll publish Pavel next week on SourceForge, I’ll write a few lines about it then.

Another thing that has held me back is my fascination for Haskell. Read the rest of this entry »

Es ist fünf Monate her da ich Web 2.0 für den Desktop geschrieben habe.

Vor einigen Tagen schrieb Joel Spolsky seinen Strategy Letter VI:

So if history repeats itself, we can expect some standardization of Ajax user interfaces to happen in the same way we got Microsoft Windows. Somebody is going to write a compelling SDK that you can use to make powerful Ajax applications with common user interface elements that work together. And whichever SDK wins the most developer mindshare will have the same kind of competitive stronghold as Microsoft had with their Windows API.

If you’re a web app developer, and you don’t want to support the SDK everybody else is supporting, you’ll increasingly find that people won’t use your web app, because it doesn’t, you know, cut and paste and support address book synchronization and whatever weird new interop features we’ll want in 2010.

Imagine, for example, that you’re Google with GMail, and you’re feeling rather smug. But then somebody you’ve never heard of, some bratty Y Combinator startup, maybe, is gaining ridiculous traction selling NewSDK, which combines a great portable programming language that compiles to JavaScript, and even better, a huge Ajaxy library that includes all kinds of clever interop features. Not just cut ‘n’ paste: cool mashup features like synchronization and single-point identity management (so you don’t have to tell Facebook and Twitter what you’re doing, you can just enter it in one place). And you laugh at them, for their NewSDK is a honking 232 megabytes … 232 megabytes! … of JavaScript, and it takes 76 seconds to load a page. And your app, GMail, doesn’t lose any customers.

But then, while you’re sitting on your googlechair in the googleplex sipping googleccinos and feeling smuggy smug smug smug, new versions of the browsers come out that support cached, compiled JavaScript. And suddenly NewSDK is really fast. And Paul Graham gives them another 6000 boxes of instant noodles to eat, so they stay in business another three years perfecting things.

Ich mache hier darauf aufmerksam, weil das thematisch so gut zu meinem Text von damals passt, nicht unbedingt weil ich noch viel Schlaues hinzuzufügen hätte. Das einzige was mir spontan dazu einfällt ist dass das in der Form ziemlich nach Java Webstart oder ClickOnce riecht.

Natürlich ist Joels Ansatz reichlich polemisch, trifft aber den Nagel genau auf den Kopf:

And that’s exactly where we are with Ajax development today. Sure, yeah, the usability is much better than the first generation DOS apps, because we’ve learned some things since then. But Ajax apps can be inconsistent, and have a lot of trouble working together — you can’t really cut and paste objects from one Ajax app to another, for example, so I’m not sure how you get a picture from Gmail to Flickr. Come on guys, Cut and Paste was invented 25 years ago.

I’m feeling all mad-scientistic tonight, sipping coke, with 30 tabs open in Opera :)

On my journey into the weird world of functional programming on the .NET CLR, I continue to stumble upon interesting stuff. Papers, articles, interviews, each worthy of hours of dedication. Alas, my day still has only 24 hours (I need to work around that somehow), so at the time being I can’t do much more than glance over everything. Read the rest of this entry »

Wie’s aussieht hat sich auch Steve Yegge schon damit beschäftigt:

OCaml has threads, exceptions, call-with-continuation, calling conventions to and from C, a rich standard library with collections, networking, I/O, graphics, a complete interface to the Unix programming API, and a powerful module system that blows Java’s packages away. It has interfaces and bindings for Oracle, MySQL, postgres, berkeley DBs, CORBA, COM, xml-rpc, SOAP, XML, perl-compatible regular expressions… the list goes on. You name it, it’s there.

OCaml has the potential to make me happy as a programmer, finally.

Mjamm :) Read the rest of this entry »

Wie heisst die Faustregel doch so schön? “Lerne jedes Jahr eine neue Programmiersprache”

Bisher schlage ich mich damit ganz gut:

2007: ein bißchen Python
2006: C#, Ruby, Javascript
2005: genug C++ um da in Zukunft einen Bogen herum zu machen, genug Haskell um ein permanentes distanziertes Interesse zu erhalten das vielleicht irgendwann durchschlägt in ernsthafte Auseinandersetzung.
2003/2004: Java
1999-2002: PHP, SQL Read the rest of this entry »