ckyl a écrit 3877 commentaires

Même constat.

Après des douleurs permanentes j'ai essayé de basculer sur un clavier typematrix 2030 + trackball Kensington. Résultats mieux mais toujours pas top. Bascule en souris verticale et pouf plus de problèmes.

J'ai une esync, rebrandée sous 13 noms différents, à genre 30€ qui me va très bien.

Par contre j'ai du tout doubler entre taf et maison par ce qu'autrement la douleur revenait.

Je garde juste un trackman pour quand je dois être précis et rapide mais la souris verticale répond à 99% de mes besoins pour un prix très raisonnable.

Ce que je n'ai pas réussi à comprendre c'est si l'activité correspond à du développement libre qui profite à quelqu'un ? (en dehors de "Libre OS USB" dont je n'ai pu trouver "que" la boutique)

Ou alors est-ce des prestations de dev ou d'integration à partir de briques libres ? Ce qui correspondrait finalement à ce que fais une bonne partie de l'industrie puisque tout repose fortement sur du libre un peu partout.

Quand je décide de faire reposer un produit sur un ensemble de briques libres; je ne considère pas faire du libre, même en contribuant des bug fixes. Je faisais du libre quand j'étais payer pour mettre développer des produits libres.

À la suite de ce journal, je n'ai pas compris dans quel cas de figure était l'auteur. Et donc oui le journal n'est pas très intéressant puisque l'on n'identifie pas les problématiques intéressantes du point de vue libre, qui était le titre du journal.

Les bonnes pratiques veulent que le DBA se connecte avec un compte nominatif sur le serveur puis passe "dba" via un "su" ou un "sudo".

Whaou y'a encore des gens qui ont pour bonne pratique de se connecter à une machine pour faire des trucs à la mano, non reproductibles, non testés et idéalement sans rien dire à personne pour être sur de prendre un KO à la prochaine mise à jour ?

Si les DBA existaient pas, faudrait les inventer.

Les bonnes pratiques ca serait pas plutôt de travailler ton infra pour viser à désactiver tous les logins sur toutes les machines ?

c'est que c'est normalement un cas qui ne doit JAMAIS arriver; si cela arrive, les unités de parse de log te remontent le machin directe chez le dev pour qu'il regarde le cas

Donc le cas qui ne doit JAMAIS arriver, tu mets quand même un système pour vérifier qu'il n'arrive jamais en fait.

Et quand ce qui n'arrive jamais arrive, le système va tout de même avoir un comportement et puisque que tu ne veux pas que ton système plante, offre 10M$ au client ou tue un petit chaton tu vas forcément avoir un chemin d'exécution qui prend le truc en compte tu ne peux pas juste continuer après ton serr comme si de rien n'était.

tiens un truc amusant pour chopper un constructor que l'on sait exister avec ensuite utilisation de ce constructor j'ai ça dans mon catch : InstantiationException | InvocationTargetException | NoSuchMethodException | IllegalAccessException
ça en fait pas mal pour rien…

Effectivement => catch (ReflectiveOperationException e) ;)

Après non, on ne va pas défendre la plupart des API du JDK non plus faut pas pousser.

C'est pour cela que j'ai tendance à préférer le stacktrace qu'on retrouvera dans les logs; ça évite de planter toute l'appli et de déconnecter sauvagement tous les utilisateurs du serveur métier.

Le stacktrace local n'est pas une solution. Ce que tu veux c'est que la fault remonte vers le fault handler adéquat qui fera alors la reprise sur erreur attendu pour l'unité en cours d'exécution (fonctionnel et non fonctionnel):

• Logguer / publier des métriques / créer une entrée dans le ticketing
• Re-essayer l'unité logique
• Planter le processus / Servir un message
• Etc.

Souvent quand tu as une base de code ou 90% des catch sont printstacktrace() / serr / log, tu vas aussi trouver des choses comme ça:

long value;
try {
  value = Long.parseLong(str);
} catch (NumberFormatException e) {
  e.printStackTrace();
}

return value + 2;

Critiquer le bordel que les Checked Exceptions mettent dans les responsabilités entre appelé et appelant, ce n'est pas critiquer le système de types… Faut se calmer, là…

Tu peux parfaitement critiquer.

Maintenant ce que tu critiques ce n'est pas uniquement les checked exceptions c'est le principe que les erreurs fassent partie de la signature d'une méthode.

Là j'ai pris un exemple tangent, mais imagine que c'est une regex en dure dans le code, faut aussi se farcir de la gestion d'exception pour dire qu'elle est mal rédigée?

Des idées:

• Tu utilises, ou fait, une API adaptée a ton besoin
• Plutôt qu'un serr tu plante ton processus par ce que tu viens de te retrouver dans un état impossible. (ça aidera aussi le prochain couillon qui après avoir oublié de mettre à jour le schema prendra une erreur propre plutôt qu'un truc qui fait semblant de marcher avec un serr ou qui plante 3kms après pour une raison inconnue)

Le problème des checked exceptions, c'est que un changement dans une méthode des types d’exceptions retournés, on doit changer tous les appelants (sinon ça compile pas). Alors que les appelants en ont rien à faire, la plupart du temps.

Donc tu n'as aucun problème dans le fait que n'importe quelle API que tu utilises change sa signature sans t'en informer et sans aucune information à la compilation ? Par ce que c'est exactement ce dont il s'agit. On parle d'un bon vieux goto non local qui peut apparaitre ou disparaitre n'importe où n'importe quand sans aucun moyen de contrôle.

En fait ce qui dérange les gens c'est d'un côté de gérer correctement une API, son évolution et de l'autre la robustesse et exploitabilité d'une application.

Vu qu'on n'est déjà pas capable de le faire correctement quand un système de type est la pour nous aider, on va tout faire à runtime histoire au moins on est plus embêté par ce foutu système de type qui nous dit qu'on fait n'importe quoi en changeant la signature / fonctionnement d'une API publiée ! Et puis c'est vrai enfin quoi puisque la plupart des utilisateurs font n'importe quoi, pourquoi s'embêter ?

Tu as une analyse du problème bien plus intéressante que la mienne dans l'article que j'ai déjà cité: The error model.

Source : Kent Beck. ;-)

Puisque tout le monde dit des conneries, Kent Beck et la maitresse inclus, l'auteur est en général bien moins intéressant que l'argumentaire.

Le code java est pollué par de la gestion de truc qui n'arrivent jamais, et le jour où ça arrive, c'est tellement ignoré que ça passe à la trappe; j'ai une préférence pour faire un printstacktrace, au cas où.

Hum ignoré ou printStracktrace(), dans les deux cas tu as merdé ton design quelque part. À priori même à deux endroits: définition de l'API et gestion des erreurs à l'utilisation.

