Allez, encore un petit effort pour le A+ sur SSLLabs :D
Il y a encore du RC4 qui traîne et quelques navigateurs sans Forward Secrecy.
Et il manque aussi le support de HSTS.
Les configs qui vont bien : http://www.iletaitunefoisinternet.fr/ssltls-benjamin-sonntag/
Les sources des bannières étant publiques, tu pouvais très bien supprimer ces boutons.
Et même héberger chez toi ces pages pour éviter le tracking.
C'est ce qui a été fait sur le site de l'April (avec en prime la traduction en Français).
Quitte à défendre une cause, autant commencer par se l'appliquer à soi-même :)
Et la « norme » est totalement incomplète, avec des gros passages de type « pour cette fonction super utile, cf spec privée non publique d'une techno privatrice qu'on gardera bien pour nous »
L'objectif est de faire quoi ? Juste de gérer tes propres certificats ?
Ou de vraiment mettre en place une vraie PKI au sens large, avec livraison des certificats aux clients de manière sécurisée, gestion de la révocation, OSCP et le reste ?
Dans le 1er cas, EJBCA et OpenCA me paraissent juste overkill, XCA est bien plus simple pour une utilisation personnelle.
C'est beau de parler sur des préjugés (combien as-tu rencontré d'Epitech ? Ayant terminé leurs études, je parle).
Un certain nombre, que ça soit des candidats, des stagiaires ou des nouveaux diplômés.
Le niveau global est assez faible, généralement la personne ne maîtrise qu'un unique point de détail ou techno, le reste lui passe à 400km au dessus de la tête.
On va quand même éviter de généraliser trop brutalement, mais apparemment je ne suis pas le seul à avoir cette avis/expérience ici.
C'est beau de confondre le service communication d'une école avec ses étudiants.
Euh, généralement l'un ne va pas sans l'autre…
À force de voir dans les journaux ou l'actualité qu'ils sont les meilleurs du monde, forcément qu'ils finissent par y croire.
Et j'imagine assez mal un service communication qui dit une chose quand le corps enseignant les étudiants disent l'inverse =)
Concernant Epitech, même la formation spécialisée est très (trop) restreinte pour appeler ça une spécialité.
Ça pisse de la ligne en très grosse quantité, guère plus.
Au final ça sort de là à Bac+5 mais je préfère bien largement recruter des DUT à Bac+3 qui ont vraiment une approche utile et intéressante de la pratique de notre métier.
Et en tout cas, le diplôme et l'école d'origine ne rentre absolument pas en ligne de compte pour motiver mon avis quand je fais passer des entretiens d'embauche.
En plus de ça (et cette article en est une parfaite illustration), ils sont élevés à avoir une très haute estime d'eux-même et pensent réellement faire partie de l'élite européenne voire mondiale…
C'est un style de personnalité dont j'ai personnellement horreur et qui s'avère généralement totalement improductive voire contre-productive sur le terrain.
J'ai bien compris, et devines quoi, le developpeur doit lire la doc des APIs aussi, histoire de comprendre quels effets de bord ils peuvent avoir, dans quel cas ils peuvent se rater, etc…
J'ai aussi une info de dernière fraicheur pour toi : une doc n'est jamais à jour, toujours obsolète, toujours incohérente, toujours incomplète, voire même inexistante.
Celui qui te dira le contraire est un fou.
Si tu persistes encore à maintenir le contraire, prend n'importe quelle doc de ton choix et prouve-moi qu'elle est non seulement correcte, mais en plus exhaustive de tout ce qui peut se passer via n'importe quel cas d'utilisation.
La seule et unique chose qui peut décrire sans omission le comportement d'un code-source, c'est ce code-source lui-même, et lui seul.
Tout ce qu'un développeur peut te dire au sujet de ce code, et en particulier la doc, est tout autant soumis aux bugs du développeur que le code lui-même.
Un développeur peut très bien ne pas s'apercevoir d'un effet de bord de son code, et ne le documentera donc pas.
Je serais ouvert a ecouter tes experiences sur le sujet relativement aux gros projets software et a leur success / qualite. Si tu as mieux, n'hesites pas.
Je développe des softs toute la journée, et la qualité logicielle est justement une de mes préoccupations principale.
Et pour te résumer ma position de manière succinte : le C et consort, c'est mal; le duck-typing, c'est mal; le non-typé, c'est mal.
Pour le cas qui nous concerne, les check-exceptions sont pour moi le meilleur moyen de résoudre le problème qui nous inquiète.
Si on regarde le problème initial :
- Dans 99% des cas, on ne sait pas quelles erreurs peuvent arriver pour chaque ligne du programme. Cf supra, la doc ne peut pas aider sur ce point;
- Dans 99% des cas, on ne sait pas gérer une erreur au niveau où l'on est, et on devra la propager au niveau supérieur, jusqu'à ce que quelqu'un sache la gérer;
- Dans les cas les plus graves (null pointer exception, out of memory, buffer overflow…), on sait pertinemment que rien ne sert de tenter le moindre rétablissement, on est mort, autant s'arrêter.
Plutôt que d'avoir du code ignoble et inmaintenable à écrire sur chaque ligne et pour chaque erreur possible et/ou avoir à écrire la propagation supérieure et/ou avoir à gérer l'arrêt du programme, et ce sur chaque méthode, chaque appel de méthode et chaque programme, ça devrait être au compilateur de faire ce travail.
D'autant plus qu'il est très laborieux à faire, très difficile à faire écrire correctement et soumis à la bonne volonté du développeur (et de son planning/ses délais/ses finances !).
Si on prend les exceptions à la Java, on règle d'un coup tous les problèmes :
- Chaque méthode déclarant toutes les exceptions qu'elle peut lever, aucun risque d'en oublier une seule;
- Si une erreur peut arriver, alors on a que 2 choix, soit on sait la traiter et on la traite, soit on ne sait pas et on la laisse remonter, en déclarant que notre propre méthode peut échouer;
- Dans les cas les plus graves, le système lève une exception non-contrôlée, qui remontera toute seule toute la chaîne d'appel et arrêtera le programme.
C'est le compilateur qui fera tout le travail ingrat, proprement et sûrement, de manière mutualisée, évitant au développeur de réinventer la roue (carrée, de préférence…).
Voilà comment faire les choses proprement : déléguer au compilateur le maximum possible de vérification.
Un compilateur ne fera pas d'erreur, un développeur en fera obligatoirement une.
La realite est que cette methode est utilisee dans certains des plus gros projets software existants (Windows et Office au hasard ainsi que le kernel Linux) et que ca marche tres bien.
C'est pas parce que tout le monde fait comme ça qu'il faut faire comme ça…
Sinon, ça veut dire que Windows est meilleur que Linux ?
Sinon, ta phrase "l'utilisateur d'une API n'a aussi aucune garantie de gérer toutes les erreurs possibles et imaginables que peut lui retourner une fonction, sauf à aller lire la doc (généralement fausse et/ou incomplète)" est franchement horrible, oh mon dieu, l'utilisateur doit lire la doc ? Grande nouvelle, si il ne l'a lit pas, mieux vaut qu'il n'ecrive pas de code !
En temps que développeur d'une application, tu es utilisateur des API de plus bas niveau.
Je ne parlais pas de l'utilisateur final, d'ailleurs ma phrase commence bien par « Au niveau développement ».
Ça ne change pas grand chose au final, ce genre de code est juste ignoble et devrait être catapulté en orbite à coup de bombes nucléaires (pour paraphraser Linus).
Sur un bout de code à la con, on voit bien que pour 2 lignes utiles qui devraient conduire à une complexité cyclomatique de 1 et dont le pseudo-code serait
fooBar() {
foo()
bar()
}
on en arrive à une 15aine de lignes de code et une complexité de 4.
Sur un soft d'une complexité standard, je te laisse imaginer ce que ça donne…
Idem en maintenance/évolution, alors que sur le pseudo-code on n'aurait qu'à ajouter une ligne entre foo() et bar(), en C on va devoir toucher aussi à toute la partie nettoyage/gestion d'erreur, aussi bien dans notre code que dans le code appelant. Idéal pour semer des régressions aux 4 coins de l'appli…
Au niveau développement, l'utilisateur d'une API n'a aussi aucune garantie de gérer toutes les erreurs possibles et imaginables que peut lui retourner une fonction, sauf à aller lire la doc (généralement fausse et/ou incomplète) voire pire, carrément le code source…
Et même s'il prend la peine d'aller lire la doc, il ne sait généralement pas quoi faire en cas d'erreur, sinon se mettre à remonter à l'appelant toutes les erreurs de sa couche basse. « Eh les gars, on est en train de recoder les check-exceptions là ! »
Par extension, tout code en C DEVRAIT être codé selon ce principe, sauf à conduire aux différents problèmes soulevés PAR UN UTILISATEUR FINAL, c'est donc carrément le langage C qui devrait être mis en orbite !
Le problème, c'est justement comme tu le dis si bien, la PLUPART des appels retourne des codes de retour en C, quasiment jamais vérifié, et que tu devrais toi aussi retourner du coup un code d'erreur.
Ton code, ça va bien quand t'as 1 appel (et encore, le goto, c'est mal…). Mais je fais quoi quand j'empile 3, 4, 10, 42 appels ?
Tes 5-10s se transforment en 5-10min puis 5-10j puis 5-10mois, puis… Et faut aussi inclure le coût de la maintenance et des évolutions futures.
int fooBar() {
if (foo()) {
goto clean1;
}
if (bar()) {
goto clean2;
}
return 0;
clean1:
cleanFoo(); // Merdeuuuuuuuuuuu, je peux planter aussi…
return -1;
clean2:
cleanBar(); // Remerdeuuuuuuuuu, je peux planter aussi…
return -1;
}
C'est moche, c'est inmaintenable, c'est soumis à une palanqué de possibilité de bugs, ça fait du code spaghetti, ça fait qu'on perd à chaque fois la possibilité de retourner des valeurs non code d'erreur et donc qu'on doit se taper des passages par référence partout…
Et on ne sait généralement pas quoi faire sinon faire arrêter le programme de manière très moche dès qu'un truc retourne un truc non nul.
On n'a aucune certitude que notre programme fonctionnera correctement sauf à écrire du code considéré comme ignoble par tout développeur standard.
Et au final tout le monde s'en contre-fou de ces codes de retour, conduisant à des applis qui plantent/fuitent/buggent !
À ce sujet, il serait intéressant de connaître le matériel utilisé par le jury.
Je ne serais pas étonné que sa grosse majorité soit équipé avec la marque à la pomme, ce qui pourrait expliquer ce verdict et sa rapidité, étant donné la propension fan-boyiste chronique de cette partie de la population.
Mon petit mien au passage : https://gist.github.com/3094451
Ce qui peut donner : « (±|master|●1|+1|…1|⚡) » , scm | branche courante | modifs indexées | modifs non indexées | fichiers non trackés | état du workspace
Alors dans ce cas précis, je sort deboostrap/virtualbox/kvm/vserver et je me monte une Debian aussi pourrie que tu le souhaites pour compiler mon paquet et en faire un package Debian que j'installe proprement sur ma véritable Debian de tous les jours qui reste du coup toujours propre.
Pour moi, les seuls softs qui nécessitent d'être vraiment à jour, ce sont les navigateurs web.
Tente d'être en firefox 3.5 pour naviguer, tu vas juste pleurer et te croire sous IE6…
Peut-être aussi les clients de messageries instantanées, surtout sur les protocoles propriétaires.
Pour le reste, effectivement, avoir la dernière version n'apporte généralement pas grand chose.
Je ne te parle pas du point de vue du développeur Debian, mais de celui d'un utilisateur lambda.
Certes, testing est sensé servir à préparer la future stable.
Mais pour une Madame Michu standard, utiliser une stable est juste inenvisageable.
Certes c'est stable, joli et propre, mais les softs datent de Mathusalem, et comme on l'a si bien dit, Firefox 3.5, KDE 4.4, Chromium 0.9 ou OpenOffice 3.2 (wé, même pas de LibreOffice…), c'est pas que c'est @deprecated depuis des lustres mais presque.
Si tu promeus Debian en disant « Testing c'est pour les développeurs qui veulent stabiliser la future stable, donc tu restes en Stable car tu es simple utilisateur standard », je comprend mieux que Linux a du mal à s'imposer, les gens vont l'utiliser 2h et aller voir ailleurs…
C'est bien pour ça qu'il y a stable et testing.
Stable pour les serveurs pour sa fiabilité, stabilité et sécurité.
Testing pour le desktop, avec des softs suffisamment à jour sans être (trop) buggés et relativement fiables pour une utilisation quotidienne (pas besoin d'une SLA de 99.999% pour un utilisateur normalement constitué =)).
Oui mais si tu veux aider à stabiliser, tu ne dois plus te considérer comme utilisateur lambda et t'attendre à des effets de bord (bugs, failles, stabilité générale, cassure dans les dépendences…).
Généralement, je fais même ça dans une VM, histoire de ne pas trop mettre en péril mon PC desktop.
Et dans tous les cas, tu ne viens pas te plaindre après sur linuxfr que ça ne fonctionne plus (et encore moins de cette manière là).
Mettre à jour régulièrement ses programmes n'est pas incompatible avec ne pas utiliser sid ou experimental.
La mise-à-jour régulière, c'est pour appliquer les patches de sécu et fixer les gros bugs méchants, histoire d'avoir un minimum de sécurité. Si on peut rester sur les mêmes versions majeures des softs, c'est même d'autant mieux.
L'utilisation de sid ou experimental aurait même l'effet inverse, en mettant en place des versions de softs non éprouvées remplies de failles et de bugs non fixés.
Sans parler de la question habituelle : a-t-on vraiment besoin de la fonctionnalité de la mort-qui-tue pas testée de la dernière version pas stable ou est-ce que c'est de la kikoololerie bling-bling et qu'on peut très bien s'en passer ?
J'ai jamais vraiment rencontré de cas crédible et défendable du 1er cas… Par contre le 2nd, j'en vois pléthore tous les jours, et généralement ça se finit assez mal =)
Je ne vois pas quel utilisateur normalement constitué a besoin de sid et encore moins d'expérimental…
Même moi en tant que dev confirmé, je dépasse rarement testing, alors…
Et ma dernière install de KDE date d'il y a à peine quelques semaines, sans aucun soucis notable.
Encore une fois, mauvais utilisateur, changer utilisateur =)
Je suis sous KDE 4.8.4 (testing/unstable) depuis des lustres, en full UTF8 depuis maintenant plus de 2 ans.
J'ai des cartes graphiques à la con (NVidia) et des cartes sons encore plus à la con (Creative X-Fi).
J'utilise couramment LibreOffice et Icedove, Scribus de temps en temps.
Je manipule des documents qui proviennent d'environnement Windows avec tout ce que j'ai pu voir comme nommage débile de fichier, à grand coup d'accents, en ISO ou UTF.
Et je n'ai JAMAIS (je dis bien JAMAIS) eu le moindre des soucis desquels tu parles, que ça soit l'encodage UTF8, l'absence de son ou la souris sauteuse…
Et d'ailleurs, je ne vois même pas ce que KDE vient faire là-dedans (surtout pour LibreOffice et Icedove qui ne dépendent même pas de lui), si les fichiers n'arrivaient pas à être lu, ça n'a qu'une chance infime de provenir du WM, mais toutes les chances d'être à cause du filesystem ou du kernel.
Avant de commencer à taper sur tous les logiciels les uns après les autres (LibreOffice/Icedove, maintenant KDE…), faudrait peut-être remettre en cause l'autre bout de la chaîne, à savoir l'utilisateur.
Comme on dit toujours « mauvais utilisateur, changer utilisateur » =)
Hello !
Je suis dans la même situation que toi, TMS depuis 1 an et du coup je me suis tout re-équiper aussi, TM et trackball pour ma part.
Par contre, je tient à apporter une précision à mon avis importante et qui a eu de graves conséquences pour moi : consultez un médecin avant de changer votre matériel, en tout cas si ce n'est pas juste un changement « de confort » et que vous avez déjà des TMS et/ou des douleurs !
Dans mon cas, j'avais une douleur au poignet, type syndrôme canal carpien.
Suivant les conseils trouvés sur le net, passage au TM, qui a déjà pas mal amélioré ma situation.
Vu que tout le monde était aussi très content de sa souris verticale et que mon expérience avec le TM était très concluante, j'ai aussi investi dans une souris verticale Evoluent.
Et là ce fut le drame… En fait je ne souffrais pas du syndrôme du canal carpien, qui touche le nerf central du poignet et rejoint le pouce (dans ce cas la souris verticale est vraiment un plus), mais du canal ulnaire, qui lui passe sur le côté de la main et rejoint l'auriculaire.
Bilan des courses, la souris verticale n'a fait qu'empirer ma situation, le nerf en question étant constamment en contact avec le bureau et supportant la totalité du poids de la main !
J'avais moins mal lors de l'utilisation de ma souris (apparement parce que le nerf était toujours sous pression), mais le nerf en question était juste en train de s'user à vitesse grand V et j'avais de plus en plus mal en dehors de la bureautique !
J'ai échappé à l'intervention chirurgicale de justesse, 7 jours d'ITT après 1 mois d'utilisation seulement, et j'ai changé pour un trackball.
En plus de m'avoir coûter une blinde inutilement, décider de changer de matériel sans consulter un médecin alors qu'on a déjà des douleurs, c'est pas très conseillé et ça peut même empirer la situation. Allez consulter si vous avez des douleurs, et ne prenez pas de décisions sans l'avis d'un médecin !
# HTTPS
Posté par Aeris (site web personnel) . En réponse à la dépêche Sortie de R.A.S. v0.5, alias RandoAmisSecours. Évalué à 5.
Allez, encore un petit effort pour le A+ sur SSLLabs :D
Il y a encore du RC4 qui traîne et quelques navigateurs sans Forward Secrecy.
Et il manque aussi le support de HSTS.
Les configs qui vont bien : http://www.iletaitunefoisinternet.fr/ssltls-benjamin-sonntag/
[^] # Re: Cohérence
Posté par Aeris (site web personnel) . En réponse à la dépêche Le jour de la riposte (« The Day We Fight Back ») contre la surveillance généralisée. Évalué à 3.
Les sources des bannières étant publiques, tu pouvais très bien supprimer ces boutons.
Et même héberger chez toi ces pages pour éviter le tracking.
C'est ce qui a été fait sur le site de l'April (avec en prime la traduction en Français).
Quitte à défendre une cause, autant commencer par se l'appliquer à soi-même :)
[^] # Re: En résumé
Posté par Aeris (site web personnel) . En réponse au journal Pourquoi je suis passé de LibreOffice à une suite propriétaire.... Évalué à 10.
Et la « norme » est totalement incomplète, avec des gros passages de type « pour cette fonction super utile, cf spec privée non publique d'une techno privatrice qu'on gardera bien pour nous »
# Utilisation personnelle simple ou PKI full features ?
Posté par Aeris (site web personnel) . En réponse au journal PKI open source: retours d'experience ?. Évalué à 2.
L'objectif est de faire quoi ? Juste de gérer tes propres certificats ?
Ou de vraiment mettre en place une vraie PKI au sens large, avec livraison des certificats aux clients de manière sécurisée, gestion de la révocation, OSCP et le reste ?
Dans le 1er cas, EJBCA et OpenCA me paraissent juste overkill, XCA est bien plus simple pour une utilisation personnelle.
[^] # Re: Écoles d'ingénieurs?
Posté par Aeris (site web personnel) . En réponse au journal Epitech, l'une des plus prestigieuses écoles d'ingénieurs en Europe, se tourne vers SuSE Linux !. Évalué à 10. Dernière modification le 15 novembre 2012 à 01:07.
Un certain nombre, que ça soit des candidats, des stagiaires ou des nouveaux diplômés.
Le niveau global est assez faible, généralement la personne ne maîtrise qu'un unique point de détail ou techno, le reste lui passe à 400km au dessus de la tête.
On va quand même éviter de généraliser trop brutalement, mais apparemment je ne suis pas le seul à avoir cette avis/expérience ici.
Euh, généralement l'un ne va pas sans l'autre…
À force de voir dans les journaux ou l'actualité qu'ils sont les meilleurs du monde, forcément qu'ils finissent par y croire.
Et j'imagine assez mal un service communication qui dit une chose quand
le corps enseignantles étudiants disent l'inverse =)[^] # Re: Écoles d'ingénieurs?
Posté par Aeris (site web personnel) . En réponse au journal Epitech, l'une des plus prestigieuses écoles d'ingénieurs en Europe, se tourne vers SuSE Linux !. Évalué à 10.
J'avais bien compris pour ta formation =)
Concernant Epitech, même la formation spécialisée est très (trop) restreinte pour appeler ça une spécialité.
Ça pisse de la ligne en très grosse quantité, guère plus.
Au final ça sort de là à Bac+5 mais je préfère bien largement recruter des DUT à Bac+3 qui ont vraiment une approche utile et intéressante de la pratique de notre métier.
Et en tout cas, le diplôme et l'école d'origine ne rentre absolument pas en ligne de compte pour motiver mon avis quand je fais passer des entretiens d'embauche.
En plus de ça (et cette article en est une parfaite illustration), ils sont élevés à avoir une très haute estime d'eux-même et pensent réellement faire partie de l'élite européenne voire mondiale…
C'est un style de personnalité dont j'ai personnellement horreur et qui s'avère généralement totalement improductive voire contre-productive sur le terrain.
[^] # Re: Écoles d'ingénieurs?
Posté par Aeris (site web personnel) . En réponse au journal Epitech, l'une des plus prestigieuses écoles d'ingénieurs en Europe, se tourne vers SuSE Linux !. Évalué à 3. Dernière modification le 14 novembre 2012 à 23:17.
Wé, 'fin généralistes, ils le sont clairement pas. Spécialistes encore moins.
Même pour amuser la galerie au bureau, j'en voudrais pas :þ
# Oh my god ><
Posté par Aeris (site web personnel) . En réponse au journal Epitech, l'une des plus prestigieuses écoles d'ingénieurs en Europe, se tourne vers SuSE Linux !. Évalué à 6.
Ça va les chevilles, pas trop douloureuses ?
Et la tête ? Elle passe encore dans les portes ?
[^] # Re: Ouf je me sens moins seul d’un coup.
Posté par Aeris (site web personnel) . En réponse au journal Free et Google. Effets de bord. Évalué à 4.
Idem, Val-de-Marne, tout ce qui touche à Google de près ou de loin rame.
Aucun soucis dès que j'utilise mon dédié OVH comme rebond.
[^] # Re: Je pense que tu confonds les cas où c'est nécessaire
Posté par Aeris (site web personnel) . En réponse au journal Genèse d'un journal. Évalué à -5.
On va commencer par la fin, ça sera plus logique.
J'ai aussi une info de dernière fraicheur pour toi : une doc n'est jamais à jour, toujours obsolète, toujours incohérente, toujours incomplète, voire même inexistante.
Celui qui te dira le contraire est un fou.
Si tu persistes encore à maintenir le contraire, prend n'importe quelle doc de ton choix et prouve-moi qu'elle est non seulement correcte, mais en plus exhaustive de tout ce qui peut se passer via n'importe quel cas d'utilisation.
La seule et unique chose qui peut décrire sans omission le comportement d'un code-source, c'est ce code-source lui-même, et lui seul.
Tout ce qu'un développeur peut te dire au sujet de ce code, et en particulier la doc, est tout autant soumis aux bugs du développeur que le code lui-même.
Un développeur peut très bien ne pas s'apercevoir d'un effet de bord de son code, et ne le documentera donc pas.
Je développe des softs toute la journée, et la qualité logicielle est justement une de mes préoccupations principale.
Et pour te résumer ma position de manière succinte : le C et consort, c'est mal; le duck-typing, c'est mal; le non-typé, c'est mal.
Pour le cas qui nous concerne, les check-exceptions sont pour moi le meilleur moyen de résoudre le problème qui nous inquiète.
Si on regarde le problème initial :
- Dans 99% des cas, on ne sait pas quelles erreurs peuvent arriver pour chaque ligne du programme. Cf supra, la doc ne peut pas aider sur ce point;
- Dans 99% des cas, on ne sait pas gérer une erreur au niveau où l'on est, et on devra la propager au niveau supérieur, jusqu'à ce que quelqu'un sache la gérer;
- Dans les cas les plus graves (null pointer exception, out of memory, buffer overflow…), on sait pertinemment que rien ne sert de tenter le moindre rétablissement, on est mort, autant s'arrêter.
Plutôt que d'avoir du code ignoble et inmaintenable à écrire sur chaque ligne et pour chaque erreur possible et/ou avoir à écrire la propagation supérieure et/ou avoir à gérer l'arrêt du programme, et ce sur chaque méthode, chaque appel de méthode et chaque programme, ça devrait être au compilateur de faire ce travail.
D'autant plus qu'il est très laborieux à faire, très difficile à faire écrire correctement et soumis à la bonne volonté du développeur (et de son planning/ses délais/ses finances !).
Si on prend les exceptions à la Java, on règle d'un coup tous les problèmes :
- Chaque méthode déclarant toutes les exceptions qu'elle peut lever, aucun risque d'en oublier une seule;
- Si une erreur peut arriver, alors on a que 2 choix, soit on sait la traiter et on la traite, soit on ne sait pas et on la laisse remonter, en déclarant que notre propre méthode peut échouer;
- Dans les cas les plus graves, le système lève une exception non-contrôlée, qui remontera toute seule toute la chaîne d'appel et arrêtera le programme.
C'est le compilateur qui fera tout le travail ingrat, proprement et sûrement, de manière mutualisée, évitant au développeur de réinventer la roue (carrée, de préférence…).
Voilà comment faire les choses proprement : déléguer au compilateur le maximum possible de vérification.
Un compilateur ne fera pas d'erreur, un développeur en fera obligatoirement une.
[^] # Re: Je pense que tu confonds les cas où c'est nécessaire
Posté par Aeris (site web personnel) . En réponse au journal Genèse d'un journal. Évalué à -6. Dernière modification le 09 septembre 2012 à 21:14.
C'est pas parce que tout le monde fait comme ça qu'il faut faire comme ça…
Sinon, ça veut dire que Windows est meilleur que Linux ?
En temps que développeur d'une application, tu es utilisateur des API de plus bas niveau.
Je ne parlais pas de l'utilisateur final, d'ailleurs ma phrase commence bien par « Au niveau développement ».
[^] # Re: Je pense que tu confonds les cas où c'est nécessaire
Posté par Aeris (site web personnel) . En réponse au journal Genèse d'un journal. Évalué à 1.
Ça ne change pas grand chose au final, ce genre de code est juste ignoble et devrait être catapulté en orbite à coup de bombes nucléaires (pour paraphraser Linus).
Sur un bout de code à la con, on voit bien que pour 2 lignes utiles qui devraient conduire à une complexité cyclomatique de 1 et dont le pseudo-code serait
on en arrive à une 15aine de lignes de code et une complexité de 4.
Sur un soft d'une complexité standard, je te laisse imaginer ce que ça donne…
Idem en maintenance/évolution, alors que sur le pseudo-code on n'aurait qu'à ajouter une ligne entre foo() et bar(), en C on va devoir toucher aussi à toute la partie nettoyage/gestion d'erreur, aussi bien dans notre code que dans le code appelant. Idéal pour semer des régressions aux 4 coins de l'appli…
Au niveau développement, l'utilisateur d'une API n'a aussi aucune garantie de gérer toutes les erreurs possibles et imaginables que peut lui retourner une fonction, sauf à aller lire la doc (généralement fausse et/ou incomplète) voire pire, carrément le code source…
Et même s'il prend la peine d'aller lire la doc, il ne sait généralement pas quoi faire en cas d'erreur, sinon se mettre à remonter à l'appelant toutes les erreurs de sa couche basse.
« Eh les gars, on est en train de recoder les check-exceptions là ! »
Par extension, tout code en C DEVRAIT être codé selon ce principe, sauf à conduire aux différents problèmes soulevés PAR UN UTILISATEUR FINAL, c'est donc carrément le langage C qui devrait être mis en orbite !
[^] # Re: Je pense que tu confonds les cas où c'est nécessaire
Posté par Aeris (site web personnel) . En réponse au journal Genèse d'un journal. Évalué à 1.
Le problème, c'est justement comme tu le dis si bien, la PLUPART des appels retourne des codes de retour en C, quasiment jamais vérifié, et que tu devrais toi aussi retourner du coup un code d'erreur.
Ton code, ça va bien quand t'as 1 appel (et encore, le goto, c'est mal…). Mais je fais quoi quand j'empile 3, 4, 10, 42 appels ?
Tes 5-10s se transforment en 5-10min puis 5-10j puis 5-10mois, puis… Et faut aussi inclure le coût de la maintenance et des évolutions futures.
C'est moche, c'est inmaintenable, c'est soumis à une palanqué de possibilité de bugs, ça fait du code spaghetti, ça fait qu'on perd à chaque fois la possibilité de retourner des valeurs non code d'erreur et donc qu'on doit se taper des passages par référence partout…
Et on ne sait généralement pas quoi faire sinon faire arrêter le programme de manière très moche dès qu'un truc retourne un truc non nul.
On n'a aucune certitude que notre programme fonctionnera correctement sauf à écrire du code considéré comme ignoble par tout développeur standard.
Et au final tout le monde s'en contre-fou de ces codes de retour, conduisant à des applis qui plantent/fuitent/buggent !
[^] # Re: J'y connais rien en droit étasuniens mais j'ouvre ma gueule !!
Posté par Aeris (site web personnel) . En réponse au journal Apple vs Samsung: le verdict. Évalué à 7.
À ce sujet, il serait intéressant de connaître le matériel utilisé par le jury.
Je ne serais pas étonné que sa grosse majorité soit équipé avec la marque à la pomme, ce qui pourrait expliquer ce verdict et sa rapidité, étant donné la propension fan-boyiste chronique de cette partie de la population.
[^] # Re: Et zsh ?
Posté par Aeris (site web personnel) . En réponse à la dépêche Un prompt bash utile, sans poudre aux yeux. Évalué à 1.
Mon petit mien au passage : https://gist.github.com/3094451
Ce qui peut donner : « (±|master|●1|+1|…1|⚡) » , scm | branche courante | modifs indexées | modifs non indexées | fichiers non trackés | état du workspace
[^] # Re: WTF
Posté par Aeris (site web personnel) . En réponse au journal Pourquoi je quitte KDE (désolé, c'est dimanche). Évalué à 2.
Alors dans ce cas précis, je sort deboostrap/virtualbox/kvm/vserver et je me monte une Debian aussi pourrie que tu le souhaites pour compiler mon paquet et en faire un package Debian que j'installe proprement sur ma véritable Debian de tous les jours qui reste du coup toujours propre.
Mauvais usage, changer usage =)
[^] # Re: WTF
Posté par Aeris (site web personnel) . En réponse au journal Pourquoi je quitte KDE (désolé, c'est dimanche). Évalué à 2.
Pour moi, les seuls softs qui nécessitent d'être vraiment à jour, ce sont les navigateurs web.
Tente d'être en firefox 3.5 pour naviguer, tu vas juste pleurer et te croire sous IE6…
Peut-être aussi les clients de messageries instantanées, surtout sur les protocoles propriétaires.
Pour le reste, effectivement, avoir la dernière version n'apporte généralement pas grand chose.
[^] # Re: WTF
Posté par Aeris (site web personnel) . En réponse au journal Pourquoi je quitte KDE (désolé, c'est dimanche). Évalué à 1.
Je ne te parle pas du point de vue du développeur Debian, mais de celui d'un utilisateur lambda.
Certes, testing est sensé servir à préparer la future stable.
Mais pour une Madame Michu standard, utiliser une stable est juste inenvisageable.
Certes c'est stable, joli et propre, mais les softs datent de Mathusalem, et comme on l'a si bien dit, Firefox 3.5, KDE 4.4, Chromium 0.9 ou OpenOffice 3.2 (wé, même pas de LibreOffice…), c'est pas que c'est @deprecated depuis des lustres mais presque.
Si tu promeus Debian en disant « Testing c'est pour les développeurs qui veulent stabiliser la future stable, donc tu restes en Stable car tu es simple utilisateur standard », je comprend mieux que Linux a du mal à s'imposer, les gens vont l'utiliser 2h et aller voir ailleurs…
[^] # Re: WTF
Posté par Aeris (site web personnel) . En réponse au journal Pourquoi je quitte KDE (désolé, c'est dimanche). Évalué à 0.
C'est bien pour ça qu'il y a stable et testing.
Stable pour les serveurs pour sa fiabilité, stabilité et sécurité.
Testing pour le desktop, avec des softs suffisamment à jour sans être (trop) buggés et relativement fiables pour une utilisation quotidienne (pas besoin d'une SLA de 99.999% pour un utilisateur normalement constitué =)).
[^] # Re: WTF
Posté par Aeris (site web personnel) . En réponse au journal Pourquoi je quitte KDE (désolé, c'est dimanche). Évalué à 3.
Oui mais si tu veux aider à stabiliser, tu ne dois plus te considérer comme utilisateur lambda et t'attendre à des effets de bord (bugs, failles, stabilité générale, cassure dans les dépendences…).
Généralement, je fais même ça dans une VM, histoire de ne pas trop mettre en péril mon PC desktop.
Et dans tous les cas, tu ne viens pas te plaindre après sur linuxfr que ça ne fonctionne plus (et encore moins de cette manière là).
[^] # Re: WTF
Posté par Aeris (site web personnel) . En réponse au journal Pourquoi je quitte KDE (désolé, c'est dimanche). Évalué à 3.
Mettre à jour régulièrement ses programmes n'est pas incompatible avec ne pas utiliser sid ou experimental.
La mise-à-jour régulière, c'est pour appliquer les patches de sécu et fixer les gros bugs méchants, histoire d'avoir un minimum de sécurité. Si on peut rester sur les mêmes versions majeures des softs, c'est même d'autant mieux.
L'utilisation de sid ou experimental aurait même l'effet inverse, en mettant en place des versions de softs non éprouvées remplies de failles et de bugs non fixés.
[^] # Re: WTF
Posté par Aeris (site web personnel) . En réponse au journal Pourquoi je quitte KDE (désolé, c'est dimanche). Évalué à 1.
Sans parler de la question habituelle : a-t-on vraiment besoin de la fonctionnalité de la mort-qui-tue pas testée de la dernière version pas stable ou est-ce que c'est de la kikoololerie bling-bling et qu'on peut très bien s'en passer ?
J'ai jamais vraiment rencontré de cas crédible et défendable du 1er cas… Par contre le 2nd, j'en vois pléthore tous les jours, et généralement ça se finit assez mal =)
[^] # Re: WTF
Posté par Aeris (site web personnel) . En réponse au journal Pourquoi je quitte KDE (désolé, c'est dimanche). Évalué à 4.
Je ne vois pas quel utilisateur normalement constitué a besoin de sid et encore moins d'expérimental…
Même moi en tant que dev confirmé, je dépasse rarement testing, alors…
Et ma dernière install de KDE date d'il y a à peine quelques semaines, sans aucun soucis notable.
Encore une fois, mauvais utilisateur, changer utilisateur =)
# WTF
Posté par Aeris (site web personnel) . En réponse au journal Pourquoi je quitte KDE (désolé, c'est dimanche). Évalué à 10. Dernière modification le 22 juillet 2012 à 19:01.
J'ai du mal à comprendre ton désarroi…
Je suis sous KDE 4.8.4 (testing/unstable) depuis des lustres, en full UTF8 depuis maintenant plus de 2 ans.
J'ai des cartes graphiques à la con (NVidia) et des cartes sons encore plus à la con (Creative X-Fi).
J'utilise couramment LibreOffice et Icedove, Scribus de temps en temps.
Je manipule des documents qui proviennent d'environnement Windows avec tout ce que j'ai pu voir comme nommage débile de fichier, à grand coup d'accents, en ISO ou UTF.
Et je n'ai JAMAIS (je dis bien JAMAIS) eu le moindre des soucis desquels tu parles, que ça soit l'encodage UTF8, l'absence de son ou la souris sauteuse…
Et d'ailleurs, je ne vois même pas ce que KDE vient faire là-dedans (surtout pour LibreOffice et Icedove qui ne dépendent même pas de lui), si les fichiers n'arrivaient pas à être lu, ça n'a qu'une chance infime de provenir du WM, mais toutes les chances d'être à cause du filesystem ou du kernel.
Avant de commencer à taper sur tous les logiciels les uns après les autres (LibreOffice/Icedove, maintenant KDE…), faudrait peut-être remettre en cause l'autre bout de la chaîne, à savoir l'utilisateur.
Comme on dit toujours « mauvais utilisateur, changer utilisateur » =)
# Consulter un médecin, c'est bien !
Posté par Aeris (site web personnel) . En réponse au journal La guérilla contre les TMS. Évalué à 10. Dernière modification le 22 juillet 2012 à 00:41.
Hello !
Je suis dans la même situation que toi, TMS depuis 1 an et du coup je me suis tout re-équiper aussi, TM et trackball pour ma part.
Par contre, je tient à apporter une précision à mon avis importante et qui a eu de graves conséquences pour moi : consultez un médecin avant de changer votre matériel, en tout cas si ce n'est pas juste un changement « de confort » et que vous avez déjà des TMS et/ou des douleurs !
Dans mon cas, j'avais une douleur au poignet, type syndrôme canal carpien.
Suivant les conseils trouvés sur le net, passage au TM, qui a déjà pas mal amélioré ma situation.
Vu que tout le monde était aussi très content de sa souris verticale et que mon expérience avec le TM était très concluante, j'ai aussi investi dans une souris verticale Evoluent.
Et là ce fut le drame… En fait je ne souffrais pas du syndrôme du canal carpien, qui touche le nerf central du poignet et rejoint le pouce (dans ce cas la souris verticale est vraiment un plus), mais du canal ulnaire, qui lui passe sur le côté de la main et rejoint l'auriculaire.
Bilan des courses, la souris verticale n'a fait qu'empirer ma situation, le nerf en question étant constamment en contact avec le bureau et supportant la totalité du poids de la main !
J'avais moins mal lors de l'utilisation de ma souris (apparement parce que le nerf était toujours sous pression), mais le nerf en question était juste en train de s'user à vitesse grand V et j'avais de plus en plus mal en dehors de la bureautique !
J'ai échappé à l'intervention chirurgicale de justesse, 7 jours d'ITT après 1 mois d'utilisation seulement, et j'ai changé pour un trackball.
En plus de m'avoir coûter une blinde inutilement, décider de changer de matériel sans consulter un médecin alors qu'on a déjà des douleurs, c'est pas très conseillé et ça peut même empirer la situation. Allez consulter si vous avez des douleurs, et ne prenez pas de décisions sans l'avis d'un médecin !