Journal De tout, de rien, des liens, bla bla bla

Posté par  (site web personnel) .
Étiquettes :
71
25
juin
2012

Sommaire

Introduction

Pour bien commencer la semaine, voici une nouvelle sélection de mes marque-pages.

Comme vous pouvez le remarquer j'ai essayé de faire quelque chose à la fois plus structuré et plus pratique pour ceux souhaitant uniquement une liste de liens. Pour une fois, j'aurais bien voulu mettre des notes de bas de page, mais je n'ai pas réussi à le faire sur LinuxFR.

Au final, vous avez donc le choix de la lecture, soit un journal de brèves, qui commence juste après l'introduction, soit un journal multi-bookmark si vous sautez directement à la section Liste des liens présentés.

Un peu de contenu

Développement

Tout codeur sait bien que la documentation est son meilleur ami pire cauchemar. Les développeurs aiment, en général, tellement écrire de documentations qu'on en arrive à avoir des choses du genre (piqué de twitter) :

/**
 * Gets the title.
 * @return string The title
 */
public function getTitle() {
  return $this->title;
}

Résultat, on en arrive à avoir des développeurs qui disent que la documentation ne sert à rien, et qu'il vaut mieux un code clair. Et oui, au final trop de (mauvaise) doc tue la doc. Pour ma part, je ne suis pas vraiment partisan de ceci. Cet exemple est exagéré dans le sens où ça ne sert à rien, mais très fortement encouragé par les générateurs de documentation (typique java & javadoc, c'est là où j'ai vu le pire de doc idiote).

J'aimerais bien pouvoir faire du literate programming, un peu ce qu'on trouver dans docco. Le problème est que je trouve que ça s'adapte assez peu à des programmes objets un peu complexes.

Et en attendant, ben je pense qu'on va rester sur des générateurs "classiques" de documentation. Côté PHP, un petit nouveau est arrivé (libéré), il s'agit de Sami, libéré par Fabien Potencier, auteur entre autre de symfony.

Histoire de rester dans le PHP, voici une présentation sur l'utilisation de Silex pour faire des api REST. La présentation est plutôt simple et claire, elle fait plutôt bien son job. D'ailleurs, je vois de plus en plus de monde utiliser speakerdeck ; slideshare serait-il en perte de vitesse ? Quoi qu'il en soit, si vous ne connaissez pas ou peu silex ça peut vous faire une introduction assez sympa à ce micro framework php.

Si vous utilisez Git pour vos projets, vous serez peut-être intéressés par ce tableau de bord. C'est écrit, une fois n'est pas coutume pour un outil du genre, en PHP. Pour ma part, je n'ai pas réussi à le faire fonctionner (sous cygwin) et pas eu le temps de faire sous linux ou mac. Si certains l'ont testé/le testent, un retour m'intéresserait pas mal.

Toujours pour Git, voici Crew un outil de code review. Comme indiqué plusieurs fois, je suis pas mal intéressé par ce type d'outil. Pour le moment, j'utilise parfois un review board pour sa compatibilité Mercurial entre autre. Avez-vous déjà utilisé Crew ?

Je sais qu'on est sur LinuxFR et qu'on parle de libre, mais je suis dans les journaux. Donc je me permets de partager ce lien, contenant nombre de logiciels non libre pour un OS terreux (mais en même temps, il paraît qu'un tel os permet d'aller sur le chan des extrémistes bdsien alors bon…). Le but de cet article est de configurer un mac pour du développement web.

edit : Ha be en fait non, les pommes sont passées de terreuses à SALE SALE SALE

Je quitte un peu la partie pur développement pour vous parler de Cloud. Vous le savez certainement, en Europe le cloud est un peu à la traîne. De grands acteurs tentent quand même de tirer leur épingle du jeu, mais ce n'est pas évident. Et a priori, au-delà des problèmes techniques, se posent également des problèmes légaux. Entre autre, les lois sur la protection des données personnelles sont un frein à certaines possibilités techniques (par exemple le fait que ces données ne doivent pas sortir de l'Europe, problématique lorsque les data centers sont répartis partout dans le monde). Le CERN demande donc une évolution de la réglementation afin de favoriser le Cloud. C'est évidement un sujet loin d'être simple, mais pour le moins urgent, surtout que changer la réglementation est long, très long, surtout à l'échelle des changements informatiques.

Voici, pour changer un peu, un long et instructif post sur WebGL et la 3D. Je ne vais pas vraiment détailler, le mieux étant d'aller le lire.
/me se souvient avoir bossé dans une startup dont l'objectif était de faire de la 3D dans les navigateurs. À l'époque, point de WebGL, on intégrait un moteur Ogre sous forme de greffon et on le pilotait depuis une interface html/js (et des web services, et du scripting lua). C'était bien sympa, même si pas évident. Aujourd'hui les choses semblent tout d'un coup un peu plus simples…

