Dev Blog AF83

Les ateliers du lundi deviennent progressivement un rendez-vous important dans la semaine d’AF83. Avant-hier, nous avons pu assister aux 3 sessions annoncés dans le post précédent. La première concernait le protocole HTTP. Ori nous a expliqué l’histoire du protocole HTTP, les différentes versions et les règles de compatibilité entre versions, la RFC 2616, les différentes méthodes HTTP et les headers les plus courants… bref, tout ce qu’il savoir sur HTTP et bien plus encore. Pour ceux qui voudraient passer aux travaux pratiques, je conseille les plugins firefox Live HTTP headers et Firebug (onglet réseau).

La seconde session sur les mondes virtuels était très dynamique. Thierry nous a montré les vidéos de ce qui ce fait actuellement dans les mondes virtuels comme SecondLife, et surtout, il nous en a mis plein la vue avec les vidéos de la prochaine génération de moteurs. Enfin, j’ai présenté une session sur UNIX Toolbox. Vous pouvez télécharger les slides au format OpenOffice ou au slides au format PDF.

Les ateliers continuent, avec dès lundi prochain (le 4 août), 2 sessions : la première, à 10H30, animée par Michel, sera consacrée au langage de balisage DocBook (très utile pour écrire de la documentation technique), et la seconde, à 11H30, est la très attendue présentation par Lucas sur l’hébergement de sites web.

La semaine suivante, le 11 août plus précisement, vous pourrez assister à 3 sessions :

• à 10h30, Romain présentera le fonctionnement du re-nouveau service HCL ;
• à 11h30, Pierre nous exposera les techniques de référencement/SEO ;
• à 12h30, Olivier animera un atelier sur les bonnes pratiques sur les tickets Trac.

Et on enchaîne la semaine d’après, le 18 août donc, avec toujours plus d’ateliers :

• à 10h30, Michel nous fera découvrir la puissance de XSLT
• à 11h30, Charles-Henri nous révélera des astuces sur ViM avancé
• à 12h30, il y aura probablement une session, mais cela reste à confirmer…Voilà, je crois que tout est dit…

Ha, non, encore une dernière chose : cela se passe au 64, 2ème étage à gauche.

Afin de mieux appréhender ViM, j’ai fait une présentation à ceux qui étaient intéressés chez AF83. Je propose les slides pour ceux qui veulent garder une trace, ou se faire une idée.

Un petit post depuis le RailsCamp Paris à la Cantine :

• Guillaume Desrat a présenté 2 sessions. Ses slides sont en ligne : Présentation Ruby France et Applications web en entreprise . Merci à lui.
• Si vous êtes intéressé par l’offre d’hébergement de Bearstech, envoyez un mail à lbonnet@bearstech.com.
• Mes slides sont également en ligne : Plateformes de réseaux sociaux
• Pensez au MashPit !

Nous travaillons actuellement sur un site web de réservations d’activités pour des particuliers. Un des points forts de ce site sera la mise en avant de 3 journées-types (appelées également pass). Comme ces recommandations doivent tenir compte d’un certain nombre de contraintes (disponibilité, compatibilité entre les activités, heures de début imposées, etc.) dont certaines évoluent au cours du temps, il a fallu mettre en place un moteur de recommandations. Celui-ci utilise la programmation linéaire via le programme GLPK (licence GPL). La modélisation mathématique a fait l’objet d’un exposé en interne. Les slides sont disponibles au format PDF : les slides. Vous pouvez également consulter les fichiers de tests pour GLPK : le modèle et un jeu (minimal) de données.

Joel Spolsky is a software developper and a famous blogger, mostly known for its work at Microsoft. He had written a test to known if developpers work in good conditions. This test is composed of 12 questions that can be answered quickly be yes or no. If you want more details, the original post is a must read.

So, I wanted to known how we perform at AF83, and I have made the test for the Noumba project. Here are the results :

1. Do you use source control?
Yes, we use subversion.

2. Can you make a build in one step?
Yes. As Noumba is a web app, I have considered that a build is a deployement on our testing environment.

3. Do you make daily builds?
Yes.

4. Do you have a bug database?
Yes, trac is used for that and other things (wiki, timeline).

5. Do you fix bugs before writing new code?
Yes, except for some exceptional bugs

6. Do you have an up-to-date schedule?
Yes/No, it’s work in progress.

7. Do you have a spec?
No, only documentation on some specific parts.

8. Do programmers have quiet working conditions?
No, but it’s better than it was : no more mobile ring.

9. Do you use the best tools money can buy?
Yes.

10. Do you have testers?
No. I think it’s our main weakness :-/

11. Do new candidates write code during their interview?
No, but I don’t consider this as a drawback. Interview without code can be very insightful.

12. Do you do hallway usability testing?
Yes/No, sometimes we do, but not very often.

So, our score is 7/12, not too bad, and we are improving it. And you, what’s your score ?

Of Lately we have been churning more and more Ruby on Rails code for our web applications. Its source-code is becoming longer and longer. It was time for us to think about formalizing the documentation process.

After a short search, we found rdoc and it seems to suit our needs. It has good source-analysing basis and interesting features such as diagram generation. The problem came from rdoc youngness which led to two issues :

• the lack of documentation, the only relevant document is the rdoc's README file
• In fact, there are no standards nor conventions on tags to describe a parameter, an instance variable, the author of the code or anything else

We had to understand that this

is not a tag. It's just a syntax for something to be parsed as a definition list.

So we decided to make our own convention, trying to be as near as possible to existing documentation conventions while banking on the emergence of a hypothetical future standard. So we looked at the Ruby source-code, seeking for its developpers conventions. Guess what... There are no comments in Ruby code nor in rdoc's one (or very few, almost none are structured).

So... we were forced to set out to do our own convention. As we do a lot of PHP code, we decided to use the inspiration of the JavaDoc inspired phpDocumentor syntax and PhpDoc tag names. We added the :: to keep compatibility with rdoc and we added home-made syntax rules such as the ## to spot the begining of a comment readable with our new convention. And the result is...

Strict conventions on documentation are a necessity today. It makes running automated systems on the code much easier, the lack of such a convention is a gaping hole in the Ruby On Rails arena. And no, the code is not the documentation, neither are Unit Tests.

What we tried was to get the minimal set of "tags" that are necessary for an API style documentation which makes writing the code in a distributed fashion much easier. While keeping in mind how important it is to stick to the existing so that we can re-use tools that are already there.

Now, we can start commenting soundly... hoping others will jump on the wagon and we can start working on a general solution.