\nmtnwestruby: Review of a Rails App by Marcello and Jamis of 37signals.com
\n17 March 2007\n<\/p>\n
\nAlmost everyone in the audience has used Rails. A little less than have write Rails apps for a living. I haven’t used Rails, and even if I had, it would be difficult to take notes on this presentation. I recommend viewing the video when it becomes available.<\/p>\n
\nMarcello and Jamis recommend Kent Beck’s book on Smalltalk best practices<\/a> and how to decide what code belongs where. They also recommend Domain Driven Design<\/a>.<\/p>\n \nWhy do you prefer the operator ‘&&’ over ‘and’? The use of ‘&&’ leads to fewer bugs. Consider the following code:<\/p>\n \nConvention: A bad smell in code is seeing a chain of if..elsif mtnwestruby: Review of a Rails App by Marcello and Jamis of 37signals.com 17 March 2007 Almost everyone in the audience has used Rails. A little less than have write Rails apps for a living. I haven’t used Rails, and even if I had, it would be difficult to take notes on this presentation. I recommend … <\/p>\n\n
return foo and bar <\/code> # will not return what you expect\nreturn (foo and bar) <\/code> # this will work\nreturn foo && bar <\/code> # use ‘&&’ and ‘||’ because they’re more predictable in behavior than ‘and’ and ‘or’\n<\/ul>\n<\/p>\n
\nstatements to check for error conditions. In this case, you probably want to
\nhandle error cases with exceptions. For example, in Rails, myobj.save! will
\nvalidate data, and raise an exception when there’s a problem, whereas
\nmyobj.save will not raise an exception.<\/p>\n","protected":false},"excerpt":{"rendered":"