Jocelyn Demoy

Tout allait bien pour Jeremy. Il venait de changer de job avec une équipe sympa dans un bureau tout récemment remis à neuf. Son cube était à la parfaite distance entre l'ascenseur, les toilettes et le distributeur. Son chef le respectait, ses collègues n'hésitaient pas à l'aider, et son travail était véritablement plaisant.

Je suis chez Oracle pendant une quinzaine de jours (première fois que je vois une machine à café avec une progress bar...). J'en profite donc pour publier la traduction d'un billet que nous avait envoyé Thomas Kyte, un vice président d'Oracle Corporation. Tom gère un forum technique très connu : askTom, il nous parle d'un post qu'il a reçu.

Les règles de l'optimisation logicielle sont simples. Règle 1 : N'optimise pas. Règle 2 (réservé aux experts) N'optimise pas pour l'instant.

La plupart des gens ont des difficultés à comprendre pourquoi les PDG sont autant payés. Ils ne voient pas qu’en vérité c'est un travail très difficile, requérant un dévouement ultime à la société. Ils ne réalisent pas que un PDG n'a pas le pouvoir de changer directement les choses et qu'il doit compter sur ses subordonnés pour réaliser les objectifs de l'entreprise. Ils ne comprennent pas que seul un communiquant née, un champion de la motivation est taillé pour ce type de job. D'un autre coté, quand on reçoit ce genre de mail, on les comprend :

Rich Leik fut envoyé dans une grande compagnie d'assurance comme consultant pour les aider à faire face aux bugs dans le noyau de leur application. Un des problèmes principaux que rencontra Rich c'était  le peu d'informations qu'avait le support  sur les cas qu'il devait résoudre : l'application ne fournissait pas de log et tous les messages d'erreur affichaient simplement "une erreur est apparue. Veuillez réessayer".

Christian P se sentait plutôt mal. Sa société venait d'obtenir un contrat de maintenance d'une application (faite maison) pour une société financière assez importante. Non seulement six développeurs de cette société étaient licenciés sur le champ, mais les trois autres restant devaient assurer la transition avec la nouvelle équipe avant d'être licenciés. Pour son premier jour, Christian s'était préparé à des réactions de colère, de tristesse, de désespoir et même de haine. Mais rien de tout ça. Bien au contraire, les développeurs sur le départ semblaient tous soulagés.

Utilisée en production, l'application web de gestion du personnel gère plus de  600 employés. L'idée derrière la table staffDirectory c'est l'expansionabilité. En mettant tout dans une seule table, on peut faire des modifications dans la structure de la base sans se soucier des conséquences ! La table est structurée de cette façon :

Les accesseurs de propriétés sont un ajout plutôt utile à la POO. Ils permettent aux designers de classe de restreindre et d’abstraire ce qui aurait été normalement de simples valeurs en utilisant la logique des "getter" et des "setter". Bien que les propriétés exposent dans 90% des cas simplement une variable privée, c'est parfois utile d'inclure un peu de logique additionnelle dans le code. Russ, remarqua que le développeur de la classe "Contact" n'avait pas compris le principe de "un peu de logique additionnelle" ...

Aujourd'hui, une traduction d'un billet que Blake Ross nous a envoyé en 2006.

Jean-Baptiste en direct du Carrefour Saint-Égrève : "J'espère qu'ils n'ont pas oublié mon numéro de compte"

Responsable des développements. Ouais, c’était un titre assez pompeux mais Jamie y était préparé. Il avait passé des années en tant que développeur et savait que c’était le bon moment pour prendre un poste de management. En plus, l’équipe qu’il allait gérer était plutôt petite et il pourrait toujours participer aux développements si nécessaire. L’offre était parfaite et ainsi, Jamie devint un manageur.

"Ca devrait être plutôt facile," déclara naïvement David M, « regardes simplement dans la table Agent_ProductLines, d’accord?"

Sandy Barnabas reçu un message plutôt étrange lorsqu'elle valida son formulaire d’enregistrement :

1999 fut une grosse année pour les publications Harvard Business School. Dans les années passées, ils avaient vu leur "business model" - vente de livres, journaux, articles, études de cas, et autres - se transformer de vente sur catalogue papier vers une boutique en ligne, pour aujourd'hui nécessiter une refonte totale du site web.

On est tous passé par là : tous nos tests unitaires fonctionnaient la veille mais quand il s'agit de lancer la démo vous réalisez que vous avez oublié quelque chose. Depuis, on a inventé la revue de code. Non pas qu'il y ait moins de bug, vous vous sentez juste mieux puisque quelqu'un d'autre a raté le problème.

Don nous propose un bout de code sur l'envoi d'email, avec une façon plutôt spéciale de gérer les exceptions :

A la une : la requête pour afficher au hasard un salon qui débute le 22 avril, qui a été validé et qui a une photo.