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

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

Sommaire

Introduction

Un numéro de zappé, mais c'était pour la bonne cause : ma css linuxfr-solarized. Finalement ça prend plus de temps que prévu, donc moins de liens collectés. Et faut dire aussi que j'ai l'impression que pas mal de monde a commencé les vacances, donc beaucoup moins d'activité. Donc toute petite revue cette fois-ci, mais revue quand même.

Un peu de contenu

Développement

On commence directement avec du développement web. L'une des questions qui revient toujours est de savoir quelles sont les fonctionnalités supportées et disponibles pour un navigateur. Ce site, haz.io, ne vous renseignera pas sur le support pour l'ensemble des navigateurs, mais mettra en évidence ce que votre navigateur supporte. Et pour quasiment chaque fonctionnalité un lien vers les specs (ou draft) du W3C est réalisé, est ça c'est bien.

Toujours côté web, la fonction css calc() est désormais non préfixée. Enfin presque, c'est pour firefox 16. C'est une très bonne chose, c'est réellement une fonctionnalité intéressante pour le design web. Voici le bug chez mozilla. Cette fonctionnaltié existe aussi dans IE9, ce qui permet de l'utiliser (en rajoutant les bons préfixes) sur tout navigateur récent, IE >= 9, firefox et webkit.

Pour continuer les précédents numéro, un peu de coffeescript : j'ai découvert qu'on pouvait chainer les comparaisons :

Au lieu d'écrire ça

value < 100 && value > 50

on écrit simplement

100 > value > 50

Mais pourquoi les autres langages n'ont pas ça ?

Une petite astuce toute simple pour ceux qui débutent avec git et qui ont peur des merges. En gros c'est l'utilisation des branches comme bookmark (pour une fois que je peux employer un terme hg en parlant de git ;-) ) pour pouvoir avoir un point de restauration si on se plante.

