H3RALD - Tag 'rails' (RSS Feed)

Book Review: The Rails 3 Way

h3rald@h3rald.com — Sat, 26 Mar 2011 06:16:46 -0600

Obie did it, again. With the second edition of his former masterpiece, The Rails Way, he managed to outdo himself delivering a new, even more useful, Rails Bible. Wether you’re a Ruby on Rails professional like him or just an enthusiast, this book is pretty much everything you need to learn how to master the third release of DHH’s Ruby web framework.

The Rails 3 Way is no ordinary second edition. If you already own The Rails Way, you’ll be pleasantly surprised that this is a different, more polished book. While something had to remain the same, there’s a lot of new content in its 708 pages, and even the old content has been rewritten or at least revised.

It doesn’t matter whether you already know Rails 2.x or you’re jumping straight into the Rails 3 world, if you use Rails, you can’t miss this book.

I started the review of the first edition with a quote from my fiancée (now wife) on how pointless programming books are, especially those dealing with newish technologies: they tend to go out of date fairly quickly. While this still holds true, there’s not much you can do about it, except maybe purchasing a digital edition of the book instead. However, if you want to keep a good Rails reference book by your side, this has to be the one.

What's New

The Rails Way vs. The Rails 3 Way

If you put The Rails 3 Way and the original The Rails Way one next to the other, you can see that the new book is considerably shorter: about 200 pages less. This doesn’t mean it contains less information, quite the opposite: the new book contains a lot more stuff with less fluff. Obie managed to reduce digressions to a bare minimum and focus on providing more informative content to the readers using less text. Think of it as a fat-free book.

While no What’s new in Rails 3 section is included in the book, Obie points out the new stuff when needed (but not always). An example is chapter 12, Ajax on Rails, in which changes introduced by Rails 3 clearly stand out, especially the section on Unobtrusive JavaScript (UJS).

Although the book is divided into chapters, it can also be divided into parts (each dealing with a specific theme) simply by looking at the front edge. According to this theme-based partitioning, Active Record makes up for nearly a quarter of the book (173 pages), followed by Active Support API appendix and the All About Helpers chapter.

Another nice addition that can really make the difference when you’re in a hurry is the Method Index, which is separate from the main Index. It seems to account for all the methods in all (or at least the most important) classes in Rails. I didn’t check method by method, but it is pretty comprehensive nonetheless, based on some quick spot checking.

Active Record makes up for over 24% of the book

The first thing you notice once you read the first few pages, is that this book is even more opinioned than its predecessor.

Even though Rails 3 is less opinionated than early versions, in that it allows for easy reconfiguration of Rails assumptions, this book is more opinionated than ever.

– Obie Fernandez, Introduction to The Rails Way

In other words, you won’t find an ERb view in the whole book (Haml rulez!) and if you don’t like RSpec… well, you’d better skip Chapter 18 altogether.

The other big difference with traditional Ruby and Rails books is the amount of reference to third-party code, mainly rubygems. Rails comes with no authentication functionality? So what: Authlogic and Devise are great for the job, go check them out! Do you need to test your Active Mailer emails? email-spec is all you need.

I was actually surprised to find so much content not strictly related to Rails in this book: the first chapter starts off with Bundler (now a Rails dependency, however), Chapter 2 (Routes) mentions Rack, and so does Chapter 4 (Controllers). If you want a nice and to-the-point practical introduction to RSpec, the first part of Chapter 18 covers that.

About 40% of the book is reference material

Then there’s reference material. Plenty of it, a good 40% I daresay. The good thing is that (unlike the first edition) it won’t bore you to death: take Chapter 5 (Working with Active Record) for example, you’ll fly through find-related methods so swiftly you’ll regret when it’s over. Active Support? I didn’t read every line of Appendix B, but when I want to know something about inflection methods I will know exactly where to find them, and what to expect: the method signature, a few lines of text, and a short example at most.

My only regret? Cheat sheets. Or better, the lack of them. More tables, please! Granted, the web is full of Rails cheat sheets, but a few of them at the end of the book or even in a separate foldable add-on like in the Pragmatic Programmer can’t hurt.

Finally, some words about the code examples. The code/text ratio is almost 1:1, but Obie’s choice of not turning this book into a huge tutorial by implementing a single example application was absolutely right: The code snippets used in throughout the book are concise and relevant to the text around them and won’t distrupt your reading. If you want to play with them, they’re even on GitHub for you to clone and fork.

Organization and Writing Style

Yes, it’s a long book. But you don’t
have to read it from start to finish!

The Rails 3 Way is a book for Rails professionals. If you don’t know Ruby or if you never heard of Ruby on Rails, this book is not for you. It won’t teach you what MVC is, it won’t waste time on explaining convention over configuration, it won’t even describe the structure of a Rails app! If you’re newcomer to Rails… well, that’s what The Rails Tutorial is for.

To be honest, I’m with Obie on this. If this book had been beginner-friendly, it would have been even longer than the previous edition, and probably more boring. Instead, by assuming that the reader has been already initiated to the world of Ruby and Rails, the author can dive into the framework straight away. Moreover, chapters are not ordered by difficulty: they don’t need to be, they need to be ordered in a way that makes sense for a Rails developer.

Once again, this book includes personal sidebars used to voice the opinion of one of the co-authors or Rails gurus: there are plenty of “Yehuda says”, “Xavier says”, “Durran says”, and so on. Nothing new there, it’s just a nice way to provide the reader with authoritative opinions on some matters.

As I progressed through the book, I started noticing how Obie anticipated my questions and doubts: I found this to be a remarkable feature of this book, and an excellent way to make the readers feel they are on the same page with the author. If something should not be done because it may cause you problems, the author won’t hold back. See page 214, “Extra Columns on has_and_belongs_to_many Join Tables”, for example: it’s a cool feature, but it can cause all sort of annoyances, and the bottom line is: use has_many :through instead, if you need extra columns on join tables.

Conclusion

The Rails 3 Way remains the de facto reference book for Rails. I was quite pleased to see that Obie improved it so much, compared to the first edition. Sure, it cannot be recommended to absolute beginners, but it’s not a big problem: if you’re new to Rails, all you have to do is browse around and read a few basic tutorials first.

What I really missed was a What’s New section, or something like that. The new stuff that was introduced in Ruby on Rails v3 is seamlessly blended with all the rest, which is great if you’re tackling the framework for the first time, but not so much when you already read tons of books on Rails 2.×. I would have tagged content specific to Rails 3 in some way at least, for example with labels on the side of each page. Or maybe have a short introductory chapter covering the new features, and directions on where to find them in the book.

Overall, The Rails 3 Way is a great book, and if you plan on using Rails 3 for your next web site, it deserves a special place on your desk.

Book Review: The Rails Way

h3rald@h3rald.com — Sun, 04 Jan 2009 01:03:00 -0700

"Programming books are pointless: you buy them, you read them and you chuck them because they're already out-of-date!"

This is a quote from my fiancée, who always pointed out the ephemeral nature of programming books and therefore highly discouraged me from buying any more. The sad thing is that this is partly true: if you buy a new programming book it will eventually become outdated pretty quickly, especially if it's about newish technologies like Ruby on Rails.

The Rails Way is no exception: Rails 2.2 has been out for a while and introduced a few new features – most notably Internationalization support – which are not mentioned neither in this book nor in others.

That being said, The Rails Way by Obie Fernandez is still the best and most comprehensive book on Rails v2 currently on the market. It's the book you simply cannot afford to ignore, if you are using (or are planning to use) this popular Ruby web framework.

Before proceeding any further, I'd like to point out that is probably one of the longest programming books I've ever come across. With its 910 pages, The Rails Way definitely cannot fit in your pocket and you cannot take it around with you easily. It's a book made to sit on your desk constantly and remain there, ready to be accessed at the right time, when needed. Unlike with other books I reviewed, this time I won't even attempt to go through every chapter and every section: it would not be meaningful for the review and it will probably bore you to death. For completeness' sake, however, here's a very trimmed-down table of contents listing only the first level headings:

Introduction
Chapter 1 - Rails Environment and Configurations
Chapter 2 - Working with Controllers
Chapter 3 - Routing
Chapter 4 - REST, Resources, and Rails
Chapter 5 - Reflecting on Rails Routing
Chapter 6 - Working with ActiveRecord
Chapter 7 - ActiveRecord Associations
Chapter 8 - ActiveRecord Validations
Chapter 9 - Advanced ActiveRecord
Chapter 10 - ActionView
Chapter 11 - All About Helpers
Chapter 12 - Ajax on Rails
Chapter 13 - Session Management
Chapter 14 - Login and Authentication
Chapter 15 - XML and ActiveResource
Chapter 16 - ActionMailer
Chapter 17 - Testing
Chapter 18 - RSpec on Rails
Chapter 19 - Extending Rails with Plugins
Chapter 20 - Rails Production Configurations
Chapter 21 - Capistrano
Chapter 22 - Background Processing
Appendix A ActiveSupport API Reference
Appendix B Rails Essentials
Afterword What Is the Rails Way (To You)?

If you already know Rails, these titles will be self-explanatory to you. If not, you'll just have to trust my words when I say that this book covers every possible aspect of the framework, and 99% of the notions you need to know to start developing almost any Rails-powered web application.

What really pleased me were chapters 17 through 22, i.e. something not strictly related to Rails Core. Normally, books about Ruby and Ruby on Rails don't deal with anything even a little bit outside their scope: as a result, topics such as Rubygems, RSpec and Capistrano are often not mentioned at all, or if they are, they are relegated to one or two pages at maximum, leaving the reader to look on the Internet for more information. By contrast, The Rails Way covers these ancillary but still very important topics very in-depth. Sure, you won't know the inside-out of RSpec after reading this book (although a whole chapter is devoted to it), but you will certanly know your way around it enough to use it properly.

What's missing in this book then? Maybe a Chapter 0 to guide the absolute beginner through the very basics of Rails and Ruby. Probably this goes beyond the scope of the book though, as the author clearly states that the book _"[...] is not a tutorial or basic introduction to Ruby or Rails. It is meant as a day-to-day reference for the full-time Rails developer. "_. Still, 100 pages about the Magic of Scaffolding & other tricks to astonish the children wouldn't have damaged the book, especially considering that Chapter 1 starts at page 60 after a lot of pages intentionally left blank, Introduction, Foreward, Acknowledgements and similar padding material.

Organization and writing style

"Before going on, I should mention that part of what makes Rails exceptional is that it is opinionated software, written by opinionated programmers. Likewise, this is an opinionated book, written by opinionated writers."

This sentence in the Introduction sounded very familiar. Almost an echo of Zed Shaw's own words in the Mongrel Digital Shortcut. After all this book is part of the Addison-Wesley Professional Ruby Series, of which Obie is the Series Editor. Like the other books in the series, this book contains all the stylistic conventions and distinctive features which make them very enjoyable to read:

Informal, almost personal style – reading this book is almost like hearing Obie telling you what he thinks about Rails, and sharing with you his own tips and tricks.
Honest, even humble at times – This book doesn't glorify Rails or Ruby: on the contrary, pitfalls are acknowledged and dealt with. Rails lacks an inbuilt authentication system? No problem, a whole chapter is devoted to the act_as_authenticated plugin. You almost feel it's part of the core itself.
"[Person] says" sidebars – The book's co-authors occasionally have their saying in special sidebars, all throughout the book. A way to evaluate different opinions and take a break from the book's main flow.
Code snippets – Not too many, not too few, just about the right amount. Granted, you won't find any sample application in this book, but the snippets provided are more than enough to get to the point.

Although this book is meant to be a reference, this doesn't mean it only contains reference material, it means that if you don't know about a particular feature of Rails or its satellites (Capistrano, RSpec, testing in general, etc.) you can open the book at any chapter and read through an in-depth discussion which will, most likely, answer all your questions.

Even if what you're looking for is not strictly related to Rails but can just be used with it, you'll find it in the book. Some examples include a 23-page-long exhaustive dissertation on Prototype, a whole Chapter on RSpec, another on Capistrano and even information on XML parsing through REXML.