Et pour fermer cette partie développement, quelques petits points sur GitHub. Tout d'abord une présentation sur l'utilisation d'une armée de robots. J'aime bien le principe et ça correspond bien normalement au boulot des ingénieurs et des informaticiens : automatiser ce qui peut l'être, ne pas faire 2 fois la même chose manuellement si on peut l'éviter. Ça permet également d'avoir des contraintes plus fermes que si les choses étaient faites humainement "oué bon, ma branche ne passe plus les tests mais c'est pas grave, je push quand même…".

I'm tired of writing bad code

C'est ainsi que commence cette présentation intitulée Why our code smells. Elle est aussi réalisée par un employé de GitHub. La présentation est vraiment sympa, et j'ai l'impression que cette boîte et quand même assez particulière. Entre autre, ce qui ressort est qu'il n'y a pas vraiment de hiérarchie ni réellement de direction des produits. On dirait que ça fonctionne simplement parce qu'ils réunissent les bonnes personnes et les laissent simplement bosser. Enfin, c'est l'impression que ça donne. Et ça donne quand même envie tout ça, même si j'ai l'impression que c'est à l'inverse de beaucoup d'entreprises. Par contre, GitHub est encore plutôt jeune, à voir ce que ça donnera / deviendra dans quelques années.

D'ailleurs vous pouvez aussi aller voir les autres articles de son blog c'est pas mal. Il y a un article qui m'intrigue, celui montrant son bureau pour travailler en position debout. Je sais que certains utilisent ce genre de bureau (ou côtoient des personnes qui les utilisent, par exemple chez Google). Que pensez-vous de ce type de bureau ? C'est pas un peu fatiguant tout la journée ? Si je me pose des questions c'est que j'ai entre autre un syndrome rotulien (syndrome du cinéma en langage courant) et rester assis est parfois très désagréable (pour pas dire plus) mais je me vois difficilement coder debout. En même temps, j'ai jamais vraiment essayé…

Misc

Si vous développez pour android, ce petit utilitaire devrait vous plaire. Il s'agit d'un petit logiciel, en lien avec le SDK d'Android, vous permettant de visualiser sur votre écran d'ordinateur ce qu'il se passe sur le téléphone ou la tablette. L'avantage est que vous avez à la fois un matériel complet, efficace et performant (par rapport aux émulateurs) et un affichage nikel sur écran, vidéo projecteur, etc. Droid@Screen peut être vraiment intéressant pour vos présentations ou formations, par exemple.

Wikimedia semble toujours en recherche autour de son éditeur visuel pour, entre autre, wikipedia, et demande de l'aide pour le réaliser. Pour ma part, j'ai été assez intrigué lorsque, quasiment à chaque fois que le sujet apparaît, il y a tout un lot de personnes plus ou moins actives sur wikipedia qui se montrent farouchement opposées à cet outil. Tout ça parce que l'édition deviendrait plus facile. Et là, je trouve que c'est réellement totalement se planter. Déjà, côté élitisme, c'est pas trop mal. Mais surtout ça fait vraiment "on veut rester entre nous". Le problème c'est que quelqu'un spécialisé en histoire, en langues, en n'importe quoi d'autre que l'informatique (et encore) n'est pas forcément à l'aise, n'a pas forcément envie de perdre son temps avec une syntaxe wiki. Et sous prétexte qu'ils ne veulent pas de cette syntaxe ils ne devraient pas écrire sur wikipedia ? C'est con mais moi ça me fait bien penser à ces histoires de religion, ou pendant longtemps la messe était dite en latin, pour garder une distance avec les pauvres fidèles. Et ça, c'est moche, surtout lorsqu'on parle de transmission et partage du savoir.

Côté savoir, v'la't-y pas que Xavier papote dans les journaux aux sujets des Free mobile : mythes et réalités. Bon, évidemment c'est à prendre de manière partiale, mais il y a des choses intéressantes, entre autre le rapport entre investissement et chiffre d'affaires, plutôt différent si on regarde Free ou les trois autres acteurs mobiles.

Que seraient ces brèves sans parler un peu de travail, de condition de travail ? Ce serait triste, non ? Allez, un article plutôt simple sur le fait de rêvasser au travail. Bon, je sais que certains vont me dire que c'est déjà comme ça, mais faut croire qu'en fait c'est pas le cas partout. Évidemment, ça peut dépendre des boulots, mais croire qu'on peut avoir un métier un minimum créatif (et probablement idem pour les autres) sans jamais lever le nez est une connerie, malheureusement encore bien implantée dans le cerveau de certains dirigeants (quel que soit le niveau de direction). C'est dommage.

Cartographie

