Showing posts with label Experience. Show all posts
Showing posts with label Experience. Show all posts

Thursday, March 26, 2009

Guy Kawasaki's keynote in Montréal

Yesterday, I attended a keynote presented by Guy Kawasaki in Montréal. It was a real fun to listen to him. He is a great communicator.

I found many commonalities with my blog post Career Advice'08, and with Tim O'Reilly's message “Work On Stuff That Matters.” So the gap to adhere to Guy's recommendations was small.

Here is a report written by Jean-François Ferland, for the magazine Direction Informatique. If I want to reproduce it here, it's mainly because it is then ad-free ;) You can find the original version on Direction Informatique website.

Good reading,
A+, Dom


Kawasaki: innover est un art... sous le signe de l'humour
26/03/2009 - Jean-François Ferland

Guy Kawasaki, un ancien « évangéliste » d'Apple, suggère aux entreprises en démarrage dix règles pour se démarquer auprès des consommateurs et se faire remarquer par les anges investisseurs. Compte-rendu d'une allocution qui a bien fait rire l'auditoire.


Guy Kawasaki
Photo: David Sifry.
Licence: CC-by-2.0
La plupart des allocutions se suivent et se ressemblent. Or, il arrive qu'un conférencier se démarque par ses propos, par son ton et par la forme de son allocution, sans causer l'ennui ou un sentiment de déjà-vu.

Au Club St-James de Montréal, dans le cadre de la deuxième édition de l'événement Capital Innovation qui réunissait des entreprises en démarrage du Québec et des investisseurs, le conférencier Guy Kawasaki a décidément retenu l'attention des invités.

M. Kawasaki, un Californien d'origine hawaïenne, est le fondateur de Garage Technology Ventures, une entreprise qui fait du maillage entre les anges investisseurs et les entreprises en démarrage, en cherchant « deux gars, un gars et une fille ou deux filles dans un garage qui développent 'la prochaine chose importante' ».

Il est surtout connu pour son ancien rôle « d'évangéliste » pour les nouvelles technologies chez Apple lors de son deuxième séjour chez le fabricant de produits de 1995 à 1997. Lors de son premier passage, de 1983 à 1987, dans la division Macintosh, son rôle était de convaincre les gens d'écrire des logiciels pour les ordinateurs d'une entreprise « qui comptait le plus grand nombre d'égomaniaques, un record qui a été depuis battu par Google ».

Après avoir clamé son amour pour le hockey, un sport qu'il a commencé à pratiquer en Californie en même temps que ses fils à l'âge de 48 ans (!), M. Kawasaki a entamé sa conférence qui consistait en dix recommandations à l'intention des entreprises en démarrage dans le domaine des TIC.

Ses propos étaient parsemés d'humour, ce qui a plu à la foule de plus d'une centaine de personnes. « J'ai écouté bien des chefs de la direction lors de conférences comme le Comdex. Souvent ils étaient 'poches' et prenaient beaucoup de temps », a-t-il lancé en riant.

Voici brièvement ses dix recommandations portant sur l'art de l'innovation, accompagnées de courtes explications (et de remarques amusantes).

1. Faire quelque chose qui a du sens M. Kawasaki affirme qu'une entreprise en démarrage ou un innovateur doit vouloir faire quelque chose en premier lieu avec l'intention que cela fera du sens, en opposition à vouloir faire de l'argent avant tout, ce qui sera une conséquence naturelle de la première intention.

« Si une entreprise est démarrée avant tout pour faire de l'argent, elle attirera les mauvais cofondateurs, et les détenteurs de MBA sont les pires, a dit M. Kawasaki. Comment évalue-t-on la valeur d'une entreprise en prédémarrage? Ma règle est que chaque ingénieur à temps plein fait monter sa valeur d'un demi-million, mais chaque MBA la fait baisser d'un demi-million. »

2. Se faire un mantra
M. Kawasaki s'est demandé à voix haute pourquoi les entreprises ne pouvaient décrire leur raison d'être en deux ou trois mots. Il a décrit la méthode nord-américaine de création d'un énoncé de mission, où les dirigeants d'une entreprise de réunissent deux jours dans un hôtel près d'un terrain de golf, avec un consultant en motivation « parce que personne dans l'équipe ne sait comment communiquer ». La première journée est consacrée à faire des activités de mise en confiance et la deuxième à écrire des idées au crayon feutre sur du papier adossé à un présentoir.

« On tente alors d'énoncer ce qui est bon pour les actionnaires, les dirigeants, les employés, les consommateurs, les baleines et les dauphins. C'est souvent trop long, il y a trop d'expertise et on ne peut comprendre si on enlève le nom de l'entreprise. Il faut dire en trois mots ce que l'on fait », a-t-il dit.

3. Sauter sur la prochaine courbe M. Kawasaki a affirmé que l'innovation survient lorsqu'une organisation sort de la trajectoire qu'elle suit ou qu'elle saute dans une nouvelle courbe. Il a donné l'exemple des coupeurs de glace des années 1900, de la version 2.0 à l'ère des usines de fabrication de glace, puis de la version 3.0 des réfrigérateurs à la maison. « Aucun des coupeurs de glace n'a bâti de fabrique de glace », a-t-il souligné, et sont carrément disparus.

4. Rouler les dés L'innovation prend forme lorsque l'entreprise prend le risque de faire le saut vers une autre courbe. En faisant un acronyme avec le mot Dicee - une altération inventée du mot « dé » en anglais, dont toutes les définitions sur Internet réfèrent au conférencier - M. Kawasaki a suggéré que l'innovation impliquait de la profondeur (Deep) par l'ajout de fonctions, de l'Intelligence lorsqu'on soulage une difficulté pour le consommateur, une expérience totale (Complete), de l'Élégance parce que le produit fonctionne lorsqu'on le branche et de l'Émotivité parce que les personnes l'aiment ou le détestent, sans zone grise.

5. Lancer maintenant, corrigez plus tard C'est ainsi qu'on pourrait traduire l'expression Don't worry, be crappy - inspirée par la chanson de Bobby McFerrin. M. Kawasaki a affirmé qu'une innovation a forcément des défauts et que ceux qui attendent qu'elle soit parfaite ne font pas de ventes entre-temps. « Le produit mis en marché ne doit pas être tout mauvais (crap), mais avoir juste un peu de mauvais. Le Apple 128 était un mauvais produit révolutionnaire! »

6. Polariser les gens M. Kawasaki a répété qu'une innovation audacieuse sera inévitablement aimée ou détestée par les gens, en donnant l'exemple de l'enregistreur numérique personnel Tivo que n'aiment pas les agences de pubs parce qu'elle permet d'éviter de regarder des messages publicitaires. « Le véhicule Scion de Toyota est vu comme étant cool par les gens de 27 ans et comme un réfrigérateur par les gens de 55 ans. On ne peut pas plaire à tout le monde, mais il ne faut pas en faire fâcher de façon intentionnelle. Cela n'arrive jamais que tout le monde aime un produit. »

