Reprise du message précédent :

 
Tu leurs donnes assez de responsabilités ou c'est juste des engrenages? Perso je les comprends (en tant que dev), si c'est pas un truc que j'ai fait (et par la je veux dire que j'ai au moins décidé de comment le faire), je suis moyen intéressé par l’aumône de mes chefs. Dit autrement, si c'est un truc que j'ai mené j'en parle aux autres avec plaisir; si j'ai juste pisse du code, je vois pas l’intérêt de faire le mariolle devant des cols roses.

Bref ce que je retiens c'est que jubi il est hyper bien payé, que c'est mérité, et que a l'empêche pas de laisser sa mère dans la merde avec les minimas sociaux

oui enfin ca veut pas dire rien foutre hein
 au contraire en fait, il est attendu que tu soit independants, n'attendent pas des ordres ou du micromanagement, soit creatif et que tu hesites pas a apprendre des trucs qui ont rien a voir avec ton poste et tes connaissances actuelles. Ca parait excellent et ca l'est mais c'est pas pour tout le monde. Je suis ici depuis plus d'un an et j'ai vu des gens partir parce que ca manque de structure et que "je suis pas assez technique" ou "moi je veux juste coder".  

euh.. pour moi avoir de la chance c'est exactement ce que tu dis : être indépendant (en fait c'est « autonome » si car sinon tu vas rendre un RH pas content en disant indépendant, je l'sais jlai fait ), être créatif et curieux.

Pour moi les gens qui disent « je veux juste coder » sans apporter plus que ça (idées, point de vue) c'est juste bon à être des stagiaires. Heureusement que je cantonne pas mon équipe à ça !

J'ai eu mon crédit Bourso

 
Le design technique (intégration, archi software, etc...)est totalement de leur responsabilité. On pose les contraintes du projet (date présumée de go live, et enveloppe budgétaire sachant qu'elle est systématiquement sizée sur la borne haute de la preestimation . On accepte toute solution qui tient dans les contraintes.
 
Nous on fournit une spec fonctionnelle, et une analyse des gaps qu'on voit avec la solution actuelle.

Merci Orange pour le passage au Gb

Pour la latence c'est normal, yavait pas de serveur assez rapide pour faire le test sur Lyon

edit : je précise, @ home bien entendu. Au bureau on a un pauv' Miséricable 100/5

 
Bonjour. Je vous saurais gré de bien vouloir aller vous faire foutre. Cordialement.

 
En même temps, je comprend cette réaction
 
Maintenant j'ai l'air con, j'suis tout seul chez moi et j'arrive à saturer mes HDD avant ma bande passante. C'est cruel au final
 
J'suis un peu Bruce Wayne tout seul dans son grand manoir.
 

D'abord merci pour la réponse argumentée.
Ensuite, vu que le seul argument c'est "la syntaxe est pourrie", le VB risque pas de disparaitre de suite parce ce que je me vois bien allez convaincre les manager de mon ancienne boite qu'il faut migrer quelques millions de lignes de codes juste pour avoir une syntaxe plus propre, niveau ROI pour la boite on a vu mieux.

ok, j'ai dit que j'irai me coucher tôt, résultat il est presque 6h, j'ai pas dormi et j'ai acheté 100€ de merdes pour un nouveau projet perso

 
Vous n'avez pas de défauts
 

Attention, un projet ça a un début et une fin

moi dans la vie, je hais les développeurs et j'enfonce les dépressifs, je m'appelle Dion. Et je suis un connard.

A aucun moment dans le post que tu cites je ne parle de migration forcée, juste de choix initial .
Effectivement, quand ça fonctionne et que les équipes en place maitrisent, on ne touche pas.

Après il y existe aussi des convertisseurs automatiques VB <-> C#. Vu que toute la couche en dessous du langage est la même le principe est totalement fiable. Par contre très souvent ces outils sont gratuits, en ligne et limités à quelques fichiers et non à des projets complets (a fortiori de plusieurs centaines de milliers de SLOC).
Dans SharpDevelop il y a (avait ??) aussi un convertisseur de projet, à voir.

Mais évidemment un truc codé immondement en VB ne sera pas meilleur après conversion, peut être même encore plus dur à lire et maintenir.

 
mais non, faut juste tout racheter.    

Je viens de tester visual studio code : pas mal du tout

 
Par contre, ils restent rigolos chez Microsoft. Car ils gardent le nom "visual studio" de manière que les journaleux disent : ouah, zavez vu? Microsoft c'est des gentils maintenant, ils ouvrent visual studio... Sauf que c'est un éditeur complètement différent si je comprends bien. Ceci dit, pour un nouveau produit, c'est bien qu'il tourne partout et je vais le tester.

Ouais pour la partie cross platform faut remercier Electron et Chromium en fait.
Mais ça reste louable Et contrairement à Atom il a l'air assez réactif.

ouais, je me suis fait niquer, je suis dans le C++ en ce moment, quand j'ai vu l'annonce j'ai downloadé sans lire dans les détails. Et à l'ouverture du programme, c'était un peu différent d'un visual studio.

Je suis aussi en train de lire le virtual shield pour arduino (utiliser les capteur d'un tel avec l'arduino notamment) et windows remote arduino
 
Ca + les passerelles faites pour porter ou executer les app ios et android : ms ne s'est pas branlé la nouille

SourceTree, effacer une branche distante : "Cela entraînera des branches à supprimer à partir de la télécommande trop (suppression sera poussé)."
Au top
 

Ah non je hais tout le monde
Et je pense que tu n'as pas la stamina suffisant pour çà parce que c'est fatiguant quand même
 

 
On sent déjà que les mecs ils sont au taquets sur les principes fondamentaux de l'agile, notamment la communication
En fait ils font ça parce qu'ils kiffent passer 10 minutes debout en début de journée ?
 

 
Cette phrase m'a interpellé parce que c'est le type de configuration où on multiplie les occasions de se gaufrer et où il faut une planification et un suivi de malades pour que ça passe (en gros ton job).
Y'a des endroits chez vous où vous avez envisagé de la mise en production continue ? Parce que les projets de x mois ou x années pour lancer un truc c'est bien mais enterrer un peu plus la concurrence en allant plus vite c'est mieux
http://fr.slideshare.net/beamrider [...] approaches
 

 
Curieux. En gros le seul cas où je me vois faire ça c'est si je n'ai aucune fierté vis à vis du projet. Donc que j'aime pas le boulot que j'ai fait.
Très mauvais signe.
 

 
Ouais là y'a un gros souci. J'ai bossé pour un client où c'était la survie de la boîte qui était en jeu.
Les devs ont été préservés tant que possible mais quand une des équipe a merdé, ls DSI n'a pas défendu l'indéfendable : à un moment un pro ça prend ses responsabilités.
 

 
Et du coup il donne quoi ce nouveau manager ?
Parce que vos devs ça a pas l'air d'être des flèches.

La règle de Nraynal de 1 commit par jour, je trouve ça pas mal

J'ai pas trop de soucis de réactivité sur Atom (ça c'est bien amélioré ces derniers temps). Pas testé le machin de MS, mais est-ce que ça peut lutter face à un Atom et sa communauté/activité énorme ? (sans oublier le côté Open Source)

