barmic a écrit 10455 commentaires

  • [^] # Re: À mort les SS2I

    Posté par  . En réponse au journal sous-developpeurs-SSII. Évalué à 3.

    C'est vrais j'oubliais que les Marmottes mettent les barres de chocolat dans le papier d'alu :-D.
    Sans rire, au risque d'être désagréable à part en Ile de France on a beaucoup de mal à trouver un "boulo ailleurs"

    Euh… Grenoble pour mon exemple n'est pas en IdF.

    D'une clause dans ton contrat qui stipule (en gros) que tu n'as pas le droit d'aller voir ailleurs et que tu n'as pas le droit d'être embauché par ton client. Au dernière nouvelles cette clause serait illégale et contraire à une ou plusieurs lois Française, mais elle est tout de même toujours présente dans mon contrat par exemple.

    Cool comme tu as l'air de t'intéresser au droit du travail, tu sais que tu t'en fou de cette clause. Ce n'est pas parce que sur ton contrat de travail, il est écris quelque chose que ça doit être appliqué. En l'occurrence en droit du travail une telle clause si elle est illégale est réputée non-écrite donc tu peux l'ignorer.

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

  • [^] # Re: À mort les SS2I

    Posté par  . En réponse au journal sous-developpeurs-SSII. Évalué à 4.

    Mais surtout il faut que tu la ferme car sinon c'est le chomage que le medef tente encore de faire baisser pour que l'argument de pression soit encore plus grand (ou alors c'est pour la sainte croissance je ne sais plus -_-). Et puis sois content il y en a plein qui aimerait avoir ta place.

    Sérieux ? (à ma connaissance) Ma promo n'a pas connu le chômage à 2 exceptions près. Certains depuis la fin de leur et ont changé de boite (volontairement) sans passer par la case chômage. Ils sont tous en CDI depuis le début.

    Je ne vois vraiment pas de quoi tu parle ? On ne vire pas quelqu'un sur un coup de tête en France et le marché de l'emploi est hyper favorable au salarié (en tout cas depuis quelques années). Tu bosse au fin fond de l'Ardèche ?

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

  • [^] # Re: variante

    Posté par  . En réponse au journal sous-developpeurs-SSII. Évalué à 3. Dernière modification le 12 avril 2015 à 00:06.

    Si personne ne se plains, pourquoi changer ?

    Par se plaindre j'entends autre chose qu'écrire des articles de blog et se montrer pas content. Si du point de vu des dirigeants, il n'y a pas vraiment de problèmes remontés (toujours 36 postulants par poste et le travail est toujours effectué), c'est que la machine tourne plutôt bien (de leur point de vu en tout cas).

    Je vais le dire autrement. Comment est-ce que ça arrive à fonctionner ? Pourquoi les gens continuent de travailler pour l'État et pourquoi des nouveaux s'y engouffrent ?

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

  • [^] # Re: m a v e n

    Posté par  . En réponse au journal Gestionnaire de dépendances en C++. Évalué à 5.

    Ce que tout le monde dis, c'est qu'on s'en fout du langage. Tu t'interdit un outil avec pour principal voir seul prétexte, il n'est pas dans mon langage c'est pas sérieux. Alors que tout le monde s'en fout.

    AMHA il vaut mieux avoir un outil qui tourne sur nodejs que pas d'outils du tout, mais après c'est toi qui vois.

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

  • [^] # Re: Mercurial

    Posté par  . En réponse au journal Git a fêté ses 10 ans hier .... Évalué à 6.

    le principe des phases, la gestion à la mq, un git outgoing,…

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

  • # Mercurial

    Posté par  . En réponse au journal Git a fêté ses 10 ans hier .... Évalué à 8.

    Sa puissance, ses qualités et son architecture y sont pour quelque chose; l'aura de son créateur bien plus selon moi.

    Je pense aussi, je ne vois pas ce que git a de plus que mercurial (mais je vois quelques trucs qu'il a en moins :) ) et j'utilise plus git que mercurial.

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

  • [^] # Re: Des promesses...

    Posté par  . En réponse au journal Biicode: gestionnaire de dépendances c++. Évalué à 3.

    Donc si tu fais de la construction de projet générique, tu fais bien des dizaines de choses différentes, même si de loin dans le brouillard ça se ressemble.

    Non tu laisse le soin à des dizaines de choses différentes le soin de faire de ces dizaines de choses. Toi tu veux un outils qui fasse à la fois du grep, du templating, de la génération de code,… si les autotools ont découpés ça en plusieurs morceaux ce n'est pas pour rien. Pour moi ils pêchent parce que l'ensemble est devenu compliqué.

    Regarde comment maven gère ça. Toutes ces actions spécifiques sont gérées par des plugins et écrire un plugin est trivial. Les plugins se configurent de manière standard de la même façon pour tous et ils exposent des targets spécifiques.

    C'est déroutant tellement c'est simple et si tu veux que le build change en fonction de la météo et de la position de ton smartphone le tout avec un langage que t'as pondu toi, c'est possible et ça demande uniquement décrire un nouveau plugin.

    Tu prône de la spécificité pour la spécificité en avançant comme seul argument que "de toute manière C++ c'est différent des autres". Alors que je te parle de modularité et de simplifier l'utilisation par des convention. Que l'outil soit écrit en ada je m'en fou mais réfléchir pour avoir de la flexibilité c'est mieux.

    Et tu as utilisé Maven ?

    Je ne connaissais pas à l'époque et aujourd'hui je ne m'en servirais pas. Pour les raisons que j'ai donné plus haut.

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

  • [^] # Re: Des promesses...

    Posté par  . En réponse au journal Biicode: gestionnaire de dépendances c++. Évalué à 3.

    Je suis curieux de comment tu fais les deux premiers avec Maven… juste pour voir.

    Tu peut écrire un plugin qui se configure ainsi :

    <configuration>
        <check type="exist" symbole="SetConsoleMode" in="windows.h" to="HAVE_SETCONSOLEMODE" />
    </configuration>

    Pour le second, il existe déjà un plugin filter, on peut en imaginer un qui utilise la syntaxe qui te fais plaisir.

    tu comprendras la différence par rapport à Java / Gradle / Ceylan.

    Ce n'est pas la question. Moi je te dis et je pense sincèrement qu'il n'y a rien d'impossible à créer un outil suffisamment modulaire pour se foutre du langage ou plus précisément d'encapsuler les parties spécifiques aux langages dans des modules/plugins/greffons/addons dédiés. Maven est l'exemple le plus connu, mais arrête de faire une fixette dessus (je t'ai déjà dis plus haut qu'utiliser maven n'est pas une bonne idée).

    CMake a tenté de le faire via leur macro (on peut créer ces propres macro si je ne m'abuse), mais c'est tellement simple que personne ne le fait et le fait de ne pas être un outil de build mais un outil qui génère les fichiers d'un build le rend compliqué à utiliser hors du cadre prévu par les développeurs.

    Si ton objectif est d'avoir un outil qui t'autorise à automatiser au mieux les différentes taches d'un build, de la manière la plus efficace et la moins verbeuse possible, pour te faire gagner du temps alors non.

    Et donc à faire outil que je peux customiser pour qu'il me génère des fichiers à partir d'autres (comme générer un fichier de données LDAP à partir d'un fichier xls, cas vécu).

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

  • [^] # Re: Des promesses...

    Posté par  . En réponse au journal Biicode: gestionnaire de dépendances c++. Évalué à 3.

    Chercher un outil qui fait tout, il y a de grandes chances que ça ne fasse rien de bien.

    Justement on est d'accord, il ne faut pas que l'outil s'intéresse à autre chose qu'à la construction de projet.

    Sinon, juste par curiosité, tu as déjà fait un code en C++ avec des dépendances ?

    Un petit logiciel qui travaillait sur des distances d'images en C++ avec Qt, boost et eigen, ça te va ?

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

  • [^] # Re: m a v e n

    Posté par  . En réponse au journal Gestionnaire de dépendances en C++. Évalué à 4.

    Il n'y a pas de raison mais c'est quand même plus crédible non ?

    Bof, tu t'offusque du fait d'utiliser un compilateur C++ qui ne soit pas écris en C++ (parce que gcc est passé en c++, il n'y a pas longtemps).

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

  • [^] # Re: Des promesses...

    Posté par  . En réponse au journal Biicode: gestionnaire de dépendances c++. Évalué à 3.

    Mais ils intègrent tout ce qu'il faut pour faire ce que j'ai décris plus haut en une simple ligne de configuration.

    Tu me montre « la simple ligne de configuration » qui permet ça dans make, gprbuild, cmake ?

    Tous des langages à JVM en gros ?

    Oui.

    Mais si tu te sens un ame de révolutionnaire, n'hesite pas à me prouver que j'ai tord et créer ton propre plugin maven pour re-faire autotools, je suis curieux de voir….

    Si tu relis ce que j'ai écris plus haut tu verra que j'ai dis que ce n'est pas forcément une bonne idée, juste que donner des arguments du genre "non mais avec C++ c'est différents" ça n'est pas pertinent parce que si tu réfléchis ton système de build par le petit bout de la lorgnette (en listant d'abord des détails) tu n'arrive pas loin et au contraire tu fini par un mauvais design.

    L'objectif c'est de lancer des tâches, d'avoir un cycle de vie intéressant (1 gestion de dépendance, 2 build, 3 lancement des tests, 4 déploiement là où tu veux - par exemple -), ensuite que lors du lancement des tâches (à chaque étape) tu puisse passer le maximum d'information à l'outil en question, d'avoir la possibilité de mettre des hooks dans tous les sens, remplacer une tâche par une autre (je veux remplacer gcc par pdflatex),… ce sont des question qui :

    • n'ont rien avoir avec ton langage (et c'est mieux tu pourra réutiliser ton outil quand tu te mettra à rust) ;
    • n'ont pas à être implémentés en C++ (et c'est cool tu va pouvoir jouer à écrire ça en go).

    Pour ce qui est de maven, ses 2 principaux défauts AMHA c'est :

    • la gestion des dépendances (je ne sais pas comment personnaliser cette partie là)
    • le fait que la construction (la compilation en elle même) est considérée comme une étape atomique (en une étape on compile tous les .java en .class). Donc la gestion de comment je choisi si je compile tel ou tel fichier doit être dupliquée

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

  • [^] # Re: Ca donne envie

    Posté par  . En réponse au journal 0linux: LA distribution FRANCOPHONE pour LES francophones par DES francophones . Évalué à 5.

    PS : le coup du "tuyau cassé" n'a pas été inventé.

    Plusieurs choses :

    1. Ça c'est un problème de mauvaise traduction. « broken pipe », « reset by peer » ça peut très bien se traduire par « lien réseau cassé » et « réinitialisé par le destinataire1 » ;
    2. Des fois des termes ne peuvent se traduire ou ils sont bien mieux compris en anglais, dans ce cas là tu peut ne pas traduire ces termes (ce qui est différent de ne pas traduire le message). « aborted commit » peut alors devenir « commit annulé » ;
    3. Souvent tu peut relancer ton application en changeant la locale si besoin ;
    4. Tu peux mettre tout ou parti de la VO entre parenthèse à la suite de ton message.

    Bref il y a probablement des cas où ça ne marche pas et je suis persuadé que tu va t'échiner à en trouver, mais de là à considérer que c'est la règle plutôt que l'exception et qu'il ne faut pas d'abord chercher à traduire avant de se dire que pour ce cas précis ce n'est pas une bonne idée. Je ne suis pas d'accord.

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

  • [^] # Re: m a v e n

    Posté par  . En réponse au journal Gestionnaire de dépendances en C++. Évalué à 7.

    Maven ne convient pas parce que C++ a beaucoup de spécificités.

    C'est quoi les spécificités ? Sachant que jamais make n'a était pensé pour du C++ (ni pour latex, etc).

    Ce que tu cherche c'est un système de build avec gestion de dépendance, c'est à dire :

    • une déclaration de dépendance avec téléchargement et installation de dépendance
    • pouvoir produire une série de règles qui dit à partir de quels fichiers faire quoi

    Il y a un tas de projets en C ou C++ qui utilisent (ou utilisaient scons en python).

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

  • [^] # Re: Des promesses...

    Posté par  . En réponse au journal Biicode: gestionnaire de dépendances c++. Évalué à 3.

    Il n'y a rien dans ce que tu décris qui ne puisse être géré par un plugin. Sérieusement avoir un découpage net entre ce qui touche au langage et ce qui gère le projet, c'est un minimum de propreté dans le travail. make ne sait pas lire du C++, il ne comprends rien au C non plus. Idem pour les autotools qui ne bittent rien d'autre que le langage spécifique de chacun des outils. CMake lis du C++ comme un développeur js.

    Bref non aucun de tes outils existant ne fait ce que tu dis. Ce qu'ils font c'est des paramétrages de programmes (en fonction du système, d'un paramétrage dans leur fichier de configuration ou en paramètre lors de leur lancement) et ça n'a rien rien de difficile ni pour maven, ni gradle, ni scons, etc.

    Maven ne supporte pas ça, n'est pas adapté pour ça, ne le sera sûrement jamais…. Et à mon humble avis, ne doit pas essayer de l'être…. sous peine de devenir un bordel encore plus complexe que les autotools eux même.

    Il n'a pas à le supporter. Les gens qui ont permis à maven de travailler sur du groovy, du scala, du ceylon voir de faire des choses plus tordus comme gwt n'ont pas touché au code de maven pour ça. De même pour ceux qui ont créé le plugin nar pour gérer du C et C++ (il est peut être pas complet, mais il peut s'améliorer) : http://stackoverflow.com/questions/1541771/using-maven-for-c-c-projects

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

  • [^] # Re: Mes idées

    Posté par  . En réponse au journal Gestionnaire de dépendances en C++. Évalué à 3.

    Ce n'est pas qu'une question de droit, mais simplement de propreté. Si tu fais un premier projet qui demande la bibliothèque A et que tu fais un second projet avec la même bibliothèque si tu utilise les même répertoire tu va devoir dans ton linker faire des ajouts plus compliqués, tu veux pas non plus que la bibliothèque que tu ne connais pas et que tu découvre soit accessible depuis n'importe où sur le système. Tu veux aussi en tant que développeur virer la totalité de ton dépôt (parce qu'il y a un problème ou pour faire des tests) sans pour autant casser la totalité de ton système.

    Utiliser ${XDG_DATA_HOME}, c'est une bonne idée.

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

  • [^] # Re: Ca donne envie

    Posté par  . En réponse au journal 0linux: LA distribution FRANCOPHONE pour LES francophones par DES francophones . Évalué à 6.

    Sinon, j'espère que c'est pas si traduit que ca. Souvent, traduire est une mauvaise idée. Par exemple, si les messages d'erreurs sont traduits, c'est une erreur : google ne renverrra aucune réponse pertinente pour un message d'erreur traduit, et tu ne trouveras aucune aide si tu parles de "tuyau cassé" au lieu de "broken pipe"

    Ça c'est une belle connerie. Si les messages ne servent plus à ce que l'utilisateur comprenne l'erreur mais à aller chercher dans une table (via un moteur de recherche plain text si tu veux utiliser une tsar bombe pour te limer les ongles alors tu peut plus simplement créer des codes d'erreurs et documenter tes codes d'erreur comme c'est fait avec http, mais aussi par oracle). Du coup ton logiciel peut retourner en même temps un message d'erreur qui essaie d'expliquer à l'utilisateur comment se débrouiller et un code que tu aura documenté et (donc pas la peine de moteur de recherche) et au pire le nom de ton logiciel + le code permettra de se retrouver.

    Bref c'est un abus ridicule de s'interdire de traduire pour ça.

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

  • [^] # Re: Des promesses...

    Posté par  . En réponse au journal Biicode: gestionnaire de dépendances c++. Évalué à 3.

    le commentaire parent donne plein de raisons

    Les quels ? Parce que parler des optimisations du compilateur pour comparer des builders ça n'a de sens que pour ceux qui ne font pas la différence entre make et gcc (en quoi make, cmake ou le builder que tu veux s'y connaît en « architecture, la taille des registres, la gestions des instructions de vectorisations (SSE…) » ? Note que c'est une question piège si tu en trouve un qui répond à la question c'est que c'est de la daube qui ne sera pas capable de gérer facilement des chaîne de compilations alambiquées).

    Perso je vois pas comment maven peut gérer les dépendances en C++ (il a un moteur de gestion de dépendance, mais l'installation des bibliothèques n'a rien avoir et il faut trouver un dépôt pour le C et le C++) et il sera désagréable car il est lent à démarrer à cause de la JVM, mais des arguments contre intéressants j'en ai pas vu dans le commentaire parent.

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

  • # Mes idées

    Posté par  . En réponse au journal Gestionnaire de dépendances en C++. Évalué à 5.

    simple à utiliser pour des petits projets : un simple fichier où on indique le nom de l'exécutable et la liste des sources devrait suffire pour tous les projets simples, avec des options par défaut sensées. Actuellement avec CMake, il faut quand même écrire un sacré pâté pour avoir un truc utilisable.

    Un truc à la gprbuild.

    Il faut créer un équivalent à virtualenv pour du C++. Il serait bien qu'un outil de ce type ne touche pas au système, ne demande pas des droits particulier et qu'un projet n'est pas d'effet de bord sur le reste.

    Il faut une syntaxe la plus déclarative possible tout en étant puissante. Il est intéressant de regarder gradle pour avoir un exemple de fichier parsable humainement par des outils, mais puissant.

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

  • [^] # Re: Ansible / Puppet

    Posté par  . En réponse à la dépêche Présentation d'Ansible et version 2 à venir. Évalué à 4.

    De ce que j'ai vu, ansible est assez populaire chez les codeurs (ce qui n'est pas étonnant, vu qu'au final, c'est une suite de pas à suivre pour déployer ou obtenir un état), la ou puppet va plus correspondre à l'état d'esprit d'un packageur ou d'un architecte (le fait d'avoir des bouts d'état interdépendant pour obtenir un état général de ton infra, et de converger vers cet état). Donc en fonction de tes affinités, l'un va te paraitre plus naturel que l'autre.

    J'ai du mal à comprendre pourquoi c'est ansible qui a tant de succès là où fabric est un vrai pur outil de développeur qui reprends les même propriétés qu'ansible (pas de serveur centrale ni d'agent, description d'une suite d'instructions) sans un certains nombre d'inconvénients (un langage connu par beaucoup et complet, mise en place encore plus simple je trouve,…).

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

  • [^] # Re: De l'openwashing

    Posté par  . En réponse au journal Windows éventuellement en open source?. Évalué à 10.

    Tu mélange tout. Microsoft fait son beurre sur le desktop, là où Linux ne représente rien. Sur serveur c'est le prix et la qualité intrinsèque qui font la différence et qui font que linux est devant Windows et AIX. Le libre est un moyen de faire quelque chose de qualité pour pas chère, pas un objectif en soit. Les clients de Red Hat et ceux de MS se comportent de la même façon,il n'y a pas de synergie particulière.

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

  • # OMFG !

    Posté par  . En réponse au journal Angular JS 2.0. Évalué à 2.

    OMFG ! Une techno web qui évolue ?! Mais on a jamais vu ça ! Manquerait plus que ça ! Bientôt on va devoir se former à des trucs comme les web worker, des indexed db voir même des ecmascript6 ! Non mais vraiment !

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

  • [^] # Re: Zsh

    Posté par  . En réponse au journal Faire de la magie avec son .inputrc. Évalué à 5.

    Oui je zle possède de base (pour ce que j'utilise) :

    • Echap + q : supprime la ligne courante le temps de lancer une commande puis la recolle (si on a oublié le nom de quelque chose on peut lancer une commande puis reprendre sa ligne ou si on a oublié de créer un dossier)
    • Echap + ? : lance la commande which-command sur la commande courante puis redonne la ligne dans l'état précédent (prend correctement en charge les choses comme PATH=tutu ls /tmp)
    # Remplacer des touches par d'autres touches
    bindkey -s '\el' '^e | less'

    Perso ça je le fais avec :

    typeset -Ag abbreviations
    abbreviations=(
      'Ia'    '| awk'
      'Ig'    '| grep'
      'Ip'    "| $PAGER"
      'Ih'    '| head'
      'It'    '| tail'
      'Is'    '| sort'
      'Iw'    '| wc'
    )

    Ce qui permet de le faire avec "Ip ".

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

  • [^] # Re: Utilisation du mode vi ?

    Posté par  . En réponse au journal Faire de la magie avec son .inputrc. Évalué à 6.

    Si c'est juste pour ce globbing là, tu l'a déjà en bash :

    shopt -s globstar

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

  • # Zsh

    Posté par  . En réponse au journal Faire de la magie avec son .inputrc. Évalué à 10.

    donc bash, mais pas zsh… Raison principale pour laquelle je ne suis toujours pas passé à zsh !

    Et si tu préfère c'est très bien. Moi tu m'as donné de bonnes idées, il faudra que je regarde comment les mettre en place avec zle (le readline de zsh) :-)

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

  • [^] # Re: Faux

    Posté par  . En réponse au journal parait que ca manque de troll. Évalué à 7.

    suffit d'aller dans n'importe quelle convention libriste pour le voir.

    Au devoxx ou à l'eclips con par exemple ? Elle fait peine ton argumentation.

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