What you won't find in the book, unfortunately, is how to get something which was not meant to be seamless integrated with Rails to work, like JQuery, for example. But again, this is understandable, as such topics would have made the book three times longer, at least.

Some constructive criticism

As a technical writer, I was somehow unhappy of the way reference material was presented in the book, i.e. more or less as ordinary chunks of text:

execute(sql_statement)
Executes the SQL statement provided in the context of this connection. This method is abstract in the DatabaseStatements module and is overridden by specific database adapter implementations. As such, the return type is a result set object cor- responding to the adapter in use.

insert(sql_statement)
Executes an SQL INSERT statement and returns the last autogenerated ID from the affected table.

You'll find plenty of pages like this in the book. Although all essential the information about each specific method is there, it is not organized properly. When I'm coding and I want to look up something quick, chances are that I can just hop over to APIdock or other similar services and query Rails documentation in a much more efficient way.
On the other end, if reference material was added for completeness' sake, it would have been much better included at the end of the book, more succinctly, through some carefully constructed reference tables. If the aim was instead to help the reader memorize all the method he must know to work productively with Rails everyday, the author should have included some diagrams or any other type of visual aid.

Similarly, the Stack Checklist included in Chapter 20 is not actually a list at all, but rather a sequence of titled paragraphs which is definitely a good read the first time, but it won't be as useful when you need to just refresh your memory.

I admit, I noticed these things because part of my daily job as Technical Writer consists in making sure that reference material is well presented in the most minimalist, direct and useful way to the reader. Maybe a year ago I wouldn't have thought anything of it, but now I felt compelled to point this out hoping the next edition of the book will deal also with this aspect of the book.

Since the book came out in 2007, the organization and presentation of Rails Documentation has been significantly improved by third-party services: I hope the authors and editors will try to make sure, next time, that the reference material is more usable by the readers.

Conclusion

Overall, the book is a good read. It's even possible to read it sequentially (even if the author discourages this practice) and still get the most out of it – a rare trait in programming books nowadays.
No other book will go so in-depth about Rails or about everything you need to know to get your site up and running in areal production environment. That's the reason why The Rails Wayis the perfect companion for web development professionals who must ensure their applications are tuned up to perform and scale well.

This doesn't mean that beginners should be discouraged from reading this book, quite the opposite. This is actually the only book newcomers to Rails need once they are done reading all those awesome beginner-oriented tutorials freely available on the Internet. Everyone interested in Rails, at some point, has to follow The Rails Way.

Rails-powered Open Source Killer Apps, Anyone?

h3rald@h3rald.com — Sun, 02 Nov 2008 02:41:00 -0700

Lately I’ve been meandering around the web to find a good CMS for a family site I’d like to set up.
Why a CMS? Well, for a few simple reasons:

I don’t have enough free time to fiddle with Rails and make my own (I’m an Hobbyist Programmer™: I code for fun and enlightment, not for money)
Even if I had the time, I’m sure there are plenty of CMSes out there which suits my needs.

It turns out that reason #2 is not really applicable in this case, especially if we restrict the field to Ruby + Rails/Merb/<insert cool DRY framework here>.h3. Rails-powered CMSes

Name a Rails-powered CMS, quick!

Easy: Radiant.

Hmm, no. As much as I do like Radiant, it really cannot be considered a general-purpose CMS, can it? When it comes to build nearly-static sites in a clean and neat way I’d pick it any day, but it lacks quite a lot of community features like comments, ability to create forums, etc. etc. It does, however, support multilingual content in a rudimentary, yet effective way: create each translated page manually and use consistent URL conventions (/en/about, /it/about, etc.).

I’m not saying that there aren’t enough CMSes built on Rails, just that there’s no “killer app” in the pack. A “killer” CMS would be something as powerful as Drupal, but easier to use and more modular.

Here’s an incomplete list of the Rails CMSes I’m currently aware of:

Name	First Impressions/Comments
Radiant	Mature, suitable for administering static sites
Typo	Mature, one of the best blogging engines out there (my opinion is slightly biased though)
Mephisto	Mature, blogging engine
Rubricks	Under development, basic features if compared to other non-Rails solutions
Slate	Missing a lot of features if compared to competitors
Beast	Forum engine, extremely ligtweight
RailFrog	Not sure if it’s still being updated, not so many features
Zena	Alpha, looks promising although it doesn’t offer many features
simplelog	Yet another blogging engine. Simple and easy to use
oooopen rcms	Early development stage (dead?), minimal feature set
Geego	Multilingual, not so many out-of-the-box features

[Psst, if you know any other Rails CMS I missed out, mention it in a comment and I’ll update this table!]

Developing Proprietary Web Applications with Rails

What’s wrong with all of these? Normally one of three things: either they are mature, production-ready but focused on only one particular function (blog, forum, etc.), or they are still too new to be used seriously or they are slowly heading towards oblivion.

What’s going on here? Rails is a damn fine framework which offers all the modularity and power you need to build sites! Why isn’t there a fully fledged CMS to rival Drupal?
I think that part of the problem is that Rails is too good. Why build a CMS from scratch when you can develop a web site from scratch much more easily, tailored to your customer?

Rails has been used to build a few “mainstream” sites like Twitter (no bashing please!), Basecamp, GitHub and many more. What do these sites have in common? They are not open source. You cannot deploy your own Twitter on your server (You can with Laconica, though), you cannot deploy your own Basecamp to your server (you can with ProjectPier, an open source fork of ActiveCollab).

It feels like that even though Rails itself is open source, there aren’t that many open source Rails-powered projects after all. Maybe there are, but they do not really compare with similar alternatives offered in other languages. This is the reason why, despite its utter ugliness, PHP is still the Open Source King of the Web, and that’s very, very sad in my opinion.

Dreams on Rails

The annoying thing is that Rails is suitable to build CMSes, and good ones, too! Take Radiant and Typo, for example: they both excel in their own ways, in their own worlds.
Theorethically speaking, there’s no reason why someone couldn’t develop a modular system to glue different components together: you’d need common user administration and common workflow, a few hooks, and a solid set of conventions on how to build third-party components.
Hell guys, the folks at Drupal developed a huge (and successful) product with a million different ways to extend it in PHP. Even without using OOP! Every damn hook in the core is a function.

What does it take to do something like this using Rails, o Merb, or whatever else you like? You already have a very solid and consistent framework to build on (Rails), a way to automate tasks (Rake) and a language which lets you do everything you want, in a very elegant and organized way.

Rails lacks successful open source projects, in particular CMSes. I wish someone could fix this: not by coding the n^th^ CMS with the only two or three features you need, but by developing an high level application framework to build complex, dynamic and interactive web sites. Don’t even develop the whole damn thing: just come up with a set of conventions on how to extend a very basic core, and tell people how they can contribute, or even integrate existing applications into it.

The community will do the rest, hopefully… Or maybe are you too busy trying to roll out your newest, closed source startup?

If someone decides to develop such a powerful, high-level framework and is determined to keep it user-friendly and open source, I hereby promise to write the documentation for it, articles, and books. And I’m not kidding.

[UPDATED] A Glimpse of Hope

A few of the commenters of this article brought up a few interesting points and actually gave me a little bit of hope. Luigi Montanez pointed out that Rails was built to help developers build web sites. For now, Rails deployment isn’t as seamless as end users would like it, so there’s no point creating a killer app for such users if they can’t even get it to run on their $2/month shared hosting environment.
Nevertheless, there seems to be at least three different open source “social network engines” powered by Rails:

These are not CMSes in the early 2000’s sense, obviously, but they do provide the basis to effectively build a late Web 2.0-ish community web site. Each one of these project seems stable and mature enough to be used in production, but surely not as well-known as many other PHP-based solutions.

On the other hand, Priit Tamboom mentioned adva cms, a project still in alpha stage which aims to be more traditional and site-agnostic:

“[…] Different from other Rails applications the all-engines approach of adva cms allows you to build your own applications on top of it. It also makes it very flexible and extensible: our plan is to make it possible to only pick those engines/features that you really need for your application and omit the rest. As they are still all designed to work together seemlessly and reuse each others functionality the whole plattform feels much more consistent to a collection of similar but separate Rails applications. […]”

This sounds exactly like what I was hoping would come out from the Rails community: something in between a web development framework and an high-level CMS.
I’m definitely going to try it out (it’s an ideal weekend project) and I’ll report back once I know more about it.

Introducing H3RALD.com v7.1

h3rald@h3rald.com — Sun, 26 Oct 2008 22:29:00 -0600

I finally decided to redesign my web site. About 2 years passed since last time and I think this was long overdue: a lot of people liked the black Nitefall theme, but a lot of people found a bit too dark for their liking.

I decided to go for something more ~~boring~~ traditional this time: white background and only black header and footer. I think the new design improves the overall readability of the site, also because this time I kept thing simple:

No more sidebars – Who needs them anyway? Who wants to see my delicious bookmarks on every single page? Who wants to see that annoying Web 2.0-ish tag cloud listing all the tags I’ve ever used from 2006 onwards? I suddently realized that the right column was nothing more than wasted space, so I removed it altogether.
No more differentiation between articles and blog posts – As a matter of fact, I’m not posting little pointless tidbits everyday, it’s more likely just once a week or even once a month. When I post though, I tend to make it worthwhile both for me and the readers by writing about something which may interest people, for a change. In short: this may not be a “traditional blog” anymore, just a publishing platform for my articles.
No more “previews” – From now on, only the title of each articles is displayed in the home page, in the archives and even when searching. If you want to read an article, all you have to do is click on its title. No more “Read More” links.
Just three main pages: Home, Archives, and About. Although there may be some more for special projects, at some point.
Use the Archives to find my articles. There you’ll find a list of the 20 most used tags, a search form, and a timeline listing all my articles from 2006 onwards.
Use the tiny palette on the left side of each page to perform common actions like bookmarking, scroll up and down, etc. You can read more about it on the About page.

I hope you like the new design, or at least I hope it makes my articles more readable. However, I’m open to suggestions, as usual.

P.S.: I dropped with Internet Explorer 6 compatibility According to my stats, less than 5% of my visitors use it, so it’s not worth the extra hassle.

Rails-Doc.org - A First Look

h3rald@h3rald.com — Wed, 18 Jun 2008 23:30:00 -0600

When you decided to learn Ruby on Rails (if you did, that is), chances are that you bought a book. I did, too, actually: there are a lot of very interesting and fairly comprehensive books out there after all.

I actually never bought a book to learn PHP, in the past though. Why’s that? Well, for two simple reasons:

The PHP manual can easily be searched and provides enough documentation, in most cases.
When the documentation is not enough, there’s always plenty of comments by experienced developers to save your day.

That being said, PHP is still an awfully disorganized language, but believe it or not, coming from PHP I didn’t find Rails documentation useful enough simply because it didn’t have these two simple but very powerful features.

Sure, there’s the Rails Documentation Project which provides more organized docs, and Noobkit does a nice job with its search-as-you-type feature… but still is not quite enough: you’d expect something much better than that for something like Rails!h3. Introducing Rails-Doc.org

Rails-Doc.org focuses on providing a better interface to Rails documentation by offering two key features:

A powerful, fast and useful document search
The possibility to add notes to Rails documentation

When the app went live, I immediately registered (it’s free of course) and started playing with it…

Search as you type…

The first thing I did was trying the search features, of course. I started typing “rout” for Routing, and I was immediately shown a list of matches:

It took a small fraction of a second to load the matches, which makes me think that definitely they have all the names indexed somewhere. Nevertheless, it was a pleasant surprise: normally, these search-as-you-type utilities are not that refined!

All you need to do is start typing at least three letters, and you get results, if any.
if you press ENTER, you get automatically redirected to the first result. This can be good, but maybe it would have been nicer to load a “traditional” list of results, but it depends on your taste, really.

…or browse through the namespaces

Alternatively, it is possible to browse the docs in the more traditional way, i.e. according to their class or module: the Browse page does just that: it lists all Rails classes and modules, regardless of the nesting. But there’s more: a little roundy icon precedes each class name, to indicate whether the documentation is present, and to what degree:

This is an interesting concept: in this way, in theory, people should contribute to the documentation where it’s more needed.

