Reprise du message précédent :

Ah mais on a tout chez Amazon et MS.
Mais les trucs comme Gerrit, Jenkins, go.cd, etc. c'est déployé et administré par notre IT.

le dev en 2016 : 3 jours pour monter un env qui fonctionne, 4 lignes de codes, 18 fichiers de conf

 
Absolument personne, y'aura peut être 1-2 éditorialistes pour le faire, et puis tout le monde s'en foutra. On en parlera un peu dans la presse écrite, un peu dans 2-3 bonnes émissions de radio, blog, podcast, bref, ce que la majorité des gens n'écoutent ou ne lisent pas.
 

Le dev JS, non ?

là je démarre sur un projet ruby et ça se présente pas très très bien non plus. Les anciennes versions de ruby on pas l'air de compiler avec la dernière version d'XCode

pourquoi pas utiliser homebrew pour ton install?

react/redux?

je l'utilise mais je crois que c'est comme node : on installe le manager de version par brew et après on installe la version précise que le projet nécessite.
et le manager de version est un truc qui compile des machins (peut-être pas tout, je sais pas) quand tu installes.

 
#jsfatigue

ça fait des années que c'est la tendance, à base de frameworks qui veulent tout faire tout seuls et deviennent immondes à débugger, non?

C'est assez général : .gitignore,.jshinrc, pacjakge.json, ...  
 
Mais bon il y a aussi des vrais progrès : j'ai bossé aujourd'hui sur un dockerfile depuis une machine Windows 10, et je pourrai déployer ça simplement a peu prêt n'importe où
 

oui et non : aujourd'hui avec un ionic/cordova je peux monter une app android de gestion en quelques heures, une fois les environnements paramétrés ( JAva_home,  android sdk,...), avec du react / angular2 / polymer , je peux vraiment modulariser le frontend ( qui a largement pris du poids ces  denières années), avec angular 1 je peux faire du formulaire brutaux sans transpirer, avec docker je peux déployer mon code sur une machine de dev ou sur un hébergement de manière reproductible

Mais c'est sur que le démarrage est plus long que de poser un index.php dans www sur un WAMP

et puis à la fin t'en a plusieurs dans le même projet des comme ça.
le projet que j'installe a ruby/ror, node, bower, ember/CLI, docker et docker compose dans le merdier.
et tu as un DLL hell à gérer par système.

2eme questions " utilisez vous des stations de vélo : non" suivi de plein de  question sur mon usage  
 
Tu pourrai donner l'objet du sondage

dans les fichiers de confs diverses, il n'y a que babel qui me file vraiment des boutons : ça pète de manière incroyablement imprédictible

madame> faire des questionnaires, c'est un metier

j'imagine qu'être étudiant ça se passe avant de savoir faire son métier ?

ok, je connaissais pas mais c'est comme virtualenv (ou conda create) pour python

meme sur aws

Je dev sur ma SP3 en Windows 10, je teste ça sur un rpi2, et je déploie ça sur des linux. Sans faire de modif  
 
Ca a un côté magique

et sinon commitstrip (re) sort un livre : https://www.kickstarter.com/project [...] oject_link

Pour moi ces machins essayent au final d'en faire trop. Ca tente de transformer notre métier en experts en déploiement de trucs faits par d'autres au lieu des devs qu'on est censés être à la base...tu conçois plus vraiment ton truc, tu suis la recette.  
 
Après c'est sûr que quand tu maitrises les différents composants de ton archi tu gagnes vachement de temps...pendant les 2 ans ou 3 qu'ils sont à la mode. Puis il faut tout réapprendre parce-qu'il y a un nouveau machin qui va encore plus loin, une nouvelle version qui casse tout, ...

en fait docker compose c'est comme le truc de heroku on dirait.

exemple: j'ai "bundle exec rake db:setup" (je pense que c'est sensé peupler la base de données neuve), qui vient de péter parce qu'il a essayé d'envoyer un mail ()

edit: on dirait que c'est l'email de confirmation à la création des users, reste à trouver comment créer des users confirmés directement

 
Pour moi ce sont des outils , à utiliser sur le bon projet    
react n'est pa super drôle pour faire des formulaires, mais bien pour les présenter  
d3 permet de faire des visualisation de fou, mais est overkill si tu veux juste 2 camemberts et un histogramme
 
Tu ne construits plus de zéro, tu assembles des briques. En même temps refaire les couches d'accès au données, la sécurisation des formulaire ou l'auth   . L'expertise sera de choisir les bonnes briques    
 

sauf qu'au moindre problème il faut descendre dans le code des briques et d'un coup t'en a 3000 et tu sais pas comment elles sont sensées s'assembler, et faire un patch de 2 ligne nécessite 30min.

yep
 
L'équivalent est de descendre dans le tas de boue qu'on a construit tout seul dans son coin au fil des années  et patché à coup de " je referai proprement quand j'aurai le temps"

Alors que de mon temps, fallait allouer et détruire sa mémoire à la main, au moins ça avait de la gueule, on voyait bien l'expertise
 
