Journal De tout, de rien, des bookmarks, du bla bla

Posté par  (site web personnel) .
Étiquettes :
28
17
juil.
2012

Sommaire

Introduction

Je suis un peu en retard par rapport à ce que je voulais faire (boulot, changement, toussa), et au final j'ai pas trop de liens intéressants. Mais tant pis, voici la petite sélection de la semaine passée avec, je l'espère, tout de même quelques liens qui pourront vous intéresser.

Un peu de contenu

Développement

Voici une petite présentation de CoffeeScript. Si vous connaissez déjà le langage vous n'apprendrez rien du tout. Si vous ne le connaissez pas et connaissez javascript çar peut être intéressant. Entre autre ça pointe certains points négatifs de CoffeeScript et ça c'est bien (il est dommage dans certaines prez de les masquer, connaître les limites est vraiment important je trouve).

C'est plus de la sécurité que du développement, mais voici un article intéressant et plutôt simple à lire concernant Stuxnet et ses mises à jour.

Voici encore un outil de code reviews, barkeep. Je ne l'ai pas testé, mais si quelqu'un a un comparatif / retour entre les différents outils existant (reviewboard, crew, etc.) je suis preneur.

Oula, je ne pensais pas qu'on pouvait encore faire des migrations du genre : les ports de FreeBSD viennent de migrer de CVS vers SVN ! Hum, je comprends qu'on n'a pas forcément réellement besoin de plus que SVN (quoique…) mais je trouve étonnant de migrer vers SVN tout de même. Quelqu'un aurait des infos sur pourquoi SVN et pas Git par exemple ?

Misc

Google a libéré les slides utilisées durant Google I/O. Évidemment (ou pas) il s'agit de slides à exécuter dans un navigateur web récent… sous webkit. Je n'ai pas vraiment essayé avec un autre, je ne sais pas trop ce que ça donne, mais surtout je ne sais pas pour quelle raison cela ne pourrait pas fonctionner avec, par exemple, un firefox récent. Quoi qu'il en soit ces slides sont plutôt sympas, assez propres et claires. J'aime beaucoup le fait qu'on puisse ouvrir plusieurs fois le même document pour avoir l'un en plein écran (pour le public) et un autre avec les commentaires par exemple (un mode présenteur quoi). C'est vraiment un point intéressant pour le coup (la communication se faisant via postMessage). Ça semble également assez bien adapté à la présentation d'extraits de code. Plutôt bien quoi.

Là où je suis par contre plutôt surpris (mais bon, je ne devrais pas il est vrai) est qu'ils n'utilisent pas les différentes libs Google mais à chaque fois un équivalent :

C'est un peu étonnant, et j'ai parfois du mal à capter la logique. Surtout que si on continue à regarder ces points, on arrive entre autre jusque Yeoman, même si pour le coup j'attends un peu de voir et tester.

