barmic a écrit 10455 commentaires

  • [^] # Re: ça marchera jamais?

    Posté par  . En réponse au journal Ubuntu Edge : Révolution ou bide annoncé ?. Évalué à 4.

    Hum, je ne comprends pas trop. Soit tu parle de la compilation d'un code en langage X vers asm.js, ça c'est fait manuellement par le développeur une bonne fois pour toute. Soit tu parle de l'exécution du code asm.js qui passe peut être (je sais pas) par une compilation vers du natif.

    Si c'est ce dernier, le singe de Mozilla ne fait aucune différence entre du code asm.js et du code js écris à la main. Tous les langages de script aujourd'hui sauf le shell utilisent cette technique parce qu'on sest rendu compte que le temps de compilation et largement compensé par le gain en performance.

    Je vois pas en quoi c'est une si mauvaise idée que ç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: Mouai

    Posté par  . En réponse au journal Ubuntu Edge : Révolution ou bide annoncé ?. Évalué à 2.

    C'est l'histoire des langues vivante ç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:çamarchera jamais?

    Posté par  . En réponse au journal Ubuntu Edge : Révolution ou bide annoncé ?. Évalué à 2.

    La spec est toujours en brouillon, il va falloir attendre.

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

  • [^] # Re: ça marchera jamais?

    Posté par  . En réponse au journal Ubuntu Edge : Révolution ou bide annoncé ?. Évalué à 3.

    Disons que quand on voit des phrases aussi tranchées que « ça c'est des vrais app », on a du mal à y voir autre chose qu'un présent de vérité général et pas un avis. Donc soit on saute dans le troll soit on laisse les gens cracher sur ce qui ne leur plaît pas sans le moindre argument Ici, on est sur linuxfr…

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

  • [^] # Re: ça marchera jamais?

    Posté par  . En réponse au journal Ubuntu Edge : Révolution ou bide annoncé ?. Évalué à 3.

    Ça montre juste que l'argument "Firefox OS c'est nul, moi je veux des vraies application" est purement subjectif. Bref c'est du « moi j'aime pas ».

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

  • [^] # Re: ça marchera jamais?

    Posté par  . En réponse au journal Ubuntu Edge : Révolution ou bide annoncé ?. Évalué à 3.

    Pour l'avoir essayé (de même que ses concurrents): c'est marrant 5 minutes mais on ne joue clairement pas dans la même cour qu'Android ou Ubuntu (après, va savoir si ça vient du hardware bas de gamme ou de l'OS…).

    Ça ne viens pas aussi de la jeunesse de l'ensemble ?

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

  • [^] # Re: Les tests unitaires, c'est bon, mangez-en :-)

    Posté par  . En réponse au journal Ce qu'on demande à un développeur aujourd'hui. Évalué à 2.

    La vérification de couverture, cela peut être rapide. Cela permet au minimum de découvrir une zone oubliée. C'est toujours instructif.

    Tu as des outils pour faire ça automatique (couverture des instructions, des branches, des chemins…).

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

  • [^] # Re: Mouai

    Posté par  . En réponse au journal Ubuntu Edge : Révolution ou bide annoncé ?. Évalué à 2.

    C'est juste que dans la plupart des architectures actuelles

    Et à part peut être dans quelques labo, il existe une archi où ce n'est pas le cas ? L'ordinateur quantique probablement ?

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

  • [^] # Re: Mouai

    Posté par  . En réponse au journal Ubuntu Edge : Révolution ou bide annoncé ?. Évalué à 4.

    Il faut aussi faire gaffe, je présume qu'il s'agit de 4 Gio ce qui fait un peu plus de 34 Gb.

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

  • [^] # Re: Intéressant mais très « acronymique »...

    Posté par  . En réponse au journal Ce qu'on demande à un développeur aujourd'hui. Évalué à 1.

    TI tests d'intégration
    TU tests unitaires
    PIC plateforme d'intégration continue

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

  • [^] # Re: ça dépend de ce que tu code!

    Posté par  . En réponse au journal Ce qu'on demande à un développeur aujourd'hui. Évalué à 3.

    Je ne reproduit pas avec Firefox 21 sous Debian Wheezy Linux en 64 bits.

    Peux-tu détailler ton problème ?

    • As-tu des plugins dans ton navigateur ?
    • Avec quel navigateur cela se produit ?
    • Quelle version ?
    • Sur quel OS ?
    • Quel est le plugin flash que tu utilise ?

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

  • [^] # Re: ça dépend de ce que tu code!

    Posté par  . En réponse au journal Ce qu'on demande à un développeur aujourd'hui. Évalué à 2.

    Je pense que c'est overkill dans des projets simple (linuxFR par exemple) mais bon, jamais inutile.

    Ton objectif quelque soit le logiciel que tu développe que tu sois une SSII, un projet communautaire, quelque soit ton langage et quelque soit les utilisateurs. C'est que la version N+1 puisse faire ce que fait la version N avec des choses en plus.

    Tu tourne le problème dans le sens que tu veux mais l'idée c'est de trouver une solution pour garantir au mieux cette hypothèse de base. Pour ça tu as pleins de solutions (faire faire des tests par ta communauté, avoir tes recettes, embaucher des gars hyper-bon qui ne font jamais d'erreur, prouver ton logiciel, faire des tests, prier un dieux) et tu évalue la solution que tu met en place en fonction des contraintes de ton logiciel et de ta confiance en ceux-ci.

    Ne pas s'intéresser sérieusement à cette problématique c'est faire du logiciel à la noix où l'on continue à habituer les utilisateurs à avoir des bugs et des régressions. La preuve que beaucoup de logiciels sont dans ce cas ? Certains sont bien heureux de pouvoir downgrader leur logiciel. Toute la plus value des distributions « stable » (Debian et Red Hat) par exemple viens du fait qu'ils ne prennent pas les logiciels upstream mais les logiciels upstream testé (par eux même et pas les autres distributions).

    Je sais pas ce que tu veux me faire dire de plus.

    J'essaie juste de partager mon point de vu, rien de plus. On voit pleins de monde jouer des biscoto en expliquant qu'ils économisent x octets d'un coté et n de l'autre et qu'avec ça dans leur cas d'utilisation, le logiciel consommer 70 fois moins de mémoire et généraliser pour dire que c'est la base que nous devrions tous connaître. Alors que depuis des lustres le plus gros problème de l'informatique particulièrement quand c'est grand publique c'est les bugs, les régressions etc.

    c'est gentil de me donner une vidéo de 50minutes mais si tu pouvais résumer le passage important?

    Fais-toi, un kiff et clique sur le lien pour voir.

    Si tu avais cliqué sur le lien tu aurais vu que tu tombe pile au moment où Greg explique comment ils testent (grosso modo ils s'appuient sur la communauté et ne font aucun autre test, chaque commiter est responsable des tests de sont code). Ça dure 1m15s.

    Pour ce qui est de la « gestion de projet » dans les points indiqués :

    • c'est à toi d'utiliser un gestionnaire de version, c'est donc à toi de le maîtriser et d'expliquer à ton superieur ce que tu fait s'il y a besoin (le workflow choisi est appliqué par les développeurs, mais il est choisi de manière collégial avec s'il y en a un, le chef de projet)
    • savoir lire de spec c'est un boulot technique qui n'a rien avoir avec de la gestion de projet, la spec ça peut être un document pondu par le client, avec le client, une RFC, une XEP ou autre c'est à toi développeur de la lire. Si tu attend à ce que quelqu'un la lise pour toi tu es mal barré
    • tests unitaires, on en a parlé
    • tests fonctionnel, on en a parlé
    • gestion des bug, à la rigueur c'est pas primordial, mais ça demande des connaissances techniques pour savoir de quoi on a besoin pour reproduire le problème
    • savoir évaluer les charge seul quelqu'un de technique peu le faire et c'est en effet de la communication, mais je doute que ton chef accepte la réponse « quand ce sera prêt » quand il te demande quand est-ce que ce sera fini
    • c'est pas de l'informatique c'est juste primordial

    Bref tout ça pour dire que ton étiqutage basique « gestion de projet » / « technique » ça ne tiens pas la route. Soit tu es dans le monde de l'entreprise et il tu dois savoir faire ça pour ton chef, tes collègue et/ou tes clients, soit tu fais du logiciel libre à titre personnel et tu doit faire tout ça parce que c'est à toi de tout faire.

    A l'IUT ou j'ai été, l'accent était vraiment mis sur ce genre de cours. Je ne sais pas si c'est le cas de tous les IUT. En tout cas c'est ce qui m'a donnée envie de fuir le plus loin possible de ce genre de boulot. Je sais que dans les facs c'est très peu enseigné, sauf dans les master spécialisés (tard, donc), mais l'enseignement à la fac se veut plus théorique normalement. Dans certaines école d'ingé tout ce qui est gestion de projet est très prioritaire sur les autres cours.

    L'IUT forme avec l'optique que tu arrête tes études à bac+2 et que potentiellement tu crée ton entreprise. C'est pour ça, entre autre, que tu as eu des cours de droit et de compta. Les programmes ont bien sûr un peu évolués lorsqu'ils se sont rendu compte que 70% de ceux qui sortent n'arrêtent pas leurs études.

    Les facs se trimbales 2 ans de sciences assez générales pour permettre aux étudiants de switcher plus facilement. Ensuite l'enseignement y est relativement modulaire et tu choisi ce que tu fait (bien sûr il y a un tronc commun).

    Les écoles, ben ça dépend des écoles, ENSIMAG et Epitech ne sont pas comme d'autres écoles (on verra ce que donnera 42).

    En tout cas il faut comprendre que faire du logiciel c'est bien. Le rendre utilisable c'est mieux et ça ça englobe un tas de choses qui ne sont pas de l'algorithmique à proprement parlé mais qui sont très importante et qui doivent souvent être pris en considération par les développeurs eux-mê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: Formation

    Posté par  . En réponse au journal Ce qu'on demande à un développeur aujourd'hui. Évalué à 2.

    test technique est enseigné partout

    Tu entends quoi par est enseigné ? Un projet dans le quel tu par d'un projet existant et du quel tu doit écrire les tests ou quelques cours + quelques questions dans un examen ? Si c'est le premier, ce n'est pas partout.

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

  • [^] # Re: Ce qu'on demande à un développeur aujourd'hui...

    Posté par  . En réponse au journal Ce qu'on demande à un développeur aujourd'hui. Évalué à 5.

    Quand tu as un soft avec énormément de fonctionnalités, une bonne batterie de tests unitaires c'est redoutable contre les régressions. Ça me permet de coder plus vite, puisque je passe moins de temps à tout vérifier 3 fois avant de passer le bulldozer dans le code. Je vérifie une fois, puis si je casse des choses, les tests me le révéleront très vite.

    Je pense que le mieux pour s'en rendre compte c'est de le faire avec de l'IHM. Passer une recette est super lourd et long. C'est une plaie équivalente à celles d'Egypte. Une fois qu'on a automatisé ça on trouve les choses tout de suite plus agréables.

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

  • [^] # Re: ça dépend de ce que tu code!

    Posté par  . En réponse au journal Ce qu'on demande à un développeur aujourd'hui. Évalué à 0.

    Ben, non, le journal dit que l'algo ça sert à rien, et mon paragraphe dit le contraire…

    Il dit le contraire parce qu'il parle d'un petit groupe de développeurs qui auraient besoin de maîtriser les performances sur les bouts des doigts ? On va dire qu'on les appels des experts techniques (c'est un peu ce qu'ils sont, non ?). Ça colle tout à fait à ce dont il parle :

    Pour les développeurs seniors et experts techniques, là ok, on peut rentrer dans de l’optimisation, de l’archi : « quels sont les pb de perfs que vous avez rencontrés et qu’avez-vous fait pour y remédier ? », « dans une appli web, à quelles couches rencontrez vous habituellement des pbs de perf ? ». Je tacherai de lui demander comment il fait pour gérer ou diminuer la dépendance aux libs externes.

    Peut être devrais-tu lire le journal jusqu'au bout avant de le commenter ?

    Certes, enfin savoir faire des tests c'est savoir programmer dans le langage dans lequel tu vas travailler quoi. Certes c'est pas de la gestion de projet comme le reste.

    Bien sûr on peut tout mettre dans le socle initial sans quoi ça veut dire qu'on sait pas programmer (qu'on est à la compagnie créole diront certains). D'ailleurs personnellement je pense que l'algorithmique en fait partie justement parce que c'est le boulot. C'est ce que l'on passe 2, 3 ou 5 ans à étudier, donc quoi qu'il arrive on s'y est froté. Ce qui va démarquer les développeurs c'est ce qui est un peu moins technique, légèrement moins au cœur de leur métier.

    Mais bon si on regarde d'un peu plus près, est-ce qu'il y a vraiment tant de tests que ça qui sont fait ? Par exemple le noyau Linux possède-t'il une base de tests unitaires (on comprend que les tests d'intégration peuvent être assez complexes à faire) ? Quelle est la couverture des tests de LibO ? LinuxFR possède-t'il une base de tests ?

    En fait les tests c'est un peu comme l'algorithmique et les bench, c'est l'étape d'après la maîtrise d'un langage c'est l'étape « maintenant je sais parler qu'est ce que j'ai à dire ? ».

    Dans la vrai vie, les tests sans quoi « tu ne maîtrise pas le langage¹ » sont relativement rares.

    Pour la suite de ton commentaire. Tu peux être certain que les compétences spécifiques à l'informatiques sont enseignées relativement bien. Les « à coté » quand ils sont enseignés (on parle pas d'un cours de 2H sur les VCS), on une grande probabilité d'avoir étaient considéré comme barbant par les étudiants qui ont fait le strict minimum pour passer à l'année suivante et sachant qu'ils n'auront plus ce cours au semestre d'après.

    ¹ : Je ne comprends pas pourquoi tu parle de langages, la majeure partie des choses à savoir pour écrire des tests n'est pas liée au 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: moef

    Posté par  . En réponse au journal Et moi qui croyais que le client lourd serait gagnant.... Évalué à 1.

    Oui dans le libre, pareil avec des web app libres.

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

  • [^] # Re: ça dépend de ce que tu code!

    Posté par  . En réponse au journal Ce qu'on demande à un développeur aujourd'hui. Évalué à -3.

    Je pense que ça dépend des projets sur lesquels tu bosses. Si tu bosses sur un énorme logiciel qui fait intervenir des dizaines de développeur mais qui ne met pas en œuvre des algorithmes compliqués, ou des traitements qui demandes des performances particulière (par exemple, le cas classique d'un système d'information où bien comprendre ce que veut le client est plus difficile que d’implémenter la solution à son problème) alors oui, maitriser les outils et les méthodes qui permettent de travailler efficacement dans une grande équipe c'est le plus important. Mais c'est pas toujours le cas. Par exemple, dans un gros logiciel il peut y avoir un petit noyau qui effectue des des traitements très compliqués, qui doivent être optimisé à mort etc… Les quelques devs qui bossent sur cette partie ont besoin de connaître leur langage à un niveau de détail plus élevé et/ou avoir un niveau correcte en algorithmique.

    Un sacré paragraphe pour paraphraser le journal.

    ça, c'est pas de l'informatique mais de la gestion de projet.

    Faux, les tests par exemple, c'est de l'informatique. C'est des compétences spécifiques à l'informatique et ça demande des développements spécifiques. D'ailleurs il faudrait le prendre en compte lorsque l'on code. Dernier point c'est très peu enseigné.

    Ensuite ce que tu appel la gestion de projet qui est en fait plutôt de la méthode de travail, ce n'est pas parce que c'est pas de l'informatique que ça n'est pas primordial. Pour moi c'est comme si tu disait à un médecin que gérer le patient c'est pas spécifique à la médecine que c'est de la gestion de clientèle ou du social.

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

  • [^] # Re: moef

    Posté par  . En réponse au journal Et moi qui croyais que le client lourd serait gagnant.... Évalué à 1.

    C'est identique dans l'absolu mais en réalité, ce n'est pas dans la culture des logiciels web que de donner l'accès aux anciennes versions, alors que ça l'est beaucoup plus pour les applications natives.

    Dans l'absolu c'est toujours pareil, la seule manière d'être à peu près sur de pouvoir récupérer une vielle version c'est que ce soit du logiciel libre.

    Pour DirectX, tu as ça, par exemple http://www.oldversion.fr/windows/directx/

    À moins que ça ai changé depuis XP impossible de downgrader DirectX. D'ailleurs c'est un sacré problème ça, généralement les applications natives ont une adhérence bien plus forte au système d'exploitation. Pour faire fonctionner le Gnome d'il y a 10 ans il te faut une bonne gtk d'il y a 10 ans, la glic d'il y a 10 ans, gstreamer d'il y a 10 ans, etc.

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

  • [^] # Re: Librairie

    Posté par  . En réponse au journal L'ère du pasclient?. Évalué à 5.

    justelibrairies

    justebibliothèque tu veux dire ?

    on manipule des fonctions/macros avec lisp.

    Ou avec tout autre langage de script (c'est moins drôle quand tu dois compiler manuellement). Python et Perl en ont pleins des comme ç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: le pasclient, c'est encore mieux!

    Posté par  . En réponse au journal Et moi qui croyais que le client lourd serait gagnant.... Évalué à 5.

    des conclusions définitives

    Je crois que c'est plutôt toi qui est entrain de lire entre les lignes. Il décris ses usages et il dit qu'avec surprise, il découvre que des applications web peuvent être réactives et ergonomiques (le fait que l'exemple en question soit propriétaire n'est qu'un détail dans cette constatation à moins que tu n'estime que seule des applications propriétaires puissent être réactives et ergonomiques lorsque qu'elles sont web).

    C'est toi qui imagine qu'il fait des généralités.

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

  • [^] # Re: le pasclient, c'est encore mieux!

    Posté par  . En réponse au journal Et moi qui croyais que le client lourd serait gagnant.... Évalué à 2.

    Et franchement, si c'est pour un petit diagramme, Inkscape va très bien et permettra d'obtenir la même chose avec son système de connecteurs (on peut ensuire remodifier la taille et la forme des connecteurs si on le souhaite). Dia est prévu pour cela également.

    Pour un diagramme plus complexe, autant utiliser un outil comme graphviz.

    Bien sûr toi tu connais les besoins des autres qu'ils ne les connaissent eux-même c'est ça ?

    Les connecteurs avec inkscapes sont pourris. Il est vraiment très loin de Dia pour faire des diagrammes.

    Dia (que j'utilise souvent) a une ergonomie exécrable comme je l'ai dis plus haut.

    graphviz c'est pas trop mal pour les développeurs mais quand le diagramme deviens un peu grand ou que tu veux vraiment pouvoir faire tout et n'importe quoi tu passe plus de temps à faire du "debug" technique qu'à organiser tes idées. Pareil pour tikz (que j'aime beaucoup malgrès ça).

    Mais oui tu as raison, faut pas être malin pour utiliser autre chose.

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

  • [^] # Re: quelques points

    Posté par  . En réponse à la dépêche De tout, de rien, des bookmarks, du bla bla #29. Évalué à 2.

    Je ne comprends pas très bien le problème que tu soulève.
    Tu as des outils inclus dans la bibliothèque standard, ceux-ci ne conviennent pas à ton usage. Tu t'en crée d'autres.

    Ce qui te gêne c'est qu'il y ai un outil dans la bibliothèque standard pour ça ? Tu préfèrerais ne rien avoir et avoir quelque chose de probablement moins testé (tout le monde ne fait pas autant de tests que le JCK et n'a pas autant d'utilisateurs qu'une JVM).

    C'est un choix, c'est ce qui est fait avec le C où la bibliothèque standard est minimaliste.

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

  • [^] # Re: Pas d'accord

    Posté par  . En réponse au journal Et moi qui croyais que le client lourd serait gagnant.... Évalué à 4.

    on bosse pas vraiment dans le même métier ;)

    Je n'ai pas parlé de mon métier ou du tiens, j'ai parlé de généralité.

    Toujours dans la même optique si ton calcul d'itinéraire en transport en commun parisien prends 15 minutes, le trajet qu'il t'indique est déjà caduc.

    Si à chaque clique tu a 2/3 secondes de lag, ton utilisateurs il va aller voir ailleurs.

    C'est précisément ce que j'ai dis. Ce sont des cas où tu indique une contrainte (rendre le résultat en un temps donné) et pas il faut être le plus rapide immaginable.

    La différence est importante car dans un cas tu va toujours pouvoir troller en expliquant qu'en assembleur t'es capable de faire mieux (d'ailleurs si le système d'exploitation arrêtait de faire de la merde ça t'arrangerais bien), alors que dans l'autre tu es tout à fait capable d'estimer si une techno de plus haut niveau peut faire l'affaire ou pas et on voit ces dernières années que plus ça va plus les techno de haut niveau en sont capables.

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

  • [^] # Re: moef

    Posté par  . En réponse au journal Et moi qui croyais que le client lourd serait gagnant.... Évalué à 1.

    La problématique est tout à fait identique. Tu peux ou non avoir accès à l'ancienne version des logiciels.

    DirectX tu peux pas. SPIP tu peut remonter jusqu'à 2009 avec des archives et pour aller plus loin tu as leur dépôt.

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

  • [^] # Re: moef

    Posté par  . En réponse au journal Et moi qui croyais que le client lourd serait gagnant.... Évalué à 1.

    Si on test ce qu'il y avait il y a 10 ans sur du matériel d'il y a 10 ans ça n'a aucun intérêt (déjà que tester les version d'aujourd'hui dessus n'en a pas beaucoup…).

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