Bépo ou le Dvorak Français

Hello,

Comme d'une le blog est un foil mort d'une part, et comme d'autre part j'ai la flemme de faire un post sur un comparatif de la gestion de la mémoire en Java et en C++, voici un post un peu plus simple à suivre. Il va parler de la disposition des touches sur un clavier.

L'origine du Qwerty (ou de l'azerty, vu les différences absolument négligeables entre les deux claviers, ça s'applique à l'un comme à l'autre) vient des machines à écrire. Le principal objectif était de faire un clavier qui tenait la route mécaniquement :

• Les balais qui relient les touches au caractère doivent tous rentrer dans le clavier. Ça explique pourquoi les touches sont décalées verticalement : le centre d'une touche n'est jamais aligné avec celui d'une autre touche.
• Les balais mettent un certain temps à redescendre. Le risque est donc qu'en actionnant deux touches à un faible interval de temps, les balais se coincent. Demandez à mon père, il pourra vous en parler. C'est pour minimiser ce rique qu'on a une telle organisation
• La légende dit que si on peut écrire Typewriter (sur un qwerty) en utilisant que la rangée du haut, c'est pour que les commerciaux puissent plus facilement impressionner les pigeons

Bien évidemment avec un clavier informatique (et déjà avec les machines à écrire électriques), ce genre de considérations n'a plus vraiment raison d'être. D'où un certain monsieur Dvorak qui a eu l'idée d'optimiser la disposition des touches.

