|
avr
1
|
 |
Cette semaine j’ai été pas mal inspiré par la lecture de cette article (how to become an expert). Ce que l’on peut retenir de cet article, c’est que tout le monde peut devenir un expert. Pour cela il faut : de la détermination, de la rigueur et du travail. A force de travail tous le monde peut devenir expert au bout de quelques années (contrairement à devenir un champion ce qui requiert en plus des aptitudes particulières).
De plus, l’article propose une méthode pour aller vers cet objectif. La méthode proposée et je trouve très interessante, elle propose de définir les domaines à travailler, d’identifier le but de tavailler ce domaine, puis de définir un ensemble d’actions concrètes. Rien de bien nouveau, cependant, j’ai trouvé intéressant la méthode qui est de travailler de manière incrémental, plutôt que de travailler full time un sujet. Mieux vaux travailler un ensemble de sujet et d’itérer dessus pour monter en compétence. Cela donne plus de recul et une meilleure vision d’ensemble. A titre d’exemple, l’année dernière en travaillant Spring, je travaillais en parallèle les design pattern, le fait de comprendre des design pattern comme le « template » ou le « stategy » m’ont aidé à avoir une meilleure compréhension de Spring et de son utilisation.
Après avoir lu l’article j’ai créé mon propre tableau d’objectif, je vous le livre dans sa version alpha :
|
9:09
|
|
fév
25
|
|
Je viens de découvrir JTrac, il me plait, il plait à toute l’équipe, je vous le présente en 2 minutes chrono!
Tout d’abord, notre besoin.
Nous travaillons à 8 sur un projet mais sur des parties bien différentes : un frontal .net, un middle Java et un backOffice PL/SQL. Avant, lorsque nous trouvons des bugs, des cas bizarres, ou lorsque nous avions des suggestions; la solution c’était un mail, un post-it ou bien à l’oral. Le client possède en interne un outil de gestions des incidents, mais c’est une énorme usine à gaz, ou l’on cible forcément toute l’équipe, et qui est bien trop lent : c’est surtout dédié aux relations MOA/MOE ou MOE/Production.
Du coup, on ne sais pas ce que deviennent ce que l’on signale, si c’est déjà corrigé ou pas, et on ne sait même plus ce que l’on a demandé, sauf à s’astreindre à une rigueur que nous n’avons pas forcément…
Premier essai : le fichier Excel !
Ca fonctionne, mais pas très longtemps… Coup de fil : tu peux me lâcher le fichier Excel pour que je puisse y rajouter quelque chose. Coup de fil n°2 : Tu as vu que ce matin, je t’ai rajouté plein de trucs.
Bilan : c’est vite chiant…
Deuxième essai : on cherche mieux
Suite à ces constats, on se dit :
- il faut une webapp ou l’on puisse bosser à plusieurs en même temps
- il faut que ça puisse envoyer des mails
- il faut que l’on puisse l’assigner à une personne donnée
- il faut que ça reste pas trop prise de tête comme mon fichier Excel sinon personne l’utilisera
- si on peut y mettre des fichiers joints en plus, ça serait bonus.
- et aussi il faut que ça s’installe et paramètre vite, pasque je suis embauché pour coder pas pour faire du consulting en productivité ou en qualité.
Jtrac!
|
22:48
|
|
fév
15
|
|
Cette semaine nous mettions en place chez BT des formations pour les collaborateurs. Le but du jeux est de permettre à ceux qui le souhaitent de partager leurs connaissances et de permettre à ceux qui le souhaitent de venir les écouter et d’en discuter. Pour ce premier essai je me suis lancé sur une présentation sur les tests. J’ai essayé de faire passer mon intérêt pour la démarche et sur le TDD, en essayant de faire passer l’argument que coder en testant ne coûte pas forcemment plus cher. Pour la suite, Jean-François Macresy nous a fait un topo des méthodes d’estimation de charges. La soirée était plutôt réussi avec une quinzaine de personnes attentives et à priori globalement satisfaites. Ci-dessous la présentation que j’ai donné :
View more presentations from nrichand. (tags: java tdd)
|
21:41
|
|
sept
15
|
|
Mardi soir avait lieu une soirée sur le thème Groovy au ParisJug. Après plusieurs désistements en cascade, me voici arrivant seul dans les locaux, cependant tant pis pour les autres car cette soirée était vraiment de qualité est très instructive.
Bien qu’un peu à l’écoute de Groovy avant d’y aller, j’en ressort avec une grande envie de m’y lancer (chose faite le lendemain en installant le plugin Groovy pour Eclipse :p)!
|
21:32
|
|
août
3
|
|
Voila un petit moment que mon blog est resté au point mort. L’explication à cela est du à :
- la fin de ma mission chez Groupama début juillet.
- le passage de la certification SCJP dans la foulée.
Je vais faire le bilan de la certification SCJP dans mon prochain post donc je ne vais pas plus m’attarder sur celle-ci maintenant. Par contre le fait d’avoir travailler la certification m’a permis de découvrir certaines subtilités du langage java. Si vous trouvez la réponse tout de suite aux questions ci-dessous c’est bon, la certif SCJP est dans votre poche, sinon au boulot…
|
21:16
|
|
mar
12
|
|
Nous utilisons très souvent les librairies commons d’Apache pour diverses choses, notamment pour le logging (commons logging), les connexions diverses et variées et urls (commons net), envoyer des fichiers en J2EE (commons FileUpload), envoyer des mails (commons email), et bien d’autres encore…
Je n’utilise que certaines de ces librairies par habitude, mais je me rend compte de plus en plus souvent que cela vaut le coup d’aller fréquemment y faire un saut pour éviter de réinventer la roue à chaque fois…
Ce coup ci je viens de retomber sur l’API commons lang qui vise à étoffer le comportement de java.lang. Elle contient quantité de classes utilitaires qui peuvent être utilisées sur énormément de projet, d’ailleurs je pense que beaucoup de projets réécrivent en partie ces classes (vécu)…
Voici un petit tour rapide de ce que j’ai découvert d’intéressant :
- La classe StringUtils avec notamment la méthode IsEmpty() qui permet de remplacer monString != null && !(« »).equals(monString)
- HashCodeBuilder qui permet de coder un bon hashCode sans avoir à ressortir à chaque fois java efficace de Joshua Blosch (que je recommande)
- ExceptionsUtils.getStackTrace(e) qui permet d’écrire la stackTrace dans une log par exemple ce que ne permet pas e.printStackTrace()
- DateUtils qui contient des méthodes tels : addYear(), addMonth(), addMinute(), …
- EqualsBuilder pour aider à redéfinir la méthode equals
- NumberUtils avec par exemple toInt(str), toFloat(str), …
- …
Mon conseil du jour est donc : gagnons du temps et refouillons un peu dans les commons 
|
23:32
|