Pour rester sur le même sujet, il existe d'autres outils permettant de faire des présentations en HTML5. Entre autre, voici celui utilisé par nono (mais non je ne cherche pas à me faire bien voir, il n'a qu'à pas balancer des choses intéressantes :-) ) : Slide'em up. Il y a tout de même quelques différences. Entre autre, je n'y ai pas vu de mode présenteur (j'affectionne particulièrement pour ma part), et c'est basé sur du Ruby. L'écriture des slides est également réalisée en Markdown (c'est a priori aussi possible pour celles de Google). De ce que j'en ai compris, il s'agit par contre d'un fork de ShowOff avec des thèmes et surtout le remplacement de Sinatra par Goliath. De ce que j'ai compris, il s'agit de serveurs web en ruby, Goliath étant asynchrone (un peu comme si on faisait du nodejs, non ?). Sinatra est plus un DSL et non un vrai serveur ? Si nono passe pas là je suis pas contre une explication de ce choix de remplacer l'un par l'autre. En fait, juste pour bien comprendre les différences entre les deux et pourquoi c'est plus intéressant d'avoir Goliath dans ce cas que Sinatra.

Voici, beaucoup plus léger, une photo que j'ai vu passer sur twitter, peut-être vous aussi : good - cheap - fast. Une façon assez sympa de présenter trois catégories de réalisations, un peu comme le théorème CAP finalement.

Humans.txt est une initiative assez intéressante. Il s'agit de replacer un peu d'humain dans les sites web. On a par exemple des fichiers robots.txt pour parler aux moteurs de recherche. Là il est question d'un fichier qui, pour le coup, est destiné aux humains : déclaration des auteurs, des créateurs, remerciements. Par contre, j'ai pas bien compris la ligne IDE, je vois pas trop ce que ça vient faire dedans… Vous trouverez une explication sur le site robots.txt…

Graphisme & co

Si vous utilisez balsamiq pour faire vos maquettes d'interfaces, vous serez probablement ravis d'apprendre qu'il existe une nouvelle alternative, moqups. Il s'agit d'un outil assez similaire, en html (au lieu de flash/air) et, qui plus est, gratuit. Par contre, ça ne semble pas libre.

Liste des liens présentés

Développement

Misc

Graphisme & co

  • # Quelques infos sur slide'em up

    Posté par  (site web personnel) . Évalué à 10.

    Comme je lis régulièrement ces journaux bookmarks avec plaisir, je vais en profiter pour aussi donner quelques infos sur slide'em up.

    Historiquement, j'ai commencé par utiliser showoff pour faire mes slides, mais j'avais quelques problèmes avec : des images qui ne se chargeaient pas dans le bon ordre, difficile de modifier la CSS par défaut, etc. Du coup, j'ai voulu contribuer. J'ai donc été voir le code et j'ai découvert que c'est un empilement de gros hacks les uns par dessus les autres et que j'allais avoir bien du mal à comprendre précisément comment ça marche. Je ne jette pas la pierre à schacon, il a écrit ça en vitesse pour ses propres besoins, puis ça a commencé à avoir du succès et il a intégré des patchs pas toujours très propres mais qui ajoutaient des fonctionnalités, et il n'a jamais trop pris le temps de nettoyer le code.

    De mon coté, j'étais en train de préparer une conf sur Goliath et pour mieux appréhender la bête, j'en ai profité pour recoder un mini showoff-like avec Goliath. Puis, comme ça marchait pas mal, j'ai ajouté des fonctionnalités et des themes. Et depuis, je ne me sers plus de showoff mais uniquement de slide'em up pour faire mes présentations (enfin, sauf celles que je fais à plusieurs où j'utilise ce que l'autre personne veut utiliser, je ne suis pas très difficile pour ça tant que ça permet d'avoir un fichier dans un format ouvert à la fin).

    À propos de Sinatra et Goliath, ils ne sont pas tout à fait équivalent. Pour comprendre la différence, je vais commencer par introduire un troisième larron : Rack. C'est un petit bout de code qui fait l'interface entre les serveurs applicatifs et les frameworks dans le monde Ruby. En gros, le serveur applicatif va recevoir du texte venant du réseau, l'interpréter comme du HTTP et ainsi construire un tableau des headers HTTP et éventuellement un body. Il va passer les deux au framework sous une forme convenue (celle décrite par l'interface Rack) qui lui va regarder le chemin et en déduire du code à appeler. Ce code va construire une réponse que le framework retournera au serveur applicatif, à nouveau sous une forme convenue par Rack (un triplet code de retour, headers et body). Le serveur applicatif peut alors envoyer ses informations sur le réseau.

    Sinatra est un framework tel que décrit ci-dessus. Par contre, la position de Goliath est plus floue : il fait à la fois serveur applicatif, rack et framework. Rack permet de décrire des échanges de type une requête -> une réponse. Mais c'est un modèle qui ne convient plus quand on veut faire des WebSockets ou streaming HTTP. Il existe des modifications de Rack pour faire ça sous diverses formes. Goliath implémente une de ses modifications et elle a l'inconvénient de lier très fortement la partie serveur applicatif de la partie framework. Du coup, jusqu'il y a peu, utiliser Goliath voulait dire que l'on utilisait rien d'autre. Ça a changé un peu récemment : il y a des gens qui utilisent Goliath comme serveur applicatif avec un autre framework (Grape), mais ça se limite aux échanges classiques 1 requête -> 1 réponse (pas de WebSockets ou de streaming HTTP dans ce cas).

    Bref, tout ça pour dire que Goliath n'a pas forcément un intérêt monstrueux pour slide'em up, c'est juste qu'il passait par là quand j'ai codé slide'em up et qu'il m'a permis d'éviter le bug des images qui se chargent dans le mauvais ordre.

    • [^] # Re: Quelques infos sur slide'em up

      Posté par  (site web personnel) . Évalué à 2.

      Merci pour cet intéressant retour et pour la différence entre sinatra et goliath.

      J'ai pas testé mais le thème io2012 c'est identique à celui de Google ?

      Et une autre question : jamais eu besoin d'un mode présenteur ?

      • [^] # Re: Quelques infos sur slide'em up

        Posté par  (site web personnel) . Évalué à 3.

        J'ai pas testé mais le thème io2012 c'est identique à celui de Google ?

        Oui, c'est le même.

        Et une autre question : jamais eu besoin d'un mode présenteur ?

        Non, je préfère avoir la même chose sur mon écran que ce qui est affiché sur le vidéo-proj.

        • [^] # Re: Quelques infos sur slide'em up

          Posté par  (site web personnel) . Évalué à 3.

          Bon, va vraiment falloir que j'essai tout ça alors (et pourquoi pas un petit comparatif entre les trois solutions si j'ai le temps…)

          Non, je préfère avoir la même chose sur mon écran que ce qui est affiché sur le vidéo-proj.

          Ha, moi j'aime bien avoir en plus de la slide visible mes notes (si j'en ai) et si possible la slide suivante. Ce dernier point permet parfois de ne pas avancer trop vite et d'oublier que ce qu'on est en train de raconter est sur la suivante. Ca aide à faire des transitions aussi je trouve. (bon après moi je parle pas en public, c'est surtout au boulot…)

  • # alternative pour les présentations

    Posté par  . Évalué à 3.

    Là où je travaille, nous utilisons landslide pour faire des slides: https://github.com/adamzap/landslide/

    Il a plusieurs avantages:
    1. On peut générer un fichier html qui contient tout, sans avoir besoin de landslide
    2. Plusieurs raccourcis clavier utiles, notamment la console du présentateur, avec des notes
    3. Une CSS de print qui permet un export PDF via son navigateur Web, pratique pour les formations
    4. Plusieurs langages de markup wiki sont disponibles: rst, markdown, textile

    Ça fonctionne bien, pas de soucis avec.

  • # SVN vs Git

    Posté par  (site web personnel) . Évalué à 7.

    Quelqu'un aurait des infos sur pourquoi SVN et pas Git par exemple ?

    Je propose la licence. SVN est sous licence Apache/BSD et Git sous GPL. Et comme la tendance est à éviter la GPL côté *BSD, ceci pourrait expliquer cela.

    • [^] # Re: SVN vs Git

      Posté par  . Évalué à 6.

      Wow ! Je suis entrain de regarder git, mercurial, bazaar, monotone, darcs et même svk sont sous licence GPL. Ça ne fait plus grand chose sans copyleft. Il y a fossil mais je ne suis pas certains qu'ils soit assez mature.

      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

      • [^] # Re: SVN vs Git

        Posté par  (site web personnel) . Évalué à 3.

        J'utilise fossil depuis environ un an et il fonctionne très bien.

        Sinon pourquoi vouloir une licence non copyleft pour un tel logiciel?

        Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

        • [^] # Re: SVN vs Git

          Posté par  . Évalué à 4.

          J'utilise fossil depuis environ un an et il fonctionne très bien.

          Je ne dis pas qu'il est pas stable ou mauvais. Juste que pour passer l'ensemble de ports FreeBSD (qui doivent faire quelques Gios), ils veulent probablement avoir plus de recule et voir des cas d'usages avec des gros projets un peu plus petits qu'eux.

          Sinon pourquoi vouloir une licence non copyleft pour un tel logiciel?

          C'est leur politique. Choisir autant que possible des licences sans copyleft (donc BSD, Apache et MIT principalement). C'est comme ça qu'ils définissent le libre. Pour eux si tu met une entrave à la réutilisation (ou sur la licence de celui-ci) du code c'est pas libre.

          Si tu veut troller BSD/GPL, tu pourra en trouver des centaines de milliers partout sur le web.

          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

          • [^] # Re: SVN vs Git

            Posté par  . Évalué à 1.

            Du moment que ça n’impose pas la licence à ton code… je ne vois pas le problème.
            Quand au choix SVN ou CVS, je serais plutôt resté sous CVS. En effet, les copies pour créer une branche, un tag… je ne trouve pas ça terrible avec le recul. Ça amène plus de problème que de solution.

            • [^] # Re: SVN vs Git

              Posté par  . Évalué à 3.

              Du moment que ça n’impose pas la licence à ton code… je ne vois pas le problème.

              En principe toute la toolchain est importante.

              Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

            • [^] # Re: SVN vs Git

              Posté par  . Évalué à 6.

              Oui, mais SVN apporte quand même l'atomicité d'un commit. Ça me parait particulièrement important pour un projet comme ça!

              Avec CVS, si tu perds le réseau au milieu de ton commit ou que tu fais un ctrl-c, tous les fichiers arrivés sur le serveur sont commités, et les autres non… ça craint vraiment.

            • [^] # Re: SVN vs Git

              Posté par  (site web personnel) . Évalué à 2.

              J'ai tendance à privilégier l'utilisation de logiciels libres, même si utiliser du proprio n'imposerai pas de licences à ce que je crée avec!
              Je comprends tout à fait qu'on regarde de près la licence des logiciels que l'on utilise, surtout quand on est une grosse distribution avec une philosophie derrière.

    • [^] # Re: SVN vs Git

      Posté par  (site web personnel) . Évalué à 5.

      Je propose la licence. SVN est sous licence Apache/BSD et Git sous GPL.

      En partie mais pas seulement. En réalité le choix de svn a été il y a longtemps pour diverses raisons. L'arbre des ports était encore sous cvs car personne ne s'en était occupé tout simplement.

      La principale de ses raisons est que pour l'heure, la distribution des sources et de l'arbre des ports se fait en utilisant csup qui est un outil basé sur cvs extrêmement rapide. Il existe donc toujours un dépot cvs qui est synchronisé automatiquement avec le svn et qui est sollicité de façon intensive. Sous FreeBSD l'utilisation des sources reste le moyen privilégié de faire ses mises à jour. Il s'agit donc d'une brique essentielle de l'infrastructure du projet, pour les développeurs certes mais aussi pour l'ensemble des serveurs en production.

      De plus autour du svn de FreeBSD il y a de nombreux outils qu'il serait long et laborieux d'adapter. Enfin dans la structure même du projet, ses traditions, ses meurs, l'aspect centralisé est extrêmement important. Très peu de personnes commitent.

      La question d'un passage à git a été débattue (vivement). Il a été décidé qu'il y aurait des miroirs git officiel (ainsi qu'un mirroir hg) :

      git://git.freebsd.your.org/freebsd-head
      rsync://repos.freebsd.your.org/freebsd-head.git/
      git://github.com/freebsd/freebsd-head.git
      git://gitorious.org/freebsd/freebsd-head.git
      https://code.google.com/p/freebsd-head

      Pour hg :

      https://bitbucket.org/freebsd/freebsd-head

      svn n'est pas forcément le meilleurs gestionnaire de sources. Mais il permet de garder la rétro compatibilité avec CVS et surtout csup ainsi que d'utiliser git et hg.

      Voir :
      http://wiki.freebsd.org/GitWorkflow
      http://www.cvsup.org/
      http://www.freebsd.org/doc/en/books/handbook/cvsup.html
      http://freebsd.1045724.n5.nabble.com/Why-not-give-git-a-try-was-quot-Re-head-tinderbox-failure-on-amd64-amd64-quot-td4047695.html

      • [^] # Re: SVN vs Git

        Posté par  . Évalué à 2.

        Enfin dans la structure même du projet, ses traditions, ses meurs, l'aspect centralisé est extrêmement important. Très peu de personnes commitent.

        Un DCVS pourrait justement leur permettre d'avoir un workflow arborescent, non ?

        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

        • [^] # Re: SVN vs Git

          Posté par  (site web personnel) . Évalué à 3.

          Et c'est justement ce qu'ils ne veulent pas…

          Tout le monde n'est pas fan des DVCS. Perso, je suis au final assez réservé même si je reconnais les atouts. Le fonctionnement d'un DVCS par rapport à un CVCS reste nettement plus compliqué, et les gens ont plus de mal à le comprendre. Et la complexité mentale du modèle des branches est significative. Alors que pour un projet moyen qui n'a que des branches de maintenance, et une ou deux banches de dev par ci par là, SVN s'en sort très très très bien.

          • [^] # Re: SVN vs Git

            Posté par  . Évalué à 3.

            Je ne vois pas en quoi cela empeche l'utilisation de git+gitolite…

            C'est probablement une decision plus politique que technique.

            Heureusement pour les devs qu'il y a git-svn parceque c'est bien gentil de devoir etre connecte pour faire un commit mais c'est legerement penible.

  • # Moqups

    Posté par  (site web personnel) . Évalué à 3.

    J'ai eu un petit renvoi de vomi en voyant encore un nom de produit qui se la joue djeun's et tendance en prenant un nom "normal": mock-up; et en en détruisant l'orthographe pour en faire un truc qui se prononce de la même façon mais qui ressemble à rien : "moqups".

    Vous en pensez quoi de ce genre de truc?

    • [^] # Re: Moqups

      Posté par  (site web personnel) . Évalué à 10.

      Vous en pensez quoi de ce genre de truc?

      Dafuq ?

    • [^] # Re: Moqups

      Posté par  (site web personnel) . Évalué à 5.

      Vous en pensez quoi de ce genre de truc?

      Que c'est pratique pour le trouver avec un moteur de recherche, tout en donnant une idée de ce que ça fait ? Moi, je suis pas contre.

      Envoyé depuis mon PDP 11/70

      • [^] # Re: Moqups

        Posté par  (site web personnel) . Évalué à 3.

        Et puis de toute façon tous les noms communs correctement orthographiés doivent être pris comme nom de domaine.

    • [^] # Re: Moqups

      Posté par  (site web personnel) . Évalué à 3.

      Vous en pensez quoi de ce genre de truc?

      heu… rien ?
      C'est pas mieux ni pire que beaucoup d'autres. Et ça a l'intérêt en faire un nom qu'on peut assez facilement retenir puisque phonétiquement très très proches de la fonction (ok, identique).
      Et ça c'est intéressant.

  • # Les slides de Google marchent avec Firefox

    Posté par  (site web personnel) . Évalué à 5.

    Bon, j'ai testé avec FF 14, mais chezmoiçamarche©.

    Commentaire sous licence LPRAB - http://sam.zoy.org/lprab/

  • # Pour les maquettes

    Posté par  (site web personnel) . Évalué à 4.

    Pour les maquettes d'interface il est également possible d'utiliser maqetta.org (Dojo Fundation, directement en ligne via http://maqetta.org, ou en installant le serveur sur son poste).

  • # barkeep

    Posté par  . Évalué à 1.

    Voici encore un outil de code reviews, barkeep. Je ne l'ai pas testé, mais si quelqu'un a un comparatif / retour entre les différents outils existant (reviewboard, crew, etc.) je suis preneur.

    J'ai passé une demi-journée à essayer de l'installer hier : j'ai vu la page d'accueil, j'ai voulu voir la page d'admin, je me suis retrouvé avec ni l'un ni l'autre. Et, à première, vu le seul moyen de se logger c'est via openid et pour les mails c'est gmail. Bref encore trop jeunes.

    Du coup je me suis tourné vers Phabricator, qui m'a vraiment séduit ;)

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.