7. Laisser cent fleurs éclore M. Kawasaki a indiqué qu'un produit innovant peut mener à des utilisations non intentionnelles, par des utilisateurs qui n'étaient pas ciblés à l'origine. Il donne l'exemple d'une crème de la compagnie Avon qui rend la peau douce, mais que les mères utilisent... comme chasse-insectes! Il a aussi évoqué la console de jeu vidéo Wii de Nintendo, destiné aux enfants, qui fait un malheur auprès des personnes âgées.

« Si cela vous arrive, prenez l'argent!, dit-il en riant. En 1984, Apple pensait que le Macintosh servirait au calcul dans les chiffriers, aux bases de données et au traitement de texte. Arrive PageMaker, qui a créé l'éditique et a sauvé Apple. Sans l'éditique, nous écouterions encore de la musique sur des cassettes de 60 minutes! »

« En ingénierie, je recommande d'aller voir ceux qui achètent les produits pour savoir ce qu'ils veulent. Chez Apple nous avions demandé aux entreprises Fortune 500 pourquoi elles n'achetaient pas nos ordinateurs. Nous leur avons créé un pilote d'impression, comme ils avaient suggéré, mais ensuite ils ont trouvé d'autres excuses... », a-t-il ajouté.

8. Vivre dans le déni M. Kawasaki a indiqué que la chose la plus difficile à faire en innovation est de refuser d'écouter ceux qui diront que c'est impossible à faire, que personne n'achètera le produit ou que personne ne fournira du financement. « On vous donnera 60 raisons. Ignorez-les. Mais une fois que le produit est lancé, virez votre capot et passez en mode 'écoute'. [Entre ces deux approches,] c'est le passage en zone neutre qui est le plus difficile », a-t-il confié. Comme au hockey.

9. Trouvez votre niche M. Kawasaki a évoqué un graphique pour une innovation où l'axe vertical décrit son niveau d'unicité et l'axe horizontal sa valeur, en affirmant que l'entreprise veut se situer en haut et à droite. « Un produit qui est unique et n'a pas de valeur ne doit pas exister. C'est comme offrir le curling aux États-Unis! »

Pour décrire une innovation qui n'a ni valeur ni unicité, M. Kawasaki a relaté le cas de Pets.com qui vendait en ligne de la nourriture pour chien. « L'enjeu en était un de gestion de la chaîne d'approvisionnement. Ils se disaient capables d'éliminer les magasins, cet intermédiaire qui prenait une marge de 25 %, en livrant directement aux propriétaires de chiens. Mais des vaches mortes en conserve pèsent lourd [en frais de livraison]. C'était plus cher et pas plus pratique... »

10. La règle du 10-20-30 La dernière règle suggérée par M. Kawasaki aux entreprises en TIC en est une qui servira lors des présentations aux anges investisseurs. « Utilisez 10 diapositives. Ne lisez pas vos diapositives - les gens savent lire. Le mieux est de ne pas avoir de diapositives! Aussi, expliquez votre produit ou votre projet en 20 minutes. De toute façon, 95 % des gens prennent 40 minutes d'une présentation d'une heure pour brancher leur portable avec leur projecteur. »

« Enfin, utilisez une taille de caractères de 30 points. Prenez la plus vieille personne dans l'auditoire, divisez son âge en deux et vous aurez la taille idéale. Comme les anges investisseurs deviennent plus jeunes, bientôt vous utiliserez une taille de 8 points! » a ajouté le conférencier, ce qui a suscité l'hilarité dans la salle.

(En bonus) 11. Ne laissez pas les « bozos » vous décourager En terminant, M. Kawasaki a suggéré aux entrepreneurs de ne pas se laisser abattre par les clowns qui les décourageront.

« Il y a deux types de clowns : le premier est mal coiffé, n'a pas d'aptitudes sociales et démontre qu'il est un perdant. Le deuxième, qui conduit une voiture allemande et porte un beau complet, est le plus dangereux. La moitié du temps, il est devenu riche et célèbre par chance », a-t-il déclaré.

Au terme de cette allocution, nous pourrions recommander aux entreprises une douzième règle : faites des présentations amusantes et animées comme celle de M. Kawasaki!

Jean-François Ferland est journaliste au magazine Direction informatique.

Tuesday, March 17, 2009

MVC Pattern and REST API Applied to GAE Applications

(This post is part of the series Web Application on Resources in the Cloud.)

I have been developing applications for various categories of end-users since 1990. I coded front-ends in X/Motif [1] for Solaris, then in Borland OWL and Windows MFC for Windows [2], then HTML/JavaScript for Web browsers. Most of the time for good reasons, JavaScript has been considered as a hacking language: to do quick and dirty fixes. Anyway, I have always been able to implement the MVC pattern:
  • My first enterprise Web applications was relying on a back-end written in C++ for a FastCGI run by Apache [3]. I wrote a HTML template language which, in some ways, was similar to the JSP concept [4].
  • The second version of this administrative console was relying on JavaScript for the rendering (a-la Dojo parser) and was using frames to keep context and to handle asynchronous communication.
  • Then I learned about XMLHttpRequest [5], and with a great team, I started building a JavaScript framework to be able to handle complex operations and screen organizations within an unique Web page. We came up with a large widget library and a custom set of data models.
  • After a job change, I discovered Dojo [6] in its early days (0.2 to 0.4) and I closely followed the path to get to 1.0. With Dojo, I am now able to relax client-side because the widget library is really huge, while still easy to extend, and it has advanced data binding capabilities. Now, I can focus on the middle-tier to build efficient REST APIs.
Among the design patterns [7], Model-View-Controller (MVC) is maybe one of the most complex (it is a combination of many basic patterns: Strategy, Composite, Observer) and maybe the one with the most various interpretations. I did write my own guidelines when I ported the MVC pattern browser-side (proprietary work). Today, Kris Zip blog entry on SitePen side summarizes nicely my approach: Client/Server Model on the Web. The following diagrams illustrate the strategy evolution.

   
Credits: SitePen.
In Google App Engine documentation, Django [8] is the template language proposed to separate the View building from the Model manipulation. Django implements the “Traditional Web Application” approach illustrated above.

My initial concern about the traditional approach is the absence of a clean and public API to control the Model. It is not rare that APIs are considered as add-ons, as optional features. IMHO, APIs should be among the first defined elements: it helps defining the scope of the work, it helps defining iterations (in the Agile development spirit), it helps writing tests up-front, it helps isolating bottlenecks.

With the move of the MVC pattern browser-side, the need to define a server-side API becomes obvious. The Model is now ubiquitous: interactive objects client-side have no direct interaction with the back-end server, they just interact with the Model proxy. This proxy can fetch data on demand, can pre-fetch data, forwards most of the update requests immediately but can delay or abort (to be replayed later) idempotent ones.

My favorite API template for the server-side logic is the RESTful API [9]. It is simple to implement, simple to mock, and simple to test. For my side project [10], the repository contains descriptions of products made available by micro entrepreneurs (see table 1).

