At the Rails Edge conference, one of the speakers mentioned how, as a young programmer, there was no better feeling than to write a program with an enormous LOC count. It made him proud. And I tend to agree. I remember first learning C/C++ and how good it felt to have a rather large program compile successfully. “The more the better,” I thought. Well, that’s hardly the case. Software development entails writing less and less LOC, intentionally. The creator(s) of Rails have made some logical assumptions that have allowed them to extract a lot of the annoying and incessant work, which provides a more focused development process.
As an example, here’s the controller portion for an edit method using the well-known MVC Java framework, Jakarta Struts:
public ActionForward edit(ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response)
throws Exception {
PersonForm personForm = (PersonForm) form;
if (personForm.getId() != null) {
PersonManager mgr = (PersonManager) getBean("personManager");
Person person = mgr.getPerson(personForm.getId());
personForm = (PersonForm) convert(person);
updateFormBean(mapping, request, personForm);
}
return mapping.findForward("edit");
}
And here’s the cleaner, simpler Rails version:
def edit @person = Person.find(params[:id]) end
Rails takes care of the tedious, repetitive, grunt work—much more than I realize am making note of, here. From this example, to cut the Struts method down to one line, a few assumptions had to be made:
- Most methods are usually public
- Put regularly used objects in scope
- No need for a “manager” (which caused two objects to represent
person, plus conversion code) - No mapping
- It’s a web application, so stuff will fail (remove the explicit
throws Exception)
That makes sense to me. While working with Ruby and Rails, I’ve enforced my desire to do more with less. It’s often more of a challenge to write less code to achieve the same results, but it’s much more fun.
