DECENT PROGRAMMING

Rails, Ajax, Python, Zope and more.

July 2006

This tutorial will assist you in personally test-driving the much anticipated Streamlined framework released earlier today.

In this tutorial we get through the basics of installing the Streamlined framework and seeing some of its exciting ajax, paging, and live search functionality. In future tutorials I hope to extend further the example application (an employee skill tracking app) and explore the promising ways that the Streamlined framework proposes to manage relationships without all the heavy View code.

Download Testdriving_Streamlined_for_Rails_tutorial_1.pdf

Posted by Jeffrey Hicks at 12:17 AM  Permalink |

Rails developer Scott Raymond was inspired by all the CRUD/REST talk and took the plung to re-factor his IconBuffet.com and then write-up his experience. His analysis has been celebrated as "The missing content from DHH's keynote".

In Raymond's CRUD analysis he explains that constraining his controller's to CRUD reduced his number of actions from 75 to 58 while only increasing his controllers from 10 to 13. A CRUD constrained controller has been a hot topic which I covered in a previous article: Rails creator has data modeling opinion.

Raymond explains "Cutting actions is great, but even more significant is that the remaining ones are almost completely uniform ... which makes the entire application conceptually simpler, and thus easier to maintain, test, and extend."

The ROR weblog recognized his work in their entry Scott Raymond on Refactoring to REST. I noticed in the the comments that Alex asks if the core team would "bring [Saffolding] in-line with the new SimplyRestful and ActiveResource way of doing things". Rick then explains that the core team doesn't use scaffolding and that he uses Dan's CRUD Generator. Hmm.. something to look into real soon!

Posted by Jeffrey Hicks at 12:01 PM  Permalink |

Barry Schwartz is the author of "The Paradox of Choice" and a psychology professor at Swarthmore College. He recently gave a speech at Google and his ideas are spreading around the Rails circles. I believe his philosophy provides a lot of insight into some design principles used by 37 Signals in their web products - and of course the Rails framework itself.

In Schwartz's video at Google, he makes a number of fascinating points. First, everyone accepts that freedom of choice is good. However it may actually be the case that the current social trend in the explosion of choice may actually be contributing to decision paralysis, unhappiness, anxiety, and depression. It may seem counter intuitive, but Schwartz has put together some powerful observations.

Below I've borrowed some bullet points from Swartch's article The Tyranny of choice.

* Shoppers who confront a display of 30 jams or varieties of gourmet chocolate are less likely to purchase any than when they encounter a display of six.

* Students given 30 topics from which to choose to write an extra-credit essay are less likely to write one than those given six. And if they do write one, it tends to be of lower quality.

* The majority of medical patients do not want the decision authority that the canons of medical ethics have thrust upon them. Responsibility for medical decisions looks better to people in prospect than in actuality: Sixty-five percent of respondents say that if they were to get cancer, they would want to be in charge of treatment decisions, but among those who actually have cancer, only 12 percent want that control and responsibility.

* The more funds employers offer their employees in 401(k) retirement plans, the less likely the employees are to invest in any, even though in many cases, failing to do so costs them employer-matching funds of up to several thousand dollars a year.

* When maximizers, as opposed to satisficers, go shopping for big items or small ones, they spend more time looking, have a harder time deciding, look around more at what others are buying, and are less satisfied with their purchases.

* Maximizing college seniors send out more résumés, investigate more different fields, go on more job interviews, and get better, higher-paying jobs than satisficers. But they are less satisfied with the jobs, and are much more stressed, anxious, frustrated, and unhappy with the process.

So what does all this mean about web design and Rails?

The web design aspect is an easier sell. The recent rise in popularity of "real" web usability supports less choice and less effort by the user altogether. I would say this is so accepted that discussion has shifted away from whether less is more and directly into how to achieve less.

The design of a web framework is a different matter altogether. Most believe that its okay to simplify things for the users of our website, but when it comes to making the web application; things are and must be complex. After all, we are brilliant programmers and we must feed our great intellect.

Needless to say this isn't the mentality of Railers. I'm not going to actually go into all the ways Rails has achieved its simplicity and beauty, but I did want to clarify that simplicity isn't actually a way to get away with putting less effort into the design of a framework. I suggest that its actually more difficult to define conventions and limit choice. Its an awesome burden, and I feel fortunate that our Rails leaders will bear the psychological trauma of weighing out all the options for us.

Posted by Jeffrey Hicks at 11:35 PM  Permalink |

I just finished watching David Heinemeier Hansson's (DHH) speech and reviewing his slides from Rails Conf. 2006. This speech isn't just entertaining, its essential study material. In this article I've collected all my study aids: DHH's video, his slides, and my humble take away message.

So, if you haven't already done so, go ahead and watch DHH's video and follow along with his slides. The main point that I extracted is to keep your controllers simple. Do not add actions beyond CRUD (Create, Read, Update, and Delete). According to the prophecy, constraining your controller to these actions will bless you with an enriched model and a design perfect for Rail's new web services.

DHH has some great examples in his slides, but if you've decided to read along before you invest in watching the video ... well, I will oblige you with a less than perfect example of how constraining your controllers to CRUD provides a better model.

Let’s say that you’re creating an application that tracks "projects" and "employees" with a many-to-many relationship. A project has assigned employees, and employees may be assigned to multiple projects. Eventually you would add an action to your employee controller named something like "assignToProject". According to DHH, this breaks CRUD. The first symptom that you are breaking CRUD, besides creating a new action is the choice you’re forced to make ... 1. Do you create the action "addEmployee" to your project controller? or 2. Do you create the action "assignToProject" in your employee controller? Another symptom is the cringe you feel when you’re asked to track additional information about the relationship - such as when an employee was assigned to the project. This is where Rails got into the sticky mess of rich associations using the push_with_attribute method. Yuck! We don't have to live like this!

In our perfect world where we are free to model the prophecy, we would create another model that tracks not a Project, and not an Employee; but the relationship between the two. DHH says "Don't just model things". In this example we would create another model named "Assignment". Now we don't need an "assignToProject" in our employee controller nor an "addEmployee" to our project controller. We simply have a "create" action in our Assignment controller. Now that we've enriched our model, we can keep our controllers wonderfully simple. Added bonuses include the easy ability to track additional information about assignments - such as when did the assignment begin or even who authorized the assignment. This information can be easily stored in the assignment model without fear of someone suggesting it should reside in either the project or employee model where it definitely does not belong.

One problem DHH mentions is that CRUD needs a better name. I liked Alex Bunardzic suggestion for RIDE (Read, Insert, Delete, Edit). On second thought, maybe CRUD doesn't need a new hyped up name. Maybe its just a healthy revisit of classic computer science.

And a problem that I will save for another post ... consider a new bad temptation -- now that having an action besides CRUD in my controller means re-thinking my model ... I'm afraid I'm going to start cramming functionality inside CRUD actions that don't really belong there. This would be bad. I'll have to work out these distinctions in a later post.

Posted by Jeffrey Hicks at 07:45 PM  Permalink |