Table 1: Samples of RESTful HTTP requests
Verb URL pattern Description
GET /API/products Return HTTP code 200 and the list of all products, or the list of the ones matching the specified criteria.
GET /API/products/{productId} Return HTTP code 301 with the versioned URL for the identified product, or HTTP code 404 if the identified product is not found.
GET /API/products/{productId}/{version} Return HTTP code 200 and the attributes of the identified product for the specified version, or HTTP code 301 "Move Permanently" with a URL containing the new version information, or HTTP code 404 if the product is not found.
DELETE /API/products/{productId}/{version} Return HTTP code 200 if the deletion is successful, or HTTP code 303 or 404 if needed.
POST /API/products Return HTTP code 201 if the creation is successful with the new product identifier and its version number.
PUT /API/products/{productId}/{version} Return HTTP code 200 if the update is successful with the new product version number, or HTTP codes 303 or 404 if needed.

HTTP CodeDescription
200OK
201Created
301Moved Permanently
303See Other
“The response to the request can be found under another URI using a GET method. When received in response to a PUT or POST, it should be assumed that the server has received the data and the redirect should be issued with a separate GET message.”
304Not Modified
307Temporary Redirect
400Bad Request
401Unauthorized
404Resource Not Found
410Gone
500Internal Server Error
501Not Implemented
Table 2: Partial list of HTTP status codes (see details in [11]).

Parsing RESTful API for Google App Engine application is not difficult. It is just a matter of using regular expressions in the app.yaml configuration file and in the corresponding Python script file.
application: prod-cons
version: 1
runtime: python
api_version: 1

handlers:
- url: /API/products.*
  script: py/products.py

- url: /html
  static_dir: html

- url: /.*
  static_files: html/redirect.html
  upload: html/redirect.html
Code 1: Excerpt of the app.yaml configuration file.
# -*- coding: utf-8 -*-

import os

from google.appengine.api import users
from google.appengine.ext import db
from google.appengine.ext import webapp
from google.appengine.ext.webapp import template
from google.appengine.ext.webapp.util import run_wsgi_app

from prodcons import common
from prodcons import model

class ProductList(webapp.RequestHandler):
    def get(self):
        # Get all products
        # ...
    def post(self, productId, version):
        # Create new product
        # ...

class Product(webapp.RequestHandler):
    def get(self, productId, version):
        # Get identified product
        # ...
    def delete(self, productId, version):
        # Delete identified product
        # ...
    def put(self, productId, version):
        # Update identified product
        # ...

application = webapp.WSGIApplication(
    [
        ('/API/products', ProductList),
        (r'^/API/products/(\w+)/(\d+)$', Product),
    ],
    debug=True
)

def main():
    # Global initializations
    # ...
    run_wsgi_app(application)

if __name__ == "__main__":
    main()
Code 2: Excerpt of the Python file processing product-related requests

Note that the second code sample shows an ideal situation. In reality, I had to change the verb PUT when updating product definitions because the method self.request.get() cannot extract information from the stream—it does only work for GET and POST verbs. The corresponding client-side code relies on dojo.xhrPost() instead of dojo.xhrPut(). If you know the fix or a work-around, do not hesitate to post a comment ;)

While developing application front-ends, developers should always rely on the MVC pattern to separate the data from user interface, to separate the data flows from the interaction processing. IMHO, organizing the server-side interface as a RESTful API is very clean and efficient. If you use Dojo to build your JavaScript application, you can even rely on their implementation of various RESTful data sources [12] to simplify your work.


Credits: SitePen

Pushing the MVC pattern browser-side has nasty side-effects when too much information are managed by the Model proxy:
  • Large data sets consume a lot of memory.
  • HTTP connections being a rare resource sometimes unreliable, rescheduling requests (important ones first, non important to be replayed later) or replaying requests (because Microsoft Internet Explorer status reports WSAETIMEDOUT for example) complexify the data flows.
  • Fine grain API consumes a lot of bandwidth especiallywhen the ratio data vs envelope is negative).
  • Applications have often too few entry points, hiding then the benefit of one URI per resource (intrinsic REST value).
  • In highly volatile environments, data synchronization become rapidly a bottleneck if there is no push channel.
So the application performance (response time and memory consumption) should be carefully monitored during the development. If applications with the MVC pattern organized browser-side and relying on RESTful APIs cannot do everything, they are definitively worth prototyping before starting the development of any enterprise application or application for high availability environments.

A+, Dom
--
Sources:

  1. Motif definition on wikipedia and online book introducing X/Motif programming.
  2. History of Borland Object Windows Library (OWL) on wikipedia and its positioning against Microsoft Foundation Class (MFC) library.
  3. FastCGI website, and its introduction on wikipedia.
  4. Presentation of the JavaServer Pages (JSP) technology on SUN website.
  5. History of XMLHttpRequest on wikipedia, and its specification on W3C website
  6. Dojo resources: introduction on wikipedia, Dojo Toolkit official website, Dojo Campus for tutorials and live demos, online documentation by Uxebu.
  7. Introduction of the Design Patterns on wikipedia and reference to the “Gang of Four” book (Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides). Specific presentation of the Model View Controller (MVC) pattern on wikipedia.
  8. Django : default template language available in Google App Engine development environment.
  9. Definition of the Representational State Transfer (REST) architecture on wikipedia.
  10. Future post will describe the nature of this project ;)
  11. HTTP status codes on wikipedia, and section 10 of the RFC2616 for the full status code list. Don't forget to look at the illustrations of the HTTP errors codes by the artist Adam "Ape Lad" Koford (license CC-by).
  12. RESTful JSON + Dojo Data by Kris Zyp, with details on the dojox.data.JsonRestStore introduced in Dojo 1.2.

Sunday, January 25, 2009

Automatic Testing of GAE Applications

(This post is part of the series Web Application on Resources in the Cloud.)

I am not a purist when it is time to apply a development method, I am a practical guy!

Update 2009/11/20
At one point, I switched to App Engine Java (see my post Google App Engine Meets Java). One of my argument at that time was the lack of tools Python-side to produce code coverage numbers... I've just posted a lengthy article about Unit tests, Mock objects, and App Engine for the Java back-end. The techniques and the code I share in this post allow me to reach the mystical 100% of code coverage, for a project with over 10,000 lines for the business code. See you there ;)

For example, I know by experience how important testing code as soon it is produced. And these tests must run after each code delivery to detect defects and regressions as soon as possible [1]. I allocate as much time to write tests (unit tests most of the time, functional tests occasionally) as I allocate to write code. And no task is considered complete if the corresponding tests do not cover 100%* of its code! I admire adopters of the Test Driven Development (TDD [2]) approach.

