Almost three months without publishing anything! I am definitively not proud of this score...
I have been busy on three fronts:
At work, I continue working on mobile related development. The easiest platform to play with is the Android one (see my post on Android Dev Phone 1) and I thrilled to see new handsets being made available, like the HTC Dream and Motorola Cliq, with their respective HTC Sense and Moto BLUR custom UIs (see videos below). Even if its SDK is not as rich as Android's one, even if the gadgets are not as polished as Android's ones, I also like developing for BlackBerry phones, like the BlackBerry Storm.
For my side project, running on Google App Engine infrastructure, it is progressing very well. Today, I reached a milestone: the first part of [still a secret] runs live. In terms of coding, it represents ~6,000 lines for the source files and ~12,000 lines for the test. I have always considered source vs test as being 50-50; it seems I should re-evaluate the balance to 1/3-2/3 ;)
Thanks to different contributors, I have developed a series of mock classes allowing to test transactions with BigTable, the database used by App Engine. A really neat piece of code I am going to describe here later.
On the social side, I am working with the board of Diku Dilenga Canada (board I am member of) to move as its Executive Director (still as a volunteer). The move has been inspired by Jean-Pierre Tchang, founder of IRIS Mundial. I hope this update will make Diku Dilenga (Canada) as successful as IRIS Mundial.
The plan to link the [still a secret] project with Diku Dilenga activities have been formally approved by the board during the summer. This side, there is a possibility I will do a presentation to the 2010 Africa/Middle East Regional Microcredit Summit (AMERMS) to be held in Nairobi, Kenya April 7-10, 2010. It would be nice to participate, isn't it?
Stay tuned, I should be back in few days with technical information about unit testing transactional code on Google App Engine ;)
A+, Dom
--
Videos:
HTC Hero, the first phone with the HTC Sense, a customized UI scheme on the top of Android.
Motorola Cliq, the first phone with Moto BLUR, a customized UI scheme on the top of Android.
BlackBerry Storm, first BlackBerry phone with a touch screen
Look at all efforts around JavaME and the MSA initiative.
JavaFX technology stack
Eric Klein, Vice President, Java Marketing, Sun Microsystems
I came without preconceived idea around JavaFX, just with my background as a JavaScript/Java developer and my knowledge of Flex and AIR.
The first deception came from looking at the scripting language: Man! they invented yet another language :( For sure, the JavaFX scripting language is nicely handled by NetBeans 6.5+ (except the code formatting) but new paradigms and new conventions are a big barrier to adoption to me. Can you figure out what the following code is doing?
public class Button extends CustomNode {
public var up: Node;
content: Node = up;
public override function create(): Node {
return Group {
content: bind content
}
}
If the visual effects to animate texts, pictures, and video are really great, the native support of a sound library is really missing! For example, I would expect to be able to synchronize KeyFrame objects with sound tracks but the KeyFrame.time attribute has to be set manually—not very flexible when it's time to change the sound track...
The pros are:
A coming visual editor to prepare clips;
A large library of image and video effects;
The multi-platform support, especially for mobile devices.
Platform dependent packaging is nicely handled: NetBeans project properties pane provides choices among {Standard Execution, Web Start Execution, Run in Browser, Run in Mobile Emulator}. As a Web developer, I am just sorry to see that the application window size cannot be expressed in percentage, that the auto-resizing is handled transparently, which is not better than usual Flex applications.
Last point: I have not seen how to invoke JavaFX handlers from JavaScript ones, and vice-versa, when the application is deployed to run in browsers. If you have a source for these information, please, drop the link in a comment.
JavaME technology stack
Christopher David, Rikko Sakaguchi and Patrik Olsson
during Sony Ericsson General Session
This was definitively the most interesting domain to me. During one session, it has been announced that 60% of shipped mobile devices in 2008 are Java-enabled. In 2009, the market share should grow up to 70%. In relation with the iPhone, Scott McNeally did this joke: the possible future Sun owner Larry Ellison might succeed to open the iPhone platform to Java because he is a well known friend of Steve Jobs.
Compared to the Java Standard Edition (J2SE) and the Java Enterprise Edition (J2EE), the Java Mobile Edition (J2ME) has more external contributors. Under the Mobile Service Architecture (MSA) initiative, a lot of mobile device manufacturers and telecommunication operators participate to the Java Community Process (JCP) to deliver Java Specification Requests (JSRs). Note that MSA itself is defined as a JSR: JSR 248. As of today, most of the recent phones are MSA 1.1 compliant (this is a mandatory requirement for the telco Orange, for example). Nokia and Sony Ericsson have shipped a lot of MSA-compliant handsets, LG, Samsung, and Motorola shipped very few ones. The standard MSA 2 (JSR 249) is being finalized and it contains the promising JSRs:
All major manufacturers have opened or are opening "App Stores" a-la Apple. They open also their development platforms. More companies will be able to adapt their software offering to mobile devices. Even Sony allows anyone to write application to run in Blu-ray Disc players. The main difficulty on developer-side is the fragmentation: there is no standard API allowing to discover the features supported by a device! Developers have to rely on each manufacgturer's feature list and on exception handling :(
The Blackberry platform is pretty well controlled and should be easy to develop on. Then follows Sony Ericsson which provides consistent phone classes (i.e. what works for one phone in the JP 8.4 class work for all phones in that class). The delivery of the Sun JavaME SDK 3.0 containing many third-party emulators (even one for Windows Mobile devices) added to better on-device deployment and on-device debugging capabilities, should motivate more and more developers.
I have not enough experience with Android (just got one Android dev phone two weeks ago) to compare it to the JavaME technology stack. I don't know neither about Symbian (Nokia devices) or LiMo (Motorola devices) platforms.
Exhibition hall
Besides the visit of mobile device manufacturers (RIM and Ericsson) booths, I visited:
Sun's project Fuji (open ESB) with a Web console using <canvas/> from HTML5, like Yahoo! Pipes.
Convergence, the Web client for Sun's communication suite, built on the top of Dojo toolkit ;)
INRIA (French national R&D lab) for its static code analysis Nit.
I want also to mention the call to developers by MifOS people who have been awarded by James Gosling during the Friday morning general session. This organization develops open source software for microfinance institutions (MFIs) to help them managing loans and borrowers (see demo). Really nice initiative started by the Grameem Bank!
Gosling next introduced a group whose great innovation with Java technology was social and not technical. Sam Birney, engineering manager and Mifos alumnus, and Van Mittal-Hankle, senior software engineer at the Grameen Foundation, took the stage to receive Duke's Choice awards for their work using Java EE to serve 60,000 clients worldwide in microfinancing, a highly successful means of helping poor people get small loans and start businesses.
Mifos is open-source technology for microfinance that is spearheaded by the Grameen Foundation.
"Sometimes excellence comes not from technical innovation but in how technology is used," explained Gosling. "This is an example of using Java technology to really improve people's lives."
With an estimated 1.6 billion people left in the world who could benefit from microfinance, the men put out a call for volunteers to contribute to the Mifos project..
What's next?
What are my resolutions? Get a Mac as the development platform (Eclipse works on MacOS and I can use a Win7 image within VirtualBox), and start development on Java enabled phone (at least MSA 1.1 compliant).
In my experience, internationalizing an application is very expensive if it is not planned upfront.
The first source of costs is due to developers who are used to lazily hard-coding labels. Extracting them at the end of the development process is always error prone because developers may have done assumptions on exact labels. Good regression test suites can help detecting such situations but they cannot avoid the cost of the required fix and its corresponding test runs. With late label extraction, developers without enough context tend to add extra dictionary entries. With the label extraction near the release milestone, developers in a rush and without the initial context tend also to produce non documented dictionaries—that is limit their re-usability and increase the difficulty of possible defect fixings.
Non localized Java code
protected String formulatePageIndex(int index, int total) {
String out = "Page " + index;
if(0 < total) {
out += " of " + total;
}
return out;
}
In the example above, I have seen the extraction of the labels Page and of instead of Page %0 and Page %0 of %1. The quick extraction leads to the impossibility to invert the two arguments! Think about the people naming conventions: in many countries, the last name is displayed before the first name, in others the first name precedes the last name (%last %first compared to %first %last), and in Japan both names are printed without separator in between (%last%first).
Localized Java code
protected String formulatePageIndex(int index, int total) {
// Get the resource bundle already initialized for the correct locale
ResourceBundle rb = getCurrentResourceBundle();
// Prepare values
Object[] values = Object[] {Integer.valueOf(index), Integer.valueOf(total)};
// Get the right localized label
String label = rb.getString("PageIndexLabel_Page");
if(0 < total) {
label = rb.getString("PageIndexLabel_PageOf");
}
// Return the localized label with injected values
return Message.format(label, values);
}
The second source of costs is due to the missed opportunities of deploying localized builds early in the development process. In Agile environments, we expect to get runnable builds on regular basis (at the end of each sprints, each 4 to 6 weeks, for example). And these fool-proof builds can be demoed to customers to get early feedback. If the development organization can work with translators iteratively, there are a lot of chance to detect localization defects while their fixing cost is not too high. In the past, I have seen product developments hugely hit when bi-directional languages (like Arabic and Hebrew) had been introduced...
Different aspects of the internationalization
Internationalization (i18n) [1] has two aspects:
The translation of the labels;
The localization (l10n) of these labels.
The localization takes into account the language and the country, sometimes with variants in a country. For example, the Spanish language spoken 19 identified countries. In Mexico (ES_MX), the language is slightly different from the one generally spoken in Spain (ES or ES_ES). In Spain, there are many regional languages like the Catalan (CA_ES). The different locales are normalized by the Unicode consortium (ISO-639 and ISO-3166). Codes are composed of a sequence of two letters for the language plus two letters for the country plus two letters for the region. If letters are missing after the language, most of programming languages fallback on common defaults.
In order to ease application localizations, Unicode references a Common Locale Data Repository (CLDR) [2]. This repository is used and updated by many companies like IBM, Sun, Microsoft, Oracle, etc. The repository describes rules on how to:
As of today, I think only timezone definitions are still not centrally managed... This is especially bad because conversions between Universal Time (UTC) dates and local dates are operating system dependent (Sun Solaris have small differences with Microsoft Windows, for example). Many tools use the Unicode CDLR information. For example, each release of the Dojo toolkit use its information to provide the Calendar widget for 27 locales [3].
Internationalization with different programming languages
Almost all programming languages have ways to facilitate application globalization. Java provide resource bundles (*.properties file), Microsoft .Net has resource files (.rc files), Python has dictionaries, etc. If JavaScript lacks of native support for globalization, some libraries offer various support. To my knowledge, Dojo toolkit is the first providing a full support.
If developing an application on Google App Engine infrastructure can be done with only one programming language, Python or Java as this time of writing, it is highly possible that developers will use some JavaScript libraries to speed up their development. This is without counting the delivery of a similar program front-end as a native application (made with Adobe AIR, Microsoft .Net, C/C++, Groovy, etc.).
In different situations, I have seen developers moving manually label definitions from one environment to another one. Sometimes, definitions were left over, cluttering the system. In Agile environments, developers should focus on the requirements for the current sprint, leaving some tuning for later sprints. For example, at one point during the development, some labels defined in a JavaScript bundle might be moved to a Java bundle because the localization will be done server-side into a JSP file.
My solution is to put all labels in one localized central repository. The dispatch among the different programming languages is done at build time. When I looked for this repository format, my solution was selected against the following criteria:
Easily editable;
Has a standard format;
Usable by static validation processes;
Has excellent re-usability factors;
Easily extensible to new programming languages.
I chose the TMX format (TMX for Translation Memory eXchange [4]). This is an XML based format (good for edition, extensibility, and use by static validation tools) which has been defined to allow translation memory export/import between different translation tools like DejaVu. The XlDiff format would have been another good candidate.
The following table illustrates the flow of interactions between the different actors in a development team. This sequence diagram shows that, once the developers have delivered a first TMX file, testers and translators can work independently to push tested and localized builds to the customer. As explained later, if developers tune the TMX entries without updating the labels themselves, translators and testers (at least from the l10n point-of-view) can stay out of the loop—only steps [1, 7, 8] are replayed.
Simplified view of the overall interaction flow
Developers
Testers
Translators
Build process
End-users
1. Write labels in one language into the TMX file. These labels are extracted from design documents.
2. Generate the application with for one locale.
3. Produce a generic bundle to identify non extracted labels.
4. Generate the application with for two locales.
5. Use the application in one locale (switching to the test language is hidden).
6. Use the initial TMX to produce n localized TMXs.
7. Generate the application with for 2 + n locales.
8. Can use the application in 1 + n locales.
The following code snippet shows how an entry into the base TMX file is defined.
Snippet of a translation unit definition for a TMX formatted file
<tu tuid="entry identifier" datatype="Text">
<tuv xml:lang="locale identifier">
<seg>localized content</seg>
</tuv>
<note>contextual information on the entry and relations with other entries</note>
<prop type="x-tier">dojotk</prop>
<prop type="x-tier">javarb</prop>
</tu>
The key features of the TMX format are:
The format can be validated with an external XSD (XML Schema Description);
One entry (tu: translation unit) can contain many localized contents (tuv: translation unit value);
Developers have a normalized placeholder (<note/>) to register contextual information;
Extensions are used by the build process to target the type of resource bundle to receive the localized label.
With such an approach, I have seen a drastic reduction of translation mistakes, especially thanks to the <note.> tag. Sometimes, graphical elements contain inter-related labels that cannot be grouped under a generic entity. The following set of elements illustrates the situation. The TMX approach saves translators headaches because they are simply informed about the relation between four entities.
The conversion from the TMX to the various resource bundles is done by an XSL-Transform. With the continuous integration handled by ant, the corresponding task generates the output after having appended the XSLT file coordinates to a copy of the TMX file and after asked for the transformation with the corresponding <xsl/> ant task. Depending on the machine performance, depending on the TMX file size, I found that the process can be time consuming. If this is your case too, I suggest you write your own little Java program to handle it. You can also use mine ;)
Stylesheet transforming label definitions for the Dojo toolkit
To start investigations on mobile application development for Compuware, I have just acquired a first Android Dev Phone, also known as G1 [1]. Last week at Google I/O, Vic Gundotra delivered an Oprah event by offering to the audience a second generation Android phone, also known as G2 or HTC Magic [2, 3]. The G1 is more limited but it is still the only Android platform legally available.
With a bit of luck, few of 18 new phones Google expects [4] will be made available to developers during the year.
I have been able to activate the phone with the Fido pre-paid plan (10 $/month) [5]:
I inserted the SIM card as illustrated into the documentation, put the the battery in place, and connected the phone to the AC adapter.
Before signing in with my Google account, I had to create an Access Point Network (APN) entry:
Name: Fido
APN: internet.fido.ca
Username: fido
Password: fido
MCC: 302
MNC: 37
In some forums, it is reported that new Fido SIM cards use 370 as the MNC value.
A post of Olivier Fisher's blog [6] gives also the coordinates to connect to Rogers network, another GSM provider in Canada.
To limit interference, I deleted all pre-loaded APN entries (related to T-Mobile networks).
At one point, a popup asked me to enable data transfers. It is important to enable it and to activate the Data roaming, disregard how expensive are the costs for a prepaid plan.
Then I specified my Google account credentials and let the phone contacting Google servers via Fido network.
Once the activation has been successfully reported, I disabled the Data roaming, even before the synchronization of the applications {GMail, Contacts, Calendar} ended. The impact on my plan should be limited ;)
Then I added the description of my home Wi-Fi network.
I found the MAC address of the phone in the menu Settings > About phone > Status, with the entry near the end of the list. I used it to let my Wi-Fi controller accepting connections from the phone.
At this step, I was able to use my phone for regular calls over Fido network, and for data transfers over my Wi-Fi network.
The phone comes installed with Android 1.0 installed. I will blog later about updating the phone OS to the 1.5 version (also known as Cupcake)...
Update 2009/07/15
Because of some restrictions to access Internet from the office, I have decided to pay for a 1GB/month data plan with Fido (30$/month). The activation has been made pretty quickly but none mentionned the following limitation:
On HTC website, you can see the network specifications for the G1: HSPA/WCDMA (US) on 1700/2100Mhz.
Fido/Rogers GSM only operates on 850/1900Mhz, so there's no possibility to go at a 3G speed in Canada!
Using this phone mainly for development purposes, it is not a blocking issue. It is just sad to not benefit from a better bandwidth...
Me voilà 40 ans révolu ! Ce 30 mai, j'ai eu le plaisir de recevoir de proches amis que j'ai rencontrés au long de mes 10 années passées à Montréal. Ce n'est pas tant le chiffre des 40 ans qui est magique, c'est plus celui des 10 ans et tous les événements qui se sont produits depuis.
En effet il y a 10 ans, ma femme Sophie et moi avons pris un aller simple Nantes-Montréal avec 2 valises, pendant que le reste de nos affaires traversait l'atlantique en bateau. Rapidement, nous avons loué un haut de duplex à Ville LaSalle. Et après quelques temps de vacances au Lac Saint Jean et dans le Saguenay, nous nous sommes mis à la recherche d'un boulot.
Pour moi, c'est la compagnie CS&T (plus tard renommée en Steltor) qui a décidé de me faire confiance. J'y ai d'abord réalisé une console d'administration Web pour le serveur de calendrier, un outil de collaboration instantanée et distribué avant l'heure. Je dois en partie mon recrutement à Patrice Lapierre, toujours employé par Oracle à Montréal ;)
Une fois acquise Steltor par Oracle, j'ai travaillé pour une équipe californienne. Mon expérience des applications Web a retenue d'Attila Bodis. Avec quelques autres, nous avons construit un environnement pour une application Web 2.0 avant même que le buzz existe ! Une première version a été commercialisé. Les débuts de la seconde version étaient très prometteurs, notamment grâce à la vision d'Amir Borna, et avec la bonne coordination de Vince Wu. Mais des aléas politiques ont cependant plombé le projet et l'équipe s'est quasiment dissoute...
Quand la semaine dernière, j'ai vu la présentation de Google Wave par Lars Rasmussen et Stephanie Hannon, j'ai trouvé beaucoup de similitudes avec ce que nous avions sur la planche de travail pour OCS (Oracle Collaboration Suite) en 2005-2006. Parce qu'Oracle évolue dans le monde de l'entreprise, les médias comme le courriel ou l'événement de calendrier devaient perdurer—j'attends à ce propos de voir quelle stratégie Google va offrir aux entreprises pour migrer leur legacy systems. Il y a sûrement des concepts OCSiens de l'époque qui s'appliqueraient à Wave aujourd'hui. Chapeau bas les gens d'en bas ;) car vous avez réussi où ceux d'en haut n'ont pas su persévérer !
C'est alors qu'IBM Rational m'a offert un poste d'architecte technique. Le projet n'était pas sensationnel (il est même mort depuis), mais les gens rencontrés et l'expérience de Big Blue ont été sans pareil. Chapeau à Steven Milstein, à Toufik Bahloul et Arthur Ryman.
Présentement, je suis chez Compuware dans un groupe d'experts multi-disciplinaires et j'aide à définir les stratégies de l'entreprise dans les domaines des applications Web et des mobiles. Évoluant dans une compagnie très conservatrice, certaines situations ont tendance à me frustrer royalement, mais les résultats que j'arrive à obtenir par ma persévérance font que finalement l'équilibre est positif. Je ne sais pas combien de temps cela va durer, mais j'en apprécie la valeur. Et je remercie Paul Czarnik, Mathieu Pageau et Abdel Belkarsi.
Du côté extra-professionnel, il y a eu mon passage dans le groupe RÉSULTATS, merci Sunnie Kim, pour lequel l'action des citoyens fait pression sur le gouvernement fédéral pour que l'aide au développement vise les plus pauvres. Maintenant, je suis impliqué dans Diku Dilenga au Canada, dont je remercie le co-fondateur de l'organisation en République démocratique du Congo révérend Tambwe Musangelu.
Je n'oublie pas non plus ma relativement récente entrée dans le monde du karaté au Dojo de Don Lorenzetti, pour le style Chito Ryu. C'est d'autant plus passionnant que toute la famille Derrien y participe : Sophie, Erwan, Goulven et moi-même chacun à des horaires différentes deux fois par semaine.
Merci Sophie, mes enfants, et mes amis pour votre amitié et les richesses que vous m'apportez. J'espère être à la hauteur et vous donner autant de plaisir.
Une fois n'est pas coutume, je prends le parti d'écrire une entrée de blogue en français. Ce qui me motive à le faire c'est la récente lecture du livre de Seth Godin qui n'était disponible qu'en français à la bibliothèque de mon quartier. Depuis quelques années, j'utilise la langue de Shakespeare mise au goût du jour par Ron McDonald pour mon travail. En plus, 95 % de mes sources d'information sont anglophones. C'est donc assez déroutant de lire du Seth Godin en français, mais aussi très rafraîchissant.
Le thème de ce court livre publié en 2007 (100 pages au format d'un livre de poche) traite de la description de différents profils d'activité et sur les stratégies à adopter pour avoir du succès. Seth est très honnête sur la notion de succès : s'il incite le lecteur à être le « meilleur du monde », il précise que ce « monde » est propre à chacun et qu'il peut varier au court du temps. Voici les trois profils d'activités qu'il identifie :
Il y a le profil que tous connaissent quand ils démarrent une nouvelle activité, où l'excitation rend les choses faciles. Cette phase est suivie d'un creux où l'évolution est lente et pénible. Quand l'obstination porte ses fruits, la sortie de ce creux est souvent couronnée de succès. Seth appelle ce creux le dip.
Il y a le profil de la falaise où les activités progressent bien jusqu'à s'écrouler totalement. Seth fait le parallèle avec le monde de la presse écrite : tout allait bien jusque récemment mais la démocratisation d'Internet a tout chamboulé. Plus besoin d'attendre le quotidien du lendemain pour connaître les nouvelles car la plupart des grands médias [2] diffusent sur Internet. Plus besoin du journal local pour vendre ou acheter un bien car les services comme craigList [3] offre de meilleures couvertures. Plus besoin du mensuel pour voir des photographies extraordinaires, il suffit de se rendre sur Flickr [4]...
Il y a enfin le profil de la progression plate, infiniment plate, sans perspective de succès. C'est le chemin vers une voie sans issue.
Seth explique que les deux derniers profils sont à abandonner rapidement, car il n'y a que de la médiocrité à en retirer. Le premier profil, celui avec le dip, est à évaluer consciencieusement.
Il arrive des situations, ou malgré les perspectives de réussite évidentes, le palier à traverser pour atteindre le succès est trop pénible. En fait, Seth écrit que la péniblité du palier est proportionnel au succès à atteindre. Si ce n'était pas pénible tout le monde serait couronné de succès, ce qui n'est évidement pas le cas. Parmi ses exemples, Seth cite le cas des grands sportifs, des dirigeants de grandes sociétés, des créateurs, etc. Il dit, par exemple, que c'est facile d'être un grand patron, mais c'est difficile de gravir les échelons pour arriver à ce poste.
La partie qui m'interpelle particulièrement, c'est son discours sur la nécessité d'identifier les situations de dip que l'on peut traverser et celles qui sont insurmontables compte tenu de nos propres contraintes. Quand une situation de dip trop difficiles, tout comme celle de la falaise ou de la progression, il est important d'y renoncer tôt. Il affirme même qu'il est important d'identifier les critères de renonciation avant d'être dans la situation de blocage pour être sûr de quitter pour les bonnes raisons. Si les raisons sont trouvées alors qu'on est dans le trouble, elles provoqueront des remords par la suite. Avec l'analogie d'un marathon, Seth dit que par exemple se mettre des objectifs de temps de parcours et de s'évaluer par rapport à eux plutôt qu'aux sensations du moment (crampes, fringale, etc.) donne de meilleurs chances de succès. Si on déjà parcouru 35 km, les sensations rendront la fin plus pénible à supporter s'il n'y a pas l'estimation initiale de succès établie en fonction de temps établis par avance.
Seth dit que le renoncement à des situations trop difficiles laisse la chance à la réalisation d'autres défis plus à sa mesure. Comme le critère de réussite est d'être « le meilleur de son monde », peu importe que d'autres pensent que l'abandon d'un situation soit un échec. Il arrive même que ceux qui vous jugeront mal sont eux-mêmes incapable de sortir du dip, qu'ils nagent dans une médiocrité relative.
Si je fais un peu d'introspection, j'en arrive aux constats suivants :
Autant mon immigration au Canada, mes derniers changements d'emploi (de Oracle à IBM Rational, puis à Compuware [5]), ainsi que le déplacement de mes activités para-sociales (de RÉSULTATS à Diku Dilenga [6]) ont été motivés par des constats de dip devenus infranchissables (en tout cas, avec des perspectives moindres lorsque comparées à celles offertes par les changements).
J'aime les difficultés, les challenges qui sont rudes, dans la mesure où la perspective de grandir est bonne. Instinctivement avant, clairement maintenant, j'abandonne les situations qui sont sans issue, ou pour lesquelles les compromis à faire sont sans commune mesure avec la satisfaction à en retirer. Cette attitude peut paraître fruste et égoïste mais c'est relatif : j'imagine qu'en étant le « meilleur de mon monde » cela bénéficie aux gens de « mon monde ». Ce qui est mieux, à mon avis, que d'affecter mon entourage parce que je reste « un médiocre dans mon monde ».
Étonnant comme un petit livre peut faire gamberger, n'est-ce pas ? À votre tour d'y consacrer quelques heures et de partager votre propre cheminement en me laissant un commentaire.
Pour le plaisir, voici la vidéo d'une présentation donnée par Seth Godin en 2003 [7]. Tout ce qui dit est du « gros bon sens » et c'est ce qui le rend pertinent. Le livre est du même acabit.
As the title let you imagine, I will be in San Francisco the week of June 2-5 for the JavaOne 2009 conference.
It will be my first visit to the event, not to the Moscone Center. While working for Oracle, I attended one Open World event there. With the recent acquisition (not officially closed yet) of Sun by Oracle, I am going to go in California for Oracle again ;)
With another Compuware colleague, we will mainly focus on mobile related sessions, but cloud computing and rich interactive application related ones will have my attention too. With sessions finishing at 10:20 PM, days will be surely long. I expect a fruitful trip.
I have been doing “Agile development” for more than 5 years. I am used to saying that an organization is Agile at the level of its weakest element. So I cannot claim having worked on any fully Agile projects. However, I have always tried to apply as many as possible Agile principles to my work. This blog entry goes over different practices and identifies the ones that worked best for me and my teams.
Agile
The Agile methodology is a not pure invention, this is the compilation of best directives gathered from various practices:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Agile principles and sub-principles have been defined by a group of technical leaders: Beck from eXtreme Programming (XP), Schwaber (Scrum), etc. The Agile Manifesto [1] is the result of their collaboration.
Scrum
“Scrum is a lightweight Iterative and Incremental (Agile) Development Method that focuses on delivering rapidly the highest priority features based on business value.” It has been defined by Ken Schwaber and Jeff Sutherland in early 1990s.
Scrum promotes high collaboration and transparency. There are different backlogs helping delivering the best business values at each iteration. Capturing and integrating feedback (from business users, stakeholders, developers, testers, etc.) is a recurrent task. Deliveries occur often and their progression is continuously monitored.
Scrum in Under 10 Minutes by Hamid Shojaee
The points I really like about Scrum:
Task reviews done with all actors, in Poker Planning [2] sessions, for example.
Product designed, coded AND tested during the Sprint.
Sprint deliveries are workable products, with limited/disabled features, but working without blocking issues.
Defined roles: Product Owner, Scrum Master (aka Project Manager), and Project Team (composed of cross-functional skills: dev., QA, DBA, Rel. Eng., etc.).
Pig and Chicken are traditional roles in the Agile teams [3].
eXtreme Programming
While Scrum is mainly managers (chicken) oriented, eXtreme Programming (XP) focuses more on do-ers (pigs).
XP is more a matter of having the right tools and having real technical exchanges within the Scrum team. For example, XP strongly suggests the adoption of peer-programming: two developers per computers, one coding and the other thinking about the coding and correcting the code on-the-fly.
Applying peer programming in teams with actors from various backgrounds is sometimes too constraining. Matching peers is a difficult exercise. However, enforcing peer code reviews allows to get almost the same benefits without too much frustration. With code reviews, junior developers can see seniors' work in action, and senior developers can learn new programming paradigms. I found it's good also for the team cohesion, because team members really know about each others' work.
Among the practices XP incites to follow, there are:
Continuous Integration: every time a developer or a tester delivers new materials, a complete build process starts to compile, package and test the entire application. Ideally, the build time is short enough to prevent committers to start any other tasks, so they can fix it right away. A safe strategy is to put “fixing the build” as the top priority whenever a problem occurs.
Unit testing and code coverage: when developers write unit tests, they provide the first piece of code consuming their own code, and experience shows that it really helps delivering better code. Unit tests without code coverage measurements does not mean much. And not trying to reach 100% coverage leaves too much space to defective code... Using mock objects [4] is an essential tool to test accurately. Test Driven Development (TDD) methodology is pushing this practice up to writing the tests before the code.
Continuous refactoring: during each sprint, developers should focus on the immediate requirements, because they have very little control on future sprints (the product owner can adjust the development plan anytime). This is sometimes difficult to limit them to their immediate tasks because many do not like the perspective of having to rewrite their code later. Investing in tools like IntelliJ IDEA which provides extended refactoring features is really worth it because developers can adapt their code efficiently while being secured by the continuously growing regression test suites.
Best of both approaches
In medium to big companies, they are often many layers of management. In such environments, when managers should be facilitators[5], they often add weight to the processes.
About the issues in shipped products, here is an anecdote about IBM:
An internal team reviewed the quality of the released products and came to the initial conclusion that minor and maintenance releases contain more flaws than major releases. The conclusion was made after studying the number of defects reported by customers: this number was sometimes twice higher for intermediate releases. But the team pushed its investigation further and polled many customers. At the end, it appears that very few customers were installing major releases immediately, most of them would wait for the first maintenance release to deploy in pre-production environments (one stage before production one).
In this story, IBM used the results of this study to size and train the support teams according to the product release plans. As you can expect, more support people are trained and made available on releases following major ones. It did not help IBM delivering better products up front, it mostly smoothed the experience of customers reporting problems ;)
Development labs are often known for delivering over the budget, over the allocated time, and with too many issues. Many times, I have seen the maintenance being operated by specific teams, without relation with the development ones. In such environments, development teams focus on delivering features and maintenance teams fix issues: each team has its own budget and life goes on!
The combination of the relatively poor delivered software, the accumulation of managers, and the Scrum burn-down chart (the chart that shows how the work progress on a daily basis [6]) favors Scrum adoption in IT organizations.
Burn down chart sample
My problem with Scrum as I see it in action is related to its usage by managers: it is a one-way communication channel for them to put the pressure on Scrum teams. And because Scrum is task oriented, if the task set is incomplete (or deliberately cut through), these managers mostly follow the feature completion rate, and sometimes the defect detection and fixing rates.
In my experience, with organizations transitioning from waterfall methodologies to Scrum, the feature check list has always precedence on the quality check list! If tasks have a risk to break the deadline, the test efforts are cut. And because these organizations have very few ways to measure the delivered quality (because they adopted Scrum but refused to invest in XP), results are not really better for customers...
This is why I think it is important to balance the importance of Scrum with the one of XP, why as the same time managers should tools to monitor the work progress, Scrum teams should publish quality metrics about all delivered pieces of code. With both sides being instrumented, it is be easier to identify decision impacts and product owners can make informed decisions.
On April 7, three days ago, Google people announced and demonstrated the new support of the Java programming language in Google App Engine ecosystem [1].
Before starting my side project [2], I was mostly a Java[3] adopter on back-end servers. Java is widely supported and have a large and active contributing community (to its core via the Java Community Process (JCP) [3] or to 3rd party libraries).
Once I decided to go with GAE, I invested a bit in improving my knowledge of Python [4], for example by looking at the WSGI specification [4] and at Django [4]. I have been impressed about the integration done by GAE people, about how easy it is to program complex steps in very few lines! My favorite part is the main function to dispatching events:
Implementing a REST API, the RequestList class defines get(self) to return selected resources, and put(self) to create the proposed resource. The Request class defines get(self, key) for the identified resource retrieval, post(self, key) to update the identified resource, and delete(self, key) to delete the identified resource.
In the J2EE world, with the web.xml file forwarding /requests URLs to a servlet (as done in the app.yaml file), the servlet code will have to get the URI (with HttpServletRequest.getPathInfo()) and will have to parse it in order to detect the possible request identifier and the possible version number. IMO, Python offers slicker interface.
Another example is the support of the JPA and the JDO [5] specifications: few annotations decorating the Data Transfer Object (DTO) class definitions allow GAE/J to deal with the persistence layer (i.e. BigTable). Compared with the Python model definitions, the getters and setters plus the annotations seem overkill, but are necessary.
With Python allowing to rely on a more compact code, why would I switch to Java?
Even if I gave directions on how to test GAE/P applications [6], I should admit testing GAE/J code is easier: JUnit is de facto standard copied by many frameworks, and JCoverage is the tool helping to determine the quality of these unit tests. While working on an open source project, with possibly contributors from various horizons, relying on a strong testing infrastructure is a top priority. It is then possible I will go over the Java tradeoff in a near future...
The Java Virtual Machine (JVM) ported on GAE opens the door to many other languages, as reported by App Engine Fan [7]. I have a personal interest in the port of JavaScript language, processed by Rhino, the Mozilla JavaScript engine. I would be nice to be able to run the Dojo build process on GAE itself ;)
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!
To start investigations on mobile application development for Compuware, I have just acquired a first Android Dev Phone, also known as G1 [1]. Last week at Google I/O, Vic Gundotra delivered an Oprah event by offering to the audience a second generation Android phone, also known as G2 or HTC Magic [2, 3]. The G1 is more limited but it is still the only Android platform legally available. 
Une fois acquise Steltor par Oracle, j'ai travaillé pour une équipe californienne. Mon expérience des applications Web a retenue d'
C'est alors qu'IBM Rational m'a offert un poste d'architecte technique. Le projet n'était pas sensationnel (il est même mort depuis), mais les gens rencontrés et l'expérience de Big Blue ont été sans pareil. Chapeau à 
Présentement, je suis chez Compuware dans un groupe d'experts multi-disciplinaires et j'aide à définir les stratégies de l'entreprise dans les domaines des applications Web et des mobiles. Évoluant dans une compagnie très conservatrice, certaines situations ont tendance à me frustrer royalement, mais les résultats que j'arrive à obtenir par ma persévérance font que finalement l'équilibre est positif. Je ne sais pas combien de temps cela va durer, mais j'en apprécie la valeur. Et je remercie 
Du côté extra-professionnel, il y a eu mon passage dans le groupe RÉSULTATS, merci 
Je n'oublie pas non plus ma relativement récente entrée dans le monde du karaté au Dojo de Don Lorenzetti, pour le style Chito Ryu. C'est d'autant plus passionnant que toute la famille Derrien y participe : Sophie, Erwan, Goulven et moi-même chacun à des horaires différentes deux fois par semaine.
Once I decided to go with GAE, I invested a bit in improving my knowledge of Python [4], for example by looking at the WSGI specification [4] and at Django [4]. I have been impressed about the integration done by GAE people, about how easy it is to program complex steps in very few lines! My favorite part is the main function to dispatching events:
In the J2EE world, with the 
