ckyl a écrit 3877 commentaires

On peut aller loin avec des grandes phrases comme ca ;)

Comme toujours c'est très différent en fonction de ton produit. Entre l'appli d'entreprise interconnectée à 1000 services utilisant 300 frameworks avec 5000 features ou tu ne vas rien pouvoir prévoir niveau perf du code avant la fin et du code du batch qui parse du fichier à gogo ou un service spécifique il y'a un monde.

Quand ton produit est à taille humaine, on est tout à fait capable d'estimer "au pif" si telle ou telle solution est viable et de le POCé/testé en quelques minutes si on a besoin de chiffre.

Tu le dis toi même d'une autre facon dans ton commentaire:

Je confirme, il y a 2 moyens de gagner du temps :
- avoir une bonne archi (ne pas faire 2 fois le même boulot couteux, éviter un parcours exponentiel.)

Ta bonne archi elle vient d'où ? D'une conception qui tient compte de tes requirements et des coûts dev & runtime des différentes options. Tu réfléchis à ce dont tu as besoin puis tu regardes si y'a un truc qui y répond. Sinon tu te sors les doigts plutôt que mettre ca sous le tapis. On est pas d'accord ?

Effectivement.

Maintenant une empreinte mémoire ca se calcule à l'avance. Un algorithme ou une structure de donnée adapté ca se choisi selon le contexte. Les structures de données toutes faites c'est cool oui.

Maintenant utiliser une TreeMap<Integer, Integer> vaut-il le coup de payer multiplier par 9 la consommation mémoire de mon appli ? Quand j'ai 100M d'éléments ?

De même quand tu choisis d'implémenter le safe browsing dans un navigateur tu sais très bien que tu vas pas utiliser un set pour contenir les URL malicieuses mais que tu vas te coder un bloom filter.

De même quand tu sais que ton code va traiter quelques dizaines de milliards d'entrées par jour tu n'attends pas la fin du dev pour mesurer ce que tu fais et lancer un profiler.

Si tu n'as plus junior devant ton nom tu sais aussi commencer à estimer ce qui va coûter cher ou non et le mesurer corriger ASAP pour ne pas cumuler des choses non-rattrapables.

Après oui, on mesure pour optimiser le code. Le faire à la fin, ca peut surtout vouloir dire le faire à la fin de la story… Pas 12 mois après quand on peut plus rien refactorer, qu'on a jamais eu de baseline de perf et que y'a plus de budget ni de temps. Si je livre une feature, elle doit tenir la charge pour laquelle elle est prévue et trouver le meilleur ratio coûts de prod/dev.

Bref le dev c'est comprendre le métier et les contraintes et s'adapter. Des fois ca veut dire faire de la plomberie bête et méchante, des fois ca de réimplémenter des trucs ou utiliser des choses non conventionnelles ou peu diffusées par ce que ca à un sens d'un point de vue business. Et c'est beaucoup moins rare qu'on le croit.

Ca dépend de ce sur quoi tu bosses, comment et quels sont tes objectifs…

Y'a un moment faut arrêter les conneries, si t'es capable de livrer un produit qui consomme 4x moins de mémoire simplement par ce que tu as branché ton cerveau 5 minutes tu le fais de base. Idem en perf. Idem pour utiliser des structures de données/algorithme adaptées au problème plutôt que tes 3 structures de base.

Dire que tout existe tout fait pour tout les usages, c'est soit de la connerie pure soit que tu ne fais rien d'intéressant.

Je ne vais pas te contredire c'est juste la base de la base. Autrement tu n'es pas développeur mais membre de la compagnie créole ;)

Je n'ai pas dit non plus, que c'était un bon critère de recrutement. Je n'en ai pas encore découvert.

Par contre la vision uniquement plomberie du job "yatoudanlélib" va finir par faire vraiment des ravages. Y'a un moment tu as besoin d'avoir des bases pour comprendre et être capable de proposer, estimer et implémenter différentes solutions. Ce n'est pas une histoire de prendre une heure de plus. C'est d'avoir un pied dans la réalité, d'être capable de proposer des solutions aux meilleur coût, de connaitre les ordres de grandeur, de connaitre que des choses existes, de faire des choses qui marchent bien.