Google a annoncé récemment l'ouverture de son nouveau service faisant partie de Google Maps/Earth, Coordinate. En gros, c'est un peu comme latitude, mais de manière professionnelle. Le but étant de pouvoir gérer des équipes mobiles en temps réel, avec entre autre assignation de travaux, workflow, etc.

La deuxième annonce de Google consiste en une simplifcation des limites et une baisse des prix de l'API Google Maps. C'est plutôt une bonne nouvelle pour ceux qui utilisent la version de base (non business).

Graphisme & co

La dernière fois, j'avais présenté quelques scènes de films reproduites en Lego. Cette fois-ci c'est une œuvre un peu différente, mais je trouve ça plutôt pas mal du tout. J'aimerais bien avoir ce genre de Lego sur mon bureau, je trouve que ça rend bien et ça change un peu de les voir à nu (mais non, pas comme ça, bande de pervers !)

Histoire de rester dans le graphisme, voici une petite vidéo sympathique vous montrant qu'on peut peindre cheveux, poils ou trucs dans le genre rien qu'avec une brosse ronde. Bon, va falloir que je ressorte ma wacom, j'en suis pas encore là moi…

Un petit making of d'une nouvelle graphique intitulée l'héritage en couleur. L'un des points intéressants est que c'est réalisé sous linux, avec krita et mypaint. D'ailleurs, si vous souhaitez avoir des infos sur le dessin numérique sous linux ce blog est une belle mine d'informations, avec des ensembles prédéfinis de brosses et outils pour vos logiciels. C'est vraiment un bon site à avoir dans ses flux / marquetapage.

Liste des liens présentés

Développement

Misc

Graphisme & co