When searching information to test Google App Engine (GAE) applications, I was happy to find a post [3] written by Josh Cronemeyer who says:
My favorite way to start any project is by doing TDD. 
If you follow GAE tutorial [4], you can create a correctly designed application implementing the Model-View-Controller (MVC) pattern [5]. Testing such an application which organizes its behavior in different logical area means testing each areas independently:
  1. Testing Python models
  2. Testing Python business logic
  3. Testing data injection in Django templates
  4. Testing rendered HTML pages
  5. Verifying the use-cases' implementation
In the following sections, I am going to summarize information I gathered. If I missed any element, please, let me know by posting a comment ;)

Testing Python models

Verifying that your models work as expected is really important. If we can rely on the robustness of Google Big Database implementation (after all, more and more of their applications run on App Engine), you need at least to detect regressions that our future refactoring operations might introduce.

To learn how to setup your environment, read the detailed post of Josh Cronemeyer: Unit Test Your Google App Engine Models.
What follows is some information to get you started writing unit tests against a GAE model. First, a list of the tools you need to install.
  • Nose is a tool for running your python unit tests.
  • NoseGAE is a plugin for nose that bootstraps the GAE environment.
An alternative is to use gaeunit [6] but tests might impact the persistence layer.

Josh Cronemeyer suggests to create a new stub data store before running all tests (function called in your test setUp()):

from google.appengine.api import apiproxy_stub_map
from google.appengine.api import datastore_file_stub

def clear_datastore(self):
   # Use a fresh stub datastore.
   apiproxy_stub_map.apiproxy = apiproxy_stub_map.APIProxyStubMap()
   stub = datastore_file_stub.DatastoreFileStub('appid', '/dev/null', '/dev/null')
   apiproxy_stub_map.apiproxy.RegisterStub('datastore_v3', stub)

Testing Python business logic

What do I mean by Python business logic? This is the piece of code that deals with the end-user requests and that does some computations before pinging the persistence layer. For example, a function verifying the format of e-mail addresses (using regular expressions) belongs to that category.

This last 6 years, I have mainly used Java as the programming language to develop the server-side logic. Java is a simple and powerful programming language. Java benefits from big companies' support and has a large set of helper tools. As helpers, I can count: ant and maven, cruisecontrol and hudson, junit and code coverage, tools for static and dynamic code reviews, powerful IDEs, etc.

To developers starting to write unit tests with the target of covering 100% of the code, I have always suggested to read at least the chapter 7 of the book “JUnit in Action” [7], written by Vincent Massol. He introduces the Inversion Of Control (IOC) pattern and the Mock object concept:
Mock objects (or mocks for short) are perfectly suited for testing a portion of code logic in isolation from the rest of the code. Mocks replace the objects with which your methods under test collaborate, thus offering a layer of isolation. 
Python has also many frameworks to mock objects. Among them, Python Mocker seems to be very popular: it consists in recording behaviors and setting expectations on mock object, before letting them being used by real functions. See [9] for a detailed “how to use Mocker.”

Reminder: with the tip from Cronemeyer (see above with the stub for the data store, for more details look at [10]), there is no need to mock the data store.

Unit Test Sample in Python

The following piece of code defines utility methods which return 1) a list of supported languages and 2) a dictionary with localized labels (fallback on English one).

# -*- coding: utf-8 -*-

import en
import fr

def getLanguages():
    return {
        "en": en._getDictionary()["_language"],
        "fr": fr._getDictionary()["_language"],
    }

def getDictionary(locale):
    global dict
    if locale == "fr":
        dict = fr._getDictionary()
    else:
        dict = en._getDictionary()
    return dict

The series of tests in the following pieces of code verifies the list of languages contains at least English and French, verifies that the expected dictionaries contains the mandatory key with their name (“English” and “Français”), and that requiring an unexpected dictionary gives the English one.

# -*- coding: utf-8 -*-

import unittest
from prodcons.i18n import accessor

class SuccessFailError(unittest.TestCase):

    def test_getLanguages_I(self):
        """Verify at least 2 languages {en, fr} are in the dictionary"""
        self.assertTrue(len(accessor.getLanguages()) >= 2)
        self.assertEqual("English", accessor.getLanguages()["en"])
        self.assertEqual("Français", accessor.getLanguages()["fr"])

    def test_getDictionary_I(self):
        """Verify we can get a valid {en} dictionary"""
        self.assertTrue(accessor.getDictionary("en"))
        self.assertEqual("English", accessor.getDictionary("en")["_language"]) # Mandatory key

    def test_getDictionary_II(self):
        """Verify we can get a valid {fr} dictionary"""
        self.assertTrue(accessor.getDictionary("fr"))
        self.assertEqual("Français", accessor.getDictionary("fr")["_language"]) # Mandatory key

    def test_getDictionary_III(self):
        """Verify the fallback on the English dictionary"""
        self.assertTrue(accessor.getDictionary("no_NO"))
        self.assertEqual(accessor.getDictionary("en"), accessor.getDictionary("no_NO"))

Testing data injection in Django templates

Django comes with its own test runner! So its templates can be simulated in a stand alone mode.

With the help of Mocker [8], as described in [10], it is relatively easy to verify that your templates extract data as expected. If there is an unexpected data access to the Mock object, or if one attribute has been forgotten, the mock object will report it (a call to verify() ensure that all expectations were met.)

Testing rendered HTML pages