Force toi à recoder ce genre de chose, à explorer des katas ou des algos différent de ceux bateaux qu'on t'a appris et tu verras que ca risque de te faire le plus grand bien à moyen terme.

Le monde bouge, les structures de données aussi.

C'est quelque chose qui se retrouve que tu mette 1h de plus ou moins qu'un autre là dessus n'est pas très important

Franchement y'a un moment où on ne parle pas d'une heure. Mais simplement de la capacité à le faire, de savoir que les choses existes et d'être capable de transformer une publication en dans code pour ton besoin.

Quasiment toutes les structures de données sont disponible d'une façon ou d'une autre pour un langage donné, et souvent optimisées par rapport aux particularités dudit langage.

Il faut aussi faire attention à ca. Évidement on commence par utiliser les trucs standards quand c'est possible pour aller vite et identifier ce qui va poser problème ou non (approche type balle tracante).

Maintenant dès que tu t'intéresse un peu à ce que tu fais ou que tu es dans un contexte un peu différent de "Je pisse du code pour la webapp lambda" tu tombes rapidement sur des trous ou des choses qui méritent un peu d'attention.

Exemple débile d'hier: trier une liste d'entiers selon un comparateur adhoc en Java. Bha ca n'existe pas. Du coup j'ai trois solutions:

1. Je trouve quelque part une dépendance qui fait ca. Mes clients vont être content et moi aussi, un truc de plus.
2. Je converti mon int[] en Integer[] ou en ArrayList et ma consommation mémoire fait mini x3 sans parler de l'impact sur les perfs.
3. Je comprends les caractéristiques de l'objet que je manipule. Je connais les outils algorithmique à ma disposition. Je peux écrire en une à deux heure le code du tri adapté à mon besoin. C'est dommage que ce ne soit pas built-in mais ces deux heures vont me faire des heures à l'exécution et gagner des Mo de RAM pour aucun autre coût que ces deux heures.

En pratique tu tombes très souvent sur des cas comme ca. En Java 6 String.split passe par des regex même si tu utilises un bête char comme délimiteur. Ca me coute 20% de mon temps d'exécution ? Je prends 1h pour le réécrire. L'UX n'est pas contente de l'highlighting de mot faire par Solr ? Je désactive et je le recode avec d'horribles algo sur les chaînes de caractères etc.

On utilise les outils qui existent quand c'est possible, mais on n'hésite pas à mettre les mains dans le cambouis quand c'est justifié. C'est une histoire d'équilibre, comprendre ce qu'on manipule et essayer de faire le choix le plus judicieux à court et long terme.

C'est justement la forme qui me pose problème. Avancer ca comme une méthode avec des règles, plutôt qu'en conseil me semble contre productif.

Par exemple, dire que couper le flux d'exécution par des return sur les conditionnels ou éviter les flux parallèles aide souvent à la lisibilité me semble une bonne chose. Par contre la facon de le dire me semble aller trop loin.

Il me semble que la cible du truc n'est pas forcément ceux qui ont beaucoup de bouteille, ce sont des choses relativement simples et banales, et la facon qu'ils ont de le dire peut faire du mal sans recherche d'équilibre.

Je suis tombé (ouille) sur cet article vraiment intéressant, sur une façon de (bien) faire de la programmation par objet : Object Calisthenics.

Je suis assez dubitatif. Ce sont, il me semble, des règles de bon sens, mais les utiliser comme pratique me semble assez ardu.

Je bosse actuellement sur l'implémentation de ca, algo page 8. J'ai un peu réfléchi comment je ferais en suivant "bêtement" les règles. Je n'arrive pas à être convaincu d'un quelconque progrès…

L'auteur de cette article propose de savoir écrire les yeux fermé des algo comme A*, des parcours de graph et autre algo de trie. La facilité de faire cela serait un bon moyen d'être embauché.

