Reprise du message précédent :
 

Ah on t'écoute alors.

J'utilise LR 4 qui fait ce que je veux et que je n'ai jamais voulu upgrader, et je ne regrette pas.

Le download du logiciel de musique Reaper tient en intégralité dans 16Mo. Il est écrit en vieux C++, je ne sais plus quelle version du compilateur est utilisée, mais elle a au moins 10 ou 15 ans. Le niveau de fonctionnalités qui tiennent dans ces 16Mo est invraisemblable:
- éditeur MIDI et audio multithread 64 canaux très avancé et performant, multiplateforme
- supporte ASIO, WASAPI, ALSA, Jack audio, etc
- permet le montage vidéo
- scriptable en LUA et dans le langage de script JSFX orienté audio temps réel
- entièrement skinnable, supporte le 4K
- configurable jusqu'au moindre clic souris
- compatible plugins VST, VST2, VST3, AU, ARA, CLAP et d'autres formats ésotériques
- compatible avec la plupart des hardwares dédiés à l'audio
- des centaines de fonctions accessibles par macros ou script ou assignables à des raccourcis
- j'en passe et des meilleures.

2 skins Reaper:

[img][/img]

 
Pour .NET ça a été au point très vite, Visual Studio .Net 2003.

 
Dans l'écrasante majorité des cas, ça ne va pas valoir le coup d'aller taper dans une stack complètement différente pour gratter de la perf à la marge.
A part rendre ton recrutement horriblement compliqué, le jeu ne vaut pas la chandelle pour beaucoup d'équipes.
 
C'est pas une question de "on a toujours fait comme ça" (qui est un non-choix), c'est faire le choix délibéré de capitaliser sur les compétence des équipes, que ce soit côté dev, ops, sécu, etc.

Non, VS 2003 c’est la version qui a ajouté le support des extensions et permis à jetbrains de sortir resharper.
 
Genre le renommage de symboles c’était une headline feature de VS2005.

 
C'était pas trop dégueux pour l'époque.. mais peu de temps après j'ai découvert Code Warrior  

 
Alors qu'un langage transpilé pour le front c'est top
 

Je me demande quels sont les arguments avancés pour dire que c'est bof  

Nous ne sommes que mardi, calmez-vous

J'ai 0 à l'étranger, de mémoire

J'avais testé rapidement le jeu de tennis de table sur Oculus, c'était sympa en terme de sensations.

Tout ce que Tim Cook a à faire, c'est sortir Apple Sports avec du bowling, du golf et du baseball.

Sans le Polo et la Voile je ne suis pas certain qu'il arrive à convaincre les personnes qui ont 3500 balles à mettre dans un truc comme ça

 
Quand tu fais du polo et de la voile, t'as pas trop d'importance à accorder à te foutre un masque sur la tronche pour te cogner dans les bibliothèques de ton salon

Jubi, y'a Google Ads qu'est down

dites, vous savez comment trouver les vents dominants dans mon bled ? y'a un énorme Vercors à l'ouest de moi, donc je suspecte que c'est pas la bonne réponse.

Le site de la Caisse d'Epargne, en 2023 nécessite toujours le préfix "www." pour y accéder

ben ouais il est dans le dossier www, ils auraient pu le mettre dans www3

 
c'est pas bien ça ?  
 
https://fr.windfinder.com/windstati [...] d_grenoble

Ventusky a des données historiques mais ça doit être assez chiant de les collecter.
 
T’as posé la question à la mairie? Ou bien s’il y a des opérateurs d’éoliennes dans le coin ils ont sûrement l’info.
 
Sinon regarder sur météo France, ou les contacter.

 
Je sais que t'es un fan de Java et Kotlin, mais il faut juste admettre que Java c'est pas la joie en serveur web Ca l'a jamais été, et les dernieres itérations ne sont que mollement meilleure.
 
