small_duck a écrit 139 commentaires

As-tu quoi que ce soit dans les logs d'Ocsigen (/var/log/ocsigen)? N'hésite pas à me contacter sur small_duck at technoturtle.net si tu as encore des soucis.

Merci de tes encouragements. Les commentaires du journal m'ont ouvert les yeux sur tout un tas d'améliorations possibles, et, comme dirait Léonard, "mon cerveau fourmille tellement d'idées que si un tamanoir passait dans le coin, il me courrait derrière !" :)

Intéressante remarque sur le stockage des fichiers dans la base de données. Énormément de ressources sur le Web critiquent cette approche, qui tend à faire des bases énormes et peu flexibles. Mon choix reposait sur ma préférence d'avoir tous mes documents centralisés au même endroit, facilitant ainsi la sauvegarde sur mon serveur distant. Mais je conviens que c'est une approche qui ne va pas monter en charge indéfiniment. Peut-être pourrais-je implémenter une approche combinée.

Et OCaml, c'est bon, mangez-en!

Ah ah, en effet, bien vu! Je ne m'étais pas rendu compte que ma ligne de compilation était un tout petit peu plus compliquée que ce que j'ai mis dans la doc. Il faut faire:

omake --absname

Et avec les chemins absolus, OMake fait les bons liens symboliques et retrouve ses petits dans le répertoire debug. Sinon, en effet, changer debug en src fonctionne impeccable également. La doc est corrigée. Merci!

Bien vu! Images chiffrées?

J'ai généralement trouvé assez difficile de travailler avec du PDF. Le résultat de la numérisation étant une image, il est ardu de le réintégrer sous forme de texte dans un PDF sans dénaturer le document. Initialement, je passais tous mes documents via un OCR, pour en indexer le contenu dans la base, mais n'ayant pas trouvé de bonne bibliothèque C++, et utilisant au final surtout les tags, je n'ai pas intégré la fonctionnalité dans le client lourd.

Vis-à-vis du PNG, une fois de plus, c'est la numérisation qui cause souci: les blancs ne sont pas si blancs, beaucoup de documents ont des fonds bariolés, et au final un PNG prenait une place folle. En comparaison, un JPG suffisamment grand (150 dpi) reste lisible, et prend bien moins de place. Mon backup distant prend déjà suffisamment de temps comme ça :)

J'imagine que l'import pourrait être plus intelligent, et choisir le format le plus adapté pour chaque page.

J'ai beaucoup de mal à combiner la rotation du monde d'une part, et les déplacements du personnage d'autre part. Et trimballer la clé est particulièrement ardu. Bon jeu, qui fait réfléchir!

La version française du Slashdottage :)

Le geste qui sauve, un lien Bittorrent?

Il m'a fallu un petit moment pour faire fonctionner tout ça, mais ça marche très bien. Un petit fichier INSTALL avec quelques instructions serait utile.

Sur Squeeze, il m'a fallu:
- Installer tous les paquets libclaw-*-dev
- cmake .
- make -j 4
- cd roller-painting
- ./roller-painting

Bravo pour le concept, c'est très prenant et plutôt rigolo. Chapeau pour avoir mis un tutoriel.

Une seule adresse, des centaines de problèmes particulièrement redoutables, c'est Project Euler. J'essaie de m'en résoudre quelques uns régulièrement, c'est très bon pour se remémorer des points importants sur la complexité des algorithmes, la montée en charge, l'utilisation et l'implémentation de théories mathématiques pour résoudre des problèmes spécifiques. Et c'est extrêmement addictif!

Maintenant, sur le niveau technique en entreprise: j'ai la chance de travailler dans une équipe où le niveau technique compte beaucoup, et où l'on pourra causer lolcats à un instant et des avantages comparés des skip-list contre les tableaux paresseusement ordonnés à l'instant suivant. C'est évidemment d'abord une culture d'équipe, mais cela se travaille. Ce que je trouve marche très bien:

• Revues de code. C'est une très bonne occasion pour apprendre, que ce soit du point de vue de celui qui subit la revue que de celui qui la fait. Et cela améliore énormément la qualité du code.
• Plus difficile pour convaincre un manager, mais nous avons dans notre équipe un équivalent du Google 5%: 1 jour par mois, nous avons la possibilité de travailler sur un sujet de notre choix, typiquement une amélioration du système, un de ces bugs pour lesquels "on a jamais le temps de s'y mettre", ou l'étude d'une nouvelle technologie ou d'une bibliothèque alternative. L'on présente ensuite son travail lors d'une réunion. C'est le moment où l'on découvre que son collègue très "senior" est en fait un pythonneux pur et dur, qu'un autre s'est déjà tapé tout le boulot pour assurer la compatibilité avec la prochaine version du compilo, ou même que son chef (quand ils veulent bien jouer le jeu) ne dédaigne pas taper quelques lignes de code de temps en temps. Avantage final pour tenter de convaincre la hiérarchie: c'est excellent pour le moral des troupes.

En entreprise, Subversion semble encore bien tenir la route. Les manageurs connaissent, le concept de dépôt centralisé les caresse dans le sens du poil, les utilisateurs sont canalisés dans un processus de développement (développement sur le tronc, et branches de releases ou de fonctionnalités), et tout le monde sait à peu près l'utiliser (ça se gâte quand on commence à toucher aux branches). Les utilisateurs chevronnés passent par git-svn, et tout le monde est content.

Aucune des améliorations de la 1.7 n'est particulièrement enthousiasmante, mais c'est bien de voir que le boulot continue. Bon courage aux mainteneurs!

Quelle avancée prodigieuse ! Il est possible d'utiliser 63 bits sur les 64 pour les nombres !
Je trouve ça plutôt malin. Ça permet au runtime de ne pas à avoir à utiliser le boxing pour les types entiers, ce qui est très bon pour les performances, et est une optimisation utilisée par bon nombre de machines virtuelles. Alors qu'avec 32 bits, la limite se situait à 1 milliard et des brouettes (compter le bit de boxing et le bit de signe), ce qui est un poil limite, en 64 bits, c'est suffisamment haut pour ne généralement pas avoir à s'en préoccuper.

Maintenant, il est vrai que +. pour les flottants, ce n'est pas bien pratique, et c'est un gros défaut du langage, d'autant plus dommage que Haskell résout le problème fort élégamment avec les type classes. Mais ça serait dommage de jeter bébé avec l'eau du bain: une fois que l'on a compris où vont les point virgules, OCaml est un langage avec lequel il est très agréable de programmer.

En 64 bits, les entiers natifs OCaml passent sur 63 bits, ce qui permet de résoudre bien plus de problèmes de Project Euler sans avoir à passer en Int64 ou en BigInt, dont les syntaxes sont moches et les performances pas terribles.

Pour des compiles plus rapides!

Pour un projet C++, OMake est mon préféré. J'ai bataillé avec gmake et CMake, et certaines constructions sont bien plus faciles à obtenir avec OMake. Un exemple de dépendances courant est par exemple de devoir d'abord compiler un petit programme, lequel va générer du code, pour ensuite compiler le plus gros programme.

Avec gmake et CMake, c'est un cauchemar et la gestion des dépendances devient très complexe, au point qu'il devient généralement plus aisé d'avoir deux cibles, une pour la génération, et une pour le programme principal. De plus, même si le code généré demeure inchangé, la date du fichier, elle, a changé, et on se retrouve avec des recompilations monstres qu'il faut dompter à coup de copies temporaires crades.

Avec OMake, qui gère explicitement le code généré, et se base sur le contenu du fichier pour détecter les modifications, c'est fait en deux coups de cuiller à pot, et les compilations sont minimales mais correctes. L'on regrettera peut-être la difficulté de faire des compilations "hors sources" (les mount virtuels aident un petit peu), et la relative difficulté à utiliser des commandes un peu plus complexes, la petite taille de la communauté n'aidant pas. Par exemple, le support des en-têtes pré-compilées requiert un bidouillage des règles initiales qui est probablement simple, mais absolument pas évident.

