J'aurais aimé écrire mon premier billet pour 2015 avec la plume guillerette,
l'âme encore enivrée par les bons moments passés en famille et entre amis
pendant les fêtes. Las ! Point n'est besoin de résumer les tristes événements
qui nous ont tant secoué hier.
Les unes acerbes de l'hebdomadaire satirique faisaient partie du paysage
urbain, et suite à cet événement, c'est un peu de notre patrimoine qui s'envole
en fumée. Et ça va rendre encore plus pénible les repas de famille ou tonton
René et mamie Jeanette vont encore se la ramener avec leur couplet sur
l'immigration, l'Islam, « ces gens là », etc.
Ne pas réagir à un attentat terroriste contre la liberté d'expression, c'est
difficile. Mais ne pas mal réagir l'est encore plus. Nous avons la chance de
pouvoir contempler des précédents historiques : justification de la guerre, des
tortures et des entraves aux libertés individuelles ont été quelques unes des
conséquences du 11 septembre pour nos voisins outre-Atlantique.
Suivrons nous le même chemin ? Il me semble que la manière dont nous réagirons,
individuellement et collectivement, en décidera.
J'utilise git au quotidien depuis plus de 10 ans maintenent et git-rebase est tout simplement l'une de mes fonctionnalités préférée. Pourtant, lorsque je donne des formations sur Git, je m'aperçois que cette commande est souvent mal comprise et mal utilisée. Nous allons donc étudier en détail la commande git-rebase : À quoi elle sert vraiment, et comment bien l'utiliser.
Par exemple, il m'arrive fréquemment, quand je facture un client, de devoir
inclure dans la facture des remboursements de frais. Et à chaque fois, je peste
car j'ai totalement oublié la bonne façon de faire.
Pour les neuneus en compta comme moi, voici donc la méthode facile et logique
pour émettre une facture qui intègre des remboursement de frais.
Ces quelques années m'ont amené à considérer certaines façons de faire plutôt
que d'autre, et à compiler une liste de bonnes pratiques qui me paraissent
positives dans la majorité des cas.
Ces bonnes pratiques ont différents objectifs, qui finissent plus ou moins par
se rejoindre :
Du coup, on se retrouve souvent avec des docs pourries et donc des logiciels
difficiles / pénibles à utiliser.
Voyons donc comment documenter correctement une application Django (ou
n'importe quel projet Python, hein, c'est juste pour l'exemple concret et mon
référencement).
Il y a quelques jours, alors que je bossais sur mon pet project du moment, je
me suis surpris à penser « tiens, ça serait bien si cette fonctionnalité
devenait une application Django réutilisable ». La fonctionnalité en
question ne nécessitant pas plus de quelques lignes, je me suis dit que ce
serait rapidement torché.
Le fait que je me retrouve 10 jours plus tard et deux applications
supplémentaires me prouve encore une fois que je suis vraiment mauvais avec les
estimations. Et on s'étonne que je ne travaille pas au forfait …
Quoi qu'il en soit, pour la dernière app, j'ai décidé de tester l'approche
Documentation Driven Development. Retours d'expérience.
Miximum