Normalement au pire tu utilise une API qui utilise des checked exceptions pour signaler des cas que tu considères être des faults plutôt que des contingencies (ie. tu ne peux rien faire localement sinon remonter le problème à un fault handler de plus haut niveau qui lui décidera de l'action adéquat)

Ça reste verbeux mais il n'y a pas de miracle. Les gens qui utilisent des unchecked se plaignent du côté loterie, de la gestion de compatibilité impossible etc. mais ne sont pas embêtés pour écrire du code de porc. Et les gens qui utilisent des checked se plaignent d'avoir à gérer ce qui est a gérer. Comme la flemmardise et le vite fait mal fait sont la règle dans le métier, on a tendance à plus entendre les gens qui ne veulent gérer aucun cas d'erreur.

Et comme les faults des uns sont souvent les contingencies des autres, on arrivera rarement a faire une séparation propre des deux niveaux API.

Rien de nouveau sous le soleil: http://www.oracle.com/technetwork/java/effective-exceptions-092345.html

c'est tellement ignoré que ça passe à la trappe; j'ai une préférence pour faire un printstacktrace, au cas où.

Et depuis la nuit des temps, ce genre de code bases sont des tas de boue.

Même quand le langage est pas coopératif, c'est pas bien difficile de mettre en place des principes simples qui empêche d'ignorer ce genre d'erreurs. Au minimum tu imposes que les trucs "impossibles" soient remontés au fault handler le plus proche ou racine, plutôt que de continuer son petit bonhomme de chemin.

A choisir, pouvoir raisonner sur une base de code est beaucoup plus important que sauver deux lignes de code.

Je ne fais pas de C++ mais vu ce que tu écris je suis d'accord avec ton constat. Un optional avec une méthode de test et de déréférencement n'apporte pas grand chose à retourner possiblement null. Les deux sont vérifiables avec une analyseur statique de code et les deux permettent de faire des erreurs… Et au passage si tu es dans un langage ou le compilo/runti,e ne peut pas virer l'optional et bien tu viens de prendre un accès mémoire en plus…

D'ailleurs bien que l'Optional de Java soit loin d'être puissant ou génial, c'est un des premier truc que j'explique aux gens. Si tu utilises isPresent() suivi d'un get() alors tu fais certainement une erreur car tu n'as rien gagné du tout. Les API fonctionnelles elles empêchent toute erreur.

Sur le sujet des différents types de gestions d'erreur et les approches des différents langages, je me souviens de cet excellent article: The error model

Donc en gros, fullstack=backend+frontend

Ah ouai donc c'est juste un terme ronflant pour dire développeur ;)

Ma question préférée d'entretien pour les "développeurs fullstack": Alors sur x86_64 elle va dans quel sens la stack ?

D'une part (et cocorico !), il y a les grid5000 qui est une grille de calcul géré par l'enseignement supérieur monté sur des petites machines réparties un peu partout en France.

Je suis pas sur que ta définition de grid5000 soit très pertinente ni en lien vers avec ce dont il parlait. C'est "juste" un ensemble de clusters repartis dans la France et reliés via liens dédiés à haut débit.

Grosso modo, ca correspond à ce que tu ferais chez n'importe quel iaas. Interco tres rapide au sein d'un meme clusters (bon la tu vas avoir des trucs bien plus rapide que du 10GB type infiniband), interco rapide au sein d'un même site geographique et tu dis bonjour à la vitesse de la lumière pour passer d'un site à l'autre même si la France est petite… C'est juste plus typé calcul scientifique qu'un iaas (batch scheduler etc.)

Il parlait je pense d'une idée veille comme le monde, et surtout les années 2000, de voler du cycle cpu inutilisés chez les gens ou stations de travail pour faire tourner les calculs. Il suffit d'aller voir tout les trucs qui ont foirés ou vivotes pour comprendre les limites du truc.

D'ailleurs, pour me prouver la véracité des prix, qu'on me dise une bonne fois pour toutes combien y'a d'antennes, où elles se trouvent, et quelles puissance elles émettent, en France et au Canada

Au moins pour la France tu as des bases des antennes en France en open data pas trop dégueulasse (ie. Si tu pars de logs indiquant à quoi était connecté un téléphone tu retrouve presque toujours ses coordonnées en base) .

J'ai plus le nom en tête mais ça se trouve sans trop de soucis.

La seule chose que je comprend, c'est que les mec ils ont des ballz … Pour envoyer un mec dans la lune avec un programme en … assembleur, les mecs sont bon quand même.

C'est bien pire que ca.

Ce n'est pas écrit en assembleur mais en MAC (MIT Algebraic Compiler), puis le MAC a été compilé vers de l’assembleur à la main par des humains. Et c'est ce résultat que tu as sur Github.

Ca donne des choses comme ca:

            TC  BANKCALL    # TEMPORARY, I HOPE HOPE HOPE
            CADR    STOPRATE    # TEMPORARY, I HOPE HOPE HOPE
            TC  DOWNFLAG    # PERMIT X-AXIS OVERRIDE

Kevlin Henney en parle rapidement dans Cool Code vers 15mn.

l'architecture d'un projet le fait d'utiliser des algo en O(N) plutôt qu'en O(log(N)) par exemple est une erreur.

Juste pour remettre 2€ dans le bastringue qui n'ira jamais nul part vu le sujet :)

Ça dépend de la taille de tes structures. Du O(N) qui fait marcher à fond le prefetch et le pipeline marche souvent mieux que du log(N) blindé d'accès non prévisibles et de branches aléatoires sur les tailles courantes de structures.

Typiquement une recherche linéaire explose une bissection jusqu'à quelques centaines d'éléments. C'est quoi le taille moyenne de tes structures ?

J'adore ces threads sans sujet ou chacun peu donner son avis sur n'importe quoi !

A mon avis tu te méprends profondément sur la difficulté de repérer ce système.

Je confirme. Virer de tels outliers n'a rien de sorcier et est fréquemment fait que ce soit par les régies, les mesureurs ou tout autre personne.

Après tu peux avoir de bonnes raisons business de ne pas le faire, comme rentrer un peu de sous en plus tant que personnes ne gueule.

Mais je rejoins les autres, même si ça marchait à court terme, ca n'aurait comme impact que de faire baisser les prix à moyen terme et de revenir a la case depart. Enfin entre temps tu as rajouté du boulot aux parasites de la pub pour faire des filtrages supplémentaires donc tu viens de basculer encore un peu plus d'argent vers la pub plutôt que vers les journalistes. Oups !

Les backups, c'est 99% inutile, dont tu n'as jamais besoin.

Le but ce n'est jamais de faire une sauvegarde. C'est d'être capable de faire une restauration. Or la seule façon de t'assurer que la restauration fonctionne et que tout est OK c'est de le faire.

Donc si tu as besoin d'une sauvegarde, tu as besoin d'accéder aux données régulièrement. Sinon tu crois au père noël.

Mais quand tu en as besoin (ton RAID1 qui casse jamais… a cassé), tu es content.

Un RAID1 ne protège que d'un tout petit sous ensemble des problèmes possibles. Il ne peut rien contre une erreur d'administration, une corruption lente du à un bug etc.

Linked in perd de l'argent. Ils publient des chiffres positifs uniquement par ce qu'ils sortent les coûts de rémunération des leurs employés en stock. C'est une pratique assez peu fréquente…

Le New York Times a écrit un excellent article la dessus: http://www.nytimes.com/2016/06/14/business/dealbook/linkedin-stock-based-compensation.html

Et l'analyse du combo rémunération des employés via stock très importante + stock voué a ne pas monter => risque important que tout le monde se casse est assez intéressante.

il n'y a rien de nouveau que les livres sur l'info (et pas que) sont assez vite dépassés

Ça dépend de ce que tu lis. En effet, ca n'a presque aucun sens d'acheter des bouquin sur une techno. Mais il existe des trucs bien plus fondamentaux.

Depuis deux ans, presque un livre sur deux que je lis date d'avant 2000. La plupart sont restés parfaitement pertinents.

Si un livre publié il y a 10+ an est encore régulièrement bien noté, jetez vous dessus c'est statistiquement bien plus intéressant que n'importe quoi publié dans l'année.

Exemples:
- La série Quality Software Management de Weinberg date de 1991
- Peopleware de 1987 ou 1999
- Code complete date de 1993 ou 2004
- The Pragmatic Programmer date de 1999
- Refactoring: Improving the Design of Existing Code date de 1999

Tu as même des trucs marrant comme Programmers at Work qui date de 1989 où tu n'apprendras pas grand chose de pratique mais il est amusant de voir que certains avaient une vision parfaitement claire de où on en était il y a 25 ans et où on allait. Avec le recul tu remarques aussi que pas grand chose a changé, on a juste changé certains mots clés et augmenté les ordres de grandeur de tout.

Ce qui m'amène a deux citations que je trouvent assez justes

The immaturity of computing is used to excuse every ignorance. There's an enormous body of wisdom but we don't care

Computing: The only industry that becomes less mature as more time passes.

Apprenez des vieux !

Ca dépend des informations que tu demandes, de la complexité pour le VCS de les obtenir, de la machine, de la taille du répo et de la performance de l'implémentation du prompt.

En pratique pour utiliser powerline quotidiennement, qui était plus rapide que liquidprompt quand je l'ai quitté en 2013, je n'ai jamais attendu mon prompt en bossant sur des repos d'un petite dizaine de milliers de fichier.

Si tu ne fais pas le jacky avec ton prompt, tu gagnes des infos utiles sans inconvénient notable. Si tu utilises un VCS lent, bha ton prompt est lent et tu vas désactiver le support de ton VCS au bout de 2h…

et que je laisse du code sale (typiquement du code dupliqué)

DRY s'applique aux idées et non au code, voir http://dearjunior.blogspot.fr/2012/03/dry-is-about-ideas-not-text.html.

Ca peut être une stratégie de garder de la duplication initialement tant que les concepts ne sont pas clairement identifiés. Souvent, on est a un stade où il est pas encore clair si deux choses sont intrinsèquement les mêmes ou si la ressemblance est juste une coïncide, possiblement temporaire. Compartimenter ces différents concepts et les blinder pour qu'ils existent indépendamment peut être un très bon choix (voir le l'article que j'ai donné plus bas). Au pire si les deux concepts sont réellement identiques, et avec beaucoup beaucoup de discipline, on pourra les fusionner à la prochaine itération.

Par contre, si il est déjà identifié qu'on a un unique concept et plusieurs implémentations qui se baladent c'est juste du boulot mal fait. Par ce qu'il est bien connu que ton futur toi aura aura plus de temps libre que ton toi actuel pour nettoyer le caca, et qu'entre temps tout ne va pas se dégrader à vitesse grand V, koufffff.

En complément, la présentation Sometimes a Controller is just a Controller est assez intéressante pour réfléchir à ces sujets. On y discute justement les différentes approches individuelles, d'équipes etc. Ce n'est pas uniquement sur ce sujet, mais ça vaut très largement les 42 minutes investies.

(Oui j'ai polioté, vive les mobiles)

http://programmingisterrible.com/post/139222674273/write-code-that-is-easy-to-delete-not-easy-to

Je pense que tu retrouveras pas mal de tes arguments de manière assez structurée dans cet article : http://programmingisterrible.com/post/139222674273/write-code-that-is-easy-to-delete-not-easy-to

C'est le genre de sujet sur lequel je challenge pas mal les juniors qui rejoignent mes équipes. Savoir visualiser le monde selon plusieurs point de vues, et découvrir le point de vue assez peu enseigné qu'on passe notre temps écrire de la merde par ce qu'on ne sait pas ce qu'on fait et que chercher à limiter / compartimenter les dégâts peut être une bonne approche. Ça fait parti des outils d'architecture.

C'est assez vrai quand on est proche du e-business, et de moins en moins vrai quand on rentre dans l'Infra ou on a une démarche beaucoup plus d'ingénierie.

Comme pour tout les fs.

Afaik la seule spécificité de zfs c'est le manque d'outils pour récupérer un pool un vrac si la corruption arrivé dans les Metz données. Mai vu que j'utilise pas zfd ça a peut être même évolué.

Tu devrais t'adresser plus particulièrement aux développeurs java

Désolé les gars mais quand je vois une classe qui hérite de classes multiples

Troll échoué !