Each reference page is very neatly re-formatted: you can hardly imagine it’s actually the same content included in Rails’ RDoc pages!

Finally, another nice addition is the Related column, which lists links to other items which are related to the current topic:

Contribute, contribute, contribute!

You have to register for something, don’t you? Yes. If you register, you can post notes to any document. Simple enough, all you have to do is to click the Add Note button and a form will slide down for you to fill in:

As you start typing, you’ll notice that a preview of the note is displayed instantly: as you can use SimpleMarkup to write notes, exactly like in RDoc, this feature can be very handy:

What if there’s no documentation for a particular class or method? You’ll get a warning like this one:

The idea behind this is that, if you provide some useful insights, they’ll eventually end up in Rails core documentation.

An Short Interview with Mikael Roos, from Nodeta

Before the application went live, I was lucky enough to get Mikael Roos to answer to some of my questions. Here’s the full interview…

What are you actually trying to do on Rails-Doc.org?

The initial goal of the project is to provide the existing documentation in a more accessible way, most importantly to provide a lightning fast search feature that gives weighted results based on the
quality and amount of documentation. This we have already accomplished, and all remaining issues are related to browser compatibility. Another initial goal is to present a smooth interface for creating inline notes to
the documentation so that Rails developers can post notes about certain methods etc. for themselves and others to draw knowledge from.

Our longer-term goal (N.B. we are an agile project, so long-term means, say, three months) is to provide a way for the active members of the Rails community to improve the existing documentation based on the posted notes
to create an extended documentation that could optimally even be made in to a patch and would find its way back into the actual Rails source.

Another clear and obvious goal is to keep improving the service steadily as we progress toward the goals that I mentioned above.

Could you spend a few words on the “development process” followed by your company to develop this app? Did I read the word “Scrum” somewhere? Am I correct?

Yes, our development process of choice is Scrum. The core team is only three members, one backend developer, one backed/frontend develope and one frontend developer/UI specialist. I feel the team is optimal in many ways.
The team also has a few more experienced developers who are primarily active in other projects to ask questions from, one of whom is also the acting product owner on the Rails-doc project (that’s me!).

Did you develop it in three months, or…?

The first release was developed in three SPRINTS, not months – so what I’m saying is the first release was developed in five weeks (first sprint was mostly introductory and lasted a week, the next two sprints, first
development and then stabilization, were two weeks each). However, it is a FIRST RELEASE, which means the app is by all means not complete, but since we make software in a very agile way, it’a all about “Ship, ship, ship!”.

What is Nodeta, exactly? My Finnish is a bit rusty nowadays…

Nodeta is a software development company that focuses on web software. We employ a highly agile and effective process. We have worked both on light independent projects and in the environment of large global enterprises.
There are currently 10 Nodetans.

Rails-Doc.org is a pilot project for your new shiny app, ApiDock. Is it an open source app?

Unfortunately, I cannot go into details about APIdoc yet. What I can tell is that it is developed with Rails and that it won’t be open source, but rather it would optimally be offered as a service, which after all is what
the word “app” on the web means these days. Open source projects could however use it for free, sort of in the spirit of GitHub.

It will also most likely be separately targeted to larger companies.

Can you give me more technical details about the way keyword search is performed? Are you indexing/tagging documentation beforehand?

There will probably be a blog post on the Nodeta blog about the search and how it works after the first release comes out.

What about the social side of it: you’re hoping people will contribute with notes, which will then be collected and integrated in the documentation correct? Do you have any moderation or anti-spam precaution?

The quality of notes is judged in a social way. Notes can be thanked by other users and notes that get many thanks are showed in a more prominent way. Registration will be required in order to post notes and the registration will feature a captcha.

Will contributors be credited somehow? Who can contribute and at what level?

Anybody can post notes and good notes get thanks and thus so do their posters. Users that get lots of thanks will be later asked to become core users that can alter the extended documentation (not in the first
release.)

You want to blow out competition and that you don’t want to fail: sounds a good plan! How is Rails-Docs different from other similar apps?

We think that our app is the first that is serious about making things happen. We think about users first and above all at this stage our search feature is frankly unparallelled.

Do you have DHH’s seal of approval? Will you? Is there any copyright issue with your domain name?

Time will tell what DHH thinks. We did contact him just a few days ago to ask what his thoughts about all this are and are waiting for his comments. I doubt there is any wrinkles with copyright as Rails-doc itself is a completely non-profit project.

What about doing something similar for the whole Ruby language? Ruby docs may also be easier, in a way…

It is possible that we might do just that but right now it’s all about Rails.

The Bottom Line

Rails-Doc.org is definitely an interesting project, which has all the potential to become a powerful, Rails-powered service. Sure, it’s not open source and this can be a bit of a letdown for some: but after all people flocked to GitHub when it opened, didn’t they?

The search capabilities of Rails-Doc.org are definitely a very important step forward in making Rails documentation more accessible and easier to use, but the killer feature is definitely the possibility to add notes, if used wisely.

I’ll be watching this project closely and I’ll pay particular attention on what happens to the community’s contributions: will it really be useful? Will it really help creating documentation patches to Rails core? Only time will tell, of course.

Beware of sudden upgrades!

h3rald@h3rald.com — Wed, 19 Dec 2007 23:41:00 -0700

Yesterday I got a rather annoying early Christmas present: when visiting my site, I noticed that the raw source code of my dispatch.fcgi file (yes, I’m on shared hosting with FastCGI, for now) was displayed “as it is” instead of being interpreted.

After the initial moment of anger and stress (I immediately realized it was BlueHost’s fault, not mine), I opened two tickets and went to bed, hoping to see everything solved in the morning.

Unluckily it wasn’t the case, so I posted on BlueHost forum trying to be as polite as possible complaining because the issue wasn’t being dealt with. It turns out that for such issues you’re supposed to use the “Live Chat” feature instead of the tickets, so that’s what I did.

After a quick chat with “Christian”, it turns out that BlueHost decided to perform a server upgrade “silently” upgrading to Apache2, PHP5, MySQL4.1, etc. etc.
Cool, pity that nobody told me that!

I was expecting some sort of PHP upgrade (not that I care like that), which was supposed to happen according to the last BlueHost newsletter:

“To alleviate any issues in the future with certain scripts that only run on one
version of PHP we have developed the ability to run PHP4 and PHP5 on the same server
simultaneously. This will be rolled out to all users in the next couple of weeks. Some
servers already have this ability while most will see it in the next two weeks.”

But… hang on? Does it say anything about migrating to Apache2? I don’t think so! What’s worse, is that quite a few things changed with Apache2, in particular the way FastCGI handlers are declared:

1# Apache 1.3:
2AddHandler fastcgi-script .fcgi
3
4# Apache 2:
5AddHandler fcgid-script .fcgi

See? Different. This is due to the fact that mod_fcgid is used instead of mod_fastcgi on Apache 2.

The fix was easy, of course, and now my site is up and running again (and actually running faster)… but, I wonder, why the hell wasn’t I informed? Is it acceptable? It sounds like I might end up on a VPS sooner than expected, unless BlueHost doesn’t roll out some new exciting feature soon, as I think it might…

Book Review: Mongrel Digital Shortcut

h3rald@h3rald.com — Fri, 14 Dec 2007 19:42:00 -0700

If you ever considered about developing an deploying a Rails application in the last year or so, you must have heard of Mongrel before. If you didn’t, I’d recommend you learn more about it because up to now it proved to be one of the few essential ingredients for deploying scalable Rails applications.

Mongrel is a creation of Zed Shaw who started writing a replacement for FastCGI to use with Rails, and ended up creating a brand new, HTTP web server who turned out to be one of the best things the Rails community ever saw happening.

It was created to be simple to use and configure, nevertheless it does require some skill to set it up and tune it. Documentation is there, along with plenty of blog posts, but there’s also an interesting book from Addison Wesley Professional which is definetely worth a read.

“Mongrel: Serving, Deploying, and Extending Your Ruby Applications” – that’s the title of the book. A Digital Shortcut, 100-odd pages long, in landscape format to make it easier to read on a computer, straight to the point with no added sugar for just 15$ (PDF only). I must say Addison Wesley got it right: the book’s format is, as a matter of fact, optimized for web developers, especially those who can’t afford to read a 500-pages book covering everything about a subject just to find that one thing they don’t know about.
This shortcut can be seen, essentially, as an expanded cheatsheet which will teach you the basics about Mongrel and also give you plenty of advice on how to learn more about it.

Let’s have a closer look at it.

Overview, Introduction & Getting Started

The first three ~~chapters~~ sections (there are no chapters, just sections) of the book are meant to be a gentle introduction to Mongrel and its world. The main author is Matt Pelletier, but Zed Show’s contributions are definitely one of the book’s best selling points.
Zed’s thoughts are scattered here and there in many sidebars throughout the book (there’s at least one in each section): you’ll see an odd-looking face (Zed’s self-caricature) with some text next to it; when you read it, you’ll notice that they are actually Zed’s own thoughts, straight from his mind, with no editorial filter whatsoever in-between.
Be warned: the text included within the Zed Sez sidebars is highly opinionated, that’s precisely what Zed feels to say about something, and he’ll just say it: just the plain, simple thoughts of an experienced programmer. As the author explains in Section 1: “[…] You may not agree with everything he says, but you probably should.”

Section 2 is a general introduction about Mongrel. It explains what it is, when and why it was made, and how it works. There’s nothing new to learn if you already used Mongrel before, probably, but it’s definitely the first thing to show to someone who’s new to Mongrel and its world, and possibly a bit skeptical about it.
The last subsection “What can Mongrel do for me” is an attempt to ~~brainwash~~ persuade you to fully embrace Mongrel and its philosophy, whether you are a developer, a sysadmin or even a manager: assertions like “Mongrel is pretty damned secure.” and “Mongrel’s license is capitalist-friendly.” will definitaly make some of you (managers) happy.

Section 3 is slightly more juicy than the previous one, as it explains how to install and use Mongrel. Basically that’s what everyone who ever used it already knows, but it’s still necessary for the book’s consistency, after all. After reading this section, you’ll probably have your first Mongrel up and running and serving your little Rails application’s pages, and you’ll begin to wonder why the hell you need to keep reading this book now that everything seems to work already…

Section 4: Configurations

…aka “a truly useful Mongrel cheatsheet”. This section dives deep(er) into Mongrel’s configuration by explaining what each start parameter does in detail. The parameters are presented in tabular form in a very well-organized way. As you would expect from an high-quality cheatsheet.

Then the author will explore a few commonly used deployment scenarios, in particular:

Standalone – The simplest configuration possible, with just one Mongrel instance serving both static and dynamic pages.
mongrel_cluster – How to use “a pack of mongrels” together to handle more traffic.
Behind a static web server – The most common (and most scalable) option, used to serve static content faster using a front-end server and use Mongrel only to handle Ruby pages.

Towards the end of the section, for the developer’s delight, the author will discuss two common, useful scenarios where Mongrel can be used:

Apache 2 + mod_proxy_balancer + mongrel_cluster
Nginx + mongrel_cluster

The difference here is that detailed instructions are provided on how to setup and configure each server, including example file sources. This can be particularly useful for the Nginx example, as most of the documentation for this fantastic, lightweight Mongrel fron-end is scattered around the web (or written in Russian in a well known place).

Section 5: Production Deployment

This section introduces one of the most important part of the life cycle of a Rails application: the deployment on a production server. The author is pretty honest about the whole subject:

“You will not do this in a day. If you are expecting to code until 1 minute before your deadline and then simply point and click and have an instant server then you need to take some kind of
medication because you are violently hallucinating. You will need at least a week of 8 hours days to make sure your first deployment works and to have the time to do it right.”

Sounds terribly true. Especially for larger projects demanding good performance under heavy traffic. Scared? Probably, if you never deployed a Rails application “properly” before, but at least the book comes to the rescue by providing an overview of what you need to perform a deployment and why it is such a complex and delicate process.

Not only this, but also a “Best Practices Rubric” is also provided for the developer’s own private enjoyement. It’s written as a list of questions like:

11. Do you have a shared location where you can document the deployment, such as a Wiki or CMS?
12. Do you know how to use httperf or ab and know what the statistics mean?