Cartographie

  • # Et ben…

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

    C'est un journal marque page de qualité et détaillé. Moi, j'aime bien.

  • # Merci

    Posté par  . Évalué à 10.

    Moi qui me posait des questions sur le sens de ce que je fais dans ma vie, je suis rassuré de voir qu'il y a des gens qui passent des heures à faire des dessins photo-réalistes à partir de photos hideuses de chiens hideux.

    Je peux continuer à coder quelque chose qui ne sera jamais vraiment exécuté en production :-)

    Envoyé depuis mon lapin.

  • # doc

    Posté par  . Évalué à 2.

    un journal bien touffu ma foi.
    Concernant la doc, j'ai un peu honte de répondre avec un commentaire bookmark, mais je ne pourrais pas écrire mieux (et même j'en ai compris plus sur le sujet après l'avoir lu qu'avant).

  • # liste de liens

    Posté par  (site web personnel) . Évalué à 4. Dernière modification le 25 juin 2012 à 22:59.

    Bon l'aide-edition est une page wiki censée présenter les possibilités de Markdown parmi lesquelles la possibilité de présentation des liens en tant que bibliographie (c'est-à-dire avec des [1] ou des [REF_VEILLE] dans le texte permettant de se reporter à la fin de l'article pour consulter les différentes sources utilisées).

    Ce pourquoi ta remarque :

    Pour une fois, j'aurais bien voulu mettre des notes de bas de page, mais je n'ai pas réussi à le faire sur LinuxFR.

    m'a interpellé, voici ci-dessous comment faire.

    Et, en fait, si vous consultez la référence Markdown c'est possible d'organiser au fur et à mesure de la rédaction les différents liens présentés (juste taper au kilomètre et reporter à la fin du texte les références de lien, au fur et à mesure).

    Il se trouve que cela ne fonctionne qu'avec la syntaxe présentée, telle quelle (i.e. [description lien][REF] puis en dessous [REF]: "descriptif qui apparaît dans le alt", cf. ci-dessous) ; cela pourrait apporter pas mal à la lecture des dépêches noyau de patrick_g< (outre le tag veille technologique que j'ajoute systématiquement à tes journaux dernièrement :D).

    Le point à comprendre(*) est que la description est en fait placée en alt du lien, ce qui permet de la voir apparaître au survol du lien (une info-bulle), peut-être faudrait-il la garder comme une bibliographie à la fin (et tel que c'est saisi dans un commentaire ou dans un journal ?).

     

     
    Recopie de la fin de ce commentaire, pour illustrer la suggestion (voir le alt sur les liens ci-dessus pour comprendre la syntaxe au besoin) :

    [1]: http://daringfireball.net/projects/markdown/syntax#link "la référence Markdown indique la syntaxe [description lien] [id] puis [id] : http://example.com "avec une description" pour créer sa bibliographie au fur et à mesure"

    [REF_VEILLE]: http://linuxfr.org/tags/veille_technologique/public "veille technologique de CrEv<"

    oui, [1] et [REF_VEILLE] pourraient apparaître dans le texte original, un peu comme les habitués des articles scientifiques ou les fidèles lecteurs de GLMF.

    (*) il faut sans doute être fana comme moi de la syntaxe des différents wiki pour en suivre la logique :/

    • [^] # Re: liste de liens

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

      hum… va falloir que je relise tout ça, je suis pas sur d'avoir bien suivi.
      J'avais bien trouvé une syntaxe markdown mais elle semblait ne pas fonctionner (à coup de [^1] par exemple)

  • # Gitboard, emacs le faisait déjà y a 10 ans

    Posté par  (site web personnel) . Évalué à -2. Dernière modification le 25 juin 2012 à 23:09.

    Et un lien de plus, pour ceux qui bossent sous emacs : git-emacs

  • # Documentation

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

    J'ai quelques remarques sur ton paragraphe à propos de la documentation.

    1. Tu aurais pu corriger la faute: “Get the title” Il ne faut pas de s à get puisqu'il s'agit d'un impératif ou d'un infinitif — pour mettre un s il faut un sujet!

    2. S'il y a bien un endroit (en fait, le seul!) où le copier-coller est tolérable, c'est la documentation des interfaces. C'est parfois automatisable avec des macros (comme dans les macros MDOC ou MAN pour les pages de man) mais parfois le plus court chemin est le copier-coller.

    3. Dans ce cas la clause return … ne sert à rien car elle n'apporte pas de nouvelle information!

    4. J'ai souvent lu ce genre de documentation pour du C ou du C++, omet l'information cruciale: la valeur de retour est-elle un alias ou une nouvelle valeur?

    • [^] # Re: Documentation

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

      1. nan mais moi je recopie hein :)
      2. toutafait, le risque par contre étant d'avoir parfois un décalage entre la doc et le code (du au copier coller)
      3. la clause return a un intérêt, celle d'être traitée par le générateur et donc d'apparaître différement
      4. ha oui, bonne remarque. Il est vrai que ça change pas mal selon les langages (qui utilisent plutôt des références ou non, que ce soit dans le langage ou dans l'usage)

    • [^] # Re: Documentation

      Posté par  . Évalué à 4.

      1. Le sujet est sous-entendu : (this function) gets the title.

    • [^] # Re: Documentation

      Posté par  . Évalué à 2.

      1. S'il y a bien un endroit (en fait, le seul!) où le copier-coller est tolérable, c'est la documentation des interfaces. C'est parfois automatisable avec des macros (comme dans les macros MDOC ou MAN pour les pages de man) mais parfois le plus court chemin est le copier-coller.

      En javadoc, {@inheritDoc} copie automatiquement la javadoc d'une méthode depuis l'interface/la super classe vers la méthode dans le sous type.

      1. Dans ce cas la clause return … ne sert à rien car elle n'apporte pas de nouvelle information!

      C'est pour ça que je ne documente que le clause @return.

  • # La doc est toujours utile

    Posté par  . Évalué à 3.

    Je trouve que l'exemple que tu donne pour la documentation n'est pas de la documentation inutile. Ça montre que c'est uniquement un getter et qu'il n'y a pas d'effet de bord par exemple, chose qui ne serait pas possible de savoir si ce n'était pas indiqué. Et comme la doc, c'est aussi lu quand on ne voit pas le code, c'est intéressant.

    « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

    • [^] # Re: La doc est toujours utile

      Posté par  . Évalué à 4.

      tout est une question de l'endroit ou tu mets le curseur entre trop de doc et pas de doc. Dans certaines méthodes à Gilles, la règle, c'est zéro commentaire dans le code. (option "Si le code a besoin d'être commenté pour être compris, c'est du mauvais code")

      Il faut distinguer la doc interne et la doc d'API à destinations de développeurs tiers. Si getTitle fait partie d'une interface externe, il faut la documenter au moins succinctement (ne serait-ce que pas un lapidaire "self explaining"). Si c'est un bout de doc interne à un module, perso, je ne documenterais pas, parce ce que le développeur qui coincerait déjà à ce niveau là, ce serait pas la peine qu'il regarde plus loin.

      En fonction du contexte dans lequel est englobé ce bout de code, les 4 lignes de commentaires seront plus ou moins utiles. J'aurais tendance à dire plutôt moins, mais c'est un exemple un peu caricatural. Les IDEs qui génèrent des getter/setter en profitent parfois pour écrire les 3 lignes de doc qui vont avec.

      concernant ton titre, cf mon commentaire plus haut. La doc obsolète, en plus d'être inutile, peut-être nuisible si on ne sait pas qu'elle est obsolète.

      • [^] # Re: La doc est toujours utile

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

        Sur le principe oui, mais je ne comprend vraiment pas cette histoire de zéro doc. Je crois que j'en avais parlé dans un autre journal mais j'ai un vrai problème avec.
        Qu'il y ait vraiment peu de doc type javadoc d'API pourquoi pas. Mais zéro commentaire montre en général que la fonction d'un commentaire n'est pas comprise du tout.
        Déjà parce que certains algos ne peuvent être forcément totalement évidents (et il vaut mieux dans ce cas garder l'explication au plus proche du code).
        Mais aussi parce que nombre de commentaires devraient non pas expliquer le code (là c'est probablement qu'il faut le réecrire) mais expliquer ce qui n'y est pas et qui est parfois même plus important que le code en lui-même : l'intention.
        C'est l'intention qui permet parfois de différentier un bug d'un comportement spécifique. Et ça, sans explication de l'intention pas moyen de le savoir.

        Donc oui, la doc obsolète c'est mal. Et les générateurs de doc encouragent la doc idiote. Mais zéro doc est à mon avis aussi dangereuse.

        C'est pour ça que j'aime bien, entre autre, le literate programming dans le sens où on lie vraiment les deux, et c'est pour ça aussi qu'il est absolument obligatoire de commenter en anglais (car commenter if value is 2 en anglais ça revient tellement au même qu'on ferait de la duplication. Le commentaire dans une autre langue poserait malheureusement moins de problème et donc inciterait à avoir des commentaires inutiles)

        • [^] # Re: La doc est toujours utile

          Posté par  . Évalué à 3.

          Je reformule, j'aurais du dire "zéro doc en tant que tel" plutôt que "zéro doc".

          "You should always write your code as if comments didn't exist. This forces you to write your code in the simplest, plainest, most self-documenting way you can humanly come up with."

          http://www.codinghorror.com/blog/2008/07/coding-without-comments.html

          le commentaire explicite, c'est quand on n'a pas réussi à transmettre tout ce qu'il fallait mettre dans le code. Je trouve l'exemple dans l'article en lien ci dessus très parlant.

          ça me rappelle aussi un peu le DOET The_Design_of_Everyday_Things. Je viens de farfouiller sur le net pour me rafraîchir la mémoire. Je pensais au chapitre 3. Knowledge in the Head and in the World". mais vaut mieux le lire in extenso, je trouve le résumé un peu aride.
          Appliqué au dev, l'objet qu'en veut concevoir serait le code proprement dit, et le commentaire, le "knowledge in the world". Si on peut s'en passer, c'est mieux.

          Le agile manifesto, en essayant de mettre tous les trolls de côté, est une liste de couple de "concepts" opposés. Ensuite, tout est dans la façon dont on équilibre la colonne de gauche et la colonne de droite. Pour certains, le bon équilibre concernant la doc, c'est pas de doc.

          voilà j'espère quelques éléments de réflexions. Sur le plan personnel, je commente assez peu, et très très rarement sur des éléments techniques.

          Pour finir, la seule documentation vraiment à jour, c'est le code !

        • [^] # Re: La doc est toujours utile

          Posté par  . Évalué à 3.

          Une règle de base: commenter le pourquoi (WHY?) et pas le quoi (WHAT?).

          Autrement dit: il faut commenter pourquoi le code fait ce qu'il fait plutôt que d'écrire un commentaire qui décrit ce que fait le code étape par étape, mais en moins bien que le code lui même (sans parler que ces commentaires deviennent rapidement obsolètes). Exemple (vécu probablement des centaines ou milliers de de fois):

           // get first name
 String firstName = getFirstName();

 // concatenate with surname to get fullname
 String fullName = getSurname() + " " + firstName;

    • [^] # Re: La doc est toujours utile

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

      Evidemment la documentation d'une API (où on ne voit pas forcément le code) doit être plus importante et n'a pas la même utilité qu'une documentation où on a forcément le code sous les yeux.

      En l'occurrence l'exemple présenté est tout de même un peu ridicule :

      • getTitle et return the title ça veut quand même vraiment dire la même chose
      • pour l'effet de bord, je le dirais dans l'autre sens. Par défaut un get ne doit pas en avoir, et il faut documenter sa présence

      • [^] # Re: La doc est toujours utile

        Posté par  . Évalué à 5.

        Evidemment la documentation d'une API (où on ne voit pas forcément le code) doit être plus importante et n'a pas la même utilité qu'une documentation où on a forcément le code sous les yeux.

        Les cas où on a forcément le code sous les yeux sont quand même rare et c'est quand même plus pratique d'avoir la documentation affichée au survol de la souris ou avec l'autocomplétion que de devoir changer de fichier ou naviguer 200 lignes plus haut pour retrouver la fonction.

        getTitle et return the title ça veut quand même vraiment dire la même chose

        Oui, mais l'ide ne va pas forcément présenter la même info dans une bulle d'aide, c'est un peu redondant mais plus utilisable à mon avis.

        pour l'effet de bord, je le dirais dans l'autre sens. Par défaut un get ne doit pas en avoir, et il faut documenter sa présence

        Entièrement d'accord, seulement, s'il y a de la doc et que ce n'est pas écrit, je vais plutôt supposer que le développeur a réfléchi 2 secondes et qu'il l'aurait écrit s'il y en avait. Tandis que s'il n'y a pas de doc, je ne sais pas s'il y en a un et que ce n'est pas indiqué par flemme ou si c'est le comportement normal.

        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

        • [^] # Re: La doc est toujours utile

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

          Tandis que s'il n'y a pas de doc, je ne sais pas s'il y en a un et que ce n'est pas indiqué par flemme ou si c'est le comportement normal.

          Au travail notre système de documentation est Visual Studio Debugger et c'est pas génial… on passe notre temps à debugger du code qui marche pour comprendre le flot du programme, les invariants, etc. Côté productivité, c'est une pénalité monstrueuse et en plus, c'est souvent très approximatif.

          En gros il est quasiment impossible d'apporter des modifications non triviales à un code non documenté.

  • # le passage sur wikipedia me rappele une discution de bistro

    Posté par  . Évalué à 2.

    il y a tout un lot de personnes plus ou moins actives sur wikipedia qui se montrent farouchement opposées à cet outil. Tout ça parce que l'édition deviendrait plus facile. Et là, je trouve que c'est réellement totalement se planter.

    Je suis entièrement d'accord, et je trouve ca désolant.
    Ca me rappelle un mec avec qui j'avais discuté au bistro, il etait contre ubuntu parce que ça rendait linux trop abordable au commun des mortels.
    Pour lui linux devait rester un truc compliqué avec une simple console et si tu passe pas par la console t'as qu'a utilisé windows.
    J'imagine qu'il y a plein de gens qui, comme lui, préfère lancer un film en utilisant la ligne de commande plutôt que de cliquer sur l'icone du film, mais de la à ne pas vouloir que les autres ai la possibilité des cliquer faut quand même être extrémiste.
    Perso j'ai jamais compris ce genre de comportement.Je continue de cliquer et j'utilise la console quand j'en ai besoin, mais jamais je voudrais qu'on empêche quiconque de se servir de sa console comme il le souhaite.

    Au final je pense que c'est l'impression de supériorité que la maitrise d'outils complexe te donne sur les autres qui te fait avoir des comportements comme ça et je pense que garder cette complexité est un des plus gros frein à la démocratisation de ces outils.

  • # tableau de bord git

    Posté par  . Évalué à 2.

    J'ai voulu essayé le tableau de bord git, il m'indiquait des erreurs liées à strtotime. En me penchant un peu plus sur le github on trouve un pull request qui corrige le problème (https://github.com/KuiKui/Gitboard/pulls) . Il suffit d'ajouter vers le début :

    date_default_timezone_set('America/New_York');

    Ça m'embête d'avoir du installer un interpréteur php juste pour ça, mais il marche bien.

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

    • [^] # Re: tableau de bord git

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

      Façon plus propre de faire la même chose:

      ; Defines the default timezone used by the date functions
; http://php.net/date.timezone
date.timezone = "America/New_York"

      (À mettre dans son php.ini)

      • [^] # Re: tableau de bord git

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

        Je crois que c'est ce qui est conseillé en général, simplement définir la timezone.

      • [^] # Re: tableau de bord git

        Posté par  . Évalué à 2.

        Le php.ini ? Ça se trouve où ?

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

        • [^] # Re: tableau de bord git

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

          ça dépend de ton installation… parfois c'est simplement /etc/php.ini (en tout cas c'est le cas sur ma mageia)

          • [^] # Re: tableau de bord git

            Posté par  . Évalué à 2.

            /etc/php5/fpm/php.ini
            Sur une debian avec nginx, php de dotdeb
            sinon dans ton shell:
            php -r "phpinfo();" | grep php.ini

            Depending on the time of day, the French go either way.

          • [^] # Re: tableau de bord git

            Posté par  . Évalué à 2.

            Ça veux dire que l'installation de base de PHP sur ma Debian est mauvais ? Je viens de regarder c'est dans /etc/php5/cli/php.ini avec le paquet php5-cli (j'en ai profité pour mettre Paris).

            C'est vraiment contraignant d'utiliser php pour faire du scripting ailleurs que dans un serveur 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: tableau de bord git

              Posté par  . Évalué à 2.

              Tu veux dire quoi par l'installation de base est mauvaise?

              Depending on the time of day, the French go either way.

              • [^] # Re: tableau de bord git

                Posté par  . Évalué à 2.

                Par défaut, on ne peut pas utiliser convenablement (de façon propre) strtotime sans modifier un fichier système.

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

                • [^] # Re: tableau de bord git

                  Posté par  . Évalué à 2.

                  Ah, ça. J'sais pas, ça devrait être configuré au moment de l'install du paquet, je me demande pourquoi ce n'est pas le cas.

                  Depending on the time of day, the French go either way.

            • [^] # Re: tableau de bord git

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

              nope, je pense pas. Mais ton php-cli a surement un fichier différent car ça doit être une version limitée cli et non serveur web

              C'est vraiment contraignant d'utiliser php pour faire du scripting ailleurs que dans un serveur web…

              Bof, au final pas beaucoup plus qu'un ruby ou autre. La seule chose est, il est vrai, cette histoire de timezone.

              • [^] # Re: tableau de bord git

                Posté par  . Évalué à 3.

                nope, je pense pas. Mais ton php-cli a surement un fichier différent car ça doit être une version limitée cli et non serveur web

                Il n'y a rien de spécifique au web dans la gestion des timezone.

                Bof, au final pas beaucoup plus qu'un ruby ou autre. La seule chose est, il est vrai, cette histoire de timezone.

                ruby, je sais pas mais avec perl et python je n'ai jamais rencontré de problème de ce genre. J'ai de la chance d'être administrateur de la machine, sinon j'aurait du recopier le php.ini et ajouter la bonne configuration puis lancer php -c mon_php.ini, ça n'est pas particulièrement pratique.

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

  • # L'héritage en couleur

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

    Très sympa, ça me fait penser au court métrage animé Out of Sight.

  • # Organisation de GitHub

    Posté par  . Évalué à 2.

    j'ai l'impression que cette boîte et quand même assez particulière. Entre autre, ce qui ressort est qu'il n'y a pas vraiment de hiérarchie ni réellement de direction des produits. On dirait que ça fonctionne simplement parce qu'ils réunissent les bonnes personnes et les laissent simplement bosser. Enfin, c'est l'impression que ça donne. Et ça donne quand même envie tout ça, même si j'ai l'impression que c'est à l'inverse de beaucoup d'entreprises. Par contre, GitHub est encore plutôt jeune, à voir ce que ça donnera / deviendra dans quelques années.

    Valve ?

    Le guide d'accueil de la boite est vraiment sympa et explique comment tout ça fonctionne. Un indice le recrutement est l'étape la plus importante.

    • [^] # Re: Organisation de GitHub

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

      Tu as ce guide quelque part ?

      Un indice le recrutement est l'étape la plus importante.

      Oui, j'ai vraiment l'impression que dans ces boites le recrutement est une étape vraiment importante, y compris pour trouver des personnes qui vont pouvoir bosser ensemble (complexe ça tout de même). Et j'ai l'impression qu'ensuite c'est "allez-y, bosser, on verra ce que ça donne" (peut-être un peu caricatural tout de même)

      • [^] # Re: Organisation de GitHub

        Posté par  . Évalué à 4. Dernière modification le 12 avril 2022 à 10:04.

        https://web.archive.org/web/20131103022258/http://newcdn.flamehaus.com/Valve_Handbook_LowRes.pdf

        NdM : lien original brisé, remplacé par un lien valide vers archive.org

        • [^] # Re: Organisation de GitHub

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

          Merci !

        • [^] # Re: Organisation de GitHub

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

          Intéressant à lire:

          Hierarchy is great for maintaining predictability and repeatability. It simplifies planning and makes it easier to control a large group of people from the top down, which is why military organizations rely on it so heavily. But when you’re an entertainment company that’s spent the last decade going out of its way to recruit the most intelligent, innovative, talented people on Earth, telling them to sit at a desk and do what they’re told obliterates 99 percent of their value.
          • Ils ont une structure à plat pour favoriser l'innovation (après ils s'organisent en équipes)
          for the most part working overtime for extended periods indicates a fundamental failure
          • Pour eux travailler en dehors des heures est synonyme de problème de planning ou d'organisation

          Certaines de nos grosses boites devraient en prendre de la graine…

          Les mentalités évoluent, l'organisation des entreprises devraient évoluer aussi.

          Sur le même sujet je recommande le livre "Rework" de 37 signals qui est vraiment intéressant à lire.

          • [^] # Re: Organisation de GitHub

            Posté par  . Évalué à 3.

            working overtime

            je traduirais ça par "heures sup" plutôt que le fait d'être en dehors des plages horaires.

            je recommande le livre "Rework" de 37 signals qui est vraiment intéressant à lire.

            oui !

          • [^] # Re: Organisation de GitHub

            Posté par  (site web personnel) . Évalué à 4. Dernière modification le 26 juin 2012 à 17:17.

            for the most part working overtime for extended periods indicates a fundamental failure

            Pour eux travailler en dehors des heures est synonyme de problème de planning ou d'organisation

            En lisant ça, j'ai immédiatement pensé à Rework, mais je n'avais pas encore lu la fin de ton commentaire

            Sur le même sujet je recommande le livre "Rework" de 37 signals qui est vraiment intéressant à lire.

            Idem, je le recommande vraiment. En plus il est très facile à lire, c'est rapide, et c'est simple (même pour ceux qui ne sont pas très bon en anglais, je crois qu'il y a une version française mais je ne suis pas certain)

            http://37signals.com/svn/posts/902-fire-the-workaholics
            http://s3.amazonaws.com/37assets/svn/Rework-by-Jason-Fried-and-David-Heinemeier-Hansson-Excerpts.pdf pour un extrait du bouquin, qui commence par ce sujet

            Et j'aime beaucoup certains arguments avancés "contre" ces personnes accro au travail

            They try to make up for intellectual laziness with brute force. This results in inelegant solutions
            They even create crises. They don’t look for ways to be more efficient because they actually like working overtime

            M'enfin allez au moins lire l'extrait, mieux, allez acheter le livre.

            edit :

            Certaines de nos grosses boites devraient en prendre de la graine…

            Malheureusement ce n'est pas limité aux grosses…

            Et sur cette histoire de (sur)travail, c'est par exemple contraire aux méthodes agiles où on indique que le rythme devrait pouvoir être tenu indéfiniment. Ce qui est tout le contraire de bosser tout le temps, n'importe quand, etc…

            • [^] # Re: Organisation de GitHub

              Posté par  . Évalué à 0.

              Je pense que certains des gros problèmes sur le comportement en entreprise que l'on rencontre sont aussi les conséquences d'idées bien franco-françaises qui résultent elles même d'une certaine stagnation des personnes en place.

              • [^] # Re: Organisation de GitHub

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

                Juste pour bien comprendre ce que tu dis : en quoi ce serait lié à des idées bien franco-françaises ? Aucun autre pays n'est touché par ce type de problème ?

                • [^] # Re: Organisation de GitHub

                  Posté par  . Évalué à 3.

                  Quand tu regardes à l'étranger, il y a des problèmes auxquels ils ne sont pas confrontés que l'on rencontre régulièrement en France. En particulier l'absence de confiance dans les jeunes (et l'innovation qui y est souvent lié), cette espèce d'omniprésence des petits chefs et une hiérarchie poussée à l'extrême, une sur-représentation des "commerciaux", une absence de passerelles au sein des entreprises qui fait que pour évoluer sérieusement il faut démissionner et pour finir une complète absence de flexibilité du temps de travail.

                  C'était principalement pour répondre à ton "Malheureusement ce n'est pas limité aux grosses…" [entreprises qui devaient prendre exemple sur Valve / GitHub] précédent.

                  Juste que je pense que la vision du travail par Valve et cie, est quasiment à l'opposée de ce que l'on rencontre par défaut chez nous et que finalement. Construire une boite qui marche sur ce modèle c'est encore très difficile pour nous (je dis pas impossible, juste difficile) parce qu'on nous "éduque" pour s'insérer dans notre modèle.

                  Bon par contre je te l'accorde, c'est un point de vue biaisé que je tiens de mon expérience passée personnelle (i.e. aujourd'hui j'ai de la chance :p). Mais dans ces expérience, cas symptomatique, l'une des sociétés était une grosse structure internationale et déjà entre les guidelines de la maison mère et l'application "à la française", il y avait déjà un gros gap.

            • [^] # Re: Organisation de GitHub

              Posté par  . Évalué à 1.

              J'en profite pour demander leur avis à ce qui aurait lu la VF http://linuxfr.org/forums/g%C3%A9n%C3%A9ralg%C3%A9n%C3%A9ral/posts/rework-37signals-avis-traduction

              Merci.

              • [^] # Re: Organisation de GitHub

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

                J'ai la version VF, je n'ai pas comparé avec la version originale, mais elle est globalement bien traduite (a part 2 ou 3 coquilles qui ne m'ont pas marqué).

            • [^] # Re: Organisation de GitHub

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

              Pour en ajouter un peu voici la vidéo d'une présentation à TED d'un des auteur du livre sur ce sujet:

              http://www.ted.com/talks/jason_fried_why_work_doesn_t_happen_at_work.html

              A voir!

  • # Et en parlant de Making of

    Posté par  . Évalué à 3.

    http://www.youtube.com/watch?v=wO4_6LfCaAA

    Depending on the time of day, the French go either way.

  • # Machine de Turing en Lego.

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

    Les étudiants de L'ENS de Lyon ont matérialisé une machine de Turing en Lego®.

    « Il vaut mieux mobiliser son intelligence sur des conneries que mobiliser sa connerie sur des choses intelligentes. »

Suivre le flux des commentaires

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