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.

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.

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.

In Search Of Stupidity: Over 20 Years Of High-Tech Marketing Disasters, by Merrill R. Chapman, 2nd edition

ISOS looks at the last 25 years of computing and provides an interesting look at what went wrong for some companies: how Wordstar lost the word processor market, the failure of the IBM PC Junior, what happened at Ashton-Tate with dBase, etc.

Positives: The writing is really engaging. Once you start the book, you will not put it down. All the stories are very interesting and well written.

Negatives: There isn’t a lot of analysis of what went wrong. It’s mostly the facts, plus a “they made a positioning mistake” sentence and that’s it. I do not understand how the in fighting between two groups of developers at a company can be considered a marketing mistake. Sometimes the author likes to be clever and his humor might annoy some people.

Conclusion: Well worth your time if you like reading about the history of the computer industry and if you would like to avoid some of these mistakes yourself.

Analyzing the Facebook Platform, three weeks in by Marc Andreesen gives a very good explanation of an application versus a platform and the advantages it provides. It also gives an overview of how Facebook chose to handle its API. If you have any interest in web application and social networks, it’s a must read.

Laïka hosted the first Montreal Web Development Book Club this past Monday. There wasn’t as much people as expected, probably because of the long weekend. It was still loads of fun and packed with great discussions. I presented In Search of Stupidity by Merrill Chapman. I’m going to post a review soon, but the book generated some good discussions about the industry in general.

The next book was Everything is Miscellaneous by David Weinberger, which is about ways to organize information, such as hierarchies and tags. Evan Promodou, who started wikitravel (which recently won a Webby award), is obviously very interested in the subject. This led to a discussion about RDF. I never understood the interest in RDF (I think XML is good for almost everything except what people actually uses it for), but I’ll definitely have to check out how he uses it on wikitravel. Anyway, the book seems very interesting as it also presents a historical perspective on the subject, such as the Dewey system.

Information Architecture for the World Wide Web was the last book of the night. Heri mentioned that he read the book 3 times. The way he said it, I’m not sure if it was because it was such a good book or because it was hard to understand. It seems to be very academic, but still the book to get if you’re interested in information architecture. Anyway, this lead to a great conversation about how to evaluate if your site has a good architecture, especially in the case of a wiki as big as wikitravel.

For those interested, all meetings will be held last monday of the month. The next one should be on July 30 at 7pm, at Laika. You can read Heri’s report here and Evan’s here.

People who know me thinks Amazon.ca survives because of the “few” orders I make from them. Here what’s in my last, in case you’re wondering what I’ll be reading in the next few weeks:

• The Art Of The Start [Hardcover]
  By: Guy Kawasaki (Author)
• Code Generation in Action [Paperback]
  By: Jack Herrington (Author)
• Non-Designer’s Design Book, The [Paperback]
  By: Robin Williams (Author)
• The 4-Hour Workweek: Escape 9-5, Live Anywhere, and Join the New Rich [Hardcover]
  By: Timothy Ferriss (Author)
• Ruby Way, Second Edition, The: Solutions and Techniques in Ruby Programming [Paperback]
  By: Hal Fulton (Author)
• Fooled By Randomness: the Hidden Role of Chance in Life and in the Markets [Paperback]
  By: Nassim Nicholas Taleb (Author)
• Founders at Work: Stories of Startups Early Days [Hardcover]
  By: Jessica Livingston (Author)
• Dip [Hardcover]
  By: Seth Godin (Author)

The number of lines of code in the application is a common measure of the importance of the application, and the number of lines a programmer can produce in a day, week, or month is a useful metric for project planning and resource allocation. Abject-oriented programming is one of the best ways to get the most lines of code in the shortest time.
…
Inheritance is a way to retain features of old code in newer code. The programmer derives from an existing function or block of code by making a copy of the code, then making changes to the copy.
…
A modular program is one that is divided into separate files that share a common header comment block.

Introduction to Abject-Oriented Programming

Tonight is the night for funny links!

Can you guarantee to us that we’ll get as many lines of code from you as we would if we hired a professional company to build this?

Top 20 Stupid Client Quotes at Clientcopia.

Nebula and Hugo award winner in 1972 and 1973. Humanity finds an unlimited source of energy, but it will destroy the sun. The book is divided in three parts, each presenting a different viewpoint: a young scientist trying to convince of the danger, the aliens responsible for the energy source and a scientist on the moon with the help of a female intuitionist.

If you like Asimov’s style, you will like this book. If you don’t, the book has the same flaws as most of his writings. Character development is limited. Most of the book deals with side stories. The first part ridicules the ego and lust for fame of scientists. Asimov then describes a strange alien society where they live in groups of 3 (a Rational, an Emotional and a Parenting), how they make love and evolve to another form after they have 3 children. The last part is about the difficulties involved living on the moon. The “real” story occupies a tenth of the book and there isn’t much development, other than finding a solution.

I personally love Asimov’s imagination and I couldn’t stop reading once I started, always a sign of a great book. 4.5/5 stars.