Joke apart, j'ai commencé le dev pro à l'époque de  struts 1, des EJB 2.0... C'était tout aussi relou niveau conf (struts, hibernate et tout le bordel, par contre c'était relativement bien supporté par les IDE (je parle de l'ide d'IBM basé sur éclipse 2.x, mais même éclipse 3.x aidait bien  
 
Je dirais que ce qui caractérise la période actuelle, c'est que ça semble pas très progressif : pour faire un  hello world tu dois embarquer 2mo de lib, 5 frameworks et leurs conf respectives, c'est un peu décourageant et lourdingue. C'est surement pas propre aux outils, tu trouves plus un tuto qui part pas du principe que tu vas scaler ton app sur 60 EC2

Faut pas t'inquiéter, quand la situation sera trop torride, il y aura bien un hiver nucléaire pour remettre les températures dans le droit chemin...
   
A+,

y a https://plot.ly/ pour ca (qui utilise d3 mais simplifie tout)

   
 
les besoins sont plus les meme, maintenant tu dev un truc et tu peux le deployer sur aws et il sera supporte sur mobile ou browser sans effort grace a ces lib. Tu payes le prix au debut et ca evolue vite (donc le support est pas la joie) mais on peut faire des trucs de malades niveau process en meme temps pour des releases rapides, qui fails rapidement sans affecter tout le monde, le systeme de component de react est magnifique par exemple. Pour toi, en tant que PM, c'est magnifique par rapport a avant
quand je vois des boites comme spotify qui ont des trucs en place depuis des annees ( cf https://labs.spotify.com/2014/03/27 [...] re-part-1/ ), on a encore du chemin a faire ici mais ca avance. et c'est en partie grace a une tech stack et des outils qui evoluent.

Mise en prod en cours au ministère...  
 
C'est la fête : dans les modifs, il ya migration JBoss EAP5 -> EAP6 et virtualisation des serveurs, avec aucun chagement niveau DB
 
Ca devait commencer à 22h. Là, ils viennent de s'aperçevoir que les machines virtuelles pour les JBoss ne peuvent pas se connecter sur la DB Oracle.
 
Les mecs, ça fait plus d'un mois qu'ils préparent la mise en prod.. Bien joué.
 
On n'est pas couchés.. Et demain, on reprend à 6h (si on s'est couchés, donc)

ton appli de suivi des bracelets électroniques ?

 
non, une autre, beaucoup plus critique

On est bien d'accord, ce que je dis c'est que tu peux vouloir prototyper sans toute cette complexité au départ
 
Sur notre projet on sait qu'on devra scaler très fort vu la taille finale prévue, donc j'encourage à prototyper vite pour pouvoir tester d'abord le fonctionnel (vu qu'il est pas fixé du tout, je veux pouvoir tester rapidement sans devoir me payer la lenteur d'être toujours prêt à déployer sur 15 data centers azure alors que dans les faits on va d'abord être sur un seul
Ça nous empêche pas de nous y preparer, mais dans mon backlog supporter un déploiement worldwide sur tous les DC Azure ça n'a pas une priorité très grande... Pour le moment

une fois que tu as fait le choix des briques :  un gars passes 2j sur l'env
ensuite le dev va très vite, avec des trucs comme react  hot loader ( tu changes le code en live) , browersync ( tu vois en temps réel les changements sur un smartphone, une tablette et un pc ) , ...
 
Avec la taille d'équipe que tu as, c'est un cout vite amorti. Le cout le plus élevé est la formation des équipes à react/angular/whatever.
 
 

Si je me rappelle bien, db:setup, ça ne fait rien d'autres que jouer toutes les migrations. J'imagine que t'as une migration qui essaie d'envoyer un email.

ouais, y'a des users dans le seeds.rb, et le système essaye d'envoyer des emails pour valider les comptes.

lutain, on y est encore..

prévois du café, et tu peux laisser ton pyjama dans ton sac.

C'est pour ça que ça fait pas mal d'années que je limite le nombre de briques en question. Je préfère prendre quelques briques qui ne cherchent pas à tout faire, mais ne sont pas limitantes pour ce que je veux faire et ne tirent pas elles-mêmes 50 dépendances, quitte à écrire un peu plus de code moi-même. OK, il n'est pas question de réécrire d3 si ce dont tu as besoin, c'est d3. Mais à l'inverse j'ai vu des mecs rajouter une lib de 50 classes pour s'éviter d'écrire deux fonctions.

Après du point de vue des perfs, la perception actuelles est biaisée et c'est marrant comme dans bien des cas on peut avoir des perfs suffisantes si on écrit le truc soi-même pour tourner sur une seule machine, là où la solution paresseuse est de construire l'usine à gaz qui va tourner sur N machines voire le cloud truc. Bien sûr, dans ce cas il faut être absolument sûr de son coup et ne pas avoir peur de poser ses burnes sur la table...

Typiquement le genre de lib dont je parle. Vu ce qu'ils annoncent (API R et compagnie), il y a de fortes chances que ça tire la terre entière. Donc si l'analyse de données n'est pas ton coeur de métier et si ton besoin, c'est d'afficher quelques graphes fixes sur un site web, pour moi ça n'est probablement pas la bonne lib.

 
Je pense que la "nature" (comprendre quelques scientifiques mal intentionnés) vont surtout produire quelques virus qui vont diviser par 2 ou par 3 la pop mondiale déjà...  Et quand je dis "diviser", ça sera diviser surtout dans les pays comme l'Inde ou les pays qui ne sont pas raisonnables en terme de natalité.  
C'est un peu comme l'hiver nucléaire, mais ça abime pas les resources pour ceux qui restent.