One of those nights
January 3rd, 2008
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.svndirectories)
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.
REST in Place
December 23rd, 2007
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 »
AJAX vs. REST
December 15th, 2007
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.
Ruby: Introducing Super-Each
October 28th, 2006
Eine möglicherweise halbwegs sinnvolle Anwendung für den Proxy den ich hier vorgestellt habe.
Es wurmt mich manchmal, für das Aufrufen einer einzigen Methode in einem Enumerable dieses hässliche Klammerkonstrukt bemühen zu müssen:
Array#each{ |o| o.method }
Das geplante Symbol#to_proc sieht auch nicht viel besser aus:
%w[dsf fgdg fg].map(&:capitalize) # => ["Dsf", "Fgdg", "Fg"]
Die Lösung:
module Eachable
class EachWrapper
instance_methods.each do |m|
undef_method m unless m =~ /(^__|^nil\?|^send)/
end
def initialize(args)
@target = args
end
def method_missing (method, *args, &block)
@target.each do |elem|
elem.send(method, *args, &block)
end
end
end
def supereach (*args, &block)
if block_given?
self.each(*args, &block)
else
return EachWrapper.new(self)
end
end
end
class Array
include Eachable
end
chars = %w(a b c d)
chars.supereach.upcase!
puts chars.inspect # => ["A", "B", "C", "D"]
Viel schöner.
Problem: das sollte nicht supereach, sondern each heissen. Das wird im moment noch verhindert:
- die Implementierung verwendet selbst
each - die Art wie Ruby das
include Eachableverarbeitet, verhindert dassArray#eachüberschrieben wird.
Morgen, wenn meine Augen nicht mehr so schmerzen, finde ich eine Lösung.
Setting up your own Rails Environment on Dreamhost
September 13th, 2006
This is just copied from ruby-talk for archival purposes.
Rdoc Cheat Sheet
September 3rd, 2006
Well, there seem to exist numerous cheat sheets for Rails and other stuff out there, yet none for Rdoc. The official Rdoc Documentation is nice and complete, but sometimes it’s handy to have something you can print out on one page and quickly glance over.
I know that this nuisance hindered me to write extensive documentation for my current project so I decided to create a cheat sheet myself in the hope to encourange other newcomers to Ruby and/or Rails to develop a habit of writing good documentation.
Gotta love ruby
July 29th, 2006
Show me a language where you can pull stunts like this in the same amount of code:
# Pretends to be someone else
class Poser
instance_methods.each do |m|
undef_method m unless m =~ /(^__|^nil\?|^send)/
end
def initialize(args)
@target = args
end
def method_missing (method, *args, &block)
puts "Long lookup operation (missing #{method})"
@target.send(method, *args, &block)
end
def proxied_method
puts "Short proxied operation"
@target.size
end
end
p = Poser.new "Ruby Rocks"
# => "Ruby Rocks"
p.class
# Long lookup operation (missing class)
# => String
p.object_id
# Long lookup operation (missing object_id)
# => 263042
p.__id__
# => 263032
p.proxied_method
# Short proxied operation
# => 10