Blog Archive
This week, I’ll roll out a major update to REST in Place. I have completely restructured the code and made the Plugin much more object-oriented, modular and maintainable. Existing installations should be able to upgrade without a hitch. The most important change for users will be the jQuery 1.4 support and support for different editors (such as textarea, checkbox, etc.).
In November I got some pull requests for REST in Place which I didn’t get to really have a look at until last week. I haven’t really touched REST in Place in ages and wasn’t really aware that it was that popular. It has 72 followers and 11 forks on github and who knows how many other people are just silently using it! So, I merged in the contributions and dealt with some issues in the tracker and thought about how to go on.
REST in Place originally was a mere proof of concept and one of my first projects in JavaScript and jQuery. I have since written a lot more complicated applications and even a diploma thesis on JavaScript and the old code just isn’t up to my standards anymore. Additionally I have received several pull requests for textarea support which all couldn’t be merged because they were just copypasted and modified a little from the input-tag version. The only solution was a complete rewrite and that’s what I did. While the plugin still works the same way, the code is properly split up and more modular now. This enables easy extension and maintenance from now on and hopefully quicker development from me and better patches from all users.
This new development has some drawbacks too, unfortunately. This massive improvement will only go to the jQuery version of REST in Place. Since I don’t know much about Prototype or mootools, I can’t support both versions anymore. If someone is willing to work with me on this, I’ll happily accept their contributions but I can’t do this on my own. If anyone is willing to do so, please reply in the comments, so we can work out a plan. I want to keep all three versions as similar as possible, this means the Prototype and mootools versions should follow the same object-oriented structure as the jQuery version.
One last thing: I will support jQuery < 1.4 until 1.4.1 comes out. 1.4 introduced some very nice changes which I’d like to make use of but since 1.4 seems a little buggy still, I’ll continue to support the older versions for a little while.
(Sorry, content in german only for this post)
Ende 2007 habe ich bei 9elements einen Crashkurs zu Ruby on Rails gegeben.
Da mich inzwischen schon mehrere Leute gefragt haben ob ich die Folien nicht mal rausgeben möchte, tue ich das jetzt.
Die Folien sind absichtlich so gestaltet, dass sie auch ausserhalb des Vortrags als Nachschlagewerk für Ruby dienen können.
Der Rails-Teil ist ein wenig arg knapp gehalten und kann vor allem einen groben Überblick in den Aufbau des Frameworks geben.
Ruby & Rails Extremcrashkurs (PDF-Link) v1.0 27.03.09
Today Smashing Magazine published an article I wrote last week about Ruby on Rails.
Instead of just doing another tutorial, I gave a rough overview of how Rails works,
together with a lot of praise of the language and the framework.
I tried to spark interest in Rails and Ruby and judging from the first comments I think it worked :)
The text released today is only the first part, covering just enough Ruby to understand the second part coming out next week. If you like the article, please digg it or promote it on reddit/delicious/slashdot.
Ever since Rails 2.0 came out, my REST in Place Plugins stopped working because of the request forgery protecting introduced into ActiveController. The AJAX request didn’t submit the rails authenticity token and the requests weren’t answered.
I fixed that problem yesterday in both the jQuery and the Prototype version (both included in the plugin.)
Check it out on the REST in Place project page.
Rails association collections know two ways to determine their size:
- Through a dumb count as soon as you query the collection for its size.
This doesn’t require any additional work but puts quite a load on the database as soon as you have a large list of objects and want to know the size of an associated collection for each object. For 100 posts with comments, this approach would query the database 100 times with SELECT count(*) AS count_all FROMcommentsWHERE (comments.post_id = 1234). This might be okay for single objects which are queried from time to time but not for collections that need to be displayed frequently.
- Through counter caches that are a bit of a pain in the ass to set up correctly and gave me the fishy impression that they are easily corrupted.
Now, I admit that I didn’t spend too long investigating the implementation of the counter cache but after fiddling around with it for an hour before I finally found out how to properly initialize the cache in my migration and after discovering that the cache can only be changed relative to its current content, I left with a bad feeling.
All this hassle is absolutely unavoidable if you need maximum performance. In this article I’ll use blogposts and comments as an example, though only because this is familiar to many people. A real blog with a bunch of posts on its index page, receiving any considerable amount of hits per day is a bad candidate for the trick I describe here.
In raw SQL, if you want to find out the amount of associated rows in a different table, you use a JOIN, combined with COUNT() and GROUP BY, like this:
SELECT posts.*, COUNT(comments.id) AS comments_count
FROM posts
LEFT OUTER JOIN comments ON posts.id = comments.post_id
GROUP BY posts.id
Admittedly, this is slower than a counter cache but is not as difficult to set up, doesn’t risk errors due to a corrupt cache and if you chose your database keys wisely it is a pretty nice compromise.
When you ask an association collection for its size(), rails checks for the presence of a counter cache attribute in the current ActiveRecord object. If it finds one, it uses its content to return the collection size, otherwise the database is queried.
The catch is now, that in the above example, we inserted a perfectly valid counter cache column into our posts without specifying caching in the association declaration in the class. ActiveRecord inserts that columns content into a comments_count attribute in our Posts but since it doesn’t know exactly what to do with it, it doesn’t cast it into an integer but leaves it in there as a String. That makes size(), or to be more precise, the count_records() method trip with a “String can’t be coerced into Fixnum” error.
To fix this, I wrote an extension for the has_many Association:
module OptionalJoinCounter
def count_records
count = if has_cached_counter?
@owner.send(:read_attribute, cached_counter_attribute_name).to_i
elsif @reflection.options[:counter_sql]
@reflection.klass.count_by_sql(@counter_sql)
else
@reflection.klass.count(:conditions => @counter_sql, :include => @reflection.options[:include])
end
@target = [] and loaded if count == 0
if @reflection.options[:limit]
count = [ @reflection.options[:limit], count ].min
end
return count
end
end
Uh, well, yeah, the only change here is the .to_i at the end of line 4 but hey, what did you expect?
Save that in lib/optional_join_counter.rb and extend your association with has_many :whatevers, :extend => OptionalJoinCounter
Now, to get back to the example, imagine we want to use this trick to count our comments.
The above SQL can either be written by hand, or with Rails finder options:
Post.find :all,
:select => ‘posts.*, count(comments.id) as comments_count’,
:joins => ‘LEFT JOIN comments ON posts.id = comments.post_id’,
:group => ‘posts.id’
Ola Bini manages to express my feelings about the difference between Ruby and Python:
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.
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.
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
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
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.
more…