Je remonte également un lien trouvé dans un commentaire de nono sur les EBook : une lib javascript pour afficher des maths dans une page web. Entre autre chose une utilisation importante des polices de caractères, ce qui permet au rendu de suivre les zooms. Et ça c'est vraiment bien, bien mieux que n'importe quel plugin, mieux qu'une image, et même mieux qu'une image vectorielle finalement (ne serait-ce que parce que c'est toujours du texte). A avoir sous le coude si vous devez inclure des maths dans de l'html. (d'ailleurs tout ça me fait penser que maintenant que je vais bosser dans les ebooks faudrait peut-être que je me mette à lire les specs…)

Comme vous l'avez probablement remarqué, je suis toujours en quête d'un bon outil pour gérer mes sources, mes bugs, mes code reviews, etc. Cette fois-ci je vous propose phabricator. Phabricator regroupe tout ça et même plus. C'est à la base un projet de facebook et ça me semble plutôt pas mal. Je suis justement en cours d'installation.

Actuellement j'utilise github, j'ai aussi des repositories sur baregit. J'ai aussi une instance de gitorious mais je n'en suis pas totalement satisfait (il manque pas mal de choses, même si le côté hébergement de source fonctionne plutôt bien). J'aimerais en fait pouvoir avoir une instance chez moi d'un équivalent (fonctionnel) à github et simplement avoir des miroirs des sources (pour alléger ma bande passante si certains veulent faire un clone).

Dans la liste des versions à tester, j'ai également gitlab qui vient de passer en version 2.7 avec pas mal de nouveautés.

Misc

Si vous êtes sous gnome, vous apprécierez peut-être ce client mail : Geary. Pour ma part je ne l'ai pas testé, mais il me semble plutôt sympa, au moins pour du mail "perso".

Vous aussi vous avez un site web ? Vous aussi vous stockez des mots de passe ? Alors ne faites simplement pas comme Tesco. Voici un article très intéressant vous rappelant plusieurs règles de sécurité à adopter, en prenant comme contre exemple Tesco. Faut dire qu'ils l'avaient un peu cherché en twittant :

Passwords are stored in a secure way. They're only copied into plain text when pasted automatically into a password reminder mail.

Qu'est ce qui motive les gens ? Les récompenses ? Leur donner le choix ? Les forcer ? Les autonomiser ? Voici un Ted talk plutôt connu dans lequel Dan Pink tente d'apporter quelques réponses : The surprinsing science of motivation. Et pour ceux qui ne le savent pas, le lecteur est plutôt bien fait avec entre autres de nombreuses transcriptions et traductions, liées à la vidéo.

Graphisme & co

Un lien sympa (parmi plein d'autres) pour savoir faire des formes en css.

Liste des liens présentés

Développement

Misc

Graphisme & co

  • # clojure

    Posté par  . Évalué à 5.

    Mais pourquoi les autres langages n'ont pas ça ?

    Je viens de tester:

    (> 4 3 2)
=> true
(> 4 2 3)
=> false

    Tu ne me l'aurais pas montré ça ne m'aurai jamais venu à l'esprit.

    • [^] # Re: clojure

      Posté par  . Évalué à 4.

      Ça existe aussi en python :

      >>> 2 < 3 < 4
True
>>> 2 < 4 < 3
False

      • [^] # Re: clojure

        Posté par  . Évalué à 1.

        Ça marche aussi en C :

        printf(1 < 2 < 3 ? "ok\n":"ko\n");
printf(2 < 3 < 1 ? "ok\n":"ko\n");


        ok
ko

        (exit(0);)

        • [^] # Re: clojure

          Posté par  . Évalué à 2. Dernière modification le 31 juillet 2012 à 15:46.

          Ou pas:

          if ( 2 < 1 < 4 )
    printf("fail\n");


          fail

          De manière générale, l'opérateur < renvoie 0 ou 1, et c'est cette valeur qui est utilisée pour la comparaison suivante…

          • [^] # Re: clojure

            Posté par  . Évalué à 2.

            Ah, ok merci… mais je crois que de toute façons, mon compilateur est cassé :

            #include <stdio.h>

int main(void) {
    int a, b;
    printf("valeur de a?\n");
    scanf("%d", &a);
    b <-- a;
    printf("a:%d   b:%d\n", a, b);
}


            valeur de a?
5
a:4   b:1695184

            • [^] # Re: clojure

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

              Non, ça semble correct.

              Par contre, je pense que la ligne b <-- a; n'est pas ce que tu voulais faire. Elle s'interprète comme b < (--a);, du coup la valeur de a passe de 5 à 4 et b qui n'était pas initialisé peut avoir n'importe quelle valeur.

              • [^] # Re: clojure

                Posté par  . Évalué à 5.

                Sans vouloir m'avancer je pense qu'on n'écrit pas un programme comme ça purement par hasard ;)

            • [^] # Re: clojure

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

              Troll?

              • [^] # Re: clojure

                Posté par  . Évalué à 2.

                Pas du tout, je cherche des gens à inviter à diner jeudi soir.

                Et qu'on ne m'accuse pas d'être ambigu, le (exit(0);) était quand même explicite.

        • [^] # Re: clojure

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

          Non, ça ne marche pas en C. Exemple :

          printf(-3 < -2 < -1 ? "ok\n":"ko\n");
// -> ko

printf(1 < 1 < 1 ? "ok\n":"ko\n");
// -> ok

          En fait, 1 < 2 < 3 va être interprété comme (1 < 2) < 3. 1 < 2 est vrai et renvoie donc 1 et 1 < 3 est également vrai.

          Par contre, pour -3 < -2 < -1, -3 < -2 est aussi vrai, mais 1 < -1 est faux.

  • # Gestion de sources et +, beaucoup plus, et léger, très léger !

    Posté par  . Évalué à 4.

    Comme vous l'avez probablement remarqué, je suis toujours en quête d'un bon outil pour gérer mes sources, mes bugs, mes code reviews, etc.

    Ne cherche plus : fossil est ce dont tu n'as même pas osé rêver.
    page principale : http://www.fossil-scm.org
    fonctionnalités en + gestion des sources : http://www.fossil-scm.org/xfer/doc/trunk/www/index.wiki
    le tout dans un exécutable de moins d'1Mo, installable sur un serveur web, ou seul( il possede son propre serveur !)

    • [^] # Re: Gestion de sources et +, beaucoup plus, et léger, très léger !

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

      fossil est ce dont tu n'as même pas osé rêver.

      Heu, comment dire…
      C'est probablement pas mal, mais ça ne me tente absolument pas.
      Ce que je cherche c'est plutôt quelque chose pour faciliter git et les opérations annexes (par exemple code review, ce dont fossil ne s'occupe pas).

      Il y a plein de raisons pour lesquelles je souhaite utiliser git et pas autre chose, et l'une d'elle est que de la sorte je suis compatible avec plein d'outils, plateformes, etc. Il devient hyper simple de créer un miroir ailleurs par exemple. Je vais très facilement trouver un connecteur pour un soft d'intégration continue, etc.

      Fossil ça me semble bien pour… heu… oué bon juste pour faire un petit truc dans un coin. Mais ça ne me donne que moyennement confiance (probablement à tord) et super pas envie en fait…

      Et le côté exécutable de 1Mo, argument souvent annoncé, est vraiment pas un critère pour moi pour le coup. Le côté j'ai pleins d'outils qui bouffent du git est beaucoup plus pertinent

      Et d'ailleurs, pour savoir, comment il se comporte en distribué ? Branches, anonymes ou non, publiées sur le serveur ou non, facilité à revenir en arrière, etc ? Et qu'on ne dise pas comme tous les DCVS car vu les différences (y compris côté simplement utilisation agréable ou non) entre git, bzr et mercurial il y a forcément des différences à fossil

      • [^] # Re: Gestion de sources et +, beaucoup plus, et léger, très léger !

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

        Si tu es heureux avec git, toujours connecté et que tu fais appel à pleins de services hébergés, fossil ne te plaira pas.

        fossil est simple et c'est sa principale force. Avec git, je me retrouve souvent à passer plus de temps sur la gestion de version que sur mon code…

        Branches, anonymes ou non, publiées sur le serveur ou non, facilité à revenir en arrière, etc ?

        Oui il y a des branches (je ne sais pas ce qu'anonyme veut dire par contre), on peut revenir en arrière, fusionner facilement.

        Ce qui est intéressant, c'est que la documentation, le bug tracking ainsi que le site web et même la configuration du dépôt peuvent être versionnés.

        Le seul truc qui manque vraiment pour moi, c'est les pull requests.

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

        • [^] # Re: Gestion de sources et +, beaucoup plus, et léger, très léger !

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

          Si tu es heureux avec git

          pour le moment ça va

          toujours connecté

          pas forcément, mais pas besoin d'être toujours connecté avec un DCVS quelconque…

          tu fais appel à pleins de services hébergés

          pas forcément non plus

          Pour les branches, ce que je veux dire c'est qu'il existe pas mal de façons de faire. Les branches de git et mercurial par exemple ne sont pas identiques. Si je ne me trompe dans git une branche n'est qu'un pointeur vers un commit (en gros hein) alors que sous mercurial une branche est une méta donnée d'un commit.
          Et dans les faits ça change pas mal de choses, dans les deux cas en bien et en mal en fait…
          Avec mercurial il est super simple par exemple d'avoir des branches anonymes (donc sans nom) juste pour corriger un truc. Il suffit de revenir à un commit antérieur, et de faire un nouveau commit. Et hop, on récupère un nouvel head sur la branche. On peut alors le fusionner et c'est ok.
          Evidemment on peut faire un équivalent en git tout de même (et inversement pour les spécificités de git, même si c'est pas toujours évident).

          Prenez des gens qui font du git et collez les sous mercurial, vous verrez leur tête lorsqu'ils faudra utiliser les branches…

          D'où ma question, surtout pour ceux qui auraient utiliser les 2 (ou plus).

          Ce qui est intéressant, c'est que la documentation, le bug tracking ainsi que le site web et même la configuration du dépôt peuvent être versionnés.

          Ca part contre c'est un bon point, il est vrai.

          • [^] # Re: Gestion de sources et +, beaucoup plus, et léger, très léger !

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

            pas forcément, mais pas besoin d'être toujours connecté avec un DCVS quelconque…

            Oui pour les sources, mais du fait de son intégration, avec fossil tu as aussi accès au bug tracking et au wiki offline.

            Avec mercurial il est super simple par exemple d'avoir des branches anonymes (donc sans nom) juste pour corriger un truc.

            Je crois que l'équivalent avec fossil, c'est les branches privées.

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

          • [^] # Re: Gestion de sources et +, beaucoup plus, et léger, très léger !

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

            Pour les branches, ce que je veux dire c'est qu'il existe pas mal de façons de faire. Les branches de git et mercurial par exemple ne sont pas identiques. Si je ne me trompe dans git une branche n'est qu'un pointeur vers un commit (en gros hein) alors que sous mercurial une branche est une méta donnée d'un commit.

            Dans le temps, j'étais fan de mercurial et de sa gestion des branches. Depuis je suis fan de git et de sa version des branches. Et je n'apprécie plus autant mercurial.

            Mais au final, ça ne change pas grand chose. Avec git, pas besoin de branches anonymes. Tu peux créer une branche nommée "tmp" et c'est strictement équivalent tant que tu ne push pas tmp sur le dépôt partagé.

  • # Bof du sucre syntaxique sans grand intéret

    Posté par  . Évalué à 3.

    Mais pourquoi les autres langages n'ont pas ça ?

    Il y a d'autres langages qui ont ça, mais bon ne me demande pas lesquels ce n'est une fonctionnalité que je retiens (pas grand intérêt)..

    Par contre un langage avec un comportement sain des entiers (exception de dépassement ou big Int) ça c'est intéressant (mais pas si fréquent que ça malheureusement) coffeescript étant une surcouche de javascript ne l'a pas d'ailleurs.

    • [^] # Re: Bof du sucre syntaxique sans grand intéret

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

      Bof du sucre syntaxique sans grand intéret

      Du sucre syntaxique oui, absolument.
      Sans grand intérêt je ne suis pas d'accord.
      L'intérêt peut être (si utilisé à bon escient) une meilleure lisibilité et une compréhension plus facile du code.

      if (score > 10 && score < 100) {
  displayGreenBadge();
}


      displayGreeBadge if 10 < score < 100

      est, je trouve, plus sympa, plus lisible et plus compréhensible.
      Evidemment ça ne change pas grand chose au final. Mais une plus grande lisibilité c'est aussi moins de risques d'erreur, une maintenance plus facile, moins de risques de régressions, etc.

      C'est comme le fait d'avoir des conditions inversées (écrire plop() if (...) plutôt que if (...) { plop(); } ou avoir des mots clés pour les conditions négatives (unless)

      • [^] # Re: Bof du sucre syntaxique sans grand intéret

        Posté par  . Évalué à 3.

        Tout les langages permettent d'écrire :

        if (10 < score && score < 100) {
    // du code
}

        Je trouve ça lisible. Les mots clefs pour les conditions négatives je suis pas sûr que ce soit une bonne idée, parce que ça apporte à peut près rien et ça permet d'écrire des conditions négative dans dans une condition négative et ça c'est bien moins lisible.

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

        • [^] # Re: Bof du sucre syntaxique sans grand intéret

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

          Oui ton exemple est lisible. Mais ça se lit quand même comme deux conditions séparées par un 'et' là où l'autre solution se lit immédiatement comme un intervalle (et c'est juste mieux, sans être transcendant évidemment)
          Par contre, il y a un cas tordu : celui où la ligne est quand même plus grande, où le code est en prod, où il faut corriger à la vas vite un problème : et dans ce cas, parfois, l'une des deux variables seulement sera changée. Dans l'autre cas (intervalle) c'est pas possible. Alors oui, on va me dire que c'est pas vrai, que c'est parce que le dev est mauvais, etc. Oui. Mais la réalité c'est que ce genre de cas existe. Et qu'il y a un tas de choses bonnes à prendre pour éviter ce genre de problème.

          Les mots clefs pour les conditions négatives […] ça apporte à peut près rien et ça permet d'écrire des conditions négative dans dans une condition négative et ça c'est bien moins lisible.

          Déjà sur la fin : et alors ? On devrait refuser car il peut y avoir un mauvais usage, c'est ça ? Des mauvais usages il y en a tout le temps, et c'est pas l'ajout de unless qui va empêcher les mauvaises écritures, ni les favoriser.

          entre 

          display if !empty

          ou

          display unless empty

          mon choix est vite fait, je préfère la deuxième solution. Et comme pour le premier problème, si je peux virer le ! c'est parfois préférable. Il m'est arrivé de voir des codes qui ne fonctionnaient pas, les développeurs ont cherché pendant pas mal d'heures, pour finalement, bien après, se rendre compte que c'était juste à cause du !. Alors idem, on va dire que c'est pas possible, que c'est des mauvais dev. Mais quoi qu'il en soit ce cas arrive. L'ajout de unless permet de gagner beaucoup en expressivité et est moins source d'erreur. Evidemment celui qui écrit unless !condition là il faut probablement le fouetter…

          Mais évidemment là c'est des cas simples.

          En js j'écris souvent :

          if (!('id' in plop)) {
  // ...
}

          et ce serait beaucoup mieux, plus lisible et moins source d'erreur d'avoir :

          unless 'id' in plop
  # ...

          Après, parfois j'ai quand même l'impression que certains (je ne te vises pas forcément hein ;) ) sont tellement habitués à avoir des langages pauvres (et ne parlons même pas de java…) que le moindre ajout d'expressivité est mal perçu. Et c'est vraiment dommage.

          • [^] # Re: Bof du sucre syntaxique sans grand intéret

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

            unless 'id' in plop
            # …

            En python on pourra certes l'écrire comme ça :

            if not 'id' in plop:
  # ...

            mais aussi comme ça :

            if 'id' not in plop:
  # ...

            qui me semble assez proche de ton envie d'expressivité, et sans ajouter de mot clé.

            • [^] # Re: Bof du sucre syntaxique sans grand intéret

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

              Et si la condition est plus importante tu te retrouves avec if not bla bla bla bla ce qui non ne change rien à !.

              En fait j'arrive pas à comprendre ce qui dérange vraiment certains dans le fait d'avoir plus de mots clés dans le langage…

              • [^] # Re: Bof du sucre syntaxique sans grand intéret

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

                Je n'ai jamais dit que ça me dérangeait d'ajouter des mots clés ; j'ai juste dit qu'en Python il y avait une alternative sympa à if !('id' in plop), et qui ne nécessite pas de mots clés supplémentaire ; c'est tout.

              • [^] # Re: Bof du sucre syntaxique sans grand intéret

                Posté par  . Évalué à 3.

                En fait j'arrive pas à comprendre ce qui dérange vraiment certains dans le fait d'avoir plus de mots clés dans le langage…

                C'est pas que ça me dérange. C'est qu'unless me semble peut important.

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

          • [^] # Re: Bof du sucre syntaxique sans grand intéret

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

            Evidemment celui qui écrit unless !condition là il faut probablement le fouetter…

            Peut-être est-ce une mauvaise idée mais j'utilise régulièrement 

              blabla unless not truc.nil?

            J'utilise unless lorsque le cas général est que le code conditionnel doive s'exécuter, et if lorsque le cas général est que le code conditionnel ne doive pas s'exécuter. Dit autrement, unless signifie pour moi « fais cela, sauf si exception », et if signifie « fais cela, seulement si exception ».

            Du coup j'ai souvent des unless not, unless, if et if not en fonction de la sémantique du code et de la condition.

          • [^] # Re: Bof du sucre syntaxique sans grand intéret

            Posté par  (Mastodon) . Évalué à 5.

            En C:

            #define unless(p) if(!(p))

unless (empty) {
  display
}

            Et hop !

          • [^] # Re: Bof du sucre syntaxique sans grand intéret

            Posté par  . Évalué à 3.

            On devrait refuser car il peut y avoir un mauvais usage, c'est ça ?

            Ce n'est pas ce que j'ai dis. J'ai dis que le gain est minime et le risque important.

            Il m'est arrivé de voir des codes qui ne fonctionnaient pas, les développeurs ont cherché pendant pas mal d'heures, pour finalement, bien après, se rendre compte que c'était juste à cause du !. Alors idem, on va dire que c'est pas possible, que c'est des mauvais dev. Mais quoi qu'il en soit ce cas arrive. L'ajout de unless permet de gagner beaucoup en expressivité et est moins source d'erreur.

            Je ne suis pas convaincu que unless aide. Il sera toujours possible d'écrire :

            foo unless !cond;

            Ce genre de chose est une plaie.

            Evidemment celui qui écrit unless !condition là il faut probablement le fouetter…

            Justement je pense qu'il y a plus de chance que ça arrive que de l'aide que ça peut apporter.

            Après, parfois j'ai quand même l'impression que certains (je ne te vises pas forcément hein ;) ) sont tellement habitués à avoir des langages pauvres (et ne parlons même pas de java…) que le moindre ajout d'expressivité est mal perçu. Et c'est vraiment dommage.

            Personnellement j'adore perl et profite autant que possible de toute sa richesse (quel pied d'utiliser given/when par exemple). D'une manière générale je fais mon possible pour le rendre conçis (ce qui implique d'éviter un maximum de boucle par exemple là où un tas de méthodes s'appliquent directement sur une liste.

            Pour ce qui est du unless, je trouve qu'il ajoute tellement peu de sémantique qu'il n'a pas beaucoup d'importance. Par contre je peste régulièrement de voir tant de programmeurs ne pas utiliser de switch alors qu'il apporte un vrai gain (et qu'il est disponible dans un tas de langage).

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

            • [^] # Re: Bof du sucre syntaxique sans grand intéret

              Posté par  . Évalué à 1.

              Je ne suis pas convaincu que unless aide. Il sera toujours possible d'écrire :

              foo unless !cond;

              Ce genre de chose est une plaie.

              En pratique, dans les langages où on a if et unless postfixés, les cas d'utilisations des deux sont davantages liés à la probabilité: "Fais ceci sauf si c'est désactivé" implique que dans le cas normal ce sera fait.

              Ceci dit, oui, c'est pas hyper-utile.

              • [^] # Re: Bof du sucre syntaxique sans grand intéret

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

                Ceci dit, oui, c'est pas hyper-utile.

                Oui, mais le problème d'aller par là c'est qu'il y a plein de choses qui ne sont pas hyper utiles…

                Par exemple, pourquoi écrire :

                var i;