To verify that Django templates display the data as expected. Selenium [11] offers probably the best framework (and it's free):
  • Selenium IDE which runs as a Firefox extension and that can record, edit, and debug test scripts.
  • Selenium Remote Control (RC): it is a server that starts/stops browsers and that makes them running test scripts.
  • Selenium Grid: to control and run tests on remote Selenium RC instances (on WinXP, Win7, RedHat, Suse, etc.)
At that step, Selenium tests are considered being functional tests because they involve many parts of the application (do not work in isolation). It's fine to run them extensively in development environment, but should be carefully used in production (see next section).

The following presentation (3:30) shows how I write a test against my local deployment. The basic test ensure the language switcher works correctly:
  • Starting from the English homepage, it checks page title (in head>title and in div#title) against the label “Producer-Consumer”.
  • After having switched to the French page, it verifies that the URL has been updated correctly (no more lang=en, but lang=fr in place). It checks also the page title against “Producteur-Consommateur”.
  • After having switched back to the English page, it verifies the URL has been updated correctly.


Rapid definition of a test case with Selenium IDE.


Check points defined with Selenium IDE.


Verifying the use-cases' implementation

In Agile development, a sprint is a period of time allocated to complete development tasks. Each task or group of tasks implement a use-case, a story. Use-cases are used to validate the deliveries. Here is a simple story:
End-users fine-tune searches with the prefixes name:, producer:, and unit-price: 
At the beginning of a project, use cases are simple and can be covered by automatic tests. After a while, use cases become more complex and running them takes quite a long time and requires a heavy setup. These complex use cases are usually processed manually by human operators (Quality Engineers).

If these qualified workers can focus on complex use cases (all dumb ones are processed automatically), they have more possibility to find real bugs, I mean behaviors that coders forgot to cover, that product owners forgot to specify, etc. Sooner these bugs are discovered lower is their cost in terms of engineer time spent to fix them and in term of lost credibility!

I hope this helps!

Update 2009/01/30:
Josh, alias Shlomo, updated his post with an excellent reference of a discussion thread in Google App Engine group: Testing Recommendations. Look specifically at two messages posted by Andy about using Selenium tools, like this one:
Selenium-RC is not necessary since Selenium core can be added to your App Engine project directory and run from there. Collected steps below to save you time:
  1. Download the core: http://selenium-core.openqa.org/download.jsp
  2. Unzip selenium core zip file
  3. Copy this selenium core directory into your App path somewhere.
  4. Edit your app.yaml file to permit static access (static because it doesn't need a sever interpreter. selenium is written in javascript, so it runs in your browser.) Under "handlers:", add something like this:
    - url: /selenium
      static_dir: ./tests/SeleniumTests/selenium-core-0.8.3
static_dir is where I copied my selenium-core directory. To access selenium, I now open the app engine url, http://localhost:8080/selenium/index.html and run the TestRunner. From there, open your test suite and go. I had trouble loading individual tests for some reason, but suites work.

I could have of course done all of this using the Firefox Selenium-IDE plugin with fewer steps, but using the core approach does make it cross browser supporting.

I'm still trying to figure out how to use Python for this. I'll continue that in a separate message. 

A+, Dom
--
Note:
  • Providing 100% of code coverage by unit or functional tests is sometimes not possible. The test case shutting down remotely the application server to verify that pending transactions are persisted correctly cannot, for example, be scripted for automation. In such a situation, we should rely on manual testing. The goal of test automation is to provide the best coverage possible, so manual testers can focus on edge cases and on trying to discover unexpected issues.
--
Sources
  1. Agile: SCRUM is hype, but XP is as important... (another post to be published soon)
  2. Test Driven Development approach description on Wikipedia, and information on the book Test Driven Development by Kent Beck
  3. Unit Test Your Google App Engine Models by Josh Cronemeyer, and Josh's short bio from a speech he gave at OSCON in 2007.
  4. Google App Engine tutorial on Google Code.
  5. MVC Pattern applied to GAE Applications... (another post to be published soon)
  6. gaeunit is a test environment that runs on development environment (not on Google infrastructure).
  7. JUnit in Action, by Vincent Massol, edited by Manning Publications Co. Chapter 7, freely available, explains the IOC pattern and the benefits of using Mock objects. Vincent Massol is now technical lead of the open source project XWiki.
  8. Python Mocker: Mock object framework which allows to record behaviors and expectations before replaying them with real functions.
  9. Unit tests for Google App Engine apps, by App Engine Fan.
  10. Proper Unit Testing of App Engine/Django, by App Engine Guy
  11. The open-source framework for Web application automatic testing: Selenium IDE, Selenium RC, and Selenium Grid. Check the core features for information on the automating the tests -- See also a Japanese wiki on Selenium: JavaScud / Selenium IDE.

Wednesday, January 21, 2009

Book "Power of Surprise" by Andy Nulman

Because I read the announcement of Six Pixels of Separation "Surprise! Andy Nulman Is Giving Away Copies Of His New Book", a blog I have been following for a long time, I decided to give a try ;)
Hey Andy Nulman, here an address for another Montreal tech guy: 
7943, Duranceau, LaSalle (Qc) H8P 3R8.
Don't hesitate to post it yourself, Andy gives away 200 copies of his book! Check his blog powrightbetweentheeyes.typepad.com or his post on the offer. Don not forget to link www.andynulman.com for him to track you back ;)

Tuesday, January 13, 2009

Web Application on Resources in the Cloud

“What? Why? When? How?” are the four questions I am going to answer to introduce my first series of posts.
  • What? I am going to build a modern Web application using resources on the Cloud. Specifically, I am going to build an open Web application for consumers to find and review products in a big database, and for producers to offer products and find consumers. The infrastructure will use Google App Engine infrastructure [1].
  • Why? There are many aspects:
    • There is the professional benefit: In my post about Gary Reynolds' presentation “Career Advice '08” [2], or as posted by Tim O'Reilly in his post “Work on Stuff that Matters: First Principles” [3], it is mentioned that delivering value is a key differentiator. Building this working application will demonstrate my various expertise.
    • As an active member of Diku Dilenga [4] which delivers microloans to small enterprises in Democratic Republic of the Congo, I know that such application will help microentrepreneurs finding customers, and vice-versa. This project helps sharing my expertise with people who need help.
    • This project gives me also a chance to contribute to the open source community which has already given so much to me, my life, and my work.
  • When? I have already played with the Google App Engine SDK on my machine. I wanted to be sure no blocking issue would prevent me building the application. The application is already available at: http://prod-cons.appspot.com/
  • How? I am a Agile Methodology Adopter [5] so I do not plan far ahead. I am going to prepare a backlog with the tasks to implement, and I am going to address them according to their priority order. The code is regularly pushed on github [6]: http://github.com/DomDerrien/diku-dilenga/tree.
If you like the idea, if you want to learn new mechanisms, if you are OK with writing lots of unit tests, contact me. Because I am pretty busy at work, and I have to assume responsibilities for Diku Dilenga, the project will move slowly. But it will move and it will be fun!

Hints on the coming post in that series:
A+, Dom
--
Sources:
  1. Google App Engine website.
  2. My post on Career Advice '08 
  3. Tim O'Reilly post Work on Stuff that Matters: First Principles.
  4. Diku Dilenga website.
  5. Agile Manifesto, and Agile Methodology description on Wikipedia
  6. Github.com offers free hosting of open sources (charges applied to personal and commercial hosting).

Monday, January 5, 2009

2009 Products I Can't Leave Without

Today, I saw Michael Arrington blog post about his annual list of products he can't live without. As a TechCrunch reader, I read Michael list few times in the past and have been maintaining my own list of favorite applications. Because of the success of Michael's post and because I use different tools, I have decided to publish my list too!

Michael and I have different backgrounds: he is the founder and the editor of a popular technical site and I am just a developer ;) So do not compare lists.

Here is my list of applications, in alphabetical order, I used often. And to make it consistent with Michael's post, the list is followed by a comment for each tool.

2009
AllChars
Blogger
Dabbleboard
Dropbox
Eclipse
Firefox
FriendFeed (private room)
Gimp
Git
GMail
Google Calendar
Google Reader
Google Search
KeePass
LinkedIn
VirtualBox
YouTube and Google Video

AllChars
For programmers or English writers, keyboards with the US layout are just fine. If you use another layout, then it is a compromise between being able to generate specific characters and staying efficient. AllChars is a Windows tool that can generate any Unicode character with few key sequences (like Ctrl+e+e for €). It is fully customizable and support even macros.

Company:FLOSS
Website:allchars.zwolnet.com

Interesting post from Jeff Atwood: We Are Typist First, Programmers Second.

Blogger
This is the tool used to publish this blog. I have not invest enough time in customizing the page layout, but I know I can easily do it later and updates will be propagated to all posts. A good and efficient tool, IMHO.

Company:Google
Website:blogger.com
Launch Date:August 18, 2007

Blogger is a blog publishing platform formerly known as Pyra Labs before Google acquired it in February 2003. Blogger blogs are mostly hosted internally with the “dot Blogspot” domain but they can also be hosted externally on a user’s own server.

Blogger provides bloggers with a WYSIWYG editor that allows them to drag-and-drop widgets, change fonts and edit page elements. Also, Feedburner’s feed management tools are tightly integrated with Blogger blogs due to Google’s recent acquisition.
Credits: CrunchBase

Dabbleboard
DabbleBoard is a tool I blogged about in a post about Effective Communication principles.

Company:Dabbleboard Inc
Website:dabbleboard.com

Dropbox
Dropbox is a composed of plugins to install on your machines (Windows and MacOS) and a website which host your virtual folders. It is a silent tool, working smoothly, and synchronizing folders in background. I use it in conjunction with KeePass to backup my sensitive information.

Company:Plum
Website:getdropbox.com

Eclipse
For an early adopter of IntelliJ IDEA by JetBrains, I had to use Eclipse (company's tool when working with IBM Rational, cheap when working with Compuware). I should recognize that it is going better and better (especially with the refactoring features and the JavaScript support) and it has more plugins than IntelliJ. It is also a platform for OSGi and for Rich Applications.

Company:FLOSS
Website:eclipse.org

Firefox
Having been a Web application developer for a long time, I adopted Firefox (then know as Firebird) in 2003. With the introduction of the Firebug extension (in 2005), it became with primary browser and it had never lost this status. Its early integration of Google search was also a serious advantage. These days, with the faviconize extension and Firefox ability to start with the previous configuration, my browser always starts with: iGoogle, GMail, Google Calendar.

Company:Mozilla
Website:getfirefox.com
Launch Date:November 9, 2004

In February 2008 Mozilla announced that they had reached 500 million downloads of Firefox, and 150 million active users.
Credits: CrunchBase

FriendFeed
I started to use FriendFeed at its early stages, mainly because it offered the possibility to share information from Web page I can visit randomly. Because few months after its introduction, Google Reader added the Share with note function, I stopped using FriendFeed... until recently when I have invited to a private room: this is a pretty nice service for offline chats. It is not as heavy as e-mails and not as disruptive as instant messages.

Company:FriendFeed
Website:friendfeed.com
Launch Date:October 1, 2007

In February 2008 Mozilla announced that they had reached 500 million downloads of Firefox, and 150 million active users.
Credits: CrunchBase

Gimp
I never the budget and training for Adobe Photoshop. So I started using Gimp. If you can pass over its weird interface (too many windows, IMO), Gimp offer tons of features for Web application developers: to adjust pictures, to generate textures, to resize images, etc. And there are plenty of free tutorials on the Web.

Company:FLOSS
Website:gimp.org

My favorite video series on Photoshop, starting with the first episode: You Suck at Photoshop #1: Distort, Warp, & Layer Effects.

Git As a developer, I always want to put my code into a source control system. It is not just because I am afraid that my laptop crashes, then wasting hours of work. It is mainly because I want to keep track of the update history. At work, over the years, I used ClearCase, CVS, and Subversion. For my personal development, I used Subversion a lot and now I use Git.

Company:FLOSS
Website:git-scm.com

Free hosting service of open-sources Github - Charges applied for private hostings.

GMail When I started working, I dealt with many machines and I hated having to start one just to look at a specific inbox. With GMail, my account is available anywhere. When I read Turn Gmail Into Your Personal Nerve Center, I started to use GMail as my knowledge database.

Company:Google
Website:gmail.com
Launch Date:April 1, 2004

Gmail, also known as Google Mail, is a free email service with innovative features like “conversation view” email threads, search-oriented interface and plenty of free storage (almost 7GB). Gmail opened in private beta mode in April 2004 by invite only. At first, invites were hard to come by and were spotted up for sell on auction sites like eBay. The email service is now open to everyone and is part of Google Apps. Paul Buchheit, an early employee at Google, is given credit for building the product.

Another Gmail feature is the organization, tracking and recording users’ contact lists. For instance, if you start typing the letter C into the “To” field Gmail will bring up a list of every email address and contact name starting with the letter. This feature helps when you can’t quite remember a name. Plus, Gmail automatically adds and updates email addresses and names to your contact list when you write emails.
Credits: CrunchBase

Google Calendar My first job in Montréal, Canada, was with a small company named Steltor (bought few years later by Oracle). The core business was the development of a distributed calendar system (servers in cluster, native clients, web client, mobile client, etc.). Since then, I am used to tracking my work with an electronic calendar. Google Calendar and its ability to mix many agendas is excellent.

Company:Google
Website:google.com/calendar
Launch Date:August 21, 2007

Google Calendar lets users create events, manage multiple calendars and share calendars with teams and groups. Users can view their calendar by day, week or month. Calendar has a “Quick Add”� feature that lets you input natural language entries fast. For instance, you can type “Dinner with Michael 7pm tomorrow” into the entry box and Calendar will add “Dinner with Michael” into tomorrow’s agenda at 7pm without needing a specific date. Calendar can also be set-up to send you SMS or email alerts for upcoming calendar entries.
Credits: CrunchBase

Google Reader In the old day, reading blogs was time consuming and annoying because of the ad banners. With the introduction of Google Reader, reading them from one central place while just using keystrokes was a pleasure. With the introduction of the Share this feature, I became to be a media myself. The Share with note function is an quite recent addition that allows me to point posts that are more important to me.

Company:Google
Website:google.com/reader
Launch Date:October 1, 2005

Google Reader is an online RSS feed reader.
Credits: CrunchBase

Google Search Google Search is an amazing tool: recently, I was trying to find a solution to a tough technical problem and I found it thanks to Google Search which pointed toward a blog post written the same day, just few hours before, in Europe! Incredible... When I give a conference into universities, I often say: “If I asked a question today and you have no clue about the response, that's fine. If you still have no clue tomorrow, you're in trouble...”

Company:Google
Website:google.com
Launch Date:September 4, 1998

Search is Google’s core product and is what got them an official transitive verb addition to the Merriam Webster for “google”. The product is known for its Internet-crawling Googlebots and its PageRank algorithm influenced heavily by linking.

When users type keywords into the home page search box they are returned with relevant results that they can further refine. Google also has more specific search for blogs, images, news and video. Google will also return search results from your own computer files and emails via Google Desktop.
Credits: CrunchBase

KeePass KeePass is an open source Password Safe. I use it in conjunction with Dropbox. Much usable that PGP/GPG in the sense I don't have to save the decrypted file and then being at risk if I forget to wipe this copy from disk.

Company:FLOSS
Website:keepass.info

LinkedIn I started using LinkedIn when a wonderful team I worked with at Oracle exploded because of stupid political decision. Then some friends left to go with Google, one colleague went to Adobe, etc., and LinkedIn was the tool to stay connected. Since then, LinkedIn allowed to get many job propositions, like Compuware's one I accepted. I have been also able to retrieve friends I had in France, even one I may engage a partnership with.

Company:LinkedIn
Website:linkedin.com
Launch Date:May, 2003

LinkedIn is a free business social networking site that allows users who register to create a professional profile visible to others. Through the site, individuals can then maintain a list of known business contacts, known as Connections. LinkedIn users can also invite anyone to join their list of connections. LinkedIn offers an effective way by which people can develop an extensive list of contacts, as your network consists of your own connections, your connections’ connections (2nd degree connections), as well as your 2nd degree’s connections (called your 3rd degree connections). From this network, individuals can learn of and search for jobs, business opportunities, and people. LinkedIn also serves as an effective medium by which both employers and job seekers can review listed professional information about one another. LinkedIn follows strict privacy guidelines wherein all connections made are mutually confirmed and individuals only appear in the LinkedIn network with their explicit consent. Other LinkedIn features include paid accounts that offer more tools to find people, and “LinkedIn Answers” developed in January 2007. A free feature, “LinkedIn Answers” allows registered users to post business-related questions that anyone else can answer.
Credits: CrunchBase

VirtualBox Developing software requires sometimes specific configurations. Testing them requires always specific configurations (at least to replay always the same test cases every time the source control system, like Git, is updated). There are the famous VMWare products (Workstation, Player, ESX) and Microsoft VirtualPC. VirtualBox is an open source product provided by SUN Microsystems, and it has nice features while being powerful.

Company:Sun Microsystems
Website:virtualbox.org

VirtualBox is a family of powerful x86 virtualization products for enterprise as well as home use. Not only is VirtualBox an extremely feature rich, high performance product for enterprise customers, it is also the only professional solution that is freely available as Open Source Software under the terms of the GNU General Public License (GPL).

Presently, VirtualBox runs on Windows, Linux, Macintosh and OpenSolaris hosts and supports a large number of guest operating systems including but not limited to Windows (NT 4.0, 2000, XP, Server 2003, Vista), DOS/Windows 3.x, Linux (2.4 and 2.6), Solaris and OpenSolaris, and OpenBSD.

YouTube and Google Video YouTube is famous because of fun videos. But it also hosts technical videos.

Company:Youtube
Website:youtube.com
Launch Date:December 11, 2005

YouTube was founded in 2005 by Chad Hurley, Steve Chen and Jawed Karim, who were all early employees of PayPal. YouTube is the leader in online video, sharing original videos worldwide through a Web experience. YouTube allows people to easily upload and share video clips across the Internet through websites, mobile devices, blogs, and email.

Everyone can watch videos on YouTube. People can see first-hand accounts of current events, find videos about their hobbies and interests, and discover the quirky and unusual. As more people capture special moments on video, YouTube is empowering them to become the broadcasters of tomorrow.

In November 2006, within a year of its launch, YouTube was purchased by Google Inc. in one of the most talked-about acquisitions to date.
Credits: CrunchBase

I hope it helps,
A+, Dom

Sunday, December 28, 2008

Career Advice '08

In my previous post, I wrote mostly about how managers should deal with their subordinates. I think most of the time the real work is achieved by regular employees and the delivered quality depends on how the management support the do-ers.

At the same time, having subordinates just doing their job and waiting for their management to come with all solutions is not realistic. I was trying to organize a post on how subordinates should differentiate themselves from the mass when I came across this presentation (thank you Steven[1]): it's a presentation by Gary Reynolds about Dave Pink's bool “Six Career Lessons”.


Career Advice '08
View SlideShare presentation or Upload your own. (tags: presentation pink)


The slide 174 summarizes the six lessons:


Slide 174 from Gary Reynolds' presentation.


Being a technician in a domain with a fantastic innovation trend, I have to emphasize on lessons 2 to 4:
Go beyond being just good at something: become an expert! For example, you can be a proficient developer, push to cover everything you produce with unit tests: you will be able to prove that your production is rock solid. If you know many natural languages, develop easily localizable applications (we produce for a global market).

Work to maintain the excellency of your expertise! Most companies do not let employees thinking freely during the regular hour - to my knowledge, only Google clearly allows it [2]. So you will have to invest your personal time to stay up-to-date.

Share your expertise! Your expertise is useless without you sharing it. Sharing it does not expose you dangerously because potential thieves will not have your experience and because they will not stay up-to-date. In reverse, sharing it will expose you to valuable experiences and feedback from your audience, adding up to your existing sources of information. 
These days, there are so many ways to build and share an expertise:
  • Write an insightful blog;
  • Participate to an open-source project;
  • Publish technical articles (developerWorks [3], MSDN [4], OTN [5], etc.);
  • Speak to conferences (require a lot of energy and often a lot of money);
  • Build a successful project which delivers values to your customers!
Everyone should make his own path, whatever the environment is. If conditions are too tough (because the management is not supportive, for example), look for another place. If they are not so bad, find any occasion to build your expertise and grow yourself ;)

Happy new year 2009!

Update:
Tim O'Reilly, on O'Reilly Radar blog, has published a post aligned with my position. Here is principles:
  1. Work on something that matters to you more than money.
  2. Create more value than you capture.
  3. Take the long view.
What? You haven't started demonstrating your value? Just kidding...

Second update:
Tim O'Reilly has been interviewed on the top Work On Stuff That Matters.


The video is on mutliple parts. Check O'Reilly radar webiste for additional parts.

A+, Dom
--
Sources:
  1. Steven Milstein's blog
  2. Google Jobs: Work Environment: 20% project concept
  3. IBM developerWorks
  4. Microsoft Developer Network
  5. Oracle Technology Network
  6. Tim O'Reilly post on Work on Stuff that Matters: First Principles

Wednesday, December 10, 2008

Manager Attitude

A long time ago, I read the famous Joel Spolsky [1] entries on management:
As an experienced worker, I know my limits: for example, I do not think I will be a good typical manager... With my expertise based on emerging technologies (read “Web 2.0+” and “mobile”), I lost sometimes my patience while trying to explain new concepts or convince conservative or ignorant people. When it is time to deal with personal problems of your subordinates, I really think that such attitudes are absolutely unacceptable.

Despite this fear, I really like mentoring people. I can focus on transferring knowledge (what is the point of being an expert if you do not share your knowledge?) without having to deal with risky personal situations! I act as a mentor in different situations:
  • With new employees and interns: to teach them the best practices (efficiency is not that important at the beginning), to have them fully understanding the requirements before thinking about implementation details (to avoid the risk of delivering something that does not match the requirements), etc.
  • With experienced developers having a different technical background: to identify their strengths and to make them more productive (better designer, delivering high quality code, documenting their production, more agile).
  • And with managers for reasons I am going to developed below.
I have been introduced to the formal process of pairing mentors and mentees while working for IBM Rational. I would say that IBM has the best personal development program I have ever seen. And the mentorship is a corner stone of that program. This was the first time I had a formal mentor (Arthur Ryman, IBM Distinguished Engineer [2, 3]). Because it was a successful experience, I started then to become a mentor myself.

Usually, implementers (or do-ers, or pigs [4, 5]) are receptive to suggestions. Managers (or chickens [4,5]) are much less willing to listen. In my experience, I met many people that followed the path governed by the Peter Principle [6]. Usually, the only way to get promoted is to become a manager; very few people start their career as managers. Promoted managers often lack of training, and they mostly following the pattern managers have serve to them.

What is the big difference among managers and regular employees? The first ones have been empowered to take decisions and the second ones usually follow orders. Many managers I worked and I work with have a technical expertise reversely proportional to their management experience. And they have most of the time a better salary than their reports.

Managers have many responsibilities, and there is one that is often incompletely assumed: ensure their reports can deliver their best.
  • I find dangerous when decisions are taken without having the big picture. Some managers follow Joel Spolsky's advice and delegate the decision instrumentation.
  • At the same way, managers should delegate, I think reports should be able to do the same. For example, a developer needing a second hard drive to host big virtual machines should be able to go to his manager, to expose his requirement, and then go back working while the manager fills up the purchase request. How many times have you seen such a situation? Personally too rarely, and just from junior managers who had still fresh in mind some past frustrations. Most of the time, managers think their time is too expensive for such basic tasks and they prefer wasting the time of their smart reports.
  • A good manager should delegate to their reports and accept delegation from their reports. Each aspect of the delegation makes the reports more motivated and then producing a better job. I think benefits gained by applying only one delegation aspect are easily compensated by the frustration generated the non application of the other aspect.
For the fun of it, and because I endorsed most of lessons described in the article 14 Things Corporations Can Learn from Seasoned Web Workers, I sent it to many managers (development managers, human resources manager, product managers, etc.). Was it because they are “control freaks”, because they are going to lost their power, because they cannot do basic things anymore for others (especially for reports), but none came back saying: “Good article. Let's see what we can make happening.”

This conclusion is another argument why I do not want to be another manager. Hopefully, my current expertise allows me to focus on technical works, to be just a mentor, to give advice and to accept suggestions in return, and to stay on the implementers' side where true collaboration is common.

A+, Dom
--
Sources:
  1. Joel on Software blog by Joel Spolsky
  2. Arthur Ryman's profile on eclipse.org
  3. Eclipse Web Tool Plateform: book co-authored by Arthur Ryman.
  4. Chickens and pigs in situation by Nick Malik
  5. Chicken and pig roles in SCRUM context on wikipedia
  6. Description of the Peter Principle on wikipedia -- read the part on Dilbert Principle ;)