En France non. Autrement cela me semble assez vrai vu les différents entretiens que j'ai pu faire.

En fait le truc c'est d'être capable de démarrer rapidement à froid et de garder la gymnastique que tu pouvais avoir à la fac. C'est certe un exercice très artificiel, auquel je suis mauvais, mais ca paie aussi dans la vraie vie. Dès que tu as besoin de faire un peu plus que manipuler l'API standard (mauvaise performance de l'implémentation par défaut, overhead mémoire, faire juste job qu'on te demande etc.)

Mais quel informaticien écrit en moyenne par mois, de tel algo ?

Écrire du code avec ce genre de gymnastique, cela m'arrive fréquemment alors que je dev majoritairement en Java.

Personne ou presque. Un codeur passe son temps à architecturer du code, prévoir plus ou moins l'avenir, revoir les besoins du "clients", debuguer. Mais certain aucun temps à faire ce genre d'exercice.

C'est vrai. Le reste c'est extra bonus pour ceux qui font du code qui doit répondre à un besoin précis et pour lequel optimiser quelques trucs après mesure à un sens par rapport au coût de dev (hello big data, langage à la con où le boxing des types primitifs est hors de prix ou bibliothèques largement réutilisées).

Regarde un peu ce qui est open-sourcé par Google, Twitter, Linked-in et tous les autres. C'est bourré de choses de ce genre par ce qu'on en à besoin et que les runtimes standards ne fournissent pas ce qu'il faut.

Concernant les structures de données, il ne sert à rien d'avoir des collections complexe pour des tailles inférieurs à 100. Le O(1) cache souvent un cout fixe énorme, il ne faut pas jeter trop vite les bon vieux tableaux ou liste chainé.

Déjà des gens qui comprennent le Big O ca court pas les rues. Si en plus tu essaies de leurs faire comprendre le k ou simplement les choix d'implémentation par rapport à comment fonctionne une machine, ca va faire beaucoup. Ils pourraient du coût être amené à écrire le genre de code dont on parlait ou comprendre qu'en réécrivant 15 lignes ils diminuent par 10 la conso mémoire ;)

Ouai c'est comme dire aimer faire du vélo et se faire traîner sur une remorque derrière une caisse par ce que "j'ai pas le temps faut que je roule à 90km/h" !

Quand tu es moins jeune, coincé entre le métro, le boulot et le manque de dodo, tu as moins de temps,[…] Donc tu tentes deux fois la quête, et tu es prêt à payer pour passer à un niveau pour profiter d'un nouveau décor/avatar/etc.. Et si tu peux payer pour avoir l'épée du destin qui permet de marraver la gueule au premier troll venu, alors tu payes avec plaisir.

En même temps si ca te fait chier de jouer et que tu as l'impression de perdre du temps que tu n'as pas ou qui pourrait être mieux utilisé j'ai une solution pour toi ;) Et en plus elle ne coûte rien.

D'ailleurs je l'applique…

