En arrivant du boulot, j'avais une petite fringale : hop au frigo et qu'est-ce qu'il y a de facile à se mettre sous la dent ? Une tranche de fromage tranché Velveeta! Dès maintenant, veuillez mettre vos jugements de côté et ne considérez même pas à me regarder de haut en prétendant qu'ingurgiter cet aliment conçu avec du lait caillé fait "petit peuple". On a chacun nos défauts et ça permet de briser le mythe que je suis un snob grano du plateau Mont-Royal (d'ailleurs, je n'habite même pas là. Quoique j'en connais qui croient que son territoire s'étend sur à peu près toute la superficie de l'île de Montréal...).

Eh oui, figurez vous que nous étions ma copine et moi au supermarché dans le rayon des produits laitiers. Nous nous attardions devant l'étalage des fromages afin de choisir le type idéal à faire fondre dans nos burgers à l'américaine. La concurrence est féroce et on doit déterminer un gagnant par élimination entre les Singles de Kraft et le Velveeta (avis aux passionnés, suivez les liens pour faire parti des 49000+ personnes qui ont déclaré publiquement entretenir une relation d'amour avec ce type de fromage (à ce sujet, Urban Dictionary propose une définition amusante à propos de Kraft Singles si vous êtes célibataire et que vous portez le nom de famille Kraft : reference to my constant status of relationship, and the lack of ability with people with the same name as cheese to get dates. Fin de la parenthèse dans la parenthèse)).

C'est ma copine qui a eu le dernier mot : le Velveeta dans le panier. Son argument : ça fait vraiment longtemps qu'elle en avait pas mangé. Ma constatation de ce soir : ça goûte carrément la même chose! À vrai dire, je ne dois pas avoir les papilles gustatives bien entraînées puisque ça me semble tout droit sorti du même mélange que :

• les tranches Singles de Kraft
• le Cheeze Whiz
• la poudre de fromage dans le Kraft Dinner
• les tranches Velveeta (ouais, pour ça on s'en doutait)
  

Quel symbole mathématique placé entre 5 et 9 permet d'obtenir un nombre plus grand que 5 et plus petit que 9 ?

Essayez d'abord les plus communs : addition (+), soustraction (-), multiplication (×), division (÷). Ensuite, référez-vous à la table des symboles mathématiques pour vous donner un coup de pouce.

Si vous n'avez pas trouvé, vous pourrez consulter la solution. C'est tellement simple que c'en est presque ridicule.

Le point décimal, évidemment! 5.9 est plus grand que 5 et plus petit que 9.

On ne va jamais aussi loin que lorsque l'on ne sait pas où l'on va.

Cette histoire m'a été rapportée il y a quelques jours alors qu'un nouvel employé, étudiant en génie, aurait cogné son doigt à quelques reprises contre la table lors d'une réunion et aurait alors posé la question à ses interlocuteurs pour leur demander s'ils savaient ce que ça signifiait. Un peu surpris et ne sachant pas trop où il voulait en venir, ils l'ont laissé parler.

- Quand un ingénieur cogne la bague à son doigt comme ça sur la table, le monde doit se taire et l'écouter.

Silence. Malaise.

Je ne faisais pas parti de la réunion mais ouch! Jamais je ne me serais permis de dire ça. Je vous le dit, j'ai sauté ça de haut quand on me l'a raconté (je sais, vous ne le voyez pas mais prenez la peine d'imaginer).

Comment une personne peut-elle se surestimer à ce point pour oser dire une absurdité pareille ? Soit il est prétentieux et imbu de lui-même, soit ses professeurs lui ont fait tout un lavage de cerveau pour qu'il croit ce qu'il a dit. Si c'était une farce, il aurait mieux fait de se taire. Mais non, il tenait à informer les autres.

Il ne faut pas être un grand observateur pour se rendre compte que la situation n'est pas à son avantage :

• il est encore aux études, donc aucun diplôme et aucune bague de l'Ordre des ingénieurs
• il est en poste depuis quelques semaines seulement
• après cet épisode, son emploi est probablement plus précaire qu'assuré
  

Ce qui m'amène à un principe essentiel tiré de la citation no. 36 sur le silence :

Avant d'ouvrir la bouche, assure-toi que ce que tu vas dire est plus beau que le silence.

Soyons franc, on n'apprécie pas beaucoup le désordre même s'il faut vivre avec. Dans un monde idéal, on combat férocement le chaos que peuvent créer les Kim Jong-il, Darth Vader ou Sauron. Seulement parce que l'équilibre de la paix est fragile et que les conséquences peuvent s'avérer désastreuses.

Tout comme en programmation. Elle se doit d'être structurée, hiérarchisée, reglementée pour que tout tourne rondement. En cours de développement, l'utopie est de construire le tout dans les règles de l'art. La réalité ressemble davantage à de la rénovation ou à une réparation de voiture : on droit tricher d'un peu partout, forcer les pièces du puzzle ensemble pour qu'elles finissement à s'emboîter adéquatement.

Lorsqu'un client soumet une demande de changement, il voudra l'obtenir au meilleur prix, même s'il faut le corriger avec du mastic et du ruban adhésif. Aux yeux de la majorité, ce genre de dépense ne procure aucun plaisir en retour alors pourquoi payer plus ? Et c'est généralement là que ça se met à déraper. Comment justifier le prix d'une réparation faite correctement si une patch à moindre coût peut suffire ? En tant que développeur, on peut tolérer quelques patches mais il vient un temps où il faut cesser de remettre du ruban adhésif par-dessus l'ancien qui déchire sans cesse.

Dans le meilleur des mondes, un logiciel serait construit comme un gratte-ciel. La fondation doit être suffisamment inébranlable pour y empiler de multiples étages de dimensions égales qui pourront à leur tour accueillir des étages supplémentaires au sommet afin de répondre aux demandes futures du client. Les contraites du monde réel font que les logiciels sont plus souvent bâtis comme une pyramide. Un nouvel étage trop large juché au sommet risque tôt ou tard de devoir tenir en équilibre sur la pointe, jusqu'à ce qu'il bascule dans le vide au moindre coup de vent. D'autres fois, la demande sera de venir glisser un nouvel étage entre le 7ème et le 8ème plancher d'un building existant (essayez un instant de vous représenter une image mentale de ce que ça implique). Retirer le 13ème étage malchanceux ? Aussi simple que de tirer une briquette d'un jeu de Jenga! Dans tous les cas, effectuer le travail proprement, tout en minimisant les risques pour les travailleurs, fera grimper les coûts liés de rénovation et de logistique de construction. Et dans certains cas, le danger est tellement grand qu'il serait peut-être plus sage de refuser le mandat plutôt que d'accepter les pires conditions et la responsabilité en cas de désastre.

Quand on parle de chaos, il faut aussi savoir reconnaître les signes précoces avant que ça commence à dégénérer. Prenez par exemple une usine. Pendant tout le temps qu'elle est en fonction, ses occupants en prennent soin (du moins, ils sont supposés). Le jour où le propriétaire met la clé sous la porte et que le bâtiment est abandonné, s'il n'est pas surveillé, ce ne sera qu'une question de temps avant qu'il commence à être vandalisé. Une fenêtre pourrait être brisée. Si elle n'est pas réparée rapidement, elle deviendra une cible facile : d'autres vitres seront fracassées, des graffitis feront leur apparition, des itinérants et des squateurs s'y établiront, ils commenceront à salir leur environnement emprunté, des dommages structureux gravent apparaîtront. Dans un espace de temps relativement court, le bâtiment sera endommagé au-delà de la volonté du propriétaire de la réparer, et le sentiment d'abandon deviendra réalité.

Lorsque le désordre augmente dans un logiciel, les programmeurs parlent alors de pourriture. Dans le livre The Pragmatic Programmer, From Journeyman to Master, les auteurs citent ce genre d'histoire pour nous rappeler une règle importante à retenir : ne laissez jamais une fenêtre brisée (mauvais design, mauvaises décisions, mauvais code) non réparée. Fixer le tout correctement dès que le problème est découvert. Prenez des mesures pour prévenir d'autres dommages. La négligence ne fera que détériorer le système rapidement.

C'est une question de gros bon sens. Maintenant, le défi est d'essayer de le faire comprendre au client...

La plupart des logiciels d'aujourd'hui ressemblent énormément à une pyramide égyptienne avec des millions de briques empilées les unes sur les autres, sans aucune intégrité structurelle, mais réalisée brutalement par la force à l'aide de milliers d'esclaves.

J'ai reçu ceci d'un ami et c'est tellement du bonbon que j'ai jugé bon de le partager avec vous.

Règle 1
La vie est injuste: habituez vous!

Règle 2
Le monde se fout de votre amour-propre. Le monde s'attendra à ce que vous accomplissiez quelque chose AVANT que vous ne vous félicitiez vous-même.

Règle 3
Vous ne gagnerez pas 60000$ par an en sortant de l'école.

Vous ne serez pas vice-président en commençant, avec smartphone et voiture de fonction fournis, avant d'avoir mérité, gagné ces privilèges.

Règle 4
Si vous croyez que votre professeur est dur avec vous, attendez d'avoir un patron.

Règle 5
Travailler dans une friterie n'est pas s'abaisser. Vos grands-parents avaient un mot différent pour ça: ils l'appelaient une opportunité.

Règle 6
Si vous gaffez, CE N'EST PAS LA FAUTE DE VOS PARENTS, arrêtez de chialer et apprenez de vos erreurs.

Règle 7
Avant que vous naissiez, vos parents n'étaient pas aussi ennuyants qu'ils le sont maintenant !
Ils sont devenus comme ça :

• En payant vos factures
• En nettoyant vos vêtements
• Et en vous entendant répéter sans arrêt combien vous êtes bons et cools
  

Un programmeur junior en interrompt un autre dans son travail pour lui demander s'il sait quelle est la version de SQL Server qui roule sur un serveur particulier sur lequel il est en train de développer. De mémoire, il ne s'en rappelle pas et il répond simplement qu'il l'ignore mais qu'il pourra le vérifier directement regardant une propriété système accessible par une requête SQL.

Plutôt que de googler les termes pour obtenir rapidement la réponse, son réflexe est de se lever et d'aller voir l'administrateur réseau pour lui demander. Soupir... Est-ce normal de m'inquiéter de l'efficacité du système D (débrouillardise) de ce programmeur ?

La programmation est avant tout un travail de résolution de problème, qu'il soit technique ou non. Avant de déranger quelqu'un inutilement et de lui faire perdre sa concentration, assurez-vous d'abord :

• d'avoir fouillé dans la documentation
  
• d'avoir posé au moins une fois la question à Google
  

-- juste le numéro de version
SELECT SERVERPROPERTY('ProductVersion')

-- la version en format long
SELECT @@version

SELECT SERVERPROPERTY('ProductVersion')

SELECT @@version

Voici un cas réel où j'ai eu à résoudre un problème en classant des individus par groupe d'âge à l'aide d'une base de données Postgres. D'abord, imaginons deux tables : la première "human" contient la liste des personnes avec une propriété "birth" où est stockée la date de naissance qu'on utilisera pour connaître son âge en temps réel. L'autre table, nommée "age_group" contient la définition des groupes d'âges en incluant comme propriétés l'âge minimum et maximum pour faire parti du groupe. Une valeur nulle dans l'âge maximum indique l'infini (pour inclure les immortels comme le Highlander par exemple).

Voici le nécessaire si vous souhaitez reproduire l'exercice :

CREATE TABLE human
(
   human_id serial NOT NULL,
   firstname character varying(50) NOT NULL,
   lastname character varying(50) NOT NULL,
   birth date
);

CREATE TABLE age_group
(
   group_id serial NOT NULL,
   age_min integer NOT NULL,
   age_max integer,
   group_name character varying(50) NOT NULL
);

INSERT INTO age_group(age_min, age_max, group_name)
VALUES  (0, 12, 'Enfant (Fan de Justin Bieber)'),
  (13, 17, 'Adolescent boutonneux'),
  (18, 25, 'Jeune adulte fringant'),
  (26, 54, 'Adulte'),
  (55, 65, 'Retraité Liberté 55'),
  (65, null, 'Bel âge (Les résidences Soleil!)');

INSERT INTO human (firstname, lastname, birth)
VALUES  ('Marge', 'Simpson', '1963-06-08'),
  ('Homer', 'Simpson', '1962-01-31'),
  ('Bart', 'Simpson', '1997-09-04'),
  ('Lisa', 'Simpson', '1999-06-06'),
  ('Maggie', 'Simpson', '2002-07-27'),
  ('Milhouse', 'Van Houten', '1997-08-08'),
  ('Montgomery', 'Burns', '1912-03-13'),
  ('Abraham', 'Simpson', '1914-07-27');

SELECT h.*, (SELECT group_name FROM age_group as tag WHERE extract('year' from age(h.birth)) BETWEEN tag.age_min AND COALESCE(tag.age_max, 200)) as group_name
FROM human as h
ORDER BY group_name

SELECT ag.group_id, ag.group_name, ag.age_min, ag.age_max, COUNT(t.human_id) as nb
FROM human as h
INNER JOIN (
   SELECT human_id, (SELECT group_id FROM age_group as tag WHERE extract('year' from age(birth)) BETWEEN tag.age_min AND COALESCE(tag.age_max, 1000)) as group_id
   FROM human
) as t ON t.human_id = h.human_id
RIGHT JOIN age_group as ag ON ag.group_id = t.group_id
GROUP BY ag.group_id, ag.group_name, ag.age_min, ag.age_max
ORDER BY ag.age_min

-- requête simplifiée
SELECT ag.group_id, ag.group_name, ag.age_min, ag.age_max, COUNT(h.human_id) as nb
FROM human as h
RIGHT JOIN age_group as ag ON ag.group_id = (SELECT group_id FROM age_group as tag WHERE extract('year' from age(h.birth)) BETWEEN tag.age_min AND COALESCE(tag.age_max, 1000))
GROUP BY ag.group_id, ag.group_name, ag.age_min, ag.age_max
ORDER BY ag.age_min

-- façon alternative
SELECT ag.group_id, ag.group_name, ag.age_min, ag.age_max, COUNT(tmp.human_id) as nb
FROM age_group as ag
LEFT JOIN (
   SELECT tag.group_id, h.human_id
   FROM human as h
   CROSS JOIN age_group as tag
   WHERE extract('year' from age(h.birth)) BETWEEN tag.age_min AND COALESCE(tag.age_max, 1000)
) as tmp ON ag.group_id = tmp.group_id
GROUP BY ag.group_id, ag.group_name, ag.age_min, ag.age_max
ORDER BY ag.age_min

À la fin de mon billet 20 choses à savoir sur Google, je vous promettais de transcrire la deuxième partie de mes notes de lecture de In The Plex. Voici donc une autre liste comptant 20 autres anecdotes sur Google :

1. Larry Page était un adepte enthousiaste et supporteur de l'Université de la Singularité de Ray Kurzweil (inventeur de l'OCR, text-2-speech, instruments de musique et auteur de l'excellent livre The Age of Spiritual Machines)
   
2. Larry et Sergey étaient des habitués de l'événement Burning Man (un festival post-hippie dans le désert de Death Valley en Californie)
3. En louant une voiture chez Hertz à Atlanta, celle-ci était équipée d'un système de navigation GPS dont Page trouvait qu'il fonctionnait mal et était convaincu qu'il pourrait faire mieux. On connaît la suite avec la venue de Google Maps.
4. Le tout premier contrat de license pour intégrer une boîte de recherche "Google Quick Search Box" fût avec Red Hat (distributeur d'une version de Linux) et rapporta 20000$ à Google. Par la suite vint un partenariat avec Netscape­. C'était une décision ambitieuse puisque Google n'avait pas assez d'équipement pour prendre en charge cette hausse soudaine de traffic.
5. Page et Brin ne voulait pas avoir de chef de la direction (CEO - chief executive officer). Après avoir rencontré Steve Jobs d'Apple, Andy Grove d'Intel, Scott Cook d'Intuit, Jeff Bezos d'Amazon et quelques autres, ils furent convaincus qu'ils étaient prêts à en avoir un. Mais le seul qu'ils voulaient et qui rencontraient leurs standards était Steve Jobs.
6. Amit Patel (un des premiers employés de Google) nota que le CEO Eric Schmidt ne partageait pas son espace de travail (pourtant restreint). Un jour, Patel alla le voir et lui demanda s'il était prêt à partager son bureau. Contrairement aux patrons des autres compagnies qui se seraient contentés de répondre "non", il accepta, preuve qu'il avait bien compris l'attitude à avoir chez Google. Patel, croyait qu'il blaguait et qu'il s'en plaindrait à son supérieur immédiat. Le personnel en charge des installations n'osaient pas procéder au déménagement, de peur de représailles. Une des règles chez Google est que si on veut quelque chose, il faut le faire soi-même. Patel prit un bureau et le déménagea lui-même dans le local de Schmidt. Il y resta 6 mois.
7. Le créateur du système de publicité extrêmement fructueux de Google, Eric Veach (un canadien originaire de Sarnia en Ontario), a déjà déclaré qu'il détestait les publicités. La force du système réside dans le fait qu'il exploite le concept de "Long Tail" auprès des annonceurs.
8. Durant une réunion où il était question decertains pays qui n'utilisent pas vraiment la carte de crédit, Page proposa d'accepter les paiements par troc selon la spécificité de l'endroit. Par exemple, il suggéra que pour les transactions en Uzberkistan, Google pourrait accepter les paiements en chèvres. Ce à quoi Veach répondit : pour l'instant, essayons d'abord d'accepter Visa et MasterCard.
9. À la conférence TED de 2001, Bill Gross, le fondateur de l'engin de recherche et de publicité GoTo (renommé par la suite Overture et acquis par Yahoo! en 2003) proposa à Page et Brin de fusionner Google avec son entreprise. Il créa même un démo qu'il nomma GOTOOGLE.
10. Le modèle d'achat pour les publicités AdWords était basé (sans le savoir) sur les enchères de Vickrey, un système utilisé par les obligations de la réserve fédérale, et dont les économistes qui l'ont conçu ont remporté un prix Nobel.
11. Le système d'apprentissage de Google pour prédire les mots associés à une recherche se nomme PHIL pour Probabilistic Hierarchical Inferential Learner. Mais il fût nommé ainsi surtout parce que ce nom sonnait bien.
12. En 2003, une compagnie nommée Applied Semantics utilisait sa technologie dans un produit nommé AdSense. Google acheta la compagnie 42 millions de dollars en comptant et 1% en actions. Google changea le nom de son propre système pour adopter le nom plus attirant de "AdSense" (bien que la technologie interne soit encore basée sur PHIL). Le nom de code d'AdSense était "Puppy".
13. Au début, l'association des mots aux annonces affichées a causé des problèmes non-intentionnels,. Par exemple sur un article dans le New York Post décrivant un assassinat où le tueur avait découpé un corps pour le mettre dans un sac à déchets, l'espace publicitaire de Google affichait des publicités pour des sacs à ordures. En 2008, une histoire de terrorisme à Mumbai était accompagnée d'un annonce où on pouvait lire : "Obtenez un certificat en terrorisme 100% en ligne. Inscrivez-vous dès maintenant". À propos d'un empoisonnement alimentaire massif dans un restaurant Olive Garden de Los Angeles, la publicité en marge offrait un "diner gratuit pour deux" à ce restaurant.
14. En mai 2010, Google révéla pour la première fois que 68% des revenus des publicités AdSense sur le contenu était retourné à ceux qui hébergeaient les annonces et que Google gardait 32%.
15. Google avait pour objectif de rentabiliser l'achat d'Applied Semantics en récoltant 1 million par jour, puis 2 millions, jusqu'à 2 milliards par année. Ils n'avaient jamais prédit que ce serait plutôt 10 milliards par année.
16. Si Sergey Brin juge vos résultats et les qualifie "d'assez bons", il faudra le considérer comme un compliment équivalent à recevoir un prix Nobel.
17. Comment acheter une compagnie selon Google : analyser le marcher jusqu'à ce qu'on trouve ce que l'on cherche. Proposer un partenariat (car toute bonne compagnie qui vaut la peine d'être achetée ne voudra jamais vendre). Inversez les règles et proposez aux fondateurs de joindre Google. C'est ainsi qu'après plusieurs mois de négociation, Google acheta Urchin pour 20 millions en 2004. Urchin deviendra ensuite Google Analytics.
18. Larry et Sergey sont des enfants de l'école Montessori, une école basée sur la philosophie de Maria Montessori, une physicienne italienne née en 1870 et qui croyait que les enfants devaient avoir la liberté de poursuivre ce qui les intéressent sans détruire la créativité innocente de l'enfant.
    
19. À un souper avec le Prince Philip, les serveurs ont apporté des soufflés avec un petit verre de jus de fruit de la passion en guise de sirop. Ce qu'il fallait faire, c'était d'écraser le soufflé et de verser le jus dessus pour éviter qu'il soit trop sec. Larry Page, qui était invité, pris le petit verre et avala le contenu d'un coup, comme s'il s'agissait d'un shooter de tequila. Sergey fit la même chose, devant l'étonnement du prince.
20. Pour le poisson d'avril de l'an 2000, Brin envoya un email aux employés pour annoncer que la valeur de l'action passait de 0,25$ à 4,01$ (une référence obscure au 1er avril). Le April Fool's Day est depuis un incontournable chez Google.

Dans un CMS, un des champs d'un formulaire permet à l'utilisateur de faire un choix à l'intérieur d'un selectbox. Comme c'est parfois le cas, l'élément recherché n'est pas disponible dans la liste et l'utilisateur doit changer de page pour aller dans un autre module ajouter un élément dans la liste de référence utilisé pour populer la liste de sélection du formulaire initial. Si le système est mieux pensé, il sera possible d'ajouter une entrée à la liste de référence sans même quitter le formulaire en cours d'édition. Parfois, ce sera sous forme d'un popup qui affichera un formulaire simplifié, qui soumettra le contenu à la base de données à l'aide d'un appel Ajax, qui lui-même retournera comme réponse l'identificateur unique et le libellé à venir glisser par JavaScript dans le selectbox du formulaire parent.

Voilà ce qui décrit le système sur lequel je travaillais cet après-midi. Tout fonctionnait à merveille. Le seul défaut, c'est que la nouvelle entrée s'insérait à la toute fin de la liste de référence au lieu de se positionner correctement par ordre alphabétique. Je me disais qu'une simple fonction de tri JavaScript de type "bubblesort" appliqué sur les options du selectbox serait suffisant pour rafraîchir l'ordre de la liste.

Un exemple de liste :

<select id="mySelectBox">
   <option value="5">E</option>
   <option value="1">A</option>
   <option value="2">B</option>
   <option value="4">D</option>
   <option value="26">Z</option>
   <option value="3">C</option>
   <option value="10">J</option>
</select>

function bubbleSortOptionsByText(optionsList){
   var length = optionsList.length;
   var swap1, swap2;

   while(length > 0){
       for(var i=1 ; i<length ; i++){
           if(optionsList[i-1].text > optionsList[i].text){
               swap1 = optionsList[i-1];
               swap2 = optionsList[i];

               optionsList[i-1] = swap2;
               optionsList[i] = swap1;
           }
       }
       length = length-1;
   }

   return optionsList;
}

$j = jQuery.noConflict();

$j(document).ready(function(){
   var elems = $j('#mySelectBox option');
   elems = bubbleSortOptionsByText(elems);
   $j('#mySelectBox').html(elems);
});

• elle ne peut trier que par le texte affiché et non par la valeur (dans ce cas, on pourrait remplacer optionsList[i].text par optionsList[i].value)
• il s'agit d'un tri alphanumérique donc sur une liste comportant des libellés ou des valeurs de 1 à 99, l'ordre logique positionnerait 10 immédiatement après 1 (plutôt qu'à la suite de 9)
  
• l'opérateur de comparaison force le tri ascendant (dans ce cas, de A à Z)
• ce n'est peut-être pas le meilleur algorithme de tri pour la performance
  

$j('#mySelectBox option').tsort({'attr':'text', 'order': 'asc'});