Faire un don ! | | style | statistiques | contactez-nous | plan | lettre d'information

Derniers commentaire(s) [Tous] :


Je fais ce que je veux, avec mes cheveux!

Posté le 06 novembre 2007
Je viens de découvrir cette licence, la "Do What The Fuck You Want To Public License"

http://en.wikipedia.org/wiki/WTFPL

Outre le fait que ça m'a bien fait rigolé (je suis un public facile ;)
je me demande si ça peut-être utile a quelque chose.

> Lire le journal (13 commentaires, moyenne: 5,2).

Michel Sardon

Posté le 22 octobre 2007
Bon, je viens de faire une recherche sur Michel Sardon sur LinuxFr, et bah, je trouve rien!

Je suis étonné car j'étais persuadé de l'avoir connu par linuxFr !
Tellement ses chansons cadrent avec les tro thèmes de ce site.

Bon alors voilà, ben telechargez le, vous verrez bien.

http://www.dogmazic.net/static.php?op=musiqueIndex.php&g(...)

> Lire le journal (14 commentaires, moyenne: 3,5).

Bonnes pratique pour le développement

Posté le 11 janvier 2007
Bonjour,
je suis intéressé par ce que vous considérez comme de bonnes pratiques, que vous avez vous-même expérimenté.

Pour préciser je suis plus intéressé par des exemples pratiques que par la théorie. Et plus par la méthode que par les technique de programmation.

Voici pour ma contribution:

- Toujours utiliser une gestion de configuration, même à un ou deux.
Les avantages sont évidents. Ne pas utiliser une gestion de configuration qui plombe le processus de développement, je pense à un certain logiciel propriétaire assez buggé, lent, contre-intruitif, et qui veut en faire trop. En bref Subversion est très bien.

- utiliser une méthodes automatisée pour générer et déployer l'application.

- plus généralement les procédures manuelles sont à proscrire.

- Ne pas laisser d'erreurs considérés comme "normales":
Tout ce qui est en gestion de configuration doit compiler (!!),
de préférence sans warning. Et quand on passe les procédures automatises (ant, make, script), cela doit se passer sans erreurs.

- Eviter les générateur de code.

- Ne pas mettre en gestion de configuration des fichiers qui sont générés.

- Commiter du code propre et indenté (penser au merge)

- Ne pas utiliser les tabulation mais des espaces à la place

- Ne pas commiter de fichier avec du code en commentaire

- Utiliser des outils réactif: rien de plus agaçant et distrayant que d'attendre devant son écran.

- définir un vocabulaire: ne pas utiliser le même mot pour des choses différentes, même si les contextes sont différents.

Voilà, et vous quelle est votre expérience du front?

> Lire le journal (89 commentaires, moyenne: 2,4).

Caméléon

Posté le 05 décembre 2006
Ces derniers temps j'ai fais un peu de Haskell pour voir à quoi ça ressemblait, et du coup, je me suis remis aussi à coder un peu en Ocaml.

Ocaml est un langage que j'apprécie beaucoup, mais étant développeur Java dans mon travail de tous les jours, je me suis habitués aux IDE qui bossent plus ou moins à ma place (et pourtant j'ai résisté pour quitter emacs et vim).

Bref un environnement de développement pour Ocaml, ça m'interesse.
C'est comme ça que je suis (re) tombé sur caméléon
qui semble-t-il a pas mal bougé ces derniers mois.

J'ai pas encore eu le temps de tester, mais je suis intéressé par d'éventuels retours.

Pour moi, un bon environnement intégrer un outils de test unitaire, une navigation rapide dans le code, un éditeur de texte digne de ce nom, et se liée facilement à CVS ou Subversion.

J'ai eu la chance de pouvoir travailler à l'université (vim/emacs + ligne de commande + python) et dans l'industrie (eclipse + Java), et force est de constater qu'un bon environnement de développement apporte du confort, surtout quand la masse de code devient importante (et pourtant je ne suis pas un fan de Java)

Je me suis toujours demandé pourquoi l'INRIA n'avait pas initié de projet dans ce sens, car à mon avis ça aurait beaucoup joué en la faveur d'Ocaml, et en plus j'ai l'impression que le langage se prête pas mal à l'implémentation d'un IDE (contrairement à Python par exemple)

Je suppose que ça doit exister, mais pour ma part, dans le milieu industriel, je n'ai jamais vu de développeur travailler directement dans un éditeur.

> Lire le journal (4 commentaires, moyenne: 2,3).

Techniques de judo et de ju-jitsu

Posté le 20 janvier 2006
Bon c'est vrai que ça n'a pas grand chose avec le logiciel libre, mais si j'en crois mon entourage, et aussi pour trouver un lien, il semblerait que bon nombre d'informaticiens soient pratiquant d'art martiaux. En tous cas je trouve souvent des informaticiens sur les tatamis.

Bref, le but de ce journal est, et je ne le cache pas, de faire de la pub pour un site que je trouve excellent (et en plus realisé par un ami;)

Ce site qui a demande un travaille énorme, répertorie l'ensemble des techniques de judo et de ju-jitsu. Chaque technique est illustrée par des photos et une video. Nombreux sont les sites de ce genre, mais celui-ci me semble sortir du lot par ça qualité.

On pourra regretter ici le format des video, je trouve que pour un site réalisé par des gens qui ne sont pas a priori sensibilisés au libre, le résultat est plus que satisfaisant.

http://matkano.free.fr/

> Lire le journal (19 commentaires, moyenne: 2).

Python et Eclipse

Posté le 30 septembre 2004
Il y a quelque jours est sorti pydev 0.6, un plugin pour développer en Python sous Eclipse.

http://pydev.sourceforge.net/(...)

Parmi les fonctionnalités intéressantes, on trouve l'autocomplétion, et quelques refactoring ('rename', et 'extract method', les plus utilisés AMA).

Je trouve que ce plugin apporte un confort indéniable pour la programmation d'application Python.

> Lire le journal (8 commentaires, moyenne: 1,8).