Moi je te parle de détecter des corruptions sur la source ou la destination afin de ne pas se retrouver avec un fichier corrompu suite à la suppression de la dernière copie intègre (que ce soit en purgeant l'incrémental, en faisant une réinstallation ou autre).

Un système de fichier moderne en est capable, seulement sous Linux je jouerai pas encore avec vu que mon but c'est de pas perdre de données…

J'ai pas envie de me prendre la tête à rajouter encore un nouvel outil, devoir découvrir les fichiers sur lesquels appliquer le truc ou autre. L'heuristique même mtime des deux côtés mais checksum différent lève la plupart des cas. Normalement ca devrait être au FS de faire ca, en attendant on patch.

J'avais POCé le truc il y a longtemps avec rsync en mode checksum et itemize-changes. Tu peux parser la sortie pour trouver les fichiers dont le checksum à changé mais pas les dates de modifications. Ca pue donc le bit-flip quelque part et tu peux lever un gros warning.

Après on aura peut être un jour un FS stable et largement dispo qui gère ca… Si tu l'as côté client et serveur t'es assez peinard.

Sinon il y a plein d'autres problématiques bien chiantes à mettre en œuvre:

Pour le web, si tu travailles proprement et que tu reposes sur des outils qui n'ont pas été conçu par trois pelés dans leur coin ca marche assez facilement. Faut juste faire attention à ce que tu fais, et remonter ce genre de problématique aux designer/UX quand ils partent sur des voies qui vont poser problème. Mais le boulot est déjà bien prémâché.

Pas d'expérience dans le client lourd mais ca doit pas être plus méchant.

Ah le bonheur de travailler sur des trucs où tu dois supporter 50 langues, 10 calendriers, et comme on est sympa on localise aussi les DSL hein ! Histoire de bien foutre la grouille.

Tu pariais dessus ? On fait des trucs pas mal avec les graphes, surtout quand on a quelques années pour les analyser.

Il est surtout très con puisque toutes les transactions sont publiques… On a vu mieux pour le blanchiment ou autre.

D'ailleurs qui voudrait d'un tel système ? Mafia ou pas.

D’après des benchmarks, le Rust peut être très proche des performances de code C++ :
http://pcwalton.github.io/blog/2013/04/18/performance-of-sequential-rust-programs/

Les benchmarks pour ce genre de chose c'est généralement du flan car tu ne compares ni du code standard, ni des problématiques standards, ni une approche standard.

Ton premier lien il désactive l'auto-vectorisation de C/C++ pour faire sa comparaison. C'est sur que si tu coupes une jambe à quelqu'un il court moins vite !

Dans 90% des cas tu peux t'en foutre, moi la semaine dernière après avoir optimisé un bout de code tout bête en Java (je lui ai mis presque un facteur 100x) je dois me résoudre à ce qu'il soit 10x plus lent que la même chose en C++ en -O9 par ce que HotSpot n'est pas capable de vectoriser le code alors que GCC si. Si je désactive le SIMD du compilo C mon code Java est plus rapide que le code C. Quelle est la conclusion ? Java c'est lent ou c'est rapide ?

Si tu sors de ces cas spéciaux en pratique ce qui limite les performances d'un langage c'est surtout sa conception et ses libs standards. Quand j'écris du code CPU bound dans un point chaud le code viol 95% des règles que j'applique dans tout le reste du code.
Il n'utilise pas du tout les mêmes outils non plus.

Si le range te pose soucis regarde du côté de subdelayrange dans la conf.

Il n'a pas demandé à ce que ce soit certifié à ma connaissance. Mais que le mec qui vend quelque chose endosse une responsabilité plutôt que de tout envoyer vers /dev/null quoi qu'il arrive et quelque soit la merde qu'il vend. La comparaison est foireuse mais on choisi toujours celle là, personne n'a prouvé que ta bagnole ne déconnerait jamais, par contre le constructeur à une responsabilité en cas de mauvais engineering, mauvaise réalisation ou mauvis approvisionnement.

Après les implications sont complexes mais ce n'est pas forcément con. Par contre ça risque de pousser vers des solutions encore plus clé en mains ou on te balance un package et que tu sors de garantie dès que tu changes un octet ou une barrette de RAM… Bref remettre les contraintes du monde réel et du matériel dans un monde ou la seule limite est les personnes et leur imagination.

Bon après d'une manière générale quand tu as gouté aux certifications et support vendeurs tu pars directement dans l'autre direction par ce que ça ne t'apporte que des contraintes pour à +/- 0 en retour. Alors que les petits codeurs à côté te filent les infos dont tu as besoin ou te sorte un début de patch en 12h quand tu leur parles correctement…

Bon bin j'ai rien dis ;)

Pour l'API article view elle n'est pas publique et réservée aux partenaires: http://getpocket.com/developer/docs/v3/article-view

J'ai besoin de la synchronisation multi-client pour les RSS donc je ne suis pas intéressé par ton appli. Mais même si tu es capable de le faire dans l'appli ajouter le support de service tel que pocket (ex. read it later) est une bonne chose.

Perso je parcours rapidement les flux pour identifier les articles que je veux lire (5 à 10 minutes par jour), et je les enregistre automatiquement dans read it later. J'utilise pocket qui me sert à regrouper tout ce que j'ai à lire pour quand j'ai du temps. Un fois que c'est lu soit je supprime de pocket, soit j'archive pour moi, soit j'ajoute un taf dans pocket puis archive et ca part directement dans mon flux de veille techno.

Avoir le support dans ton appli et pouvoir utiliser un service externe n'est donc pas redondant ce sont deux cas d'utilisation différents.

Si si l'option est la: "Je ne travaille pas dans l'informatique ni dans l'enseignement ou la recherche" (par contre je me tripote bien la nouille)"

Ouai vive les mecs qui bossent du lundi au mardi par ce qu'après faut pas déconner on risquerait de casser la prod pour le WE.

Vive les mecs incapables de faire confiance aux SE et qui ont donc une peur bleue d'opérations bégnignes dès que ca sort des softs avec lequels ils ont l'habitude de travailler alors que c'est objectivement la meilleur solution pour tout le monde.

Vive les mecs qui s'inventent du travail par ce qu'ils sont resté en 1990 alors qu'ils pourraient absolument tout automatiser.

Vive les mecs qui pensent que faire des recettes dans leur coin deux jours avant la prod sans rien comprendre au business ou à l'intégrité métier à un quelconque intêret.

Vive les mecs qui auront compris d'ici 10 ans l'intêret de bosser en amont avec les SE et de la continuous delivery qui leur permettrait à la fois d'avoir un meilleur service et de faire du job intéressant plutôt que de passer leur temps à essuyer les plâtres et à faire 1000 fois la même chose.

Mais soyons honnête la prod c'est comme les romanos et les putes, y'en a des biens.

Bisou on vous aimes quand même ;)

