J'aime ce passage:
"""
La dette technique est donc un facteur largement négligé dans les décisions quand il n’est pas complètement ignoré. Très souvent dans notre métier, les décisions sont prises avec une vision très court terme, sans trop penser aux conséquences sur le long terme. Or, ce qui est intéressant sur du court terme l’est rarement sur du long terme, et ça s’exprime notamment à travers la dette technique.

Lorsque la pression économique nécessite de s’endetter, le bon sens voudrait que cette dette soit remboursée dès que la période critique est passée. On emploie souvent dans cette situation l’expression « nous le ferons plus tard ». Mais « plus tard » signifie bien souvent « jamais ». Les décideurs ont en effet toujours besoin de choses plus prioritaires (à leurs yeux en tout cas) que de rembourser la dette technique. C’est ainsi que la dette s’accumule, petit à petit.
"""
Oui, la tentation du surendettement est grande.
Faire un truc vite fait mal fait, qui fait le taff mais qui te pétera à la gueule ou qui te ralentira dans ton travail plus tard. C'est comme construire une maison sur des fondations en polystyrene. C'est d'autant plus chaud sur du code d'infrastructure. Car remettre en cause du code qui tourne en production exige de faire des migrations, elles-mêmes dangereuses et chronophages. Le produit c'est avant-tout une infra qui fonctionne et qui est robuste, rien d'autre.

Il faut réussir à avancer relativement rapidement (avec de l'intégration continue) tout en se projetant sur le long terme. Il y a un juste milieu à trouver.

Lien via http://geekandtips.com/links/?kyw5Xg

oui!
une code review engage à la discussion.
de l'"infrastructure as code" ne peut fonctionner que si il y a un minimum d'échange.
si chacun release dans son coin, on peut vite se retrouver à passer son temps à debugger des trucs et mettre en danger la production.
en particulier si le niveau d'automatisation et élevé (et que le code est complexe)
tout est lié, et la moindre bourde peut avoir des implications qu'on ne verra pas forcément dans l'immédiat.
les tests et surtout la communication permettent d'éviter ces bombes, de les désamorcer, voire de diminuer leur impact.

"""
Lime Text is a powerful and elegant text editor primarily developed in Go that aims to be a Free and open-source software successor to Sublime Text.
"""
code: https://github.com/limetext/lime
roadmap: https://github.com/limetext/lime/wiki/Goals

petite démo de programmation pour générer de la musique
intéressant
via http://shaarli.fr/my/aceawan/?kfDxpQ

Assez d'accord avec Bayard pour dire qu'il faut d'abord apprendre à s'avoir s'exprimer en public; et faire comprendre que ce que tu vas raconter sur ton mur facebook n'aura pas la même portée que les conneries que tu as raconté à tes 3 camarades pendant la récré.
Comme le dit Nekoblog (http://links.nekoblog.org/?ji28IQ) l'un n'empêche pas l'autre, mais autant commencer par ce qui est faisable. Car il me semble que les profs ne sont pas encore formés pour enseigner la programmation.

"""
Scratch est un langage de programmation qui facilite la création d’histoires interactives, de dessins animés, de jeux, de compositions musicales, de simulations numériques, etc. et leurs partage sur le web.

Il est conçu pour initier les enfants, à partir de 8 ans à des concepts importants en mathématiques et informatique, tout en apprenant à développer une pensée créative, un raisonnement systématique et à travailler en équipe.
"""
on m'en a dit beaucoup de bien.