for (i = 0; i < l; i++) {
  // bla
}

                Alors qu'on pourrait écrire :

                var i = 0;
while (i < l) {
  // bla
  i++;
}

                C'est pas transcendant non plus…

                • [^] # Re: Bof du sucre syntaxique sans grand intéret

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

                  Et puis pourquoi utiliser 

                  do{
   //bla
}while(1==4);

                  Quand on pourrait faire

                  int a=1;
while(a>0 || 1==4){
   a=0;
   //bla
}

                  Le sucre syntaxique est une abomination du démon, il faut créer une version de C-- qui enlève toutes ces fioritures, et SamWang< pourra coder Zino avec.

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

                • [^] # Re: Bof du sucre syntaxique sans grand intéret

                  Posté par  . Évalué à 2.

                  Le for du C (celui que tu montre) montre une itération. Il est d'ailleurs utilisé bien souvent de manière non-intuitive pour faire autre chose. Le foreach est bien plus pertinent (il apporte de la sémantique en limitant les mauvais cas d'usage).

                  Je n'avais pas vu la subtilité que propose nud et qui me semble bien plus pertinent que ce que indiquait (et qui laisse libre court à des conditions négatives dans un unless), mais tu vois bien que unless (comme until d'ailleurs) apporte bien moins d'expressivité que for (il en apporte mais moins).

                  Tu devrais te pencher sur ruby pour voir un tas de manière de faire des boucles de manière très très lisible.

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

                  • [^] # Re: Bof du sucre syntaxique sans grand intéret

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

                    Le for du C (celui que tu montre)

                    raaaa non, avec var c'était du javascript :)

                    montre une itération

                    Oui, mais c'est pas nécessaire d'avoir un for pour ça

                    Il est d'ailleurs utilisé bien souvent de manière non-intuitive pour faire autre chose

                    Ce qui est souvent une horreur, et dans ces cas il vaudrait bien mieux des mots clés dédiés (ou des macros si besoin par exemple) qui permettraient de s'approcher de la volonté, de l'intention du programmeur et non de purement l'implémentation.

                    Tu devrais te pencher sur ruby

                    Ha mais c'est justement pour ces raisons (par exemple unless) que j'aime beaucoup ruby. En fait l'expressivité des langages permettent souvent de mettre en évidence l'intention du programmeur, et ça c'est réellement important pour pouvoir comprendre et corriger, maintenir un programme.

                    • [^] # Re: Bof du sucre syntaxique sans grand intéret

                      Posté par  . Évalué à 2.

                      Le for du C (celui que tu montre)

                      raaaa non, avec var c'était du javascript :)

                      Mince je suis passé vite dessus et le fait que la variable soit déclarée à l’extérieur m'a induit en erreur.

                      Ce qui est souvent une horreur, et dans ces cas il vaudrait bien mieux des mots clés dédiés (ou des macros si besoin par exemple) qui permettraient de s'approcher de la volonté, de l'intention du programmeur et non de purement l'implémentation.

                      Multiplier les mots clefs ne me semble pas une bonne idée. Une vraie bonne approche pour ça, c'est perl (mais je suis certain qu'un paquet de langages le font aussi bien sinon mieux) : utiliser des fonctions !

                      Si tu veux utiliser une boucle pour filtrer, tu utilise la méthode grep.
                      Si tu veux appliquer un bout de code à chaque élément d'une liste, tu utilise map.
                      Si tu veux faire une réduction, tu utilise reduce.

                      C'est aussi ce que propose C++ avec la partie algorithm de la STL : http://fr.cppreference.com/w/cpp/algorithm

                      Pourquoi ajouter des mots clef quand ça peut être fait via de la bibliothèque ?

                      Ha mais c'est justement pour ces raisons (par exemple unless) que j'aime beaucoup ruby. En fait l'expressivité des langages permettent souvent de mettre en évidence l'intention du programmeur, et ça c'est réellement important pour pouvoir comprendre et corriger, maintenir un programme.

                      J'ai juste dis que unless apporte très très peu à ce niveau là c'est tout (mais c'est vrai que la nuance que nous a fait remarqué nud change un peu la donne).

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

    • [^] # Re: Bof du sucre syntaxique sans grand intéret

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

      C# :)

    • [^] # Re: Bof du sucre syntaxique sans grand intéret

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

      Ben voilà ! Utilise Scheme ou Lisp !
      T'as un comportement sain des entiers, la fonctionnalité requise et même mieux :

      (apply < '(1 2 3 4 5))

      Et ça existe en plein de variations (Gambit, Racket, Gauche, SBCL, Clojure, ), avec au moins une qui te plaira !

  • # git tag

    Posté par  . Évalué à 3.

    Et pourquoi ne pas utiliser git tag plutôt que de faire un branch?

    C'est ce que j'utilise pour éviter de faire le mammouth avant un merge, et pour faire le lien entre les numéros de version et les commits (y'a pas de branches pour la maintenance, on fait tout sur la même branche parce que le code est très spécifique à chaque version).

    C'est un peu plus léger et rapide qu'un branch.

    • [^] # Re: git tag

      Posté par  . Évalué à 2.

      Je ne suis pas si sur. Avec git tag j'ai toujours peur d'avoir un commit fait par un dev dans sans branches de developement qui se trouve merge avant le tag. Du coup le tag ne correspond pas a la version voulu. Je me trompe peut etre mais bon vu le coup d'avoir une branche avec git, je prefere me la jouer secure.

      • [^] # Re: git tag

        Posté par  . Évalué à 2.

        Je ne suis pas si sur. Avec git tag j'ai toujours peur d'avoir un commit fait par un dev dans sans branches de developement qui se trouve merge avant le tag.

        Quoi ?

    • [^] # Re: git tag

      Posté par  . Évalué à 2.

      Non, les branches sont faites pour ça. Les tags c'est pour marquer des points précis dans ton code, alors qu'un merge ça va recouvrir un ensemble de commits ; mieux vaut une branche pour les tracker correctement. Après, dans l'absolu, les deux sont des refs, donc c'est pareil, mais le tag peut potentiellement avoir plus d'attributs (signature GPG, …).

      • [^] # Re: git tag

        Posté par  . Évalué à 2.

        Dans son cas, la branch est utile seulement pour pouvoir faire un 'git reset --hard nom_de_branche', au lieu de faire 'git reset --hard id_de_commit'. Et pour autant que je sache, on peut aussi faire 'git reset --hard nom_de_tag'.

        Comme c'est marqué en gros sur le site en lien, dans son utilisation ça marche parce que git branch "C’est une putain d’étiquette toute simple". Une étiquette, en anglais ça s'appelle un tag :)

        Dans son cas, je ne vois pas la différence entre faire un tag et faire une branche au niveau fonctionnalité recherchée. J'ai loupé quelque chose?

        • [^] # Re: git tag

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

          Une branche et un « lightweight tag » seront exactement équivalents. Dans les deux cas, ce sont des références nommées vers un commit. La vraie différence entre une branche et un tag, c'est que quand on fait « git checkout ; git commit », ça déplace la branche, alors que « git checkout ; git commit » va nous mettre en « detached HEAD » et ne va pas toucher au tag. Pour cette utilisation, je préfère un tag.

          Tout ceci étant dit, je ne comprends pas bien pourquoi l'auteur de l'article pointé s'énerve autant pour un merge.

          $ git pull
# ...
# ratage de résolution de conflits
# ...
$ git reset --merge

          git refuse de démarrer un merge si les fichiers concernés par le merge sont modifiés, et « git reset --merge » ne va réinitialiser que les fichiers concernés par le merge, donc ça marche, sans point de sauvegarde (c'est juste HEAD), et sans « git stash » préalable.

  • # Geary

    Posté par  . Évalué à 3.

    Je confirme, c'est prometteur. Je l'ai testé il y a quelques mois, ça ne marchait pas encore bien mais l'interface est sympathique.

    Pour aller avec lui, il se prépare GNOME Calendar bâti au dessus d'Evolution Data Server. Pour l'instant c'est un peu léger mais pareil, ça s'annonce bien d'autant qu'il y a des recherches ici. Par contre, pour tester il faut minimum Evolution 3.5.3.

    Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

    • [^] # Re: Geary

      Posté par  (site web personnel, Mastodon) . Évalué à 3. Dernière modification le 01 août 2012 à 07:45.

      Pour rappel, Geary est développé en collaboration avec le projet elementary dont on retrouve la patte dans l'interface graphique. Il sera le client email par défaut du bureau Pantheon et donc d'elementaryOS Luna (sortie quand c'est prêt mais mon petit doigt me dit "avant la fin de l'année").
      Postler, feu le client mail d'elementary, a été déprécié car trop buggué sur la partie service (l'interface fonctionnait très bien et ressemblait comme deux goûtes d'eau à l'actuelle de Geary) a été abandonné au profit de cette collaboration.

      Pour information il est for probable que l'interface de Shotwell soit également retravaillée par Daniel Foré, leader et designer en chef d'elementary (Adam Dingle, le big boss de Yorba, attend encore le design parfait pour ça).

  • # pinry

    Posté par  . Évalué à 4.

    http://overshard.github.com/pinry/

    Pinry is a private, self-hosted, Pinterest inspired by Wookmark and built on top of Django.

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

  • # La conférence sur TED était très intéressante

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

    Merci !

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

  • # dév web

    Posté par  . Évalué à 1.

    tiens, un lien de plus : un autre site qui recense les fonctionnalités de son navigateur (et des autres)

    html5test.com

    attention, ça enregistre des choses côté serveur (mais apparemment on n'est pas obligé de confirmer qu'on utilise le navigateur truc-muche)

    Envoyé depuis mon Archlinux

Suivre le flux des commentaires

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