stopspam a écrit 695 commentaires

grasse, en grende parti, a la KliT de c komentR et a labsense 2 fotes

Mon chouchou, riotjs, est simple :

• la séparation entre html et javascript est claire et propre
• et donc pas de nouvelle syntaxe à coucher dehors à devoir apprendre
• le petit guide et les différents exemples du site officiel se suffisent à eux-même pour comprendre l'ensemble de la bibliothèque

et pourtant puissant :

• routing
• templating
• event handler
• pas de besoin de plus ;)

bref, après quelques tests on l'adopte vite et c'est difficile d'utiliser autre chose (angular, react, polymer, barbone…).

Je trouve que c'est beaucoup de moyen pour si peu de mort…

Je suis d'accord. Le lobby de la route est très puissant, notamment les associations qui passent en prime time et nous sortent des mesures à la con déduites d'études faites au doigt mouillé.

On nous casse les bonbons depuis des années avec les barres symboliques : j'ai connu l'objectif -8000 morts, l'objectif -4000… Je n'ai jamais compris pourquoi le chiffre était exprimé en nombres de morts et non en pourcentages du nombre de conducteurs. En fait si je sais pourquoi…

3000 morts par an quand même

Je faisais allusion à une réplique de Valls.

3000 morts par an

quand même

ça coûte de plus en plus cher, au fur et à mesure.

Le fraudeur s'en fou : l'idée, c'est que ça lui coûte moins cher que de payer les impôts/taxes de son territoire de rattachement.

C'est de moins en moins facile d'être anonyme,

Les flux d'argent sont de plus en plus maîtrisés et globalement pour des choses comme Panama Papers

Moi ce que je vois, c'est que je suis limité à 1000 € de paiement liquide quand les "adhérants" de Panama Papers planquent leur fric et l'utilisent comme bon leur semble.

il y a des malfaçons dans les banques qui ont obligations de vérifier ce genre de choses (elles doivent tracer l'argent qui pars ou qui arrivent d'endroit chelou)

Tu viens de provoquer le fou rire de tous les banquiers d'affaire et des ministres des finances.

Je ne suis pas javaïste, je suis CSharpiste (donc un langage contaminé pour reprendre tes propos).

Pas de bol pour toi alors si dans les quelques langages dont, je ne suis pas au bon niveau, c'est le ressenti que j'ai.

Et bien franchement, j'ai presque envie de dire que c'est la base… Et je ne vois pas en quoi c'est gênant. Pareil, il faut que tu m'expliques.

C'est donc que tu n'as lu entièrement mon premier post :

2.je recode de manière plus chiadée (héritage, interface…) uniquement si : moi ou un de mes collègues risque de l'utiliser plus tard.

Je n'ai rien contre l'utilisation des concepts de base d'un langage d'autant plus si tu travailles à plusieurs et que tu dois exposer des fonctionnalités. Pour autant, je ne vois pas en quoi c'est mal d'utiliser directement une classe sans devoir SYSTEMATIQUEMENT interface/implement/extend.

Les extrêmes c'est une chose, il y a ensuite tous les autres cas moins clairs.

Je n'ai jamais dit le contraire, je suis parti d'un cas particulier qui pour moi était l'overengineering flagrant.

Tu ne semble pas comprendre la subtilité du problème.

Je ne suis pas expert du noyau pour autant je comprends l'overengineering comme étant "utiliser un bazooka pour tuer une mouche". En ce sens, je sais reconnaître les extrêmes pour un projet donné et un langage que je maîtrise: un code trop complexe pour ce qui doit être fait et un trop simpliste qui ne supporte pas léger changement sans tout casser.

Ou alors l'overengineering n'est réservée qu'aux ingénieurs et je suis effectivement trop bête pour comprendre la subtilité.

Comment faites-vous pour ne pas trop en faire ?

Tu devrais t'adresser plus particulièrement aux développeurs java qui ont juste inventé le concept. L'infection s'est propagée chez les autres, C# en tête.

Désolé les gars mais quand je vois une classe qui :

