riduidel’s posterous

Je suis quand même une tanche, moi.
hier, l'un des premiers trucs que j'ai voulu faire avec Google Wave a été d'envoyer un message posterous pour dire à quel point c'était bien.
Malheureusement, je n'avais pas vraiment compris le fonctionnement des Blips
Et surtout le fait qu'il fallait cliquer sur le bouton "done" avant de cliquer sur le bouton "login to posterous". Maintenant que je suis loggé, j'en profite.
Et je peux donc vous dire qu'à mon avis, la feature qui fera décoller Google Wave (et peut-être le marchand de saucisses) sera l'édition de code collaborative à travers le web, un peu à la façon de Bespin » Code in the Cloud , ce qui ne sera peut-être pas trivial à implémenté, mais vachement pratique pour les boîtes distribuées.
Pour être pragmatique, qu'est-ce qu'il faut pour implémenter tout ça ?

• 
  Un gadget pour éditer du code avec de la coloration syntaxique (un peu comme KaSyntaxy - Google Wave Bots Wiki )
• Un outil qui sauvegarde automatiquement le code dans un SVN/GIT en tenant compte de l'utilisateur de wave
• Et un serveur d'intégration continue façon Hudson.

Et avec ça, on pourra facilement produire du code (mais pas forcément le débugger) depuis son navigateur.
Je me demande si d'autres ont déja pensé à cette idée ... (en tout cas, d'autres ont déja posé la question).
je sais qu'il eixste aussi déja des waves de jeux de rôle : Google Wave RPGs = Excellent Experience!
Bref, Wave ne va pas tarder, à mona vis, à devenir un outil génial pour la collaboration en "live".

Loading mentions Retweet

Dans majick-properties, je suspecte le code que j'ai écrit d'être potentiellement à l'origine de fuites de mémoire. Et ça, c'est plus qu'embêtant quand on fait une bibliothèque dont le but est de faciliter la vie.

Surtout que, traditionnellement, la chasse aux fuites mémoires en Java est compliquée : il faut un profiler (en Java, le meilleur rapport qualité/prix est obtenu avec le profiler de NetBeans), trouver le truc qui foire, le corriger, et espérer que ça tienne 

Heureusement, la communauté Java dispose maintenant de méthodes permettant de vérifier que ces fuites de mémoire ne reviennent pas. La première que j'ai trouvé utilise une librairie dont le nom seul est un hommage au bont goût : insane. Et la deuxième utilise jUnit pour parvenir au même résultat, ce qui fait que je vais pouvoir utiliser les concepts dans mes tests. Je me demande quand même s'il ne va pas falloir que je regarde insane de près pour améliorer ça, parce qu'en fait, cette deuxième solution ne semble pratique que quand on sait précisément ce qu'on cherche, alors que la première est plus efficace en terme d'exploration.

Tiens, au fait puisqu'on parle de mémoire en Java, il semble que cet article : understanding weak references, soit une mine d'infos sur les distinctions subtiles entre weak, soft et phantom references.

Loading mentions Retweet