Il existe une version française du Dvorak qui est le Bépo (d'après les 4 premières lettres). Cette disposition optimise :

• Les lettres les plus utilisées sont sur la rangée centrale (position de repos en frappe à l'aveugle)
• Alternance de la frappe main droite — main gauche
• Digrammes et trigrammes : essayez de taper (sur un azerty) LKJ et JKL, vous verrez que dans un sens ça sera plus facile
• Possibilité d'écrire en français : les caractères œ, «, » et les accents en majuscules (ÉÀÇÈ) sont indispensables si on ne veut pas faire de faute d'ortho-typographie

L'intérêt de tout ça c'est

• Plus grand confort lorsqu'on frappe (ça a l'air con, mais c'est bluffant)
• Moindre risque de se faire mal (articulations qui font mal, tout ça)
• Moins de fautes de frappe
• Accessoirement, au bout d'un certain temps, pour certains, une plus grande vitesse de frappe
• Caractères plus accessibles pour le dev
• Gain même dans d'autres langues comme en anglais
  

Comment ça s'apprend ? Là il n'y a pas de solution miracle. Il faut s'y mettre exclusivement au Bépo, imprimer le layout et le mettre à coté de l'écran. On peut faire des exercices (y'a plein de programmes qui proposent de faire des gammes). La seule connerie à ne surtout pas faire c'est de mettre des étiquettes sur le clavier. En effet la méthode n'a d'intérêt que si on tappe à 10 doigts. Les étiquettes vont donc uniquement ralentir l'apprentissage. Si vous ne tapez pas à 10 doigts, c'est l'occasion rêvée de vous y mettre !

• Au bout d'une journée : vous connaissez la disposition de toutes les lettres
• Au bout d'une semaine : vous êtes suffisemment à l'aise pour dire des conneries sur irc
• Au bout d'un mois : vous n'avez pas encore rattrapé votre vitesse initiale en Azerty, mais vu le gain en confort, pour rien au monde vous voudriez y revenir
• Au bout d'un an : vous explosez votre vitesse de frappe en Azerty

Voilà ! Tout est dit :) pour plus d'informations, allez sur le site web officiel : http://www.clavier-dvorak.org/

Merci pour votre intérêt, et si vous avez des questions je me ferrai un plaisir d'y répondre. N'oubliez pas que le but est que tout le monde parle un peu de tout, y compris de conneries qui seraient arrivées au boulot, de trucs d'omtis, de trucs intéressants, etc.

Et pour vous convaincre de l'intérêt, regardez cette vidéo :

Azerty vs bépo
envoyé par tiot10

Le Paris JUG a 1 an

Ce soir le Paris JUG fêtait son premier anniversaire dans une ambiance chaleureuse.

Quelques chiffres sur l'année passée :

• Un public composé majoritairement de développeurs seniors et d'architectes ;
  
• Le site Web compte 15000 visites pour les 7 derniers mois (majoritairement d'île de France).
  

A suivi un quicky d'un quart d'heure sur Wicket parTarik Filali Ansary.
Wicket m'a semblé être un framework recherchant des objectifs similaires à GWT : simplifier la vie des développeurs Java pour la création d'application Web.
Rien n'est plus explicite que quelques exemples.
De plus Wicket semble jouir d'une communauté très active : Wicket Stuff, Wicket Library.

Par la suite, nous avons pu nous rendre compte combien les JUG florissent en France. En effet, cette session avait pour invités d'honneur des représentants de tous les JUG français : Christophe Jollivet (Tours JUG), Xavier Hanin (Bordeaux JUG), Nicolas Leroux et Stephane Epardaud (Riviera JUG), Nicolas de Loof (BreizhJug), Sebastien Roul (Nantes JUG), Christophe Meyer, JM Doudoux et Xavier Roy (Lorraine JUG), Gaël Blondelle (Toulouse JUG), Julien Ripault et Cédric Exbrayat (Lyon JUG).

Puis Christian Frei a présenté Jazoon09 de manière très dynamique.

Ce fut ensuite le tour de Stephan Janssen avec pour sujet Parleys.
J'avais déjà assisté à la présentation de la version Flex de Parleys durant JavaPolis07 mais je ne pense pas me tromper en disant que Stephan a eu beaucoup d'effet sur l'assemblée de Juggers en présentant les versions prototype JavaFX et surtout GWT !
Pour la partie moins fun, Parleys proposera bientôt des espaces professionnels pour poster des présentations. Ces espaces seront gratuits pour les JUGs.
Pour finir, Stephan a continué d'envoyer la purée en présentant l'outil de post-processing vidéo qu'il a développé (avec Adobe AIR) pour traiter les enregistrements des conférences Devoxx.

Pour la présentation de Java SE 7 Dolphin, ... et bien, j'étais en train de me faire masser donc je n'ai pas pu prendre de notes ! D'ailleurs merci aux masseurs et aux organisateurs du Paris JUG, c'était un très bonne idée, et toutes mes excuses à Thomas Chamas.
Par contre je me souviens en avoir entendu parler durant une keynote de Devoxx08.

Le dernier quicky traitait de l'état de l'art et de l'utilisation de Java dans les jeux vidéo par Julien Gouesse.
J'avoue qu'il m'a bluffé. Je ne savais pas que des jeux développés en Java était commercialisés même s'ils se comptes sur les doigts.
Pour les personnes intéressés par ce genre de développement, le code source du doom-like TUER développé par Julien est dispo ici.

1er post : présentation et git (gestionaire de code decentraliser)

Mineurs, Mineuses, bonjour !
Les autres bonjour aussi.

L'origine de ce blog, c'était qu'on se disait que ça serait bien de savoir ce qu'on fait, de s'échanger des infos intéressantes autour de l'informatique au lieu de le faire bourré.

On invite donc tout le monde à parler de ce qu'il fait, de trucs chouette qu'il a apris, humeurs diverses etc. Le tout est de rester dans le vague nuage qu'est l'informatique.

Pour se lancer, je vais tenter de présenter Git, un outil que je ne maîtrise ni par les concepts, ni par la pratique, mais qui me semble très intéressant.

Gestion de version décentralisé

Vous connaissez tous CVS ou Subversion. Le but est de faciliter le travail collaboratif quand il s'agit de code, mais aussi de pouvoir voyager dans le temps pour voir les évolutions, trouver la source d'un bug etc. Ces deux sont centralisés : un serveur centralise toutes les contributions des utilisateur, et tous les utilisateurs vont y déposer leurs contributions et récupérer celles des autres.

Un gestionnaire décentralisé, vous l'aurez deviné, n'a pas de serveur central. L'idée derière c'est chaque développeur a son propre dépot, et tout le monde va chercher ce qu'il veut, chez qui il veut. Le but est de fluidifier le développement : on clone le dépot d'un logiciel qui nous intéresse et on code dessus.

Les plus connus sont Git et Mercurial, mais il y a également bazaar (utilisé par launchpad), Darcs (utilisé par ion), Bitkeeper (propriétaire, initialement utilisé par Linux).

Pour que ce soit un peu plus clair, je vais développer un peu plus Git qui est le seul que j'aie manipulé.

Git

Git a été développé lorsque Bitkeeper ne pouvait plus être utilisé gratuitement pour le développement Linux. Le développement a commencé en avril 2005 et la version 1.0 est sortie en décembre de la même année.

Preuve de sa robustesse, il est utilisé par Linux, xorg, bref de gros gros projets. Par contre Mozilla par exemple a finalement décidé de ne pas y passer au profit de Mercurial.

Travailler seul

• mkdir mon_projet; cd mon_projet; git init hop ! votre repository est fait
• Code code (ou pisse pisse pisse pisse pisse pour ceux en SSII)
• git add mes_fichier_modifiés; git commit et votre travail est commité

Rien d'exceptionnel venant de subversion ou cvs (peut-être à part le fait d'explicitement devoir ajouter les fichiers à commiter). Et si maintenant je veux mettre tout sur un serveur pour synchroniser mon travail entre deux PCs ou pour sauvegarder ?

• cd ..; git clone mon_projet mon_projet.bis J'ai cloné mon dépot. Tout l'historique est gardé etc.
• scp -r mon_projet.bis mon_serveur_ssh: Hop, j'ai mon dépot sur mon serveur ssh
• cd mon_projet pisse pisse pisse, commit, pisse pisse etc.
• git push ssh://mon_serveur_ssh/~/mon_projet.bis/ Et tout est mis à jour sur le serveur
• Sur l'autre ordinateur, la première fois git clone ssh://mon_serveur_ssh/~/mon_projet.bis
• Les fois suivantes : git pull ssh://mon_serveur_ssh/~/mon_projet.bis
  

Bon c'est chouette tout ça, mais tout le monde n'est pas un thésard autiste à faire son bout de code dans son coin; il y en a qui font de trucs utiles, et qui travaillent colaborativement !

Travailler à plusieurs

Imaginons que suite à trop d'alcool vous vouliez participer au développement de Linux. Il vous suffit de cloner le dépot de Linus (évidemment git fonctionne aussi au travers d'autres protocoles que le ssh). Vous codez, commitez, revenez sur vos modifications, faites des mini-branches pour tester etc. Vous finissez par avoir une amélioration que vous considerez comme pertinente. Vous envoyez un mail à Linus « hey, hey, hey, j'ai fait un truc super cool, tu devrais l'intégrer dans le noyau ! Voici mon dépôt git ». S'il pense la même chose, il fait un merge et c'est réglé.

Si on est dans le contexte d'une entreprise, on peut vouloir que tout soit centralisé dans un seul serveur. Il est parfaitement possible de gérer les droits pour un push, et imiter les accès en écriture d'un traditionnel Subversion.

Informations en vrac

• Performance en vitesse : c'est tout le temps mis en avant. J'imagine que pour projet comme Linux c'est important pour les gros merge
• Performance en place : il est dit que tout l'historique des modifications du noyau 2.6 fait la moitié de la taille de la version courante
• Git n'a pas de numéros de version (à la CVS) ou de commit (SVN), mais utilise un hash sur chaque objet pour l'identifier dans l'espace et dans le temps (un objet peut être un fichier, une arborescence etc.). Un hash permet donc d'identifier à la fois un fichier/arborescence à un commit particulier. Un corollaire est qu'il est possible de ne récupérer qu'une arborescence précise à un instant précis.
  
• Il existe de nombreux outil pour utiliser Git sur sa machine tout en travaillant avec un dépot central
• Je ne maîtrise pas l'outil, alors pardonez toute connerie que j'ai pu dire dessus
• Git est juste un exemple, les autres décentralisés sont également très bien d'après ce que j'en ai lu (et débatu avec Paul)
  

GitHub ou le Facebook du code

http://github.com/ est un dépot Git. Derrière c'est une entreprise privée, mais pour les dépôts open-source c'est totalement gratuit. Contrairement à la majorité des forges (sourceforge, berlios, google code etc.), le dépot est orienté utilisateur et non pas projet. Chaque utilisateur a sa liste de projets sur lesquels il travail. S'il veut collaborer sur un autre projet, il se contente de cloner le projet, et celui-ci apparait dans ses projets. Un simple click permet de notifier au développeur initial qu'il pourrait intégrer les modifications (pull request).

L'idée c'est de vraiment créer un réseau social de développeur. Chacun met son petit bout de code (comme des photos sur Facebook) embryonnaire qui ne mérite rien. Quelqu'un d'autre le récupère et tripatouille autour (tag la photo). Si jamais ça donne quelquechose d'utile on intègre les modifications. On peut également juste suivre un projet par curiosité.

Ma page github c'est https://github.com/Tristramg si ça intéresse quelqu'un.

Considération pseudo-métaphysique ou la philosophie informatique au vin rouge

Par rapport à la gestion de code centralisée, je dirais qu'il y a deux grands changements

1. C'est le développeur qui est au centre et non pas le code. On développe de la même manière qu'on travaille : on fait un truc dans son coin, on le montre au collègue qui prend que ce qui est bon à prendre, et quand tout est nickel on va voir le patron. Le fait de pouvoir cloner et commiter directement un projet aide aussi à se lancer directement dans un code existant.
   
2. Ça encourage beaucoup plus au bidouillage dans un sens positif. Dans un dépot central on a toujours un peu honte de commiter de la merde et que ce soit visible à tout le monde, donc on fait attention, on branche trop rarement. En décentralisé on branche plusieurs fois par jours. Si ça marche pas, on oublie la branche et personne ne se rendra compte qu'on a eu une idée débile. C'est idiot que de tels sentiments humains perturbent le dev, mais qui peut le nier ?

Merci d'avoir lu jusqu'au bout :) Pour la suite je parlerais bien un peu de ma thèse et de Qt. Peut-être un troll de bas étages pour dire que le java c'est nul...
En tout cas si vous voulez écrire quelque chose sur votre vie, surtout n'hésitez pas, c'est quand
même le but premier de ce blog. N'hésitez pas non plus à faire remarque les fautes diverses de français.