sans que cette entreprise ne démente clairement depuis, juste en évitant de répondre à la question à chaque fois qu'on lui demande la source des données?

Ils disent clairement leurs sources de données sur leur blog. http://blog.qwant.com/qwant?lang=en

En gros pour le moment ils ne gèrent que le social. Pour le reste c'est du repompage de service tiers.

mais de là à dire que l'on est mieux protégé avec Facebook ou Google

Tu ne peux pas être moins bien protégé.

Joue un peu avec firebug et autre et tu verras la masse d'information que Qwant donne à Twitter, Google (via Youtube et Analytics), Shopping, FB. Dire le contraire c'est juste une blague.

Maintenant c'est pire par ce qu'ils sont même pas capable de mettre du SSL du coup non seulement leurs amis sont au courant mais n'importe qui qui se trouve au milieu.

Et enfin réflechi à long terme. Comment le site se finance ? C'est facile de dire qu'on ne log rien sur les utilisateurs quand on en a 5 et qu'on a pas besion d'avoir un modèle économique viable. Mais à long terme ca donne quoi ? Non par ce que le refrain du "on garde juste les données permettant de fournir un meilleur service" c'est exactement ce que reproche certains aux grosses .dot. C'est juste qu'ils sont incapables d'en faire quoi que ce soit actuellement ;)

1. Non ce n'était pas trop dur de mon temps. Loin s'en faut, je trouvais déjà le niveau très bas. Pourtant il s'agissait d'un très bon endroit.
2. Il s'agit d'une observation à court terme. Pas que cela ait baissé lentement depuis 40 ans, mais en quelques années les règles du jeu ont l'air d'avoir changées.
3. Les témoignages sur lesquels je base mon opinion me semblent avoir un poil de recul, c'est leur boulot, et ne disent pas plus qu'ils doivent depuis quelques années de laisser sortir des assistés incapables je m'enfoutiste (pour caricaturer un poil).
4. Les programmes d'info n'ont pas beaucoup changés ces 10 dernières années ;)

Maintenant je vais m'arrêter là, car nous ne serons jamais en mesure d'aller plus loin !