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 :(

So what’s the point? Well, the point is Ruby. In fact, Ruby has almost all of the flexibility of Perl to do things in different ways. But at the end of the day, none of the Perl problems tend to show up. Why is this? And why do I feel so comfortable in Ruby’s “There is more than one way to do it” philosophy, while the Perl one scares me?

I think it comes down to language design. The Python approach is impossible for the simple reason that what the language designer chooses is going to be the “one way”, by fiat. Some people will agree, and some will not. But what I’m seeing in Ruby is that the many ways have been transformed into idioms and guidelines. There are no hard rules, but the community have evolutionary evolved idioms that work and found out many of the ways that doesn’t work. This seems to be the right way - if you do the choice as a language designer, you have actually chosen the people that will use your language: that’s going to be the persons who doesn’t dislike the language designers choices. But if you leave it open enough for evolutionary community design to happen you can actually get the best of both world: both a best way to do things, and something that works for a much larger percentage of the programmer world.

– http://ola-bini.blogspot.com/2008/02/language-design-philosophy-more-than.html

I like constraints, they can be liberating, but I also want to be treated as a grownup when it comes to breaking them. So Ruby’s socially suggested guidelines are much more comfortable to work with than Python’s enforced style.

I actually tried emacs before but didn’t stick with it long enough to really learn anything.

One school is that everything is fully deterministic in practice (“Theory D”). If development appears, from the outside, to be probabilistic, it is only because we haven’t discovered the “hidden variables” that fully determine the outcome of software development projects. And, since we are talking about development in practice, it is practical to measure the variables that determine the outcome such that we can predict that outcome in advance.

The other school of thought is that development is fully probabilistic in practice (“Theory P”), that there are no hidden variables that could be used to predict with certainty the outcome of a software development project. Theory P states that the time and effort required to measure all of the variables influencing a software development project precisely enough to predict the outcome with certainty and in advance exceeds the time and effort required develop the software.

…

To date, Theory P is the clear winner on the evidence, and it’s not even close. Like any reasonable theory, it explains what we have observed to date and makes predictions that are tested empirically every day.

Theory D, on the other hand, is the overwhelming winner in the marketplace, and again it’s not even close. The vast majority of software development projects are managed according to Theory D, with large, heavyweight investments in design and planning in advance, very little tolerance for deviation from the plan, and a belief that good planning can make up for poor execution by contributors.

Does Theory D reflect reality? From the perspective of effective software development, I do not believe so. However, from the perspective of organizational culture, theory D is reality, and you ignore it at your peril.

– http://weblog.raganwald.com/2007/06/which-theory-first-evidence.html

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.

What clicked about Smalltalk was a few things: one was simply the maturity, both of the community and of the technology. Smalltalk implementations have been refined over the last 25 years, and they’ve really benefited from it.

One of the major benefits, in my opinion, is that Smalltalk VMs are fast enough that it’s reasonable to implement all of the standard libraries – Array, Hash, Thread, and so on – in Smalltalk itself. So there’s no barrier where you switch from your Ruby code to the underlying C implementation; it’s “turtles all the way down”. This may not seem like a big deal but once you have it, it’s really hard to give it up.

…

In Smalltalk, you don’t have to choose one file layout or order of methods and classes in your code; you’re constantly switching views on what’s basically a database of code.

My friend Brian Marick hates this, because you lose any “narrative” that might have existed by putting the code in a certain order in the file, and it’s hard to get used to, but for me, it’s the ultimate power tool for hacking on a large code-base.

– http://www.akitaonrails.com/2007/12/15/chatting-with-avi-bryant-part-1
– http://www.akitaonrails.com/2007/12/22/chatting-with-avi-bryant-part-2

Long story short, the key to being bad and nationwide is to do something useful. Create something new, that definitely came from you, that other people value. Rails, Adhearsion, or even just a blog. This simple step is much more important than most people realize. It has to trace back to you personally, or it’s useless for your career. As programmers, we are in the position of working for people who do not have the ability to determine whether or not we are good at our jobs. Even other programmers sometimes have trouble figuring out who is or isn’t a good programmer. For potential managers and/or potential clients, the hiring and firing processes are both essentially random, unless you have some obvious distinguishing feature. That makes marketing yourself essential

– http://gilesbowkett.blogspot.com/2007/10/im-bad-im-nationwide-job-security-vs.html

Ironically, “I want to be a manager” is just about the worst sentiment a would-be manager could possibly express, because the statement has absolutely nothing to do with leadership. A leader doesn’t fixate on management, which is after all just a bureaucratic framework that attempts to simulate leadership through process and protocol.

http://steve-yegge.blogspot.com/2006/05/not-managing-software-developers.html

also

http://steve-yegge.blogspot.com/2006/03/moores-law-is-crap.html

Well, after a day playing around with jQuery, I present REST in Place

(Please head to the project page for REST in Place for the full announcement and comments)

In-Place editing RESTful resources

Writing applications in REST-style encourages an even stricter separation of view and controller logic than the usual Rails’ stack. A key principle is that the client alone should provide the user means to manipulate and PUT/POST data to the server. This is easier said than done in current browsers and with the HTML format (which just wasn’t made for building GUIs, but that’s a topic for another post). AJAX is the closest we can come to this ideal, enabling a seamless transition from a plain view of a resource to a editable form without going through too much pain.

A widely used way to achieve these transitions are inplace editors, made popular by Flickr and supported through nice helper methods in rails. The probem now is that these helper methods were written around, or even before Rails 1.0 with not the slightest hint of REST in them. Planting in_place_edit_for :object, :attribute in your controller creates a set_object_attribute action that finds an object by id, updates only attribute and renders attributes new value as a plain, short string to the client. The client, in this case the XMLHttpRequest, takes that response and puts it in the appropriate place in the HTML document.

There are several problems with this approach:

1. The generated actions are extremely simple and devoid of any form of sophisticated flow control (authorization, exception handling)
2. The generated actions perform a task that can be done in the good old update action and are thusly redundant.
3. Those new actions aren’t at all RESTful.
4. Ideally, no special server side code should be necessary.

While problem 1 can be easily countered by implementing your own version of in_place_edit_for, the real point are the other issues. The update action already performs the task of updating one or more attributes and is equipped with whatever authorization checks are necessary (does object belong to the logged in user?). The update action corresponds to the REST-verb POST and doesn’t violate REST principles.

A solution that solves all these problems would have to look like this (client-side Javascript only):

• The inplace editor posts to the objects url (something like /object/123), passing the attribute to be updated as a HTTP parameter.
• The server sends a response when the update is completed successfully or unsuccessfully.
• In case of an unsuccessful update some form of status could be transferred in the response
• In case of a successful update, the server doesn’t send the updated attributes value, instead the client should GET the object requesting a text/json content-type, extract the desired attribute from the json and update the HTML with its value.

I already tried building my own inplace editor Javascript helper but since much of the functionality of the rails inplace editor depends on the the editor defined in script.aculo.us I gave up. On the one hand the problem wasn’t so pressing that I could justify spending a weekend digging through the source, on the other hand I’d really like to see a good jQuery integration in rails and think maybe I could hit two birds with one stone if I try to go this direction one day.