1. utilise des setter/getter à tire-larigot quand bien souvent un attribut suffit.
2. hérite de classes multiples
3. qui implémentent elles mêmes des interfaces

Je me dit que le mec n'est pas assez efficace ou vaut bien faire trop tôt, de la même manière qu'il ne faut pas optimiser son code trop tôt.

Je préfère le concept de l'implémentation naïve, cité dans le journal :

1. je crée ma classe jusqu'à temps qu'elle fasse le job de manière propre mais sans prise de tête.
2. je recode de manière plus chiadée (héritage, interface…) uniquement si : moi ou un de mes collègues risque de l'utiliser plus tard.

À celui qui :

1. crée une classe.
2. crée l'interface sans savoir si ça va servir.
3. crée une classe de base qui implémente son interface parce que c'est dans la logique.
4. modifie sa classe en (1) pour qu'elle hérite de (3).

Tout ça pour une fonctionnalité sur laquelle il est le seul à travailler et dont il n'a aucune visibilité (one-shoot ?). Si c'est pas de l'overengineering…

Tellement neutre que le pékin moyen va croire a du braille…

J'aurais préféré quelque chose qui soit plus reconnaissable sans tomber dans le cliché (masque de guy fox, matrix… comme cités plus haut).

Si je ne me trompe pas, un hackeur est un bidouilleur. Alors même un petit bonhomme avec un clé à molette ça serait déjà plus simple à comprendre ?

TechnoHipster - NodeJs, Electron

Vu tout le battage médiatique avec NodeJs, on se demande si c'est pas devenu mainstream… Et ceux qui utilisent un langage serveur, ce sont eux les technohipsters.

Rapidité

sxfglkjsrg (je me suis étouffé)

Genre « Je suis ravi de mes précédentes rétro-commissions de la part de Cisco, et je suis impatient de toucher celles de mon prochain projet de ville connectée ».

rétro-commissions pot de vin

on te vend "full-web"

Ça a été le plus grand foutage de gueule pour te faire passer racheter obligatoirement la nouvelle version.

Vers 2009, de nouveaux éditeurs ont mis en avant le fait que leur soft fonctionne simplement avec le navigateur. Puis ça a été une course pour les vieux de la vieille à celui qui allait sortir sa version web. Et là, on a eu droit aux 2 cas d'écoles en matière de gestion de projet :