After these 13 questions, the author provides the key to give a meaning to your answers:

"For each question you answer with “NO”, add 10 hours to your time estimate for completion. This may seem unrealistic, since saying “NO” to everything means it’ll take 190 hours (about one
month), but this estimate is actually low according to most first deployment experiences."

If you answered “NO” too many times to these questions, you may want to read on through the next subsection which states 17 “worst practices”: an invaluable read for beginners!

But after all this section is not only about stating the obvious (…right?): a full example scenario is describedand examined throughly to give you an idea of how a deployment should be made, using three different machines:

One for Apache (as a front-end to Mongrel)
One for the Mongrel cluster and the Rails application
One for the database

Maybe something you’ll never do if you just want to run your grandma’s site on Rails, but certainly something you may want to start looking at if your grandma becomes really popular and your small server gets grounded by several thousands of visitors per day.

The last part of the section will give you a brief introduction on monitoring your applications and on which tools you should be using, although it does not discuss the subject in detail at all, it’s just meant to point you to the right direction.

Section 6: Extending Mongrel

This section digs deeper into the software code internals and describes how to teach new tricks to your Mongrel, i.e. how to extend its functionality.

Before you begin, though, don’t forget what Zed himself has to say about Mongrel’s simplicity:

“I’ve always had a different aesthetic sense when I write my software. I value simplicity and directness and try to write software that follows this approach. I jokingly call it the Shibumi School of Software Structure. All I do is apply this rule: When given two possible designs with equal end results, pick the simpler one. I then ruthlessly strip the solution down to its finest elements, but no more.”

Mongrel’s architecture is not that complex, and this section is sufficient to get you started by providing an overview of the main classes involved (HttpServer, HttpRequest, HttpResponse, HttpHandler, URIClassifier), and how they work together.
Note that the book won’t describe anything about the APIs of these classes. but after all, the project’s RDoc documentation should cover all the details you need.

The rest of the section focuses on how to extend Mongrel, by:

Writing custom handlers in Ruby
Creating custom filters to perform security checks, clean up requests and preliminary file processing
Creating plugins and distributing them as rubygems

Two working examples are also provided:

An example handler to deflate content (if the browser supports deflate)
An example “duck” plugin, to make Mongrel quack like a duck when it’s started (not the most useful thing in the world, but serves the purpose)

Debugging, Performance & Security

The last three sections deals with other important aspects concerning the deployment of your application, how to debug, how to improve performance and how to secure your application.

Section 7 introduces two debugging modes:

Dash-Bee logging (-B)
USR1 logging (lighter)

And also gives you an idea on what to look for when debugging an application. Nothing too detailed, granted, but enough to make sure you are pointed in the right direction.

Again, Zed’s wisdom and wit are remarkable:

“These people’s problem is they suffer from Potpourri Turd Syndrome—a belief that their you-know-what don’t stink and smells like fine dew on freshly cut grass. Whenever there’s a bug, they go
running like kids in a candy store to other people’s code trying to find fault and just assume that it’s nothing they wrote.
[…]
When you run into a problem with your application, always assume it’s your fault first. Mongrel’s not perfect, but its code is minuscule compared to the size of Rails and most likely even your own appli-cation code. Mongrel also powers many large and medium deployments without any problems. If there’s an error, the evidence already says it’s in your code, so bite the bullet and start investigating it as if it’s your problem.”

Similarly, Section 8 is a short but useful overview on performance tips and tricks and deployment tuning. The most useful thing is probably the checklist of the “tuning process”, which illustrates the simple steps to take to tune your application.

Finally, Section 9 addresses some common security concerns and clarifies how Mongrel deals with them. The answer is normally “Mongrel strictly does this” or “Mongrel doesn’t support this feature”. After all, you should have understood by now that Mongrel is an example of simplicity and that it deliberately does not aim to offer all the feature you’d expect by a server like Apache:

"As you probably see, Mongrel say, “No” in many places where most Web servers say, “Yes, OK.” Sometimes this is because no one using Mongrel has needed it yet, sometimes it’s because there’s a
better, simpler way to accomplish the same goal. Mongrel is a different kind of Web server, and frequently you can solve your problem with a different solution."

Conclusion

If Mongrel is opinionated software, this is definitely an opinionated book which fully embraces the project’s philosopy of simplicity above everything else. It’s an interesting read and it won’t bore you to death by deliberately skipping long and potentially tedious subjects and adding interesting insights instead (like the Zed Sez sidebars). Perhaps it is a bit too direct towards certain people, who may get even get offended (as planned) by some of the author’s assertions.

Despite being a 100-pages book, this shortcut covers pretty much everything you need to know about Mongrel. It will not teach you everything about deployment, security, performance tweaks and debugging though: as the authors often state throughout the book, a lot of (big) books are available on those subject, and it wouldn’t make sense to even attempt to discuss them in this shortcut.

Similarly, you won’t find complex examples either, but that’s acceptable because simple examples are often the only thing you need to grasp the basics of a concept or feature, and then use them as a “scaffold” for your own code.

Globally, the book is well balanced and optimized for its size: lightweight introductory sections at first, then the “real juice” in the middle, and a few overview sections on advanced topics towards the end. You can read it easily in a few hours, perhaps less, and whenever you need to look something up in a hurry it will be fairly easy to locate.

A good read, and a must for everyone who wants to learn more about Mongrel or Rails deployment.

Text Link Ads sidebar for Typo

h3rald@h3rald.com — Fri, 16 Nov 2007 20:47:00 -0700

I thought it would be nice to share the code of the sidebar I created to display Text Link Ads sponsor links on my Typo powered blog.

There’s actually another plugin which was made for Typo 2.6, but unfortunately it doesn’t work with Typo 4.1.1.

Installation

Just unzip it inside your vendor/plugins directory. The new sidebar should appear in the list of your available sidebars in the Typo’s administration area.

Configuration

In Typo’s administration area, configure the following settings for this sidebar:

Title: The title of the sidebar
KEY: Your TLA’s XML key
Affiliate ID: Your TLA’s affiliate ID
Advertise Here: A message shown when no links are displayed.

Download Text Links Ads Sidebar v0.2

To REST or not to REST?

h3rald@h3rald.com — Sun, 23 Sep 2007 21:48:00 -0600

Lately I’ve been reading quite a bit about Rails’ REST approach, and to be totally honest I’m not 100% convinced it can always be a good idea. The purpose of this post is to re-evaluate the situation, and ask other people their opinion on the matter.

Let’s see…

Key Benefits

To cut a long story short, from my understanding REST can be a good thing because:

It introduces the powerful concept of “resources”, which is independent from the presentation. This basically means that you can have your “resources” represented in HTML. XML etc. etc. “for free”. If you are making an extensive use of web services, this is truly a bless.
Each CRUD action is carried out using a different HTTP command (get, post, put and delete). At present, because most browsers don’t understand PUT or DELETE requested, this is somehow simulated by Rails.
By thinking and modeling your application in terms of resources, everything should always be “in the right place”.

Downsides?

Let’s now try to summarize what made me think more carefully this approach…

While I really like Rails’ convention over configuration philosophy, this sounds a tiny bit too extreme for me. In the end it could be good, but it requires developers to completely re-think the way they develop their application in order to be 100% RESTful.
URLs aren’t that pretty anymore. While someone suggested a way to improve the way RESTful URLs look, that sounds like extra hassle to me. It’s subjective, I know, but I really don’t like using IDs in the url… I’d rather go for an univocal code any day (check out this site… I don’t even like dates in my blog).
Sometimes, it may take quite a bit to figure out how to model some functionality using resources. While it is straightforward when you want to perform CRUD operations, modeling a search action or authentication may be a bit tricky and may also feel a bit forced. Again, maybe it’s just me.
It may be a bit too early to take full advantage of this approach. PUT and DELETE are simulated, and this doesn’t sound right — agreed, that’s the only way for now, but it still sounds like a forceful workaround. Browsers are not RESTful (yet)!
All resources are virtually accessible by a URL. I’m not a security expert, but this scares me a bit.

Here are some posts which made me think a bit:

Looking for a good argument against REST

RESTful Myths: Unraveling the Confusion

Why Can’t Web Apps Be REST-ful?

The bottom line is: is REST really worth the hassle? Especially for small and simple applications like a blog, is it really worthwhile to coerce myself to adopt a RESTful approach when I could accomplish exactly the same things with much less hassle?

In other words, is REST really the answer to everything or in some cases it is just not necessary?

And also (OK, this may sound harsh and impolite): does it really make sense to push people to adopt a RESTful approach no matter what? Sometimes someone may get the feeling that Rails is all about REST now. Is that true, or is there still room for ~~freedom~~ other views?

Looking forward to hear your comments, but please be nice and civilized!

Simply On Rails - Part 4: Quick and Easy Default Data Migrations

h3rald@h3rald.com — Sat, 15 Sep 2007 05:10:00 -0600

In the last post of this series I tried to find a DRY solution to deal with tables storing “ancillary” data, i.e. names of user roles, predefined categories, page state names and other similar things.
I personally chose to put this kind of data to make my application more dynamic, although I could have decided to use ENUMs or simply ordinary varchar fields — that would have been easier, but less flexible. For now, I’m sticking with my original choice.

The data in these tables is kind of a prerequisite for the application to run: I must be able to have a status to assign to a user when creating it, and the same applies to roles. Sure, I could spend 20 minutes populating these tables manually, but it would be nice if there was a less tedious way, wouldn’t it?

There is indeed. The inspiration came from a technique described in the book (which I highly recommend) Agile Web Development With Rails, in which the author outlines how it would be possible to use Rails’ fixtures and migrations to load data in the database automatically from YAML files.
All you have to do is create a migration to load the specified YAML files and you’re all set.

I wanted to take a little step further, allowing the migration to load data from all YAML files in a specific directory, automatically.Let’s start creating the YAML files then and place them all in one directory of the application like /db/migrate/defaults. Here’s the one I used for user roles, for example:

 1visitor:
 2  id: 1
 3  name: Visitor
 4  level: 0
 5
 6user:
 7  id: 2
 8  name: User
 9  level: 10
10
11contributor:
12  id: 3
13  name: Contributor
14  level: 20
15
16provider:
17  id: 4
18  name: Provider
19  level: 50
20
21operator:
22  id: 5
23  name: Operator
24  level: 100
25
26administrator:
27  id: 6
28  name: Administrator
29  level: 500
30
31webmaster:
32  id: 7
33  name: Webmaster
34  level: 1000

The important thing to remember is to provide a unique string to identify each record, before specifying each fiels. The other files look similar, so I won’t bother listing them here.

And here’s the simple code for the migration:

 1require 'active_record/fixtures'
 2
 3class LoadDefaults < ActiveRecord::Migration
 4
 5  def self.up
 6    down
 7    models = self.default_models
 8    models.each do |m|   
 9      Fixtures.create_fixtures(self.default_directory, m)
10    end
11  end
12
13  def self.down
14    models = self.default_models
15    models.each do |m|
16      eval("#{m.singularize.capitalize}.delete_all")
17    end
18  end
19
20  def self.default_directory
21    File.join(File.dirname(__FILE__), "defaults" )
22  end
23
24  def self.default_models
25    files, names = Dir.glob("#{self.default_directory}/*.yml"), []
26    unless files.blank?
27      files.each { |f| names << File.basename(f, '.yml') }
28      names
29    else
30      []
31    end
32  end
33
34end

Basically the migration will look in a directory named “defaults” for some YAML files named after a particular database table, and it will attempt to load all the records defined in each one of them.
The down method of the migration deletes all the data in the specified tables, so use with care…

Simply on Rails - Part 3: LiteController

h3rald@h3rald.com — Sat, 21 Jul 2007 22:03:00 -0600

Enough with concepts, ideas and diagrams: it’s time to start coding something. Everyone knows what’s the first step when creating a Rails applications, but anyhow, here it is:

1rails italysimply

Then I create a new development database, load it up with the schema I previously prepared and modify the config/database.yml to be able to connect to it. Nothing new here.
I actually had to modify the schema a little bit:

I changed all the names for the foreign keys to something more evocative than “has_many” or “has_one”
I added a level column to the states, availabilities and conditions table
I removed the description column from the categories table

Great, but… hang on: now some of the database tables look awfully similar with each other:

statuses
states
roles
types
tags
conditions
availabilities
categories

They all have a name column, some of them have a name column as well, they’ll hold only a relative small number of records which will hardly ever be deleted. In fact, I was tempted to use Enums for some of those things…
Anyhow, I’ll still have to add and modify data in those tables, so it looks like I kinda need to create 8 controllers, 8 models and about four views for each one of them. No way. Fair enough for the controllers and models, but I’m not going to create 32 views which all look exactly the same. Rails should be smarter than that!And it is, luckily. Derek Sivers & C. came out with an interesting Shared Controller concept, which could be just what I’m looking for in this case. Actually I need something really simple in this case:

Put all the CRUD logic into one controller
Create only one set of views

Here’s the controller:

app/controllers/admin/lite_controller.rb

 1class Admin::LiteController < ApplicationController
 2
 3  layout 'admin'
 4
 5  before_filter :prepare
 6  
 7  def prepare
 8    @item_name = model.to_s
 9  end
10  
11  def index
12    list
13  end
14
15  verify :method => :post, :only => [ :destroy, :create, :update ],
16         :redirect_to => { :action => :list }
17
18  def list
19    ordering = model.column_names.include?('level') ? 'level ASC' : 'name ASC'
20    @items = model.find(:all, :order => ordering)  
21    render('lite/list')
22  end
23
24  def show
25    @item = model.find(params[:id])
26    render('lite/show')
27  end
28
29  def new
30    @item = model.new
31    render('lite/new')
32  end
33
34  def create
35    @item = model.new(params[:"#{@item_name.downcase}"])
36    if @item.save
37      flash[:notice] = @item_name+' was successfully created.'
38      redirect_to :action => 'list'
39    else
40      render('lite/new')
41    end
42  end
43
44  def edit
45    @item = model.find(params[:id])
46    render('lite/edit')
47  end
48
49  def update
50     @item = model.find(params[:id])
51    if @item.update_attributes(params[:"#{@item_name.downcase}"])
52      flash[:notice] = @item_name+' was successfully updated.'
53      redirect_to :action => 'list'
54    else
55      render('lite/edit')
56    end
57  end
58end

 1class Admin::LiteController < ApplicationController

 2

 3  layout ‘admin’

 4

 5  before_filter :prepare

 6  

 7  def prepare

 8    item_name</span> = model.to_s
<span class="line-numbers"> <a href="#n9" name="n9">9</a></span>  <span class="keyword">end</span>
<span class="line-numbers"><strong><a href="#n10" name="n10">10</a></strong></span>  
<span class="line-numbers"><a href="#n11" name="n11">11</a></span>  <span class="keyword">def</span> <span class="function">index</span>
<span class="line-numbers"><a href="#n12" name="n12">12</a></span>    list
<span class="line-numbers"><a href="#n13" name="n13">13</a></span>  <span class="keyword">end</span>
<span class="line-numbers"><a href="#n14" name="n14">14</a></span>
<span class="line-numbers"><a href="#n15" name="n15">15</a></span>  verify <span class="symbol">:method</span> =&gt; <span class="symbol">:post</span>, <span class="symbol">:only</span> =&gt; [ <span class="symbol">:destroy</span>, <span class="symbol">:create</span>, <span class="symbol">:update</span> ],
<span class="line-numbers"><a href="#n16" name="n16">16</a></span>         <span class="symbol">:redirect_to</span> =&gt; { <span class="symbol">:action</span> =&gt; <span class="symbol">:list</span> }
<span class="line-numbers"><a href="#n17" name="n17">17</a></span>
<span class="line-numbers"><a href="#n18" name="n18">18</a></span>  <span class="keyword">def</span> <span class="function">list</span>
<span class="line-numbers"><a href="#n19" name="n19">19</a></span>    ordering = model.column_names.include?(<span class="string"><span class="delimiter">'</span><span class="content">level</span><span class="delimiter">'</span></span>) ? <span class="string"><span class="delimiter">'</span><span class="content">level ASC</span><span class="delimiter">'</span></span> : <span class="string"><span class="delimiter">'</span><span class="content">name ASC</span><span class="delimiter">'</span></span>
<span class="line-numbers"><strong><a href="#n20" name="n20">20</a></strong></span>    <span class="instance-variable">items = model.find(:all, :order => ordering)  

21    render(‘lite/list’)

22  end

23

24  def show

25    item</span> = model.find(params[<span class="symbol">:id</span>])
<span class="line-numbers"><a href="#n26" name="n26">26</a></span>    render(<span class="string"><span class="delimiter">'</span><span class="content">lite/show</span><span class="delimiter">'</span></span>)
<span class="line-numbers"><a href="#n27" name="n27">27</a></span>  <span class="keyword">end</span>
<span class="line-numbers"><a href="#n28" name="n28">28</a></span>
<span class="line-numbers"><a href="#n29" name="n29">29</a></span>  <span class="keyword">def</span> <span class="function">new</span>
<span class="line-numbers"><strong><a href="#n30" name="n30">30</a></strong></span>    <span class="instance-variable">item = model.new

31    render(‘lite/new’)

32  end

33

34  def create

35    item</span> = model.new(params[<span class="symbol"><span class="symbol">:</span><span class="delimiter">&quot;</span><span class="inline"><span class="inline-delimiter">#{</span><span class="instance-variable">item_name.downcase}"])

36    if item</span>.save
<span class="line-numbers"><a href="#n37" name="n37">37</a></span>      flash[<span class="symbol">:notice</span>] = <span class="instance-variable">item_name‘ was successfully created.’

38      redirect_to :action => ‘list’

39    else

40      render(‘lite/new’)

41    end

42  end

43

44  def edit

45    item</span> = model.find(params[<span class="symbol">:id</span>])
<span class="line-numbers"><a href="#n46" name="n46">46</a></span>    render(<span class="string"><span class="delimiter">'</span><span class="content">lite/edit</span><span class="delimiter">'</span></span>)
<span class="line-numbers"><a href="#n47" name="n47">47</a></span>  <span class="keyword">end</span>
<span class="line-numbers"><a href="#n48" name="n48">48</a></span>
<span class="line-numbers"><a href="#n49" name="n49">49</a></span>  <span class="keyword">def</span> <span class="function">update</span>
<span class="line-numbers"><strong><a href="#n50" name="n50">50</a></strong></span>     <span class="instance-variable">item = model.find(params[:id])

51    if item</span>.update_attributes(params[<span class="symbol"><span class="symbol">:</span><span class="delimiter">&quot;</span><span class="inline"><span class="inline-delimiter">#{</span><span class="instance-variable">item_name.downcase}"])

52      flash[:notice] = @item_name‘ was successfully updated.’

53      redirect_to :action => ‘list’

54    else

55      render(‘lite/edit’)

56    end

57  end

58end

Then all I need to do is create eight controllers with just a few lines of code in each:

app/controllers/admin/statuses_controller.rb

1class Admin::StatusesController < Admin::LiteController
2  def model
3    Status
4  end
5end

1class Admin::StatusesController < Admin::LiteController

2  def model

3    Status

4  end

5end

Basically, I just need to specify which model the specific controller takes care of, Ruby’s inheritance does the rest. The model name will be passed to the views like this:

app/controllers/admin/lite_controller.rb

1def prepare
2  @item_name = model.to_s
3end

1def prepare

2  @item_name = model.to_s

3end

And each method uses the model method to access the model, like this:

app/controllers/admin/lite_controller.rb

 1def create
 2  @item = model.new(params[:"#{@item_name.downcase}"])
 3  if @item.save
 4    flash[:notice] = @item_name+' was successfully created.'
 5    redirect_to :action => 'list'
 6  else
 7    render('lite/new')
 8  end
 9end

 1def create

 2  item</span> = model.new(params[<span class="symbol"><span class="symbol">:</span><span class="delimiter">&quot;</span><span class="inline"><span class="inline-delimiter">#{</span><span class="instance-variable">item_name.downcase}"])

 3  if item</span>.save
<span class="line-numbers"> <a href="#n4" name="n4">4</a></span>    flash[<span class="symbol">:notice</span>] = <span class="instance-variable">item_name+‘ was successfully created.’

 5    redirect_to :action => ‘list’

 6  else

 7    render(‘lite/new’)

 8  end

 9end

Note how the params are collected:

1@item = model.new(params[:"#{@item_name.downcase}"])

params[:"#{item_name.downcase}"]@ at runtime becomes params[:status] or params[:role] etc. etc., depending on which controller is called. Sweet.

The views? Modified accordingly:

app/views/lite/edit.rb

 1<h1>Editing <%= @item_name %></h1>
 2
 3<% form_tag :action => 'update', :id => @item do %>
 4  <%= render :partial => 'lite/form' %>
 5  <%= submit_tag 'Edit' %>
 6<% end %>
 7
 8<%= link_to 'Show', :action => 'show', :id => @item %> |
 9<%= link_to 'Back', :action => 'list' %>

 1<h1>Editing <%= item_name %&gt;&lt;/h1&gt;</span></span>
<span class="line-numbers"> <a href="#n2" name="n2">2</a></span><span class="string"><span class="content"></span></span>
<span class="line-numbers"> <a href="#n3" name="n3">3</a></span><span class="string"><span class="content">&lt;% form_tag :action </span><span class="delimiter">=</span></span>&gt; <span class="string"><span class="delimiter">'</span><span class="content">update</span><span class="delimiter">'</span></span>, <span class="symbol">:id</span> =&gt; <span class="instance-variable">item do %>

 4  <%= render :partial => ‘lite/form’ >

 5  <= submit_tag ‘Edit’ >

 6< end >

 7

 8<= link_to ‘Show’, :action => ‘show’, :id => @item > |

 9<= link_to ‘Back’, :action => ‘list’ %>

app/views/lite/_form.rb

 1<%= error_messages_for 'item' %>
 2<!--[form:lite]-->
 3<p><label for="<%= @item_name.downcase %>_name">Name: </label>
 4<%= text_field @item_name.downcase, 'name',  {:value => @item.name} %></p>
 5<% if @item.methods.include?('level') then %> 
 6  <p><label for="<%= @item_name.downcase %>_level">Level: </label>
 7  <%= text_field @item_name.downcase, 'level',  {:value => @item.level} %></p>
 8<% end %>
 9<!--[eoform:lite]-->

 1<%= error_messages_for ‘item’ >

 2<!—[form:lite]—>

 3<p><label for="<= item_name.downcase %&gt;_name</span><span class="delimiter">&quot;</span></span>&gt;<span class="constant">Name</span>: &lt;<span class="regexp"><span class="delimiter">/</span><span class="content">label&gt;</span></span>
<span class="line-numbers"> <a href="#n4" name="n4">4</a></span><span class="regexp"><span class="content">&lt;%= text_field @item_name.downcase, 'name',  {:value =&gt; @item.name} %&gt;&lt;</span><span class="delimiter">/</span></span>p&gt;
<span class="line-numbers"> <a href="#n5" name="n5">5</a></span>&lt;<span class="string"><span class="delimiter">% </span><span class="content">if</span><span class="delimiter"> </span></span><span class="instance-variable">item.methods.include?(‘level’) then %> 

 6  <p><label for="<%= @item_name.downcase >_level">Level: </label>

 7  <= text_field @item_name.downcase, ‘level’,  {:value => @item.level} ></p>

 8< end %>

 9<!—[eoform:lite]—>

An Interview with the creator of the Akelos Framework

h3rald@h3rald.com — Wed, 18 Jul 2007 21:02:00 -0600

I already covered the Akelos PHP framework in the past, but for those who don’t know it, Akelos seems to be one of the few Rails-inspired PHP frameworks still worth mentioning, besides CakePHP and Symphony of course.

I recently has a look at their recently-relaunched community website and I noticed this phrase:

“Being port of Ruby on Rails to PHP Akelos is also optimized for programmer happiness and sustainable productivity”

Bermi Ferrer, Akelos creator, openly admits the framework is a port of Ruby on Rails to PHP, an attempt to help “Ruby on Rails developers who need to code in PHP”, among others. Of course Akelos is not Rails, simply because Ruby is (thank God for that!) not PHP, however I decided to find out more, and I asked Bermi a few questions, which he promptly answered.

There are a lot of frameworks for PHP, perhaps too many: why did you decide to create Akelos rather than using one of the existing ones?

I started coding Akelos back in 2004 for our internal developments. At that time I only found very few frameworks out there like Mojavi and eZ Publish. These frameworks were not my ideal of an Agile development environment, so I decided to brew my own solution.

After reading Patterns of Enterprise Application Architecture it was clear to me the kind of framework I wanted Akelos to become, so I started to implement some of the design patterns from the book into Akelos.

During the summer of 2005 I had a look into other PHP frameworks like CakePHP, PHP on Trax, and Biscuit but none of them was more complete or easier to use than what Akelos was already at that time.

Then I used Rails for one small personal project and immediately found that Akelos interfaces, conventions and philosophy were close to the Rails approach. Rails ActiveRecord implementation was impressive, better than mine and much much better than other existing PHP implementations, so I first ported the ActiveRecord code using PHP AdoDB as the database abstraction layer.

After that point, whenever I had a problem to solve while coding my customers applications I turned to Rails and they usually had the most elegant solution available. So I did like the idea of digging into Rails code to learn more Ruby and bringing Rails magic to the PHP world. It also helped the fact that Rails inline documentation is excellent so it could be easily adapted for Akelos.

What’s new since last time I posted about Akelos?

The biggest change is the direction that the project has taken. Until now we have not dedicated time to promote Akelos, we just used it for our internal projects and we have been adding features as needed without a fixed roadmap or advocacy.

Now this has changed. More and more developers are using Akelos and contributing functionalities they miss from Rails. After some serious contribution proposals and many developers telling us how much they like Akelos, we decided to take the time to build a nice community site which includes forums, a wiki, a new tutorial and a screen-cast.

There are also some improvements like:

Sintags, now accepts ruby-like calls to helper methods from the views.
Action Webservice, a component for creating and consuming Web Services easily.
Action Mailer, which allows you to receive and send (directly or in delayed mode) emails from within your application. (this is almost ready to ship)
Acts as tree behavior for Models.
Many performance improvements.
Many small contributions and bug fixes.
Code base reduced from 16MB to 9MB.

From the new site, it seems that Akelos is – or aims to be – a port of Rails for PHP. Is that true? Do you aim to target Rails developers as possible users of the framework in situations in which “they have no choice” but to use PHP instead of Ruby?

Akelos has ported many Ruby on Rails components keeping their interfaces and functionality whenever it was feasible to port the Ruby code to PHP. It might be considered a port in the sense of functionality, but there are some Rails strengths that rely on the Ruby language and that are impossible to port to PHP. However, Ruby developers will find that Akelos is the PHP framework with is the closest to Rails.

On the other hand, many PHP developers have moved to Ruby because PHP lacked a hyper-productive and fun-to-use framework like Rails for building complex applications. That is no longer the case, and those who excel at PHP can start being productive from day one by using Akelos. In this way, Akelos target users are those who already know PHP and need to build complex applications that can run on almost any cheap shared hosting using a solid foundation based on good coding practices and widely accepted conventions.

What Rails features are missing in Akelos?

A standalone webserver like WebBrick, RJS, has and belongs to many through associations, string/number/date extensions and Active Resource.

Ruby-powered features like modules, runtime class overriding and blocks will never be available in Akelos.

Scaffolds in Akelos work by generating code, I found quite useless to enable $scaffold = true; and have magic functionality that you can’t modify, so I decided not to invest my time on that one.

I noticed quite a few generators available for Akelos, do they work as a Rails developer may expect them to work?

The ones that are available do pretty much the same as in RoR.

How does Akelos compare to other similar PHP frameworks like, say, CakePHP? What features does Akelos offer which Cake doesn’t offer and vice-versa?

I’m not aware of Cake’s functionalities. At the time I started porting Rails my feelings about CakePHP were that they missed the simplicity point in favor of architectural discussions that lead to confusing code, but that was long ago.

Akelos (and Rails) do not implement ACL like Cake does, as that is a business logic component that varies too much from one case to other, it has no place inside the framework.

Akelos is built with internationalization in its core. You can even internationalize your Models by prefixing the column name with the locale.

I think that Cake only has an act_as_tree behavior on models while Akelos has Tree, Nested Set, and List. Akelos also implements handy features from Rails like optimistic locking, lazy loading, table inheritance, counters, automatic transactions, really powerful validations, calculations…, and I think most of these advanced features are still missing on Cake, but maybe I’m wrong.

Did you include unit tests for all the framework classes?

The main components are fully unit tested, and no new code or patch gets into the trunk without unit tests.

Did you or someone do any performance test or benchmarks on Akelos already?

During the last month a lot of code was refactored to improve performance with the help of Xdebug, Kcachegrind and ab. We significantly improved the performance in one of our most complex intranet applications, a basecamp-like system.

Akelos also implements caching at many levels, so it’s very easy to increase performance as we did with a new CMS that can handle +200 requests per second using Apache in a cheap shared server environment.

Why should a PHP developer choose Akelos over another PHP framework?

Akelos MVC implementation and workflow are really easy to understand.

In Akelos all the methods and interfaces are thoroughly selected, so whenever you need to do something you just need to type what you think. Default options are selected with care so you don’t need to set any configuration unless you want to modify the default behavior.

Coding multilingual applications, building complex relationships within models, distributing databases changes within your development team, building Ajax interfaces, unit testing your code and many other common tasks for PHP developers are really simple to accomplish when using Akelos.

Akelos is designed to work on PHP4 and PHP5 and it comes with an easy web installer you can adapt for your application. It has functions for working with files and directories in common situations when the web server runs as a different user.

And one of the main reasons for choosing Akelos is that it makes coding fun and lets you focus on solving user problems rather than wasting your time in repetitive technical annoyances. When coding with other developers the convention over configuration philosophy helps everybody to understand exactly how everything works and where to find things.

Is there any website using Akelos already?

The Chemical Brothers new website which has been developed by 3rd Eye Vision (3ev) is using Akelos.

The Akelos.org site is running a CMS named Editam which we will release as Open Source in a near future.

Some small websites like Fundacio Caixa Carlet and many intranet/extranet sites that we’ve been coding during the last 2 years.

What are your future plans for Akelos? Anything new on the way?

A new manual, and a better API interface are the main priorities right now.

Continuing bringing Rails functionality as needed.

Releasing our sister project Editam CMS which will help developers who need to add functionality on the top of a CMS using a solid MVC framework like Akelos.

Simply on Rails - Part 2: Database Design

h3rald@h3rald.com — Sat, 14 Jul 2007 03:27:00 -0600

This week I attended a course for work on how to Implement Databases with Microsoft SQL Server 2005. An interesting course indeed, which made me realize how feature-rich Bill’s product is, compared to the Open Source alternatives like MySQL. It also made me realize how nice it is to implement database-related logic (read: Models) using a proper programming language rather than using triggers, stored procedures, functions and other goodies offered by Transact-SQL.

It’s all a matter of taste and of necessities: using MS SQL Server for one of my website is simply not going to happen anytime soon, and I’m more than happy to have a database which can be used just as a database and a programming language (Ruby, in this case) which can do wonders, rather than a procedural-only surrogate.

Anyhow, back to our weekly series. After creating a concept map, it’s time of get real and try to figure out a database architecture. The tool of choice this week is obviously the widely popular DbDesigner 4. It’s free, it’s easy to use, and the results are pretty enough. There:

It’s amazing how a relatively simple concept map can lead to such a complex database architecture, isn’t it?
Well, it’s normal. One of the reasons of this is that I totally forgot about geographical information about the houses which will be featured on the site, or better, I thought about it as a strings typed in by the administrators, whereas it would be much better having dropdown boxes.

Countries, regions, privinces, areas and cities will be added to the database only once, rather than having to type them in every time a house is added. Obvious, but this lead to five tables more and nine (!) relationships more.

The other reason of why the number of tables is higher than the number of entities in the domain model is that I decided not to use the ENUM type. Firstly because it’s not handled very well by Rails
and also because there’s a number of reasons why ENUMs should not be used.

The only problem now is that whenever I load a house, I’ll have to get data from a lot of tables at once (and this means a lot of joins underneath the model layer) or – worse – a lot of queries in case I decide to load related data “on the fly”. It looks like I’ll have to do a bit of piggy-backing here and there. Someone already thought about a way of doing this in a more “Model-friendly” way. Perhaps I’ll give it a shot.

Rails to Italy 2007

h3rald@h3rald.com — Sat, 07 Jul 2007 05:15:00 -0600

So it looks like there will be a “Rails conference in Italy”, after all. In Pisa as well, and that’s maybe even less than 2 hours drive from where I live (Genoa)!

Sounds cool!

Well, the entrance fee put me off a bit, I daresay (€89 if you book before August 1st, more otherwise), but it would be great to go there.
They are actually looking for speakers too, pity that at the moment I don’t have anything prepared, but who knows… There’s free entrance (and beer) for speakers, apparently, which it wouldn’t be bad, but unfortunately my girlfriend would have to pay though, of course.

We’ll see what happens, for now I’m just going to promote the thing on my site (see the banner on the side).

Simply on Rails - Part 1: Concepts and Bubbles

h3rald@h3rald.com — Fri, 06 Jul 2007 23:43:00 -0600

The first thing I do when I start developing a new application is write down some ideas.

Pen and paper normally do the job, but nowadays there are some valid online and offline applications which work as good if not (probably) better.

I’ve never been a fan of Mind Mapping. I’ve been to a seminar on problem solving and creativity and they were showing how mind mapping can unleash your creativity, but it didn’t really work for me. I found the concept-idea-concept-idea sequences a bit too restrictive for my liking.

So I decided to try something different: bubbles! Bubbl.us is an interesting online flash application which lets you create bubbles. You can create bubbles and relationships between them, change their color, their dimensions etc. And above all it’s absolutely fun to use. I created two bubble sheets, the first one to define how content will be organized in the next version of ItalySimply:

The diagram identifies three main types of content:

Houses – basically what the site is about: house listing with information and pictures about houses for sale or rent.
Links – Either swapped with partners or suggested by users.
Pages – Static content.

which will be organized in three different ways:

Tags
Categories
An internal search engine, allowing people to filter houses according to some criteria.

The other sheet focuses on relationships between content and users.

At the far sides we have users and administrators, and in the middle how they interact between themselves or with content, in particular:

Users will be able to access house feeds and be notified automatically of new additions
Users will be able to ask questions or comments to each house (they’ll be moderated, of course).
Users will be able to suggest links, or contact administrators using a “House Preferences” form or a more generic contact form.

Bubbles are fun, but while I was creating these two diagrams, I felt I absolutely needed to name the relationships between each entity or concept, so I spend some time trying to find a tool who would let me do so in an easy and fast way.

Yep, I needed to create a domain model to move a bit closer to create the database architecture of the site.
It turns out that this magic tool exists, and it’s free for non-commercial use: CmapTools.
It’s not web based, and it’s a 59MB Java desktop application which can be used to create Concept Maps.

Within minutes I was able to create a simple but pretty and functional enough domain model for my site:

Basically all the concepts I used are going to become models, and all the named relationships will become model associations in Rails.

Next step: database architecture.

Simply on Rails?

h3rald@h3rald.com — Fri, 29 Jun 2007 22:00:00 -0600

So finally my site is back up, I don’t have to worry about coding anymore: just writing about whatever I like, no more Cake, no more MVC, no more frameworks…

What do you mean no coding anymore? You’ve been bragging about how this Rails thing is fast, how you can develop things easily, and this, and that… You know what you have to do now

^{^} That was my fiancée, actually, and she’s right: my web development days are far from being over, actually. I admit I tried to get away from it, but she kindly reminded me (and she can be very persuasive) that now I have to fix ItalySimply, the site I created a while a go (4 years?) with a mixture of Mambo (the CMS, now Joomla) and spaghetti PHP.

A sort-of-real-estate thingie visited by people who want to move to Italy or simply buy a house here. And it’s due a makeover, to be honest.

How am I gonna manage this? Let’s see…

COW

COW \- Code On Week-ends. my web development methodology: simple, effective, basically my only choice. Actually the full name is COW (IYL): Code On Week-ends If You’re Lucky, i.e.: if we’re not going out, if there’s nothing better to do, if I feel like it. No deadlines (almost), no plans to follow, nothing.

No, I’m not terribly motivated to take on this project, but I already thought about two things to get me going:

Get Agile Web Development with Rails \- I read bits of the first edition, and that’s what got me started with Rails, now it’s time to buy the real thing.
Blog about it \- I’ll try to keep a diary of my coding efforts and share the most juicy bits with the rest of the world. In this way I’ll also have content for my site and the three people who read this blog will have something (hopefully) interested to read.

The Cunning Plan

Instead of getting out of troubles by simply tidying up some PHP code or migrate the site to Joomla, I’d like to re-code the whole thing from scratch using Rails. Ideally I’d like to migrate quite a bit of the content (including the hundreds of houses with pictures which were published over the years), but at the moment I’m not thinking about it: after all, in the end the site will be so addictive and easy to use that adding hundreds of houses back on will be just so much fun! Right? Yeah, right…

First of all I’ll spend quite a bit of time planning the application and what has to be done, then I’ll have to practice a little bit with Rails, and then, eventually, I’ll end up writing some code. Of course, suggestions and ideas will be more than welcome throughout all the process.

Let’s see how it goes…

Back on Track...

h3rald@h3rald.com — Fri, 22 Jun 2007 06:38:00 -0600

…or better, on Rails_.
Yep, this 7th (!) version of the H3RALD website is powered by the overly-popular Ruby web framework and by the Typo blogging platform.

Nope, I decided not to re-develop my website entirely from scratch this time, although I was tempted to, for three simple reasons:

My “coding time” is close to non-existent nowadays, and even with a framework like Rails re-developing a site from scratch would have taken at least some time, which at the moment I don’t have.
Typo is a fairly robust and feature-rich blogging platform, and after learning a little bit of Rails I could customize it to my needs straight away. URLs didn’t break thanks to Rails’ routing system, migration was easy enough, and developing the missing bits (like a rudimentary BBCode parser and a TextLinkAds sidebar) wasn’t hard at all.
I wanted to take a break from my site, not code it again.
Fair enough, but why the new site anyway?

Again, there’s more than one answer:

Lately I didn’t feel comfortable sporting a Cake-powered website \- that makes sense, to an extent, right? Good.
I got fed up with spam. I wanted to re-open comments but I didn’t want to implement spam protection for the old site.
To be totally honest, I got fed up with PHP itself as well, after trying out Ruby for a few days and ordering and reading the 2nd edition of the PickAxe, which I highly recommend.

…But let’s say something about what’s new in this new release, shall we?

A new, black (and red) theme. Something completely different. Probably not that good, but quite useful: Every day I check my site from my laptop at work, and if it looks like a big black blob I know that I have to regulate my monitor. I showed it to my parents on their old monitor, and they realized that perhaps it’s time to buy an LCD one…
Comments, trackbacks, desktop client support, theme support, a cool admin area and everything else Typo offers.
Full RSS feeds. With no ads. So you don’t need to see this black blob anymore, if you really don’t like it.
No projects or bookmarks, just my blog and my articles. Let’s keep it simple.

More to come…

Ruby on Rails & CakePHP

h3rald@h3rald.com — Fri, 07 Jul 2006 01:52:28 -0600

This article is an attempt to port a famous Ruby on Rails tutorial to PHP using an emerging PHP MVC framework, CakePHP. CakePHP was inspired by Rails’ philosophy of Rapid Application Development. It implements a lot of the features and concepts that made Ruby on Rails popular in a very short time. Although Ruby’s syntax and way of doing things is known to be much more elegant than other programming languages, there is yet hope for PHP to get more organized and effi cient. This tutorial will follow its Rails counterpart step-by-step, covering the essential steps to create a simple, yet fully functional, web application.
Register on the International PHP Magazine to read the full article.

Rails-inspired PHP frameworks

h3rald@h3rald.com — Wed, 03 May 2006 06:57:00 -0600

There are various articles online examining many PHP frameworks, providing short reviews or comparative charts, but I could not find yet an article examining the so called “Rails-inspired frameworks” anywhere on the web, so I decided to write my own…

IMPORTANT UPDATE: I do no longer recommend the CakePHP framework anymore due to the unprofessionalism of some member of its development team. My site is now powered by Ruby on Rails and I totally lost interest in PHP and any PHP framework. If you are looking for a decent web framework, try Ruby on Rails (for Ruby), Django (for Python) or Catalyst (for Perl).
I’m talking about those PHP frameworks who give at least part of their success to Ruby on Rails², but don’t call them clones or ports as some of their creators may get offended.

Since Rails shocked the world with an easy-to-use, powerful and semi-sentient web development framework, web development is not the same anymore: everything must be done efficiently, quickly and you have to produce a Web 2.0 compliant public beta after X days/weeks/months or your work is simply not useful to anybody. Try doing that with the traditional PHP spaghetti code: you can’t, it’s too much, it will be too tangled up and in the end you’ll lose your mind trying to find that small insignificant bug which makes your web application completely useless.

Yes, you could use Rails, but maybe you don’t know or don’t want to learn Ruby, your host doesn’t support it, your boss loves PHP etc. etc. If you’re in this situation or you simply would like to know what’s going on at the PHP front of the Rails Clone War, you should keep reading this article.

I’d like to introduce – briefly – six Rails-inspired PHP frameworks and compare them with each other, to point out their features, their pros and cons.

Disclaimer: I’m a CakePHP³ fan, this site has been built with CakePHP and I even wrote something⁴ about it in the past. This makes me inevitably partial and more familiar with this particular framework, but I’ll try my very best to provide a relatively objective analysis. Obviously frameworks which are not based on the MVC architechture and that weren’t inspired by Ruby on Rails have not been included, so forget things like PRADO, Qcodo, eZComponents, or even Mojavi: it’s not that they are “bad”, they’ve just been left out because they are not pertinent to this article

CakePHP

Website: www.cakephp.org
PHP version: PHP4 and PHP5
License: MIT⁵
Download size (.tar.gz): 184KB
Supported Databases: MySQL, PostgreSQL, SQlite, MS SQL + any other supported by ADOdb or PEAR::DB database abstraction layers
Beginner’s Tutorial: Blog Tutorial

Official Description:
“Cake is a rapid development framework for PHP which uses commonly known design patterns like ActiveRecord, Association Data Mapping, Front Controller and MVC. Our primary goal is to provide a structured framework that enables PHP users at all levels to rapidly develop robust web applications, without any loss to flexibility.”

PROs:

Lightweight, not bloated, containing only essential code
Runs both on PHP4 and PHP5
No configuration needed – except for a stupidly short database configuration file and a few constants which can be modified. You can literally start baking in less than five minutes
Extended table association support, allowing the creation of complex database architechtures
Extremely logical and functional directory structure: better than Rails, if you ask me.
Enhanced AJAX support through the AJAX and Javascript view helpers
useful “bake” command line script to generate parts of the code automatically
Very active community and plenty of satellite sites
Suitable for every kind of website, from the small personal site to the advanced e-business application.

CONs:

No “official” internationalization support for now, but it will be included in the next milestone.
It does not take fully advantage of PHP5 features
Official documentation still needs some some improvement, although now it seems pretty complete and exhaustive.

Comments:
CakePHP is my personal favorite: easy to learn, easy to use,multi-purpose and not bloated. Cake’s philosophy is not to include unnecessary code in the framework unless it’s absolutely necessary for the framework itself, as a result, 3rd-party libraries are not included in the official releases, but may be seamlessly integrated with the framework if developers need them.
Cake’s success is partly determined – at least initially – by the fact that it can run fine with no limitations on PHP4, while other similar frameworks don’t. Although this may still be one of its most obvious strengths, it must be said that Cake seems to go in the right direction, taking only the best from Rails, without forcing developers into complex and pointless adaptations, and evolving into a great framework created in PHP, for PHP.

Symfony

Website: www.synfony.project.com
PHP version: PHP5
License: Symfony⁶
Download size (.tgz): 1255KB
Supported Databases: MySQL, PostgreSQL, SQLite, Oracle, MS SQL + any other supported by Creole database abstraction layer
Beginner’s Tutorial: My first project

Official Description:
“Based on the best practices of web development, thoroughly tried on several active websites, symfony aims to speed up the creation and maintenance of web applications, and to replace the repetitive coding tasks by power, control and pleasure. […]
Symfony is an object-oriented PHP5 framework based on the MVC model. Symfony allows for the separation of business rules, server logic and presentation views of a web application. It also contains numerous tools and classes aimed at shortening the development time of a complex web application."

PROs:

Fully featured framework, includes everything you might ever need (see CONs, below)
Full native internationalization support
Truly excellent documentation, tutorials, wiki, book, screencasts, API, real-world examples, etc. etc.
Code generators
Various “pre-built” modules/libraries for the most common tasks
It was not inspired only by Rails, but borrows concepts and practices from various other frameworks
Good community support

CONs:

Seems too big compared to the others, too many “extras” which may not be useful to all developers
PHP5 only
Confusing and disorganized directory structure
Uses too many configuration files, not suitable for simple projects
Steep learning curve

Comments:
Symfony is really an interesting framework: it’s perhaps the most complete in terms for features and documentation. The only problem I have with it is that it just seems too complex and rather difficult to learn if compared to the others, which can do almost the same things (or will soon be able to) in a MUCH simpler way. A nice blend of MVC, pre-built components, command line generators and YAML/Propel configuration files, but perhaps a bit disorganized in its internal structure, unlike its wonderful documentation and support section.

PHP on Trax

Website: www.phpontrax.com
PHP version: PHP5
License: MIT
Download size (.tgz): 843KB
Supported Databases: Any database supported by PEAR::DB
Beginner’s Tutorial: How to create a Trax application

Official Description:
“Php On Trax (formerly Php On Rails) is a web-application and persistance framework that is based on Ruby on Rails and includes everything needed to create database-backed web-applications according to the Model-View-Control pattern of separation.”

PROs:

Simple, logical, essential: a true RoR port to PHP5
Code generators, like Rails
Zero configuration (like Rails and Cake
Easy and logical directory structure (the same as Rails)
Supports table associations, but more in a way which is more similar to Ruby on Rails than Cake.

CONs:

Lack of documentation compared to the others
Trying to port Ruby on Rails to PHP, ignoring why RoR was not built in PHP in the first place⁷
No internationalization or other advanced functionalities
PHP5 only
Small community
DBO class based only on PEAR::DB

Comments:
In my opinion this project aims too much to be a Rails-clone to acquire a proper consensus. Trying to port something to another language is not good, especially in the case of Rails and Ruby. This framework looks somehow like an old version of CakePHP, which evolved slightly but always remained anchored to its beliefs of building a Rails port for PHP (even in the name!). Some may say that this is a lost battle since the beginning – or better, since before it started – but others found that PHP on Trax can be the easiest way to switch from Ruby on Rails to a PHP equivalent. Who is going to do that? Well, Ruby programmers forced to develop in PHP, maybe. Not too good, but not too bad either.

Code Igniter

Website: www.codeigniter.org
PHP version: PHP4 and PHP5
License: CodeIgniter⁸
Download size (.zip): 609KB
Supported Databases: MySQL, PostgreSQL, SQLite, MySQLi, MS SQL + ODBC
Beginner’s Tutorial: Hello World! Introduction to Code Igniter [video]

Official Description:
“Code Igniter is an Open Source Web Application Framework that makes writing kick-ass PHP programs simple as apple pie. […] Designed to enable, not overwhelm, Code Igniter is a powerful PHP framework with a very small footprint, built for PHP coders who need a simple and elegant toolkit to create full-featured web applications.
If you’re a developer who lives in the real world of shared hosting accounts and clients with deadlines, and if you’re tired of ponderously large and thoroughly undocumented frameworks that require rocket science to understand, Code Igniter might just be the right tool for you."

PROs:

Good and organized documentation
Zero configuration (like Rails and Cake)
Includes various classes and libraries for common tasks
Compatible with PHP4 and PHP5
Medium-sized community
Intuitive directory structure
Ships with the full user guide included in separate HTML files

CONs:

No full (“written”) tutorials except the videos!
Relatively new to the scene, but growing
Does not seem to support table associations.

Comments:
People on the Net seem to be rather enthusiastic about this framework: where there’s a thread about the big ones (Cake and Symfony), there’s always, someone who pops in suggesting to try out Code Igniter. I personally think this can be a true bless for small/medium sized projects, however, I’d opt for CakePHP or Symfony for a large scale application: something is missing, e.g., most notably, table associations.

Biscuit

Website: biscuitproject.tigris.org
PHP version: PHP4 and PHP5
License: MIT⁵
Download size (.zip): 240KB
Supported Databases: Any database supported by PEAR::DB
Beginner’s Tutorial: Creating a simple application using the Biscuit MVC framework

Official Description:
“The mission of this project is to port Ruby on Rails to PHP5 (minus the Ruby part ;-)”

PROs:

Zero configuration, easy to deploy
Runs both on PHP4 and PHP5
Simple to learn

CONs:

Still under development and incomplete
Offers a limited subset of the features and functionalities offered by competitors: no internationalization, no table associations, no scaffolding…
“Documentation coming soon”
Almost non-existent community

Comments:
This project started as an attempt to create something simpler than CakePHP and more similar to Rails. I’m not sure whether the project is still active or not, since the last “release” on the former’s developer site is dated August 2005. Still in early stage – or dead.

Pipeline

Website: livepipe.net/pipeline/
PHP version: PHP5
License: Pipeline⁹
Download size (.zip): 288KB
Supported Databases: SQLite
Beginner’s Tutorial: none

PROs:

Simple directory structure
Suitable for small projects
Comes with various ready-made components
Supports table relationships

CONs:

PHP5-only
Too restrictive: only SQLite supported, kindly suggests developers to use its built-in features only
No documentation or tutorials, just the API
Not suitable for large projects
Almost non-existent community

Comments:
This project mainly borrowed the MVC architecture and some basic concepts from Rails, creating a simple PHP5 framework with personal/small websites in mind: it offers various built-in components which can be handy to most of us, supports only SQLite, and basically tells developers what to do. In my opinion it’s not flexible enough to be compared to the others, and it’s simply not suitable for anything other than small websites.

Conclusions

My favorite framework still remains CakePHP, it’s simple and yet powerful, easy to learn and use, mature, well supported and continuously improving. Symfony – at the moment – seems to be the one with most features and the best documentation, and it is an excellent and well supported project. The only problem I have with it is the scary amount of configuration files necessary to create an application: CakePHP doesn’t need any and can be used for (almost?) equally complex projects.
Although I didn’t have a chance to try them out, PHP on Trax is certainly the most faithful port of Ruby on Rails to PHP, but it lacks some of the features CakePHP and Symfony offer. Code Igniter may not be as advanced as the others, but its community seems to grow and its simplicity may appeal more users in the future…

At any rate, developers should always choose the best framework for their needs: I tried to write a quick comparative analysis of these six Rails’ “PHP children”, now it’s your turn, try out some of them, if you choose wisely you won’t be disappointed.

Notes

¹ They are all distributed according to various Open Source licenses.

² Ruby on Rails – Ruby framework for web development

³ CakePHP – Rapid [PHP] Development Framework

⁴ CakePHP – A ‘tasty’ solution for PHP programming, originally published on zZine Magazine

⁵ Open Source MIT License.

⁶ Symfony License:

Copyright © 2004-2006 Fabien Potencier
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the “Software”), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

⁷ Read the comments by David Heinemeier Hansson on Ruby on Rails to Basecamp

⁸ CodeIgniter License Agreement

Ten minutes on Rails (while eating Cake)

h3rald@h3rald.com — Sat, 29 Apr 2006 07:29:00 -0600

Today I decided to do something different, something I’ve been dying to do since before coming across CakePHP: give Rails a proper try. Like many other PHP developers out there, when Ruby on Rails came out I felt damn jealous and terribly tempted to learn Ruby only to start using such an amazing web development framework. At the time I actually even started reading various tutorials about it, and I was literally amazed at how RoR revolutioned the way of developing web applications.

One of the main problems which made me – sadly – abandon Rails was Ruby itself: personally I’ve never seen a programming language with a cleaner and more elegant syntax, but also – at least at the time – there weren’t many hosts supporting it. LuckilyI found CakePHP quickly after that…
Now however, more and more hosting companies boast full Rails support, and so when recently I had to move to a new host, I made sure it was Rails-friendly, just in case I wanted to give Rails another try, someday.
Oh well, the temptation was so strong that today, only a two days after switching to my new host, I felt I had to try it, I had to taste something different than the usual Cake.

I decided to (re-)read and follow the OnLamp tutorial about RoR, step by step, once again. I quickly typed rails cookbook from my shell and voilá, rails silently creates the skeleton of my application:

README
Rakefile
app/
components/
config/
db/
doc/
favicon.ico
index.html
lib/
log/
public/
script/
structure.txt
test/
tmp/
vendor/

That’s familiar: it’s very similar to what CakePHP’s directory structure used to look like. Now Cake evolved and adopted its own schema, which – I must say – seems more functional than RoR’s, at least at a first glance:

app/
- config/
- controllers/
- models/
- plugins/
- tmp/
- vendors/
- views/
- webroot/
cake/
- config/
- docs/
- libs/
vendors/

Cake felt the necessity to divide what you can mess with (app/, vendors/) from what you’d better not touch (cake/). Rails just left everything on the same level.

After creating my database and the necessary tables I have to edit config/database.yml, which corresponds to Cake’s app/config/database.php. Then things start to become a bit different from Cake, as Rails offers some very handy built in scripts which can be used to automatically create your application’s files, i.e. executing ruby script/generate controller Recipe creates the controller and other bits:

exists  app/controllers/
exists  app/helpers/
create  app/views/recipe
exists  test/functional/
create  app/controllers/recipe_controller.rb
create  test/functional/recipe_controller_test.rb
create  app/helpers/recipe_helper.rb

And so on. Anyhow… I followed the tutorial and yes, it was a nice read. CakePHP borrowed a lot from Rails but not everything. Inevitably Ruby’s syntax is less verbose and looks very very clean:

<% highlight :ruby do %>
class RecipeController < ApplicationController
scaffold :recipe

def list
@recipes = Recipe.find_all
end

def edit
recipe = Recipe.find(params[“id”])
@categories = Category.find_all
end
end
<% end %>

While CakePHP’s, simply because it uses PHP and not Ruby, looks less pretty:

<% highlight :php do %>
class RecipesController extends AppController
{
var $scaffold;

function list()
{
$this→set(‘recipes’, $this→Recipe→findAll());
}

function edit($id)
{
$this→set(‘recipe’, $this→Recipe→find(“id = $id”));
$this→set(‘categories’, $this→Category→findAll());
}

}
<% end %>

CakePHP Development Team did a great job translating some of Rails functionalities into PHP, and the while CakePHP’s syntax is much cleaner if compared to PHP’s standard spaghetti-code approach, Ruby just looks much more clear, sorry. Imagine a world without funny unnecessary brackets, pointless semicolons and where everything just looks better: that’s Ruby.

Sigh. Now I do understand why Rails was built in Ruby and not in PHP: simply because a PHP’s Rails would have been outscored by its “Ruby port”!

One thing I liked about Rails which has not been ported in Cake (yet) is a somehow smarter way of scaffolding. While the Ruby code above actually works, the CakePHP’s edit method doesn’t, or better, it does but not as expected: when you remove var $scaffold the scaffold is just plain gone, and you have to code everything yourself, while in Ruby you can leave the scaffold and then develop methods one by one, and still be able to use scaffolded methods if you didn’t define the custom ones.

The other thing I noticed about RoR is that it definitely handles errors better! This is probably another language issue. I basically forgot to set a category for the recipes, and when executing my custom list of recipes I got a very, very well structured error page showing something like:

<% highlight :ruby do %>
NoMethodError in Recipe#index

Showing app/views/recipe/index.rhtml where line #18 raised:

You have a nil object when you didn’t expect it!
The error occured while evaluating nil.name

Extracted source (around line #18):

15: <% @recipes.each do |recipe| >
16:
17: <= link_to recipe.title, :action => “show”, :id => recipe.id >
18: <= recipe.category.name >
19: <= recipe.date >
20:
21: < end >
< end %>

I took a screenshot of the page, because it was too nice: check it out. This error page really tells you what’s wrong, and even prints the lines of code around the error! It also lets the developer check the full backtrace and every sort of information… Can we have this in CakePHP please? I actually started to develop something like this, but seemed quite hard to do in PHP.

H3RALD - Tag 'rails' (RSS Feed)

Book Review: The Rails 3 Way

Book Review: The Rails Way

Contents

Organization and writing style

Some constructive criticism

Conclusion

Rails-powered Open Source Killer Apps, Anyone?

Developing Proprietary Web Applications with Rails

Dreams on Rails

[UPDATED] A Glimpse of Hope

Introducing H3RALD.com v7.1

Rails-Doc.org - A First Look

Search as you type…

…or browse through the namespaces

Contribute, contribute, contribute!

An Short Interview with Mikael Roos, from Nodeta

What are you actually trying to do on Rails-Doc.org?

Could you spend a few words on the “development process” followed by your company to develop this app? Did I read the word “Scrum” somewhere? Am I correct?

Did you develop it in three months, or…?

What is Nodeta, exactly? My Finnish is a bit rusty nowadays…

Can you give me more technical details about the way keyword search is performed? Are you indexing/tagging documentation beforehand?

What about the social side of it: you’re hoping people will contribute with notes, which will then be collected and integrated in the documentation correct? Do you have any moderation or anti-spam precaution?

Will contributors be credited somehow? Who can contribute and at what level?

You want to blow out competition and that you don’t want to fail: sounds a good plan! How is Rails-Docs different from other similar apps?

Do you have DHH’s seal of approval? Will you? Is there any copyright issue with your domain name?

What about doing something similar for the whole Ruby language? Ruby docs may also be easier, in a way…

The Bottom Line

Beware of sudden upgrades!

Book Review: Mongrel Digital Shortcut

Overview, Introduction & Getting Started

Section 4: Configurations

Section 5: Production Deployment

Section 6: Extending Mongrel

Debugging, Performance & Security

Conclusion

Text Link Ads sidebar for Typo

Installation

Configuration

To REST or not to REST?

Key Benefits

Downsides?

Simply On Rails - Part 4: Quick and Easy Default Data Migrations

Simply on Rails - Part 3: LiteController

An Interview with the creator of the Akelos Framework

There are a lot of frameworks for PHP, perhaps too many: why did you decide to create Akelos rather than using one of the existing ones?

What’s new since last time I posted about Akelos?

From the new site, it seems that Akelos is – or aims to be – a port of Rails for PHP. Is that true? Do you aim to target Rails developers as possible users of the framework in situations in which “they have no choice” but to use PHP instead of Ruby?

What Rails features are missing in Akelos?

I noticed quite a few generators available for Akelos, do they work as a Rails developer may expect them to work?

How does Akelos compare to other similar PHP frameworks like, say, CakePHP? What features does Akelos offer which Cake doesn’t offer and vice-versa?

Did you include unit tests for all the framework classes?

Did you or someone do any performance test or benchmarks on Akelos already?

Why should a PHP developer choose Akelos over another PHP framework?

Is there any website using Akelos already?

What are your future plans for Akelos? Anything new on the way?

Simply on Rails - Part 2: Database Design

Rails to Italy 2007

Simply on Rails - Part 1: Concepts and Bubbles

Simply on Rails?

COW

The Cunning Plan

Back on Track...

Ruby on Rails & CakePHP

Rails-inspired PHP frameworks

CakePHP

Symfony

PHP on Trax

Code Igniter

Biscuit

Pipeline

Conclusions

Notes

Ten minutes on Rails (while eating Cake)