Pour te donner une petite idée (mais bon ca fait des années que je change de boite et c'est a chaque fois la meme chose):
  - 150 process node qui se partagent une seule machine
  - un seul code en Java (lucene) qui en prend 7 a lui tout seul, et qui supporte pas, a 7 donc, la charge des 150 process autour.
 
Ca donne le ton, et ce ton il est contant depuis bien 10 ans maintenant
 
A vrai dire, je crois qu'on a une fois utilisé la commande pour augmenter le max mem de Node? Sinon on s'emmerde meme pas a se poser la question de si l'algo il est perf ou pas. En code "moyen", Node ou PHP bat facilement Java ou Ruby, parce qu'ils sont plus tolérant sur le "moyen" justement.
 
Apres je parlais surtout de la vitesse de dev et de la flexibilité, le web a bcp besoin de flexibilité sur les inputs, et donc de base un language compilé quel qu'il soit...
 
 

 
Je parlais a vrai dire bcp plus de vitesse de dev que de perf a la marge. Ce qui justifie aujourd'hui de réellement se poser la question, c'est le tradeoff que propose les languages interprétés, dans le cas du web c'est une écrasante victoire, ca va plus vite a dev, le web a de gros besoin de flexibilité qui sont problématiques en compilés et c'est pas plus lent en prod.
 
Pour ce qui est de capitaliser sur les compétences des équipes, étant manager depuis pas mal d'année maintenant: ca s'envisage meme sans changer les équipes, et vu que le gain est significatif...
 
Bon par contre ca implique plus d'investissement du manager lui-meme, parce que nouvelle stack = nouveaux problemes. Mais sur le moyen/long terme le gain est tel que ca n'est pas une petite chose a mettre dans un coin
 

 
 
Un truc que j'arrive pas a comprendre c'est que le front end c'est comme si les mecs capitalisaient jamais sur ce qui marche, il faut tout le temps tout réinventer...

 
Faut bien justifier les salaires

https://www.ecmwf.int/en/era5-land ?
J'ai trouvé ça en partant des données horaires de pvgis qui présentent la vitesse du vent.

C'est à dire pas la joie et mollement meilleure ?  
Car bon Spring Boot si tu connais la stack ça va très très vite de dev, de même avec Quarkus.
 

 
Ils font quoi les process node ? Lucene c'est un gros process pas simple, et ça peut prendre de la place si y'a de l'utilisation.
 

Ça m'étonnerait très fort. En plus quel rapport entre Java et Ruby, Ruby c'est déjà pas le plus rapide des langages de script.
 

Ah ok donc c'est une comparaison de static typing avec langage dynamique ?
 

Ben si c'est plus lent en prod. Pour la vitesse de dev je demande à voir.

j'ai trouvé la même chose par google, mais la géographie me stresse un poil :

 
 
Et si t'écris un équivalent de Lucene en JS et que tu le fais tourner sur Node, ça marche aussi?  
 
 

De mémoire, c'était assez nase même à l'époque. Sous windows 95 et après, il y avait UltraEdit comme éditeur potable.

Qu'est-ce que le fuck ? On est en 2008 ?

Perso je l'ai direct MP pour une proposition d'emploi à la COGIP 3LIT3 CONSULTING  

==Stack==
Language: PHP
Database: db.txt

Un Homme écrirait les datas directement dans le fichier source  

Du literate programming + storing.
 
brillant

 
Ah oui ? Et bien ca tombe bien j'ai du passer 30min pour lire le debut de la stack d'Express, c'était il y a 10 ans maintenant et puis en fait j'ai compris que ca servait a rien et il se trouve que ca ne sert effectivement pas a grand chose
 
Java par contre oui j'en ait bouffé de la JSR a la con.
 

 
On a de tout mais la plupart de ces process sont au meme niveau en complexité que le code en Java, certains sont plus simples bien sur, et d'autres bien plus compliqués (IA en Node), donc Java est un process dans la moyenne des autres pour nous. Reste que Lucene est en java, et Lucene reste le standard de l'industrie donc pas le choix (les gens veulent AUSSI les bugs de Lucene - et il y en a).
 

 
C'était pour pointer le fait que interprété ne veux pas dire forcément génial non plus, il y a aussi des languages interprétés naze
 

 
Entre autres, en terme de vitesse de dev et de flexibilité du code, au scope de faire un serveur web et non pas une appli en dur par exemple.
 

 
Le trick c'est que j'ai vu des process Node faire mieux que des process Rust par exemple. Encore une fois Node ou PHP s'en sortent mieux pour du code moyen, je ne remet pas en question qu'un code opti sera plus rapide en Java qu'en Node.
 
Mais en code moyen, quand le mec moyen sort son code, le fait ait que tu auras bcp moins d'emmerdes en Node qu'en Java, et c'est le manager qui parle, pire, mon équipe Node aujourd'hui je la juge un poil en dessous de ma précédente équipe en Java.
 
EDIT: et niveau vitesse de dev node > java, PHP > Java, easy. Encore une fois, mec moyen, j'en ai RAB de parler du top 2% qui connais le language au poil de cul.
 

 
Je connais bien le code de Lucene donc je peux te répondre: c'est pas tres compliqué, le code est convoluted a mort, parce que Java, et les mecs en Java ca aime les classes de classes de classes. Mais sinon il n'y aurait pas de réel probleme a le refaire. C'est juste que c'est parfaitement inutile, puisque ca existe deja, et que mettre plein de serveurs palie au probleme plus ou moins.
 
Dans l'industrie ou j'évolue actuellement, tous les competiteurs (nous y compris) supportent des opérateurs customs, comme "si A est proche de B a moins de 5 mots" par exemple, donc on a bouffé un peu lucene pour avoir ce genre d'opérateurs customs.
 
Et au passage, parce que Lucene est un enfant boiteux dans les languages CJK, oui, on a un lucene in-house custom pour ces languages, en node. A vrai dire, c'est meme un melange d'IA et de lucene-like, puisque le split de mots dans ces languages, se fait mieux en IA qu'en algo/dico de mots.
 
 

 
J'avais dit que je me tirerais les foudres des gens qui savent
 

 
Taille de la BDD actuellement et avec laquelle je me pavane dans mon code node: 50to.
 
Ca fait un gros fichier txt komeme

 
En fait tout dépend de comment t'arrives à la conclusion. Si c'est rétrospectif en observant en gros comment se démerdent les équipes dans les COGIPs, vu que Java est le nouveau COBOL et que par conséquent tu vas y trouver des quantités astronomiques de devs moyens, voire carrément atroces, tu pourrais aboutir à la conclusion que c'est le langage le problème
 
Autant parfois les technos sont immatures et mettent des bâtons dans les roues (y'a 15 ans tu m'étonnes que ça avait l'air plus sexy de faire du Ruby On Rails que du Java EE) autant au bout d'un moment le field s'égalise et la principale problématique ce sont les gens. Et parfois comme les technos font office de filtre sur les profils, ça peut renvoyer des images faussées, genre que Scala/Akka c'est incroyablement mieux que de faire du Spring Web alors qu'en allant sur Scala tu filtres juste plein de devs médiocres.
 
Perso je sais absolument pas sur quelle stack je partirais pour développer un app web aujourd'hui, côté serveur. Et ça pourrait très bien être du Node. Mais pas parce que je vois des technos intrinsèquement plus productives que d'autres.
 
(et sur le débat compilé/dynamique/typage/etc, je rigole parce que t'as plein de monde dans l'écosystème JS qui a fini par se dire "ah ouais un typage plus fort et explicite c'est pas mal des fois" quand il se sont mis à devoir maintenir des codebases de plusieurs centaines de kloc )

 
Nah je pense que c'est mon parcours qui donne ca
 
Deja j'ai été bien plus manager que dev, CEO & CTO le plus souvent, donc ca me donne une perspective tres différente de l'équation.
 
Donc ma vision est a l'envers en fait, les gens ici doivent voir plutot la partie code et moi je passe ma vie dans la partie management et assez peu dans le code (j'en fais encore hein, mais c'est pas mon coeur).
 

Clairement c'est presque ce qui me surprend le plus au final: après 15 ans à supporter des applis web en Python, de tailles assez variées, j'en ai clairement marre des erreurs au Runtime et du temps "perdu" une fois l'app en prod à la maintenir pour corriger des conneries de NoneType error qui auraient pu être catchées avant avec un langage moins permissif.
 
Du coup j'aimerai bien bosser sur un vrai backend en Rust pour voir ce que ça fait (j'ai fais quelques petits toy project perso, mais bon, c'est pas représentatif de vrais projets quoi)
Alors oui, tu vas sans doute un peu moins vite à avoir ton MVP qui tourne en prod en Rust qu'en Python ou RoR, surtout s'il faut former l'équipe. Mais je suis de plus en plus convaincu que pour une appli que tu vas devoir supporter en prod pendant plusieurs années cet investissement initial est très largement compensé par la fiabilité accrue au runtime.

C'est ce que tu crois, de mon XP tu as juste d'autres erreurs.
 
Et pour ce qui est du NoneType, la ou Rust te protege, ca n'est pas le cas de java:
https://stackoverflow.com/questions [...] ava-string
 
Crashera tout pareil...

Je suis d'accord : et c'est aussi un filtre pour trouver des gens motivés

Le choix il dépend énormément de la gueule de ton MVP et de ce que tu veux vraiment tester.
Dans les COGIP ce n'est pas rare que ton MVP ce soit des milliers de jours de dév., il n'est également pas rare que des gens se tirent la nouille à faire des trucs dans des technos sexys ou robustes pour être foutue à la benne six mois après.
(Ressources pour aller plus loin : resume driven development, microservices appliquées aux personnes âgées, Apache Kafka Quickstart)

Après ça dépend aussi du contexte, si l'investissement initial te fait rater le coche c'est un problème, et à cette idée on peut opposer le fait que la migration elle peut toujours avoir lieu plus tard quand la fiabilité devient un problème

Fallait attendre l'an prochain et les 20 ans avant de ressortir ça

Et en startup nation il est pas rare que tu doives pivoter 3 fois avant d'arriver sur un truc qui clique (tu vas me dire en COGIP c'est pareil c'est juste que les pivots c'est des changements de spec random parce qu'un VP veut mettre sa crotte).

Ca va depuis il a trouvé d'autres moyens pour énerver plein de gens  

 
Le null est pas tout à fait une question de type system en Java, mais même si on le considère comme tel, au lieu d'avoir un ensemble assez important d'erreurs de type au runtime, t'en as plus qu'un subset réduit (principalement les génériques si tu t'amuses à faire des trucs foireux). C'est toujours ça de moins.
 
Après à mon sens un des intérêts majeurs du typage fort et un minimum explicite, c'est que ça permet à ton tooling de faire des trucs un peu plus malins que de match des appels de méthode juste sur leur nom.