1. Ceux qui en avaient une grosse et qui ont réussi une réécriture from scratch en web en moins de 2 ans (j'en connais 2 ou 3 pas plus).
2. Le reste, 90% d'éjaculateurs précoces, s'est vautré. Toujours la même technique : le bon vieux contrôle ActiveX qui lance l'ancienne appli en client/serveur. "On vous livre l'application fullweb, module par module".

On est passé d'une appli lourde qui satisfaisait tout le monde, à un monstre en fullweb qui faisait chier tout le monde. J'ai repris de volé quelques commerciaux lors des démos quand ils parlaient de fullweb.

CEGID n'est pas un vrai éditeur, il ne crée pas de logiciels mais se contente de racheter des logiciels de gestion existants

J'ai bossé 4 ans avec Civitas jusqu'à le connaître par coeur (db, gestion) et j'ai subi le rachat renommé en Cegid Public. Grosse période à vide avec un soft qui régressait en terme de stabilité. Je ne sais pas si Cegid a taillé dans les effectifs des dév… Ils se sont améliorés vers la fin quand bon nombre de clients partaient à la concurrence qui proposaient ces amélioration depuis déjà plusieurs années.

Les administrations françaises sont fortement équipées avec des produits CEGID, pour des raisons commerciales et sûrement aussi politiques.

Je peux même te préciser :

1. raisons commerciales : le code des marchés publics, on peut se demander s'il ne fait pas plus de mal que de bien…
2. sûrement aussi politiques : les délais. Souvent le délais imposé à la migration vers une nouvelle solution exclut tout développement en interne ou via la base d'une solution libre. Ce qui fait qu'on passe par un éditeur (1).

Le choix de tels outils est suicidaire à long terme, les clients n'ont aucune maîtrise de leur système d'information.

Ça dépend ce que tu appelles maîtrise ?

• Jusqu'à présent les gros éditeurs se connaissent entre eux et assurent la reprise des données depuis un concurrent.
• Moyennant un peu d'huile de coude, on arrive toujours à comprendre la logique de la base de données et donc partir sur une solution perso ne pose généralement pas de problèmes.
  

Sur la durée du contrat, je suis d'accord, on est pied et poings liés à l'éditeur en terme d'évolutivité ou de corrections de bugs.

vu le titre provocateur, je n'ai pas pris la peine de lire ton journal en entier et me suis arrêté aux 2 premières lignes. En tant que commentateur moyen, j'ai simplement moinsé ta bouse en laissant donc un commentaire sur lequel tu pourras te défouler, comme convenu.

autant pour moi

Personne n'a cité celle là Google Search Link Fix.

Pourtant rien de plus énervant de voir google me rediriger lui-même vers le bon site, qu'elle perte de temps, sans parler du tracking…

SQL server est quand même un jouet

Microsoft disait ça de Linux avant, c'est drôle de voir d'anciennes vannes ressurgir. Ce que tu appelles jouet, je l'appelle le meilleur SGBDR du moment. Les dba PostGReSQL vont me dire que SQL Server n'est pas libre, je leur dirais que ça ne rentre pas en ligne de compte pour savoir qui est le meilleur. Les dba Oracle vont me dire que c'est moins puissant que leur usines à gaz, je répondrai que la profession de dba oracle est en train de mourrir au profit de dba tout court.

coincé entre MySQL/mariaDB d'un coté, puis Oracle/MongoDb/Cassandra/redis de l'autre.

Oulah… Je pense que SQL Server taquine Oracle depuis quelques années maintenant et qu'avec une pente d'apprentissage bien plus faible ça va continuer. Ça ne veut pas dire qu'on ne peut pas faire de traitements complexes.

et pour info, bower a encore moins à voir avec la choucroute, c’est pour le frontend, et c’est aussi utilisé dans des projets faits en PHP

bower est marqué en pré-requis dans ce journal c'est donc un nième outil à installer.

Faudra m’expliquer la différence fondamentale entre https://github.com/symfony/symfony/blob/master/composer.json et https://github.com/expressjs/express/blob/master/package.json pour appeler l’un usine à gaz et pas l’autre.

Il n'y en a pas puisque c'est la même chose. J'ai parlé, par exemple, d'un CMS : il peut très bien utiliser symfony (donc d'y dépendre) mais va assurer sa propre mise à jour de manière autonome…

Tu vois sincèrement pas en quoi un projet qui utilise un ORM connu et largement testé comme Doctrine aura beaucoup moins de chances d’avoir des SQL injections qu’un projet qui décide de faire toutes ses requêtes SQL à la main

Non, je ne vois toujours pas de rapport entre le nombre d'utilisateurs et les risques de sécurité. Il y a un ensemble de facteurs (complexité du projet, taille du projet, qualité technique du codeur…) mais celui-ci tout seul n'en est pas un !

Tu confonds un utilisateur/testeur avec quelqu'un qui :

• va effectivement auditer le code
• a les connaissances techniques pour trouver des bugs (failles incluses)
• va les remonter UPSTREAM

Les récents événements ont montré que même les librairies les plus utilisées ne sont pas exemptes de bugs/failles depuis des années, elles ont "autant de chances" (pour reprendre ton expression) d'en avoir :

• openssl tellement secure que forké en libressl,
• debian : on se rappelle tous du petit problème de génération ssh
• glibc
• rails : qui se vantait d'une protection native des sql injections et s'en est mangé une monstrueuse il y a 2 ans…

A côté de ça, le stagiaire de ma boîte a peut-être fait toutes ses requêtes SQL à la main mais c'est de bonne qualité et sans sql injection. La qualité d'un projet ne dépend pas du nombre d'utilisateurs.

Tu veux dire, le temps où chacun réinventait la roue de son côté, de préférence carrée en apportant son lot de trous de sécurité (XSS, SQL injections, local/remote file inclusions) et ses correctifs douteux (magic quotes) ?

Ça n'a rien à voir. Là tu parles techno alors que moi, si je fais abstraction du fait que je n'aime pas node, je parle d'un problème de packaging (facilité d'install, mise à jour) mais plus globalement de "lourdeur".

Tu te rends compte que pour exposer ce service REST, je dois me manger git/node/bower et pour chacun d'eux peut-être des dépendances supplémentaires qu'il va falloir que je gère sur le long terme. Ensuite viens encore l'application qui va elle-même me demander d'installer des librairies complémentaires. Et puis mon appli nodejs, je ne suis pas assez tête brûlée pour la mettre en 1ère ligne et vais sûrement la mettre derrière un apache/nginx.

Si je compare à une bête appli PHP : je décompresse le zip sur mon ftp et l'appli juste marche et se met à jour (prend n'importe quel CMS largement plus compliqué que firefox-sync).
Au passage, je ne vois pas le rapport entre réinventer la roue et les trous de sécurité. De trous de sécurité, il y en a partout même sur une bibliothèque un peu utilisée.

