From the monthly archives: July 2007

Montreal Tech Entrepreneur Breakfast Meet-up, July Edition

by jfcouture on July 11, 2007 · No Comments

Yesterday morning, I attended my first MTEBM at Bistro etc. I’ve always been a bit shy, but it was surprisingly easy (even for me) to start talking. I met some very nice people and the energy level was high.

Mark Schanzleh and his partner Amélie Racine talked about staynomad, their travel startup. Mark is very passionate and he probably could have talked about his project all morning long. I had a very interesting (and mostly technical) talk with Marc-André Cournoyer and Pierre Phaneuf. On my way back, I had the chance to discuss with Mathieu Balez. He’s a smart guy and I can’t wait to see what new project he is working on. He is also starting a Montreal on Rails community, with the first meeting around August 7.

You can read Marc-André’s and Heri’s report with some photos.

Popularity: 11% [?]

 

Rethinking Design Patterns

by jfcouture on July 6, 2007 · No Comments

Jeff Atwood has a good post entitled Rethinking Design Patterns.

It’s certainly worthwhile for every programmer to read Design Patterns at least once, if only to learn the shared vocabulary of common patterns.

No matter what you think of design patterns, you have to read the book at least one time. I remember a talk with a fellow programmer, explaining a part of his design: “so you this object inheriting from that one, and implementing that one interface, and blabla blabla object object blabla more objects etc…”. After a couple of minutes, I said “so basically, you have a composite”. “Yes”. As a design gets bigger and bigger, it’s important to have a bigger vocabulary than just class this, object this.

But there are problems with patterns as Jeff continues:

If you find yourself frequently writing a bunch of boilerplate design pattern code to deal with a “recurring design problem”, that’s not good engineering– it’s a sign that your language is fundamentally broken.

In his presentation “Design Patterns” Aren’t, Mark Dominus says the “Design Patterns” solution is to turn the programmer into a fancy macro processor.

Don’t Repeat Yourself. If the same pattern happens again and again, maybe you should find a way to automate it? A good language can help here. I hear a lot more about patterns in the java world than in the ruby world. Why? You have no choice but to code the pattern and it’s boilerplate every time in java. In ruby, you do it one time with a bit of metaprogramming. The ruby standard library provides a library for the singleton. “Include singleton” in your class and you’re done. Other design patterns are there to cover a flaw in the language. For example, you don’t need visitors if you use lisp because of multiple dispatch.

How can you distribute responsibility for design through all levels of a large hierarchy, while still maintaining consistency and harmony of overall design? This is the architectural design problem Alexander is trying to solve, but it’s also a fundamental problem of computer systems development.

I will have to read the Alexander book. That’s a much more interesting problem than something you can abstract in a good language.

Popularity: 5% [?]

 

Making the mental switch to REST

by jfcouture on July 4, 2007 · No Comments

I finally played a bit with the REST part of Rails. Over the weekend, I made my first RESTful web app. How did it go? I don’t know. I don’t think I’ve yet made the mental switch. There’s a few things that bug me about REST, and I’m not sure I can put it in words yet.

I think there’s “REST” and “Rails REST”. The way Rails does REST seem to be a subset of REST, or at least it puts more constraints on how you should do it.

The one thing that bothers me the most is the respond_to and how you can handle different formats. Yes it is nice to be able to reuse the same action and send back XML or CSV or a basic html representation of the information. But when it comes to the actual UI of your application, the html, the forms, the navigation, I don’t want my user to interact with the application the same way a machine would.

Maybe I should investigate a bit more the RADAR architecture as described by Dave Thomas. The idea is to have the html application be another layer on top of your resources.

Popularity: 3% [?]