From the monthly archives: September 2007
One of the best books I’ve read about design is Domain Driven Design: Tackling Complexity in the Heart of Software, by Eric Evans. InfoQ has a small ebook called Domain Driven Design Quickly that provides a nice summary of the book. It was a good refresher for me as I read DDD about three years ago.
So What is Domain Driven Design? Read the link to have a good overview. Here are the two most important points:
- Focus on modeling the domain and domain logic of your application.
- Build a “Ubiquitous Language” that is used by all the team (from domain experts to analysts to developpers).
The most interesting part of the book for me was the patterns presented as the basic building blocks of a model-driven design: Layered Architecture, Entities, Value Objects, Services, Modules, Aggregates, Factories, Repositories. These are all very simple but fundamental patterns in software development. These are types of objects that are present in all designs. Understanding the difference between a value object and an entity is crucial and can help simplify a design.
The book also discusses the importance of iterative design, the importance of incorporating back what you learned about the domain in the model as you iterate and how to preserve the integrity of the model. There is a good discussion of ways of separating the model as the team gets bigger.
The value of this book for a Rails developer
Ever heard about skinny controller, fat model? This is THE book about building a rich model.
However, it really depends on the type of application you’re building. Most Rails application are mostly concerned about CRUD operations without too much logic behind. You won’t get out much from this book.
But if you’re working on a business app with a lot of business logic, then this is a must-read.
The ebook also has a small interview with the author. He highlights the expressiveness of ruby and mentions that DSLs are probably the next big step in Domain Driven Design.
Popularity: 42% [?]
When I started university a couple of years ago, getting an MBA after finishing my degree was something I was considering quite seriously. My mind has since changed and this blog post by Bob Sutton (who wrote “The No Asshole Rule“), Why Management is Not a Profession, gives food for thought about the real value of an MBA:
The discussion about the “value” of the MBA always seems to end — no matter where it starts and no matter what nuances are discussed by Pfeffer and others — with a focus on how much money it puts (or doesn’t put) in the recipient’s pocket.
The End of Business Schools? Less Success Than Meets the Eye has two interresting findings:
- Don’t bother if you’re not going to one of the top 10 business schools. You won’t make more money and you will actually lose two years of salary.
- There is no relationship between grades and salary at the top 10 schools. Only the networking that happens there is important.
Business school professors really hate this one, as it means that those students who do as little work in classes as possible, and devote all their time to networking, are acting in economically rational ways.
So that’s the money perspective about an MBA. What about what you learn from getting an MBA:
There is remarkably little conversation about whether it teaches people to do a better job of helping and serving clients, employees, or anyone else. (…) the societal message — and it is often quite explicit — is that the most effective managers take as much money as possible for themselves from their clients.
Getting an MBA is far from my mind right now. I really believe you can make a more than decent living without it happening to the detriment of people around you.
Popularity: 6% [?]
The last part is easy. Now what is architecture as related to software development, that’s a much harder problem (42 is still a good answer of course). I think I just read the best explanation of what it is.
Roy Fielding(inventor of REST) gave a talk at RailsConf Europe entitled “The Rest of REST“. The last slide really sums it best:
use principled design:
- identify desired architectural properties
- constrain behavior to induce properties
- compensate for the inevitable design trade-offs
I think this is the best way to really understand why constraints are liberating. When designing, you choose the properties important to your application (whether it be efficiency, scalability, maintainability or any other -ilities). The architecture will codify a set of constraints that should lead to your application having these properties. These constraints free you from having to constantly think about any of the properties, as long as you respect the architectural guidelines.
An example from the slides: Constrain interactions to be stateless. This simplifies the server, improves scalability and reliability. However, it degrades efficency. Checkout the slides as Roy gives very detailed info on the advantages and tradeoffs of using a REST architecture. Seriously, these slides are gold. I will read them again and again over the next few weeks.
Popularity: 9% [?]
I want you to try finding the US population by going through the US Census Bureau website.
Did you find it? According to a recent study by Jakob Nielsen, only 14% of users could find it, even though it is big and red at the top of the page. (check the study to see a screenshot of the original image in case the website changed). Quite surprising no?
The problem is that it looks like an ad and most people are banner blind. The problem here is that it is in a sidebar with big red text, images and made-up term like “population clock”, traits people associate with an ad.
Even more interesting is to look at the heat map, showing where the user’s eyes stopped. In this case, the user clearly looked at the zone where the answer is, but quickly moved on.
Usability is an interesting beast. Results like this clearly show that you can’t take anything for granted and you need to test with real users.
Popularity: 5% [?]
The Rails Edge: Quotes and Notes is a very interesting collection of quotes from the rails edge conference. Two in particular caught my attention:
“Metaprogramming + DSLs is the Ruby equivalent of Design Patterns in the Java world”
— Chad Fowler. Fowler’s point here was more about the buzz and hype, just like there was a time in the early 2000s when every Java programmer wanted Design Patterns whether or not they were needed, Fowler sees a similar rush to add DSLs to Ruby programs.
“If programmers, on average, were able to write parsers and compilers, Ruby on Rails would not have taken off”
— Stuart Halloway
This is something I’ve noticed a lot recently: every plugin that gets released is a DSL! or it uses a cool metaprogramming trick! That’s nice, but was it really needed? And can we really talk about a ‘language’ when your plugin adds two simple commands to a controller?
I guess it’s a rite passage when learning ruby to write something using metaprogramming. The problem is when you start using it for everything, just like when you add patterns after patterns to your code, just because.
Again, this is a case of using the right tool for the right job. Metaprogramming is a power tool that is useful some time.
Here are other quotes that I like, as they echo the discussion I had with Fred Brunel at the last book club about process:
“The right process is always ‘not quite enough process’”
— Stuart Halloway
“Do the dumbest, simplest thing that almost works”
— Stuart Halloway, on process
“The traditional view, with sixteen pounds of documentation, introduces a single point of failure in the process, understanding the problem domain”
— Dave Thomas
“Getting a specification involves bullying the customer”
— Dave Thomas
Popularity: 26% [?]
Last night was the second edition of Montreal On Rails, with 50% more stuff! (3 presentations instead of 2) My thoughts on the presentation:
First up was Chris Scott, who presented the extjs Javascript framework. Notes to future presenters: please make sure you take 15 seconds to explain what the framework is and why I should care at the start. Don’t wait 5 minutes where you’re setting up your example to finally drop a ‘btw, extjs is a widget framework’. The presentation started slowly with basic stuff and moved on to bigger and better things at the end. I was really impressed by the layout management possibilities that extjs offers.
There was a lively discussion after the presentation comparing extjs to Protoype. Someone pointed out the obvious that prototype isn’t a widget library, but extjs seems to also cover a lot of what the prototype/scriptaculous combo can do.
I’m not a fan of javascript widgets library. I just don’t think it’s a good idea to want to emulate all desktop application functionalities in a web application. Working with the constraints of the web browser forces you to look for simpler alternatives.
Second presentation was by Chris Lamothe who did a demo on how to add user authentication to your rails application using acts_as_authenticated. It was geared toward newbies. He also briefly mentioned a plugin I didn’t know about, role_requirement, that adds basic role based security to acts_as_authenticated.
“Client-side debugging in Firefox” was the title of the last presentation, by Terje Tjervaag. Actually, he quickly presented a couple of Firefox plugin like Web Developer Toolbar, Firebug and YSlow. If you don’t know about these plugins, download them now! There’s no way I’m going back to using Firefox without Firebug (except for the increased slowness and memory usage). It allows you to poke at and modify anything in your web page, live. Terje seems really knowledgeable about testing the view/javascript/browser issues of an application and I hope he can do a more advanced presentation someday explaining how he does it. Right now, my automated testing stops at the models and controllers.
Suggestions for next presenters: although it’s nice to show live how to do things, you don’t have to type everything in front of the audience, especially when we can see the complete examples commented just below what you’re typing. It’s OK to copy paste. You can also have a basic rails application already setup with what you need. This would help speed up presentations next time.
I hope I don’t sound too critical of the speakers. They did a really good job and I realize that speaking in front of people is not easy. I wouldn’t have done better myself.
The best part of the night was after the meeting, as we went to McClean’s for burger and beer. I had an awesome discussion with Marc-André Cournoyer (read his report), Carl Mercier and Francois Beausoleil (who will be doing a presentation on piston next time). We exchanged war stories and talked about every subject concerning rails from deployment to testing to plugins we use. I hope we can do the same next time!
Note: The next meeting will apparently be at the StandoutJobs office. I bet this is just a ploy by Fred to make sure every rails programmers in Montreal wants to work for them. 
Popularity: 23% [?]
One very useful feature of Texmate that few people seem to know about is Textmate Footnotes. It’s a Rails plugin that adds this menu at bottom of your pages:
When you are testing your app, you have links that takes you directly to the contoller, view, layout, stylesheets. You can also see the session, params and log for the current page. If you get an exception in your action, each line of the stack trace is turned into a link, taking you right to the file at the correct line where the exception occurred. If you haven’t tried it yet, what are you waiting for?!
Popularity: 6% [?]