Après si c’est ton trip tu peux très bien faire du node sans npm et 0 dépendances en réécrivant tout toi-même avec amour, la technologie de base n’a pas grand chose à voir avec ça. Dans le fond j’ai du mal à voir en quoi express est plus usine à gaz que symfony.

Non c'est pas mon trip de recoder, simplement node ne passera pas par moi. De toute façon Firefox-sync a déjà subit des réécritures dans 3 langages différents (PHP, Python, Node). Mozilla est encore pire qu'un chevreuil en rut en plein mois d'août : il saute sur tout ce qui bouge. J'attends juste qu'ils passent à ASP.NET Core et là j'installerai ;)

node

Je me suis arrêté là, je fuis cette technologie comme la peste. Pour moi, c'est du même temps niveau que Java ou Oracle qui sont des usines à gaz dans leurs domaines respectifs.

Il est où le temps ou un simple serveur LAMP faisait l'affaire, sans les 15.000 dépendances utilisées et un gestionnaire de paquets propre à chaque couche (OS, langage de l'appli…).

Au hasard d'un commitstrip, j'ai appris qu'il existait une stack MEAN… Putain, si à 18 ans t'as pas développé sur MEAN, t'as raté ta vie de stagiaire !

Si tu développe un module weboob pour pyjobs j'ai un nom tout trouvé ;)

À quand un module Weboob pour pyjob ? :)

Aujourd'hui, il faut reconnaître que Bootstrap s'est pris un petit coup de vieux

Je suis aussi de cet avis mais au final le design, ça va, ça vient. Celui de semantic-ui est du flat design qu'on retrouve dans un des nombreux thèmes bootstrap. J'attends avec impatience la v4…

la documentation doit toujours être à portée de main pour pouvoir s'y référer rapidement. C'est chiant, mais on s'y fait.

Je me suis reconnu dans ces propos. J'ai beau rajouter tous les snippets qui vont bien (dans sublime ou visual studio), j'ai toujours besoin de la doc pour un truc à la con.

j'apprécie la possibilité qu'offre Semantic UI … la quantité de composants fournis

Ce qu'il manque vraiment à Bootstrap se sont ces 2 plugins juste indispensables : select2 et datetimepicker.

par exemple, les sous-menus s'ouvrent sans clic sur l'élément parent

Beuk ! Rien de plus détestable qu'un menu au survol. J'ai un exemple tout simple en tête : sur developpez dot com je balance des noms d'oiseaux à chaque fois que ce put*** de menu s'ouvre quand je lis une actu.

Sur le fond, j'ai un avis contraire à toi : j'ai essayé plusieurs frameworks front-end prometteurs (Pure, Material UI, Materialize) et j'en suis toujours resté à Bootstrap car il me manquait toujours un petit qqch…

Docker, c'est le NPM des applications.

Pensé au départ pour simplifier la vie. En peu de temps, c'est devenu une usine encore plus compliqué à mettre en place que les programmes qu'il empaquette.