Tuesday, November 4, 2008

Nov. 4: Election Day in USA

It is not really possible to ignore today's race when the winner will become the 44th President of United States of America. In Canada, we are accustomed to being tightly influenced by American affairs. But this time, I think a lot of people around the world are waiting for these election results.

There are lots of information sources available out there, but the sources I like to use are the ones where you can drill down to see the details. In that sense, I really like the maps provided by Google with data from Associated Press [1] and displayed below.


Mashup from Google [1]


Update:
Ouf! Winning the White House is one thing (~350 EV on 538). Winning with popular votes is another one. Hopefully: 52% Obama / 46% McCain! I hope our so influential neighbors will reconsolidate to fix issues in their own country that have nasty side-effects on the rest of the world.

A+, Dom
--
Sources:
  1. http://maps.google.com/help/maps/elections/#2008_election

Saturday, October 4, 2008

Effective communication

To assume an IT Architect role, a candidate must have very good communication skills besides his excellent technical skills. IBM proposes the role of IT Specialist to domain experts having weak communication skills. What type of communication skills?
  • Communicating with Product Managers (PMs) and Business Analysts (BAs) to transform requirements and priorities into architectures and development plans.
  • Communicating with Development teams and Quality Assurance (QA) teams to lead technically the development phases, the continuous quality verification, and the incremental deliveries (alpha, beta, release candidate (RC), release to manufacturer (RTM), fix pack, minor revision, major revision, etc.).
  • Communicating with Executives (execs) to report issues and progresses of ongoing projects, to propose plans consolidating the company mission, to align the company capabilities with the strategic direction.