ça risque de se terminer par un "tas de cons" rajouté dans un fichier README.
C'est un peu comme payer un dev à la ligne de code, il va écrire n'importe quoi de façon dégueulasse, pas vérifié et pas documenté pour faire juste pour faire le job qu'on lui demande: pondre des lignes.

 
Euh, c'est pas une règle que tu imposes aux gens, c'est une règle personnelle que tu embrasses toi-même.
Ca n'a strictement aucun sens de vouloir la contourner : soit tu la suis vraiment, soit tu l'ignores.

un peu comme les bonnes résolutions du nouvel an ?  

 
Non mais bien sûr, je parle pas de le faire de manière « industrielle » et conne. Mais genre mon lead dev, il peut passer 3 ou 4 jours à refaire le truc dans tous les sens sur son poste avant « d'oser » commiter un truc (même dans une branche pas utilisé en prod du tout).
 
Moi j'aime pas trop, pour plusieurs raisons :
 

• je sais absolument pas du tout s'il s'en sort (sauf à lui poser la question si tout va bien, ce qui peut être relou)
• quand il sort tout d'un bloc, il faut que je prenne le temps de le digérer
• j'ai pas suivi son schéma de reflexion
• si son SSD crame pour x raison sur son poste, il a perdu son travail.

Bref, commiter régulièrement, même du draft ou même pas du code ! (genre du markdown expliquant l'approche vite fait), ça permet une meilleur transparence pour tout le monde et réduit la communication verbale.

 
Les résolutions du nouvel an c'est de la merde pour deux raisons :  
- comme on veut marquer le coup on fait un changement très important et c'est difficile à tenir
- tout le monde abandonne ses résolutions du nouvel an, pas d'exemple positif
 
Et du coup, "1 commit par jour" ça ne me semble pas rentrer dans la case "changement très important".

Une MEP continue pour le lancement de produits matérialisés?

Complètement. Le "lancement" c'est un flag de config d'un truc qui tourne déjà.
T'as déjà mis en prod graduellement en feature toggle la plupart des trucs.

ça m'est arrivé.

Je l'ai fait parfois, pour pas briser la chaine et essayer soigner un peu mon moral (genre à l'américaine l'école des fans tout le monde est gentil).
Je crois même qu'une fois j'ai trafiqué un commit de 2min.

 
il y a le debugguer et une partie des outils et raccourcis de visual studio, le tout dans une app qui demarre en 3s, et qui charge un projet node  de taille raisonnable sans broncher

 
Oui donc ça peut intéresser un certain public, mais pas moi

ils n'ont pas non plus fait table rase du passé.
L'intégration de git est nickel per défaut, je ne me souviens plus de ce que donne atom ( mais j'imagine que ça doit etre aussi bien)

Briefing Kanban à toute la team (non-techniques). Ça y est, vision globale du flux de travail de toute la boîte sur ma tablette
 
Le rêve

 
L'intégration de Git dans Atom est du niveau de ce que tu peux attendre de l'outil utilisé tous les jours par les mecs de GitHub

Dernier jour de travail du collègue que je remplace, et ça foire en environnement de test, heureusement que c'est pas la prod

J'ai survolé le débat, et ce que je comprends, c'est que les devs de jubijubland sont des tanches et donc doivent être sérieusement encadrés. C'était pas le cas avant, et le fait qu'il l'ait réalisé lui a fait gagner du galon. De toute façon, un projet sans specs préalables part systématiquement en couille, parce que les devs ne comprennent pas le besoin; et d'une certaine manière, c'est triste à dire mais c'est excusable parce que ça n'est pas leur boulot. On est tous passés par là, il faut bien apprendre le métier au début.
edit: ah mais ils ont la responsabilité technique ?

edit: ah, je vois que __alt a la même conclusion, c'est inquiétant.