Les move semantics sont un sujet un petit peu complexe, mais ce qui est agréable, c'est que l'on peut s'y mettre doucement. Sans rien faire, déjà, le code utilisant lourdement la bibliothèque standard profitera d'une amélioration de performances. Ensuite, l'on peut commencer à écrire des constructeurs par copie pour ses objets les plus utilisés, et continuer dans cette voie.

J'aime également beaucoup std::chrono, qui permet de mesurer le temps et de faire des calculs sur des intervalles. Les templates sont intelligemment utilisées pour vérifier les unités à la compilation, afin de ne pas confondre ses secondes avec ses microsecondes.

C'est par phases. Et étrangement (ou pas tant que ça, en fait), j'ai d'autant plus envie de coder le soir, que j'ai peu codé pendant la journée, parce que j'ai écrit des specs, fait du test, ou du recrutement.

C'est principalement une histoire de motivation. Un problème m'intéresse, ou je me motive enfin pour réécrire un jeu qui m'a marqué durant ma folle jeunesse de gamer. Ça me travaille, je surfe furtivement sur de la doc pendant la journée, et je code le soir et le week-end. Et puis, quand le problème a été résolu en principe et que j'ai un prototype, la rage de vaincre m'abandonne, et je laisse malheureusement tomber. S'ensuit alors une période de moulage intense.

Je me force à écrire du code générique et à tout coder dans une même dépôt, afin de gagner du temps sur le prochain projet.

Alors, cela vaut-il le coup, vu que jamais rien n'en sort?

J'ai l'impression d'en retirer quelque chose. Pour le boulot, pour ma culture, et puis coder c'est un hobby plutôt bon marché, une fois passé l'investissement initial dans le hardware.

Mais je connais de nombreux codeurs qui ont de très belles carrières sans coder une seule ligne chez eux. Et quand ils passent managers, ils se remettent à coder à la maison :)

Ne pas oublier la variation pour le cinéma de la licence du CNRS:

CeCILL-B 2000.

Parce que la plupart des noms de marque peuvent s'écrire de bien des manières. Prenons une célèbre marque de fast-food. L'on peut commencer par mac, mc, mac-, mc-, et combien d'autres. Il va donc falloir raquer 150€ pour chaque?

J'aurais envie de dire qu'au contraire, le risque de confusion avec son alter-ego en xxx est plutôt faible si l'on est pas déjà sur le créneau. Autant ignorer les squatters et garder ses 150€.

Et qui se contrôle au clavier. Je croyais qu'Emacs occupait déjà le terrain...

Et l'éléphant de Postgres.

Tout appareil électrique doit répondre à un certain nombre de normes en matière d'ondes électromagnétiques afin de limiter les interférences. Pour le matériel grand public, cela assure généralement que rien de bien grave ne peut arriver. Pas d'inquiétudes, donc.

J'ai trouvé qu'en finance, les problèmes à résoudre sont variés et intéressants, et les équipes suffisamment petites et mouvantes pour pouvoir espérer faire une réelle différence. Avec quelques années d'expériences, l'on peut espérer avoir un réel impact sur l'architecture des systèmes, sur les technologies utilisées, ou sur l'organisation du travail.

Il est également agréable de travailler dans une industrie qui se donne les moyens de ses ambitions en termes de qualité de travail. Il est rafraîchissant d'entendre mon manager se plaindre que je n'ai pas assez d'écrans, et me demander si je veux une machine plus puissante.

Après, cela reste un boulot où l'on aide des gens très riches à devenir encore plus riches...

Ça fait un certain temps que je me suis penché sur la question, mais il me semble que l'argument contre le chaînage des techniques de cryptage était que la combinaison est généralement plus facile à déchiffrer que la somme des parties, car mieux à même de faire ressortir des invariants, ou de magnifier les faiblesses des algos, un peu comme faire un double ROT13. Maintenant, ce n'est peut-être plus vrai avec les algos modernes.

Et en plus, je suis même pas foutu de cliquer sur le bon "répondre" :(

Vais aller me coucher.

Il a fallu que je cherche le sens de DPI... Pour ceux qui sont aussi nuls que moi, il ne s'agit donc pas de "double pénétration intellectuelle" (quoique) mais de "deep packet inspection".