As a senior developer, dealing with the rest of the development team and with QA people in agile environments helped me to communicate efficiently with my peers.

Later, when I assumed the position of IT Architect in the team developing the Web 2.0 front-end of the Rational Portfolio Manager product1, I acquired a good experience in communicating with PMs and BAs. I especially liked translating business requirements in technological plans. It's really interesting connecting the dots (the devil is in the details).

Now, thanks to my position within Compuware Corp., I have the chance to get in touch with execs and I need to polish my skills there! Most of messages sent to execs should be short:
  • One line to introduce and to get their attention;
  • Few bullet points if there are many actions expected or proposed;
  • Formula of politeness, signature, and phone number.
Due to the amount of solicitation messages they receive, execs pass through their messages quickly. Their attention should be caught immediately in order to have them taking an action. Being brief and dense is usually a good recipe.

Presenting to execs should follow an equivalent pattern: keep it short, be dense, be prepared to any question, propose the next steps if you obtain their blessing. When I have to propose a solution (to fix a problem or to describe a new concept), I like to rely on a few pictures to introduce it. There is usually one picture for the “current” situation and a second one for the “proposed” solution. I found that these pictures really help people to get the essence of the presentation very quickly, sometimes more than 5 or 10 slides with just bullet points would do. I usually have such slides after the pictures, but they are optional and they describe specific points answering possible specific questions. The following image gives an example of my approach2.




By Dan Choam for Guy Kawasaki

Update:

My friend Tugdual Grall has posted an article [4] about tools he uses to build quickly UI mockups, for example. I want to mention that I use DabbleBoard [5] to convert my drawings in electronic formats! This is a simple online tool, written in Flex, which listens to mouse movea to decide which shape should be included. Really neat tool!

A+, Dom
--
Sources:
  1. Inside and outlook series of articles from various IBM IT Architects (especially Kerry Holley, IBM fellow, in the 8th issue).
  2. The Visual Art by Guy Kawasaki, from a discussion with Dan Roam, author of the book The Back of the Napkin: Solving Problems and Selling Ideas with Pictures.
  3. Excutive Presentation Tips by Luke Wroblewsky (aka. LukeW), Senior Director of Product Ideation & Design at Yahoo! Inc. and author of the blog Functioning Form.
  4. DabbleBoard and Balsamiq introduction by Tugdual Grall.
  5. DabbleBoard website.
    Notes:
    1. Rational Portfolio Manager is a product in maintenance mode. I joined the team after the development of RPM TeamMember has started (delivered in version 7.1) and helped fixing issues up to the 7.1.1.2 release.
    2. At the time of writing, I do not have picture I can not share any of mine yet :(