This week, I decided to try PHP and Ruby-on-Rails for prototyping web applications (I’d never used either before).
These are both web-application frameworks that serious J2EE-type developers tend to sniff at, claiming that they may be fine for simple toys but are not suitable for real projects. Otherwise, however, the two are drastically different: PHP encourages a page-oriented architecture and makes you do a lot of extra work to get any kind of model-view-controller (MVC) setup; Rails enforces an MVC architecture with pre-defined naming conventions for database tables, etc., and makes you do a lot of extra work to design your application any other way.
I’ve long been an MVC and Java servlet fan. I love object-oriented programming, use REST as a web architectural style, and tend to think of XML-encoded data in entity-relationship terms. So why did I like PHP so much better than Rails?
I think that the answer has to do with the fact that web applications — whether producing HTML for people or XML for machines — are really about views, not objects. In anything but the most trivial cases, the views involve information from many different types of objects merged together to create a new object type. The most common way to generate these views is through SQL queries joining together different tables, and the columns in the result set define the properties of the new object type. I’ve spent a lot of time trying to use and trying to write object persistence layers for web applications, but they never made sense — my models always progressed quickly through the simple CRUD steps (X.create, X.read, X.update, X.delete) but then fell apart as soon as I tried to make my app do anything other than manage its base data. Should I define a new Java class for every possible kind of query result? How do I handle results that do not involve full objects? If I’m not getting full objects in query results, what’s the point of a persistence layer in the first place?
After all that soul-searching, prototyping an app in PHP was like a cool breeze on a hot day. I wrote a few helper functions to automate escaping values to avoid SQL or HTML insertion attacks, but I managed to fight off the temptation to write a persistence layer in PHP. Instead, each page has some PHP code at the top that makes one or more SQL queries, followed by HTML markup with only minimal PHP added to insert dynamic results. It works, it actually seems scalable and maintainable, it’s easy to deploy (just about all ISPs already support PHP, so you just upload the *.php files), and debugging is trivial, because the query is right there on the page with the HTML that will display its results. Bugs are not buried deep beneath 20 layers of abstraction, and the database and filesystem are the only shared state.
Rails, on the other hand, was a disappointment. It tries to make my database invisible so that I think I’m dealing only with objects, but my database, and its query capabilities, are what will make my application more than just a collection of objects with a simple search box. I ran into a bug during one of the tutorials and it was almost impossible to trace the problem due to the deep layering. And the only thing that Rails seems to simplify is the basic CRUD operations, which are the easiest part of any web app. Rails also tries to tell me exactly how to set up my database and page hierarchy — I know that I can change it, but by the time I’ve learned to do that, would Rails still be any easier?
I don’t know if I’m ready to jump to PHP for serious development yet. Java has a lot of good libraries for XML and supports Unicode well, and J2EE also lets me develop in a page-oriented model if that’s what I really want (though I have to do a lot of configuration rather than simply plopping a file into a directory). At the very least, though, I’m going to stop worrying about abstracting away the database and will try to learn to love it, whatever environment I use.
Quoderat 
Hey David,
What was the bug you hit during the tutorials? I’d appreciate it if you could report it at http://dev.rubyonrails.org, as we approach v1.0 we’d like to get everything squared away.
Hi,
Maybe CherryPy would be attractive to you then as an alternative?
To paraphrase the great American president Abraham Lincoln, “Rails rulez, PHP drewelz.”
You are definitely not the first person to feel his velocity plummet after getting past the scaffolding, which is basically a joke feature in rails. There’s something wrong with the learning curve that rails people need to figure out. Of course, it’s totally possible that the framework is just not for you, but to me, Rails’ architecture actually makes me more likely to think in terms of “how should this view really work, ignoring how I’ll have to implement it.” because there is so much less friction doing something like user.neighbors.magic_data rather than writing a bunch more $query = “SELECT *…” $result = mysql_query($query)… while ($line=…
I hear ya. I’m over in Perl-land, but there too, all abstraction layers have failed to really let me use a database as much more than an object persistance layer. SQL is a powerful way to combine and recombine data; all the persistance layers I’ve tried simply force me to clumsily reimplement the work the database can already do for me, and do so much better than anything I can write in the time willing to on it.
I hear ya. I’m over in Perl-land, but there too, all abstraction layers have failed to really let me use a database as much more than an object persistance layer. SQL is a powerful way to combine and recombine data; all the persistance layers I’ve tried simply force me to clumsily reimplement the work the database can already do for me, and do so much better than anything I can write in the time I am willing to spend on it.
I congratulate you write now Spagetticode.
Is it a jocke?
Wouldn’t a better comparison be PHP vs. Ruby or maybe Blue Shoes vs. Ruby on Rails? Comparing a scripting language to an application framework doesn’t seem like the best way to go.
I have to agree with Keith. You are comparing apples and oranges. It’s like comparing PHP with Strus + Tapestry + Hibernate. Which one would you say it’s easier? Still, you would have to admit that Rails is a lot easier that such a Java combo. Personally I make a living developing in PHP and have used different MVC PHP frameworks (and built my own) and now I’m starting to use Rails. I’m making my company switch to Rails for some large projects and I’m not looking back. Good lok with straight PHP.
Sorry to add to the nitpickers, but you say that Java people sniff at PHP and Rails (setting aside the fact that the apples to oranges comments are 100% correct) because they are only good as toy languages then pass judgement after working on small toy projects. Try comparing a PHP MVC-app to Rails and seeing what you think then. With erb, Ruby too supports a page oriented / templated design much like PHP. That would be a good side by side with PHP itself.
Lots of great comments — thanks everyone. Note that I’m comparing the web application design styles that PHP and Rails encourage, not the PHP and Ruby languages themselves. All Turing-complete programming languages are equally capable when you look at them long enough — it’s the programming communities that grow up around them that differ.
When you strip my posting down to its roots, the real question is whether it makes sense to organize information in web apps primarily as objects or as views. I used to be a big fan of the object approach, but it keeps getting me into trouble as soon as I move too far past the basic CRUD level.
Its not a question of objects *or* views, the real answer is both. Rails provides that balance very nicely.
I can relate to this post. I come from a background of serious C++ and Java infrastructure development, but have recently done a few small websites (just a few tables) using PHP. I find the simplicty of the PHP way of doing things very refreshing. Not having to worry about configuration or compiling makes the code-test cycle very quick. It would be intersting to try to find the level of complexity where it makes sense to start using the more complex frameworkd like Ruby on Rails or J2EE.
PHP vs rails might be apple to oranges, but In my own experience there is much more than a grain of truth in the concept that most MVC/application frameworks are 1 – not really needed in building 99% of web apps, and 2- tend to be more complex than the problem they aim to solve.
Separating sql from html is usually a best practice that will give you 80% of code reusability and maintainability.
SQL-to-object layers will usually be: 1 – harder to debug: is the local cache copy of the data in sync with the db? 2 – sloooow: you are giving away the best featuers your dbms gives you. You are ususally better off writing a stored proc than a query anyway. And what about objects that map to n tables? You will have to write views first, that map into objects. 3 – much less widely known and accepted than plain SQL. Next coder in the project is likely to have had sql experience, not necessarily experience with db-abstarction-layer-ofthe-month
Templating langauages are nice, but theings get complicated very quickly as they evolve into full fledged languages (see Smarty for a behemoth). In the end a simple language is a better bet than a good framework!
Gaetano — Smarty is a behemoth, but since PHP is itself a template language, all you really need is something to separate out your view logic. Savant (http://phpsavant.com/) is great for this, and it uses PHP itself as the template language, so it’s lightweight and very fast.
Just a general note – if you want something approaching a case study of how to build a maintainable PHP application, with use of MVC framework, check out Eventum, http://dev.mysql.com/downloads/other/eventum/index.html, MySQL’s bugtracker application.
Pretty much it’s what you’re describing here, with two further abstractions in the form of a template engine (Smarty) and classes with methods wrapping individual queries. The controllers themselves are individual PHP scripts with names corresponding to the actions they perform e.g. close.php. There are more elegant / clever / minimalistic ways to do things but Eventum represents a sane / safe approach to PHP apps.
I had many of the same concerns with Ruby on Rails – until I moved passed the prototype and started developing real applications with the framework.
The #1 reason I’ll never code in PHP again (and try get out of J2EE) is that RoR makes it easy to do things the right way. I reuse far more code and I find it drastically easier to track down bugs, conduct unit tests, use continuous integration, and refactor.
These are things you won’t experience in a weekend prototype – they are brought to light when you deliver an easily expandable, well-tested, and working application to clients.
I use PHP for 5 years now and really love it. There are 2 things that bother me though. For starters there are numerous MFC frameworks, code databases and other stuff but none of them is official supported except PEAR (which i don’t like for some unexplainable reason). Furthermore there is no decent universal package system in PHP.
Yesterday i read three Ruby on Rails tutorials from Curt Hibbs (O’reilly).
I was impressed.
Coming from page-oriented models en moving to MVC a few years ago (even creating my own PHP MVC framework). I like the way ruby implements the MVC model because is resembles my own solution model.
Ruby on Rails has already surpassed my own PHP MFC framework on things like javascript integration & AJAX.
Switching frameworks is hard, switching languages is even harder …
Pingback: Quoderat » Blog Archive » Sean McGrath’s obit for SOA
I know the guy that put this PHP on Trax together. It gives developers the ability to program in a most popular web language, yet in a framework that mimics Rails. No need to learn Ruby. http://www.phpontrax.com
You mean its a cheap clone of ROR and should be called Ruby on Rails
Pingback: Rails and Django Compared [@lesscode.org]
I’ve worked in PHP for 7 years (and some Java). Perl people had similar backlash to PHP when PHP was taking over its web niche.
I think Ruby on Rails is good beginning in making itself a niche of web applications.
It takes more thought to make a “realworld” * application fit into MVC, so I don’t think RAILS is going to take over PHP.
( * limited time, limited experience, limited scope of the application)
Ruby itself, or Python, might. (I’d speculate more towards python because it still lets you mix functional and object programming.)
I think the real problems MVC and other design patterns attempt to address are clear logical separations of code in larger systems. We’re all still in the infancy of a kind of architectual engineering. UML, flowcharts, requirements and specs written in English are our blueprints.
Check out aspect oriented programming, mostly used in javaland if you want to find a way to address big architectual issues. Otherwise, if you use PHP, try to clean up your code and separate and abstract functionality that was a happy, dirty hack a few years ago. If you use Ruby or Rails try to address critcisms as well as bugs, because the customer is always right.
Apparently even the Rails people prefer PHP:
http://www.rubyonrails.com/index.php
http://web.rubyonrails.com/includes/iframe_header.php?body_id=weblog
PHP fanboys are failing to see a very important distinction here – Rails is for building scalable web *apps*, not for building a quick data-driven website.
My own site is 100% PHP, and I will not likely change that. My newest project, however, will be in Rails, because it’s simply far easier to build an object-based web application in a framework like Rails, than coding in PHP. I should know, this is my 5th attempt at building this project. I’ve tried Perl and PHP, and am finding that 2 months of rails work is already surpassing 3 months of PHP work, and the system is far easier to debug and extend.
Making the database invisible shouldn’t cost speed. Rails creates the SQL and you can view it all in the logs to see what’s going on. I’m not going to claim the SQL is as good as if I had hand-written it, but it’s not something I’m concerned about causing speed issues. The backend seems to be pretty well-written, and continues to improve.
Another consideration is that all RAD tools come with a cost in speed. VB is a language I despise, but I can’t deny that people with vision have been able to throw together an app in a short time, and provide a valuable and useful product that fills a hole somewhere. At my previous job, we originally aimed for Visual C++, scoffing at our competitor who used VB. The competitor constantly outdid us, building new features faster (and with more stability) until we switched to Delphi.
What was my point… oh yes, speed tradeoffs. In most cases, if you use a RAD tool properly, you’ll lose a small bit of performance and cut down the development cycle drastically. For most web apps, the query performance isn’t the problem – it’s the bandwidth. And with rails’ architecture, using proper page/action/fragment caching is a breeze, so you can optimize *later* if you need to, without any code redesign.
Final thought: don’t rag on rails if you don’t spend a good deal of time playing with it. It may claim to be easy to learn (and it is, mostly), but there are things that make a lot of PHP/Java/Perl people change their minds when they dig deeper than the first layer. It’s really easy to use non-traditional database table and field names if that’s what you want to do, or if you’re connecting to a legacy database, for instance. Many-to-many relationships are expressed so easily it’s almost criminal. Hierarchical data structures, which are usually a pain to implement in a relational database, are a breeze. AJAX functionality, as of 0.13.1, is extremely powerful and still easy to use.
Dig deeper; you may be surprised at what Rails can do.
The real question is: what framework in PHP offers, right now, about the same stuff as ruby on rails with a great community and great docs? I work in PHP everyday and I love it, but I loved how I can build a prototype/application in RoR with just some lines of code. Most of my admin backend systems could be made in RoR in hours instead of days. Any ideas to improve productivity in PHP development (CRUD aplications and not-so-CRUD apps).
Pingback: workhabit: blog » Blog Archive » A conversation with Aaron.
Interesting article and discussion.
Another interesting thing is that people seem to mostly be concentrating on two-tier apps, where the server code accesses the database directly. These apps tend to be simpler which means that they can easily be written in straight PHP but they also can easily be achieved with something like Rails, which wraps the database with an object layer. The stuff that people do in J2EE tends to be three-tier architectures where there’s a layer of business objects and business logic on top of the database. Perhaps Rails would be a bigger win in this type of situation? In this type of situation, you’d have to write a bunch of glue code in PHP, but presumably in Rails you’d just modify the pre-generated scaffolding.
I’m no Rails or J2EE expert though. My experience is with PHP, building for the most part, two tier kind of stuff. I see Rails as being interesting for prototyping.
Now that I’ve gone through a basic tutorial of Rails (http://webmonkey.wired.com/webmonkey/05/28/index4a.html) and have seen how to build really simple apps, I’d like to hear from the Railophytes about how it fares for more advanced stuff…
Pingback: Marc Abramowitz
The best framework I have seen so far is Perl’s Catalyst, which improves on Rails in many ways, and builds on of the killer apps of the Perl world — Template Toolkit (TT2) and Class::DBI. The flow control mechanism is superior to Rails’ (and borrows from Cocoon), and the syntax of TT2 makes implementing a true MVC and page-centric app a breeze. People seem to bust on Perl just because it has been around, and it’s syntax isn’t “clean,” but it still seems to have the best apps at the end of the day. PHP is great — in part because it retains some Perl and C grammar — but to date it has nothing like CPAN, which is the real reason Catalyst ist possible.
Thanks for the article. When I tried out the Rails tutorials I didn’t find the paradigm pleasing. I’m still trying to figure out if that is because I’m not comfortable with web-based OOP or becuase I’m too familiar with the page-based PHP style. I certainly thought Java OOP was elegant, though I didn’t use it too extensively – but I haven’t been able to feel that elegance on the web side yet, and I think that this article points out why – because, fundamentally, traditional web apps are view-centric, and don’t adapt easily or particularly well to the MVC model. Certainly, there are plenty of ways to make web apps work with MVC and other OOP frameworks, but it doesn’t seem straightforward to me, at least not yet.
The problem here stems from the incorrect definition of what a web application is — it is not about views, nor is it about objects. A typical web application is centered around the state.
The MVC metaphor (or pattern) is solely concerned with the state as well. This is why it is a very natural fit for the web application paradigm. As the user/community interacts with a particular web app, it changes its state. That change governs how is the web app going to behave, which in turn facilitates various behavior from the end-user/community. All these changes in state need to be detected/processed/communicated by the web app.
Rails is by far the most sophisticated platform for enabling developers to articulate the above described dynamics. Placed next to Rails, J2EE and/or .NET platforms look like a very elaborate simultaneous translation session during a rock concert for the hearing impaired. Yes, it is possible to ‘sort of/kind’ of communicate in real time what’s going on at the concert stage using the sign language, but the real thing is to actually plug in and experience the performance directly.
Alex
> Rails is for building scalable web *apps*, not for building a
> quick data-driven website.
That’s a somewhat arbritary distinction. The Relational Model is able to provide data-schemas for every “need” that arises in the real world. It only starts getting “problematic” if you develop a (complex) OO-application first, and then want to “tack-on” persistence at the end using an RDBMS. Obviously programmers not familiar with the relational model and how to take advantage of it, favor this way of development – hence the hype and the many fanboys.
But then there are also those that believe it is going to cut short their development time (which does cost more than performance), because they don’t have to think and write DB-stuff. And to those the article gives a nice answer, IMHO. Sometimes it may, but often it won’t.
There’s a lot of misunderstandings here. PHP is not comparable to Rails. PHP is a language. Rails is a platform.
PHP is not page-based. The easiest way to start with PHP is to write page-based PHP, that’s all. But you can write php scripts that output no html.
I use my own homegrown MVC php platform regularly. The webhit hits a very short php script that looks like this (pseudo-code; not accurate php):
tpl->assign(“user”, new User($this->userid));
$this->tpl->display(“index.tpl”);
}
}
new Index();
?>
The Page is a Model. The User is a Model. Index.tpl is a smarty template.
My system is homegrown so it isn’t anywhere near as configurable as some of the open source models. But you’re comparing Rails to the absolute worst way of coding within PHP. Only newbies program in php by shoving php code (and sql commands! Ugh!) in the middle of an html page.
Ah well… the blog code wouldn’t output my php code example. Oh well.
Pingback: Standard Deviations » Blog Archive » AJAX and the clean Model-View-Controller
Pingback: zuzara.com » Ruby on Railsについて調べる
What about IBM and Zend working on an official framework that is supposed to be better then sliced bread and a visual studio type IDE….. I am excited, all these new frameworks, etc.. are really make each other work harder
check out http://cakephp.org
Maybe the reason you got tired of updating your persistance PHP layer is because you had to do them manually. I know that’s the reason why I almost gave up on persistance layers and “object databases” in general. But yesterday I found this website: haven’t used it too much yet but it looks pretty nifty, since apparently, whenever you need a new field, you simply regenerate your class. This might reinforce your choice of PHP vs OnRails.
http://www.phpobjectgenerator.com
I’m sorry but this article is very irresponsible. You played with the two languages for a couple days and then you write an apple-to-oranges comparison with nothing more than a cursory first impression.
First of all, you haven’t spent enough time building PHP apps to realize that you end up doing a ton of repetitive work. Sure it feels faster than the ever-verbose J2EE, but combine a dynamic language like PHP with a good MVC framework and you’ll triple your productivity again.
As for Rails, you claim that it tries to hide the database, is difficult to debug, and only helps with CRUD. You are wrong on all counts. First of all, RoR is very careful to give you hooks to any level of abstraction you want, from the common find and find_all queries through custom joins and where clauses, down to raw SQL. Why is this better than raw SQL? Because 90% of queries are the simple ones. Just because you are familiar with SQL doesn’t mean a simpler syntax isn’t better.
As for debugging, Rails is slightly weaker than PHP in terms of raw print lining, but it excels with features such as the breakpointer and logger. Not to mention you can debug the model completely separately from the command line. The ruby console allows you to modify instances of objects, not only changing methods, but modifying and creating singleton methods on the fly. This opens up debugging doors that users of almost any other language can only dream of. Debugging rails is actually pretty easy, but of course it will be hard when you are a complete beginner to ruby and rails.
The whole CRUD thing is a typical argument by people who make a snap judgement after watching the 15-minute video. Scaffold is not even 1% of Rails. It’s practically an afterthought. What makes Rails special is how it utilizes Ruby’s advanced features to set up a framework where you can truly Not Repeat Yourself to the maximum extent possible. Look into routes, flash, helpers, filters, callback, validation, and observers before making these kinds of snap judgements.
There are definite criticisms that can be made of Rails, but this kind of knee-jerk reaction just pollutes the web with misinformation. If you’re going to ‘try something out this week’, please give it a serious try.
Eventhough I haven’t used Ruby on Rails, I have seen their promotion video. Been on PHP boat since 2002, and I must say It’s just up to you! It’s OO now with PHP5 and it has matured to the level that it’s become enterprise level. Check Zend.com the official & commercial back of PHP. Lately IBM, Oracle, and others been partnering with Zend for PHP integration. SAP is in the game too! And with introduction of Zend Platform there is no excuse why not to use PHP.
PHP5 has all that you’re used on in Java, XML libraries, unicode, and many MVC frameworks that are available and waiting for you to grab them such as Mojavi, ZNF, Prado, BlueShoes, etc…
And if you’re worried about IDE or deployment tools, then check out Zend Studio at Zend.com
One very important point about PHP is that it’s joint the big players, we’ve got PHP certification now!
To conclude, use what makes sense for your job, project, and prefrence. I beleive you could never compare apples & oranges! Rails is a framework while PHP is a language and a platform.
Pingback: SitePoint Blogs » Looking at Catalyst
In reference to the original post, I find it ironic that a Java developer is complaining about the “deep layering” of Rails apps. Java, and all its Three Letter Acronyms (TLAs), have become the essence of superflous complexity. Ruby-on-Rails, by contrast, is very lightweight.
You should really, really try CakePHP (www.cakephp.org) it has all of the advantages of PHP, many advantages from Rails and a few little more things that make life easier.
Pingback: SitePoint Blogs » MVC and web apps: oil and water
You may consider http://www.achievo.org is a RAD in PHP, in few line you can code a CRUD application. They started in 2000 and there is a version 5.5.3 of their framework ready for download.
Please consider that if only requirement to WEB server is to publish XML then what is the position of Spring or Structs os Rails?
In my point of view, PHP is ok, mod_python is ok, snakelets is ok, servlet is ok. JEE or Rails may be good but useless. Everything for build page is XSLT or AJAX which runs within browser.
PHP feels good by accepting that you don’t have to hide the SQL.
For persistent ‘objects’ I like visible SQL (queries and views for your abstractions). PHP is scalable as long as your SQL is scalable.
In Java I like iBatis instead of Hibernate.
Comes down to ‘I use PHP/Ruby/Java whatever to acces my SQL data’ versus ‘I use SQL to store my PHP/Ruby/Java objects’.
What I find lacking in object oriented programming are (SQL) views. In SQL I can combine several tables/queries into one view and then treat that view as the basis for other queries.
what is better ??
this type of questions are not applicable in the software field , because the best is the best for that particular problem as an example my company is devoloping e-learning materials and tools and we devoloped all the projects using php becase
1- the all team knew it very well.
2- whe were dealing the database in a very low level.
3- we dealed with multimedia files in very low level format , creating swf,image and audio files from php.
after we produced our application we needed to have all those tools as a cd based applcation so we crafted apache,mysql,php together and with some addiotional exe’s whalllla we had a custom version that works in a cd.
could this be done in ruby ??? i doubt but it still possibel.
does that make ruby bad ??? of course no but in this particular situation i think it would be a bad choice
rotfl,
cakephp vs. ruby on rails -> GOOD!
PHP vs. ruby on rails -> BAD!
even if I love php, I feel the lack of what cpan is for perl and rails is now for ruby, i think the php comunity’s real problem is that pear is not as good as php itself. too concerned of beeing perfectly designed… none uses it.
Pingback: litiumOnline » it’s all about web app
>> I think that the answer has to do with the fact that web applications — whether producing HTML for people or XML for machines — are really about views, not objects. In anything but the most trivial cases, the views involve information from many different types of objects merged together to create a new object type.
—
I would disagree with that. Maybe my programming has not been proper MVC, but I have found that for something more complex than a couple of webpages put together – I spent about 6 months helping convert a legacy Foxpro app to PHP/MySQL – the separation is essential.
Imagine – we had like 10 developers in 3 countries, all trying to convert different parts of an around 120 screen Foxpro app (they defined the job amount by the “screens” converted).
Not separating Model into classes independant of controller/view pages would have been suicidal.
A typical page that user would call, would fulfill the role of Controller – getting input, validating it, and then depending on input and general app state, calling the appropriate actions in different models, assembling all the presentation info received into a structure, which then gets passed to a View (we used Smarty for Views, and it worked quite OK).
something like (pseudoPHP):
AddressEntryManagement.php (controller class):
…
if (user input action is delete && $id is sane and some other checks)
{
$addr = new AddressEntry($id);
$addr->delete();
$VIEW[‘result’]=’Success’;
}
… // other actions
$tpl= new Smarty(‘AddressEntry.tpl’);
$tpl->assign(‘DATA’,$VIEW);
$tpl->display();
=============
not entirely proper MVC maybe, but definitely loads better than the default approach used of simply making all the DB calls in the same place as presentation and controller.
Pingback: Quoderat » PHP, XML, and Unicode
Obviously, .net is the way to go.
I agree with this article for the most part. In fact, I am trying to do some independent research about frameworks in general which will hopefully clarify when a framework stops relieving the developer of tedious tasks so they can concentrate on their problem and starts forcing the developer to fit the problem to the constraints of the framework.
Pingback: Steve’s Log » Blog Archive » MVC and web apps: oil and water
Pingback: Upstream » My infatuation with ruby
Pingback: Quoderat » Sean McGrath’s obit for SOA
Pingback: Bit a Bit - by kTzAR » Ruby on Rails