Posté par ckyl .
En réponse au journal Privateur....
Évalué à 4.
Tu ne parles donc pas d'écosystème. Tu parles du fait qu'un noyau précis soit répandu et utilisé. Les noyeaux sont d'ailleurs un très mauvais exemple pour les licences car elle n'impact qu'eux-même.
Je persiste que la plupart du code produit en libre actuellement en dehors de Linux et du desktop, c'est du BSD 2-clause ou de l'ASL. Simplement par ce que les boîtes ne veulent pas s'emmerder avec de la GPL. Il y a beaucoup de code historique en GPL qui n'est pas négligeable, mais regarde la tendance et ce qui est produit maintenant.
C'est une grande porte ouverte pour proposer du contenu vendeur sur leurs smartphones HTML5… comme Netflix, etc. Mais je suis sûrement mauvaise langue
Ils semblent avoir raté le coche:
We've been working with Google to implement support for the HTML5 Premium Video Extensions in the Chrome browser, and we've just started using this technology on the Samsung ARM-Based Chromebook. Our player on this Chromebook device uses the Media Source Extensions and Encrypted Media Extensions to adaptively stream protected content. WebCrypto hasn't been implemented in Chrome yet, so we're using a Netflix-developed PPAPI (Pepper Plugin API) plugin which provides these cryptographic operations for now. We will remove this last remaining browser plugin as soon as WebCrypto is available directly in the Chrome browser. At that point, we can begin testing our new HTML5 video player on Windows and OS X.
We're excited about the future of premium video playback on the web, and we look forward to the day that these Premium Video Extensions are implemented in all browsers!
il faut inférer le pourquoi. Le commentaire a l'avantage de prémacher le travail. Il a aussi l'inconvénient, parfois, de mettre notre cerveau sur off,
Donc en gros on galère plus pour avoir moins d'information, dont certaines vitales et on peut facilement passer à côté alors que justement le but d'un commentaire de s'assurer que le lecteur à le contexte.
Le jeu de piste c'est rigolo sur un exemple jouet, mininuscule et statique, comme celui-là. Maintenant sur du vrai code qui a une vraie vie je ne donne pas très cher de la survie des informations ni de leur efficacité.
D'ailleurs en tant que lecteur, que tu refactorises ou non, je te maudirais si tu m'enlèves l'explication explicite sur le base.js.
Quand on dit qu'un code bien écrit se passe de commentaires, c'est un peu comme dire qu'un texte bien écrit en anglais peut se passer de commentaires en français
Je ne suis pas d'accord avec ca. Un commentaire c'est une note en bas de page qui explique un contexte, spécifie une particularité ou intension précise que le lecteur peut ne pas connaître. C'est peut être pas élégant ou idéal, mais l'important c'est avant tout d'avoir l'information. Et il y a beaucoup de cas ou si tu te l'interdit alors tu vas forcement en perdre.
Lire du code c'est lire un vieux bouquin dans un domaine très pointu. Je te serais reconnaissant de me prendre pas la main par ce que bordel des lignes de code comme ca y'en a 500 000 dans 5 langages dans le repo…
"Ne parlons même pas d'AUR ou quand tu regardes la gueule des packages et les discussions, tu fuis loin, très loin."
Oui sur AUR je me permets de généraliser. Tout ce que j'ai pu regarder était abandonné ou de la beta crado ou quand tu lis les commentaires de suivi tu te demande sérieusement si ce n'est pas le forum de 01informatique. Tu ajoutes à cela que tu installes sur ton système des composants empaqueté par je ne sais qui sans aucun contrôle. Vraiment sans façon, et après on reproche aux utilisateurs de Windows d'installer n'importe quoi et de pourrir leurs systèmes…
Après la logithèque est suffisamment large pour ne pas trop avoir à s'aventurer là dedans, c'est qui est très bien.
En même temps quelqu'un qui jugerait la qualité de quelqu'un par ce qu'il bosse chez MS ou d'un bouquin par ce qu'il est publié par MS est un idiot ;)
En fait ce bouquin ou pourrait en faire un calendrier du type "un jour un conseil" sauf qu'il y a de quoi tenir 10 ans. Il est vieux mais ne s'est pas tant démodé que ca, la plupart des conseils et remarques sont intemporelles et ca fait toujours du bien de l'ouvrir au hasard.
ainsi on a plusieurs mode de lecture hors ligne tout en restant KISS
Attention au KISS pour l'utilisateur aussi. Avec read it later, je bookmark plein des trucs de partout, je clique sur offline, je pars en voyage sans connexion, je lis 30 articles que je tag et archive ou jette, je reviens automatiquement il me mets à jour ma collection et ca repart. Et quelques soit le nombre de devices.
C'est tout l'intêret de l'outil: gérer la TODO et l'archivage sans réfléchir. Ce qui permet de retrouver facilement ce que tu as lu.
Tu peux faire KISS et avoir des fonctionnalités. Elles peuvent même être offertes par des clients tiers ;)
Si c'est pour pisser des PDF à lire un répertoire sur le filesystem; la fonction "imprimer" fait tout aussi bien l'affaire.
Il faut en effet être nuancé. Une partie des commentaires peuvent être connu avant l'implémentation finale, ce sont les restes du peusdo code quand ils sont nécéssaires. Cependant ce que tu laisseras dépendra du résultat final.
Après les commentaires sur le code lui même, tu vas t'en rendre compte de leur utilité compte en écrivant. "C'est évident pour moi qu'on n'a pas besoin besoin de tester pour un int overflow mais je le signale au lecteur".
Après la plupart des commentaires concernent la logique métier et sont ajoutés après la v1 et sont des bugfix et de l'évolution du code. Généralement la v1 est simple et n'a pas besoin de beaucoup de commentaires car elle a été designée de 0 et que le code peut exprimer assez précisément la pensée. Les 10 autres versions après vont rajouter des options, gérer les problèmes de compats, subir du perf tuning, fournir de nouvelle feature etc.
Bref tu ne mets pas un commentaire pour dire que tu as mal utiliser une lib, c'est débile. Par contre tu laisses des indications comme quoi "On fait ca par ce que": "On attrape cette erreur par ce que sur le système X version Y il peut se produire ca", "On utilise cette option plutôt qu'une autre par que la v21 à un bug", "On ne touche pas a ce pointeur par ce que y'a une action asynchrone qui l'utilise", "On choisi cette approche par ce qu'un utilisateur à rapporter un problème de performance dans la version d'avant", "attention si tu changes cette variable tu changes aussi le comportement de ca" etc. C'est pour ca que les réécritures sont rarement des succès, repartir de 0 ca veut dire remettre sa maturité à 0 et donc perdre son avance.
Tu parles de documentation d'API et non de commentaire. En effet c'est une bonne pratique de savoir exactement ce que ta méthode va faire et comment elle va le faire avant de commencer à l'écrire (cf. "pseudocode programming process" dans l'excellent Code Complete).
Cependant les commentaires tu ne peux généralement les décider et les écrire correctement qu'une fois que le code existe. Je trouve que la nouvelle classe String de Java est un bon exemple:
Le grain des méthodes est bon, le code est simple et se lit naturellement
La documentation de l'API est excellente bonne
Les commentaires sont présent uniquement lorsqu'il y a besoin de souligner l'intention ou un fait particulier et ne sont absolument pas redondant avec le code.
C'est assez facile à faire pour des classes simples comme String. Par contre plus ta classe à de métier ou d'interaction avec l'extérieur plus tu vas avoir le logique à expliciter dans le code. Genre ca ou c'est très difficile de garder un code limpide à long terme et ou beaucoup de choses doivent être explicitées.
Certains éditeurs ont bien compris l'enjeu et proposent des métriques de mesure de nombre de lignes de commentaires rapporté au nombre total de lignes de source.
C'est totalement débile: vouloir améliorer la qualité en utilisant une métrique quantitative. Tu auras juste beaucoup de commentaires qui ne servent à rien.
" Individuals and interactions over processes and tools ": remplace ton outil par des relectures pour diffuser le savoir ca sera beaucoup plus efficace. Si tu ne fais pas confiance à ton équipe change l'équipe.
Hum, c'est pas tellement la vision que j'en avais…
C'était une formule. Le fait d'être deux t'aide à ne pas te dire "bon aller c'est pas grave on passe en done et basta" ou "ouai aller ca passe".
Mais oui dans ce cas ce n'est pas le côté extérieur qui est recherché, mais plutôt le fait que les deux personnes ne vont pas penser exactement de la même manière (c'est bien là le but du pair programming).
Ca c'est excellent pour la recherche de solution, l'implémentation et le troubleshooting. En effet ca permet de combiner deux approches et donc d'explorer plus large.
Pour ce dont tu parles ca n'apporte pas grand chose je trouve. Quand tu es deux à avoir passer 3j à troubleshooter un sale problème ou tordu une lib, niveau commentaire je trouve que ca change pas grand chose à si tu étais tout seul. La paire à acquis une connaissance que les autres n'auront pas.
L'un s'attachant plus au code proprement dit, et l'autre plus sur l'intention, les objectifs, la doc justement.
Ca c'est très très variable selon sur quoi tu bosses. Personnellement on a jamais suivit une telle organisation. Le pair c'est pour résoudre une tâche. Une fois que la tâche est résolue, un testeur et un relecteur valide le boulot pour avoir d'autres yeux et diffusé la connaissance.
La valeur de la pair c'est d'avoir deux cervos. Si tu les découpes en ne les faisant pas bosser ensemble tu perds plein de choses je trouve.
Ca peut être intéressant. A condition que ce soit fait assez rapidement tout de même.
De toute facon la review elle se fait avant d'intégrer ou dans la semaine suivant les commits.
Mais c'est effectivement un très bon détecteur d'avoir un oeil naïf à côté. Dès qu'on à un doute ca vaut souvent le coup de demander à quelqu'un dans le coin son avis spontanée.
Mais d'ailleurs, c'est aussi à rapprocher du pair programming.
Pas d'accord avec ca par contre. Quand tu pair tu ne formes qu'une seule entitée (même si vous ne faites pas la même chose) et tu n'as plus du tout le côté extérieur au problème. Être deux permet d'avoir quelqu'un qui te tape sur les doigts plus facilement et se laisser aller moins facilement, mais on était arrivé à la conclusion qu'il fallait quand même un review par quelqu'un d'extérieur à la tâche.
Simplement par ce qu'il n'a pas emmagasiné les connaissances de tâche et qu'il va challenger à la fois la solution que son implémentation.
Je suis d'accord avec toi, c'est le but. Mais sur une base de code sérieuse même en v1 je n'ai jamais vu un état ou l'on pouvait se passer de commentaires. Ceux qui l'ont fait mentaient, et ceux qui ont maintenu ont pleuré. Après ca doit beaucoup dépendre des domaines et du type de produit. Quand ca peut être simple et évident, aucune raison de faire compliqué.
Le commentaire interne ca sert à expliquer les cas tordus du fonctionnel ou une approche. Un compilo sérieux aide, mais il reste des choses à expliquer pour aider le lecteur (ou expliquer pourquoi ca a fini comme ca et pas autrement). Exemple à la con, un comportement spécifique à une plateforme qu'on t'a remonté. Si tu ne laisses pas une trace de pourquoi tu fais ca, le lecteur n'a aucune chance de le deviner jusqu'à ce qu'il réintroduise le bug et qu'un nouveau BR arrive.
Souvent plus une code base à veilli et murri plus il y a des commentaires internes. Car les choses se sont fait affiner et un million de cas tordu sont gérés ce qui n'est pas forcément le cas d'une base neuve. Idem quand tu dois gérer la compatibilité.
Mais pourquoi ne pas placer la documentation au plus près du code. Voire dedans, comme Python le permet —avec même la notion de références croisées, même inter-projets.
Par ce que la notion de documentation est très dépendante des projets. Ton idée marche pour les libs et uniquement les libs.
Autrement je te rejoins que si on ne distingue pas parfaitement 3/4 types de documentations on parle de tout et n'importe quoi et on fait n'importe quoi:
Les commentaires: Ils sont là pour aider à lire le code. Leur seule raison d'exister est "pourquoi" et l'intention. Par exemple, ca serait domage de laisser réintroduire des bugs dans une code base qui a été testé pendant des années par ce qu'on n'indique pourquoi on fait ce foutu truc (ah oui c'était une bugfix suite à un BR ouups).
Les documents de design: Selon la taille du projet ils sont à écrire ou non. Ca peut aller de 10 lignes dans un readme, à pleins de page pour permettre de comprendre le design général et comment s'y retrouver dans ces 300 modules. Les règles générale, les règles d'interactions etc.
La documentation des API: La encore selon ce sur quoi on bosse l'interet varie. Toute API publique doit évidement être parfaitement documentée. Pour les API internes c'est à choisir. Ecrire de la bonne documentation d'API est très couteux, et je constate que si c'est pour de l'interne je n'investi pas assez et donc qu'elle ne sert à rien car extremement redondante avec le code (typage static évidement)
La documentation utilisateur: La encore il faut voir en fonction de son produit. Dans la plupart des cas on essayera de faire léger et concis.
Dans tout les cas celui qui explique que le premier type ne sert à rien est un idiot avec une bonne mémoire qui bosse tout seul et n'a jamais travaillé sur autre chose que son code. Je ne vois pas d'autre explication.
Par contre il est vrai aussi qu'il faut se forcer pour que son code ait le moins besoin possible d'être commenté. Ca indique qu'il y a le moins de truc chelous ou difficile à intuiter dans le code et l'algo.
On ne parle peut-être pas de la même chose par contre …
Il y a effectivement une subtile différence qui fait que je ne considère pas cela comme une fonctionalité hors ligne.
Dans la majorité des cas, le service ne sera pas hébergé sur les machines qui a besoin de la fonctionalité hors ligne. Si tu mets ca chez toi, alors de toute facon tu as accès à internet. Le hors ligne ne sert à rien. Et tu ne vas pas mettre ca sur une machine mobile car tu n'auras pas accès depuis autre part.
Le truc vraiment bien avec ces choses c'est de pouvoir bookmarker de n'importe ou, n'importe quand; de t'en servir comme d'une TODO. En plus de ca, tu as la possibilité de tout recupérer hors ligne sur un périphérique donné quand tu as le temps de lire mais sans connexion internet. Quand tu reviens en ligne, ce que tu as lu se synchronise automatiquement.
Pour moi le mode hors ligne c'est ca. Ce que t'offre poche je verais plus ca comme un cache au cas ou le contenu disparait. Ce qui est très bien (fonctionalité bookmark++).
Je répondais juste à la question qui avait été posée. Indiquer ses intentions, sa roadmap et ses opinions est je trouve intéressant même si on est au début.
Si je peux me permettre un conseil au niveau des fonctionalités, c'est de penser le back comme une combinaison read it later + bookmark pour les archives. C'est actuellement le point faible des UI type read it later. Alors que ca fait tout son sens d'avoir après une jolie collection de bookmarks organisés, avec des metadonnée semi structurée, un contenu indexé et une sauvegarde locale si ca disparait.
Le plus marant c'est que tu peux monter un service de ce type avec l'API de read it later mais qu'ils l'ont pas encore fait.
Un mode de lecture hors ligne : c'est implémenté.
Je suis pas certain d'avoir compris tu peux développer ?
Différence entre Poche et Pocket : l'un est open source, vous savez ce que l'outil fait, les données vous appartiennent. L'autre n'est pas open source, gratuit mais avec un drôle de modèle économique.
Tu passes un peu vite sur les différences fonctionnelles pour être crédible ;)
Il manque:
- Tout le système de gestion des articles (tags, recherche etc.)
- L'intégration aux browsers/devices
- Un mode de lecture hors ligne
- Un mode de synchro après un hors ligne
- Une API complète
C'est une excellente initiative. Je trouve cependant quand même dommage que vous n'ayez pas commencé par des bases sérieuses en prenant un approche service/api + frontend. J'ai regardé le code rapidement, ca ressemble aux méli-mélo php qu'on trouve souvent.
Surtout que ceux qui sont dans des boîtes qui ont des flottes de TP seront un peu moins dithyrambique sur le côté inusable. Des TP qui surchauffent ou meurent j'en ai vu un paquet.
Je n'aurais pas du donner d'exemples, et surtout aucun de problème temporaire, car ils brouillent le message. Ca n'a de sens que si tu as méticuleusement tout noté. Regarde simplement la philosophie de Arch ca dit la même chose que moi.
Maintenant je n'ai pas dit que c'était bien ou mal. J'ai deux Arch à la maison, et au cours des 15 dernières années j'ai du utiliser intensivement 7 distros et 2 BSD. Étant assez pragmatique, il me semble que je peux commencer à avoir un avis sur un outil. Arch c'est DIY, j'en fait le moins possible, et "ca devrait marcher". Ca convient à certains usage pas à d'autres. Maintenant dire que c'est génial comme on le lit souvent non désolé. C'est une option intéressante par contre.
Le côté volubile des utilisateurs d'Arch passera tout comme Debian, Mandrake, Gentoo, Ubuntu dans le désordre…
Pertinent immédiatement non. J'aurais du tenir un journal de bord histoire d'avoir quelque chose d'intéressant à dire.
Il y a plein de trucs qu'il faut configurer simplement pour que ca marche. Alors qu'un choix rationnel par défaut irait très bien. J'ai souvenir de trucs hallucinants dans le wiki du genre " Une fois le démon installé penser à lui attribuer un utilisateur dédié plutôt que celui de l'install pour que ca soit secure ". Simplement la semaine dernière. Une bête installation de 0 n'a jamais réussi à faire tourner ni gnome3 ni gdm.
Arch c'est vraiment le niveau 0 de l'intégration. Je trouve ca assez similaire à ce que pouvait fournir SourceMage il y a bientôt 10 ans, l'excellent wiki en plus… Tant mieux si ca répond aux besoins de certains. Mais ce qu'on peut souvent en lire ici me semble assez loin de la réalité. Ne parlons même pas d'AUR ou quand tu regardes la gueule des packages et les discussions, tu fuis loin, très loin.
Non, ils ont certainement de bonnes raisons. Mais je les invite tout de même à essayer cette distribution que l'on peut façonner aux petits oignons
Je corrige:
Mais je les invite tout de même à essayer cette distribution que l'on peutdoit façonner aux petits oignons
Suivre l'upstream c'est cool, mais le boulot d'une distrib c'est de configurer correctement pour que ca soit utilisable. Le boulot de l'upstream c'est d'offrir des choses configurable, pas de les configurer et intégrer correctement. Les paquets d'Arch bien souvent ne font rien hormis un configure ; make install. Et tu passes donc ton temps à faire ce que la distro devrait faire juste pour que ca marche correctement de base… Génial !
[^] # Re: Openshot se tire une balle dans le pied ... Ils font fausse route ;-)
Posté par ckyl . En réponse au journal OpenShot abandonne Gtk+.... Évalué à 2.
Tu m'étonnes,
relatimeest par défaut depuis le 2.6.30…[^] # Re: Tellement répété…
Posté par ckyl . En réponse au journal Privateur.... Évalué à 4.
Tu ne parles donc pas d'écosystème. Tu parles du fait qu'un noyau précis soit répandu et utilisé. Les noyeaux sont d'ailleurs un très mauvais exemple pour les licences car elle n'impact qu'eux-même.
Je persiste que la plupart du code produit en libre actuellement en dehors de Linux et du desktop, c'est du BSD 2-clause ou de l'ASL. Simplement par ce que les boîtes ne veulent pas s'emmerder avec de la GPL. Il y a beaucoup de code historique en GPL qui n'est pas négligeable, mais regarde la tendance et ce qui est produit maintenant.
[^] # Re: Tellement répété…
Posté par ckyl . En réponse au journal Privateur.... Évalué à 2.
La version "par défaut" autorise la FSF à faire ce qu'elle veut "or later".
Dans quel domaine ?
Le seul endroit ou la GPL est importante c'est le Desktop. L'écrasante majorité du reste c'est de l'ASF ou assimilé.
[^] # Re: Mozilla, HTML5, DRM et ses smartphones
Posté par ckyl . En réponse à la dépêche Une coalition de 27 organisations demande au W3C de garder les DRM hors du Web. Évalué à 3.
Ils semblent avoir raté le coche:
http://techblog.netflix.com/2013/04/html5-video-at-netflix.html
[^] # Re: Mozilla
Posté par ckyl . En réponse à la dépêche Une coalition de 27 organisations demande au W3C de garder les DRM hors du Web. Évalué à 10.
Ne t'inquiètes pas les 15 filiales de la FSF et du parti pirate ont signées. Ca fait un sacré poids !
[^] # Re: Controverse sur le numéro de version
Posté par ckyl . En réponse à la dépêche jQuery 2.0. Évalué à 4.
Bienvenue dans le monde réel !
[^] # Re: Code auto-documenté
Posté par ckyl . En réponse au journal To comment or not to comment. That is the question.. Évalué à 3.
Donc en gros on galère plus pour avoir moins d'information, dont certaines vitales et on peut facilement passer à côté alors que justement le but d'un commentaire de s'assurer que le lecteur à le contexte.
Le jeu de piste c'est rigolo sur un exemple jouet, mininuscule et statique, comme celui-là. Maintenant sur du vrai code qui a une vraie vie je ne donne pas très cher de la survie des informations ni de leur efficacité.
D'ailleurs en tant que lecteur, que tu refactorises ou non, je te maudirais si tu m'enlèves l'explication explicite sur le base.js.
Je ne suis pas d'accord avec ca. Un commentaire c'est une note en bas de page qui explique un contexte, spécifie une particularité ou intension précise que le lecteur peut ne pas connaître. C'est peut être pas élégant ou idéal, mais l'important c'est avant tout d'avoir l'information. Et il y a beaucoup de cas ou si tu te l'interdit alors tu vas forcement en perdre.
Lire du code c'est lire un vieux bouquin dans un domaine très pointu. Je te serais reconnaissant de me prendre pas la main par ce que bordel des lignes de code comme ca y'en a 500 000 dans 5 langages dans le repo…
[^] # Re: Ce que j'en pense
Posté par ckyl . En réponse au journal SystemD et Arch autosuggestion. Évalué à 0.
"Ne parlons même pas d'AUR ou quand tu regardes la gueule des packages et les discussions, tu fuis loin, très loin."
Oui sur AUR je me permets de généraliser. Tout ce que j'ai pu regarder était abandonné ou de la beta crado ou quand tu lis les commentaires de suivi tu te demande sérieusement si ce n'est pas le forum de 01informatique. Tu ajoutes à cela que tu installes sur ton système des composants empaqueté par je ne sais qui sans aucun contrôle. Vraiment sans façon, et après on reproche aux utilisateurs de Windows d'installer n'importe quoi et de pourrir leurs systèmes…
Après la logithèque est suffisamment large pour ne pas trop avoir à s'aventurer là dedans, c'est qui est très bien.
[^] # Re: Sélection naturelle
Posté par ckyl . En réponse au journal To comment or not to comment. That is the question.. Évalué à 3.
En même temps quelqu'un qui jugerait la qualité de quelqu'un par ce qu'il bosse chez MS ou d'un bouquin par ce qu'il est publié par MS est un idiot ;)
En fait ce bouquin ou pourrait en faire un calendrier du type "un jour un conseil" sauf qu'il y a de quoi tenir 10 ans. Il est vieux mais ne s'est pas tant démodé que ca, la plupart des conseils et remarques sont intemporelles et ca fait toujours du bien de l'ouvrir au hasard.
[^] # Re: Poche vs Sync
Posté par ckyl . En réponse à la dépêche Alternatives : Pinry et Poche. Évalué à 2.
Attention au KISS pour l'utilisateur aussi. Avec read it later, je bookmark plein des trucs de partout, je clique sur offline, je pars en voyage sans connexion, je lis 30 articles que je tag et archive ou jette, je reviens automatiquement il me mets à jour ma collection et ca repart. Et quelques soit le nombre de devices.
C'est tout l'intêret de l'outil: gérer la TODO et l'archivage sans réfléchir. Ce qui permet de retrouver facilement ce que tu as lu.
Tu peux faire KISS et avoir des fonctionnalités. Elles peuvent même être offertes par des clients tiers ;)
Si c'est pour pisser des PDF à lire un répertoire sur le filesystem; la fonction "imprimer" fait tout aussi bien l'affaire.
[^] # Re: Sélection naturelle
Posté par ckyl . En réponse au journal To comment or not to comment. That is the question.. Évalué à 3.
Code complete: excellente référence qui contient pleins de bon conseils pour ca et pour beaucoup d'autre choses
[^] # Re: Commenter l'intention
Posté par ckyl . En réponse au journal To comment or not to comment. That is the question.. Évalué à 6. Dernière modification le 23 avril 2013 à 14:34.
Il faut en effet être nuancé. Une partie des commentaires peuvent être connu avant l'implémentation finale, ce sont les restes du peusdo code quand ils sont nécéssaires. Cependant ce que tu laisseras dépendra du résultat final.
Après les commentaires sur le code lui même, tu vas t'en rendre compte de leur utilité compte en écrivant. "C'est évident pour moi qu'on n'a pas besoin besoin de tester pour un int overflow mais je le signale au lecteur".
Après la plupart des commentaires concernent la logique métier et sont ajoutés après la v1 et sont des bugfix et de l'évolution du code. Généralement la v1 est simple et n'a pas besoin de beaucoup de commentaires car elle a été designée de 0 et que le code peut exprimer assez précisément la pensée. Les 10 autres versions après vont rajouter des options, gérer les problèmes de compats, subir du perf tuning, fournir de nouvelle feature etc.
Bref tu ne mets pas un commentaire pour dire que tu as mal utiliser une lib, c'est débile. Par contre tu laisses des indications comme quoi "On fait ca par ce que": "On attrape cette erreur par ce que sur le système X version Y il peut se produire ca", "On utilise cette option plutôt qu'une autre par que la v21 à un bug", "On ne touche pas a ce pointeur par ce que y'a une action asynchrone qui l'utilise", "On choisi cette approche par ce qu'un utilisateur à rapporter un problème de performance dans la version d'avant", "attention si tu changes cette variable tu changes aussi le comportement de ca" etc. C'est pour ca que les réécritures sont rarement des succès, repartir de 0 ca veut dire remettre sa maturité à 0 et donc perdre son avance.
[^] # Re: Commenter l'intention
Posté par ckyl . En réponse au journal To comment or not to comment. That is the question.. Évalué à 3. Dernière modification le 23 avril 2013 à 11:43.
Tu parles de documentation d'API et non de commentaire. En effet c'est une bonne pratique de savoir exactement ce que ta méthode va faire et comment elle va le faire avant de commencer à l'écrire (cf. "pseudocode programming process" dans l'excellent Code Complete).
Cependant les commentaires tu ne peux généralement les décider et les écrire correctement qu'une fois que le code existe. Je trouve que la nouvelle classe String de Java est un bon exemple:
C'est assez facile à faire pour des classes simples comme String. Par contre plus ta classe à de métier ou d'interaction avec l'extérieur plus tu vas avoir le logique à expliciter dans le code. Genre ca ou c'est très difficile de garder un code limpide à long terme et ou beaucoup de choses doivent être explicitées.
[^] # Re: Comment inciter à commenter
Posté par ckyl . En réponse au journal To comment or not to comment. That is the question.. Évalué à 4.
C'est totalement débile: vouloir améliorer la qualité en utilisant une métrique quantitative. Tu auras juste beaucoup de commentaires qui ne servent à rien.
" Individuals and interactions over processes and tools ": remplace ton outil par des relectures pour diffuser le savoir ca sera beaucoup plus efficace. Si tu ne fais pas confiance à ton équipe change l'équipe.
[^] # Re: Commenter l'intention
Posté par ckyl . En réponse au journal To comment or not to comment. That is the question.. Évalué à 3.
C'était une formule. Le fait d'être deux t'aide à ne pas te dire "bon aller c'est pas grave on passe en done et basta" ou "ouai aller ca passe".
Ca c'est excellent pour la recherche de solution, l'implémentation et le troubleshooting. En effet ca permet de combiner deux approches et donc d'explorer plus large.
Pour ce dont tu parles ca n'apporte pas grand chose je trouve. Quand tu es deux à avoir passer 3j à troubleshooter un sale problème ou tordu une lib, niveau commentaire je trouve que ca change pas grand chose à si tu étais tout seul. La paire à acquis une connaissance que les autres n'auront pas.
Ca c'est très très variable selon sur quoi tu bosses. Personnellement on a jamais suivit une telle organisation. Le pair c'est pour résoudre une tâche. Une fois que la tâche est résolue, un testeur et un relecteur valide le boulot pour avoir d'autres yeux et diffusé la connaissance.
La valeur de la pair c'est d'avoir deux cervos. Si tu les découpes en ne les faisant pas bosser ensemble tu perds plein de choses je trouve.
[^] # Re: Commenter l'intention
Posté par ckyl . En réponse au journal To comment or not to comment. That is the question.. Évalué à 3.
De toute facon la review elle se fait avant d'intégrer ou dans la semaine suivant les commits.
Mais c'est effectivement un très bon détecteur d'avoir un oeil naïf à côté. Dès qu'on à un doute ca vaut souvent le coup de demander à quelqu'un dans le coin son avis spontanée.
Pas d'accord avec ca par contre. Quand tu pair tu ne formes qu'une seule entitée (même si vous ne faites pas la même chose) et tu n'as plus du tout le côté extérieur au problème. Être deux permet d'avoir quelqu'un qui te tape sur les doigts plus facilement et se laisser aller moins facilement, mais on était arrivé à la conclusion qu'il fallait quand même un review par quelqu'un d'extérieur à la tâche.
Simplement par ce qu'il n'a pas emmagasiné les connaissances de tâche et qu'il va challenger à la fois la solution que son implémentation.
[^] # Re: /* commentaire ou documentation inline ? */
Posté par ckyl . En réponse au journal To comment or not to comment. That is the question.. Évalué à 4.
Je suis d'accord avec toi, c'est le but. Mais sur une base de code sérieuse même en v1 je n'ai jamais vu un état ou l'on pouvait se passer de commentaires. Ceux qui l'ont fait mentaient, et ceux qui ont maintenu ont pleuré. Après ca doit beaucoup dépendre des domaines et du type de produit. Quand ca peut être simple et évident, aucune raison de faire compliqué.
Le commentaire interne ca sert à expliquer les cas tordus du fonctionnel ou une approche. Un compilo sérieux aide, mais il reste des choses à expliquer pour aider le lecteur (ou expliquer pourquoi ca a fini comme ca et pas autrement). Exemple à la con, un comportement spécifique à une plateforme qu'on t'a remonté. Si tu ne laisses pas une trace de pourquoi tu fais ca, le lecteur n'a aucune chance de le deviner jusqu'à ce qu'il réintroduise le bug et qu'un nouveau BR arrive.
Souvent plus une code base à veilli et murri plus il y a des commentaires internes. Car les choses se sont fait affiner et un million de cas tordu sont gérés ce qui n'est pas forcément le cas d'une base neuve. Idem quand tu dois gérer la compatibilité.
[^] # Re: /* commentaire ou documentation inline ? */
Posté par ckyl . En réponse au journal To comment or not to comment. That is the question.. Évalué à 7.
Par ce que la notion de documentation est très dépendante des projets. Ton idée marche pour les libs et uniquement les libs.
Autrement je te rejoins que si on ne distingue pas parfaitement 3/4 types de documentations on parle de tout et n'importe quoi et on fait n'importe quoi:
Dans tout les cas celui qui explique que le premier type ne sert à rien est un idiot avec une bonne mémoire qui bosse tout seul et n'a jamais travaillé sur autre chose que son code. Je ne vois pas d'autre explication.
Par contre il est vrai aussi qu'il faut se forcer pour que son code ait le moins besoin possible d'être commenté. Ca indique qu'il y a le moins de truc chelous ou difficile à intuiter dans le code et l'algo.
[^] # Re: Poche vs Sync
Posté par ckyl . En réponse à la dépêche Alternatives : Pinry et Poche. Évalué à 3.
Il y a effectivement une subtile différence qui fait que je ne considère pas cela comme une fonctionalité hors ligne.
Dans la majorité des cas, le service ne sera pas hébergé sur les machines qui a besoin de la fonctionalité hors ligne. Si tu mets ca chez toi, alors de toute facon tu as accès à internet. Le hors ligne ne sert à rien. Et tu ne vas pas mettre ca sur une machine mobile car tu n'auras pas accès depuis autre part.
Le truc vraiment bien avec ces choses c'est de pouvoir bookmarker de n'importe ou, n'importe quand; de t'en servir comme d'une TODO. En plus de ca, tu as la possibilité de tout recupérer hors ligne sur un périphérique donné quand tu as le temps de lire mais sans connexion internet. Quand tu reviens en ligne, ce que tu as lu se synchronise automatiquement.
Pour moi le mode hors ligne c'est ca. Ce que t'offre poche je verais plus ca comme un cache au cas ou le contenu disparait. Ce qui est très bien (fonctionalité bookmark++).
[^] # Re: Poche vs Sync
Posté par ckyl . En réponse à la dépêche Alternatives : Pinry et Poche. Évalué à 2.
Je répondais juste à la question qui avait été posée. Indiquer ses intentions, sa roadmap et ses opinions est je trouve intéressant même si on est au début.
Si je peux me permettre un conseil au niveau des fonctionalités, c'est de penser le back comme une combinaison read it later + bookmark pour les archives. C'est actuellement le point faible des UI type read it later. Alors que ca fait tout son sens d'avoir après une jolie collection de bookmarks organisés, avec des metadonnée semi structurée, un contenu indexé et une sauvegarde locale si ca disparait.
Le plus marant c'est que tu peux monter un service de ce type avec l'API de read it later mais qu'ils l'ont pas encore fait.
Je suis pas certain d'avoir compris tu peux développer ?
[^] # Re: Poche vs Sync
Posté par ckyl . En réponse à la dépêche Alternatives : Pinry et Poche. Évalué à 3.
Tu passes un peu vite sur les différences fonctionnelles pour être crédible ;)
Il manque:
- Tout le système de gestion des articles (tags, recherche etc.)
- L'intégration aux browsers/devices
- Un mode de lecture hors ligne
- Un mode de synchro après un hors ligne
- Une API complète
C'est une excellente initiative. Je trouve cependant quand même dommage que vous n'ayez pas commencé par des bases sérieuses en prenant un approche service/api + frontend. J'ai regardé le code rapidement, ca ressemble aux méli-mélo php qu'on trouve souvent.
[^] # Re: le vrai prix
Posté par ckyl . En réponse au journal Un Thinkpad livré sous Linux, pour pas cher ? C’est possible (d’occasion).. Évalué à 4.
Surtout que ceux qui sont dans des boîtes qui ont des flottes de TP seront un peu moins dithyrambique sur le côté inusable. Des TP qui surchauffent ou meurent j'en ai vu un paquet.
[^] # Re: Ce que j'en pense
Posté par ckyl . En réponse au journal SystemD et Arch autosuggestion. Évalué à 2. Dernière modification le 19 avril 2013 à 15:38.
Je n'aurais pas du donner d'exemples, et surtout aucun de problème temporaire, car ils brouillent le message. Ca n'a de sens que si tu as méticuleusement tout noté. Regarde simplement la philosophie de Arch ca dit la même chose que moi.
Maintenant je n'ai pas dit que c'était bien ou mal. J'ai deux Arch à la maison, et au cours des 15 dernières années j'ai du utiliser intensivement 7 distros et 2 BSD. Étant assez pragmatique, il me semble que je peux commencer à avoir un avis sur un outil. Arch c'est DIY, j'en fait le moins possible, et "ca devrait marcher". Ca convient à certains usage pas à d'autres. Maintenant dire que c'est génial comme on le lit souvent non désolé. C'est une option intéressante par contre.
Le côté volubile des utilisateurs d'Arch passera tout comme Debian, Mandrake, Gentoo, Ubuntu dans le désordre…
[^] # Re: Ce que j'en pense
Posté par ckyl . En réponse au journal SystemD et Arch autosuggestion. Évalué à 1.
Pertinent immédiatement non. J'aurais du tenir un journal de bord histoire d'avoir quelque chose d'intéressant à dire.
Il y a plein de trucs qu'il faut configurer simplement pour que ca marche. Alors qu'un choix rationnel par défaut irait très bien. J'ai souvenir de trucs hallucinants dans le wiki du genre " Une fois le démon installé penser à lui attribuer un utilisateur dédié plutôt que celui de l'install pour que ca soit secure ". Simplement la semaine dernière. Une bête installation de 0 n'a jamais réussi à faire tourner ni gnome3 ni gdm.
Arch c'est vraiment le niveau 0 de l'intégration. Je trouve ca assez similaire à ce que pouvait fournir SourceMage il y a bientôt 10 ans, l'excellent wiki en plus… Tant mieux si ca répond aux besoins de certains. Mais ce qu'on peut souvent en lire ici me semble assez loin de la réalité. Ne parlons même pas d'AUR ou quand tu regardes la gueule des packages et les discussions, tu fuis loin, très loin.
[^] # Re: Ce que j'en pense
Posté par ckyl . En réponse au journal SystemD et Arch autosuggestion. Évalué à 3. Dernière modification le 19 avril 2013 à 11:52.
Je corrige:
Mais je les invite tout de même à essayer cette distribution que l'on
peutdoit façonner aux petits oignonsSuivre l'upstream c'est cool, mais le boulot d'une distrib c'est de configurer correctement pour que ca soit utilisable. Le boulot de l'upstream c'est d'offrir des choses configurable, pas de les configurer et intégrer correctement. Les paquets d'Arch bien souvent ne font rien hormis un configure ; make install. Et tu passes donc ton temps à faire ce que la distro devrait faire juste pour que ca marche correctement de base… Génial !