Reprise du message précédent :
Je dois exploiter une appli locale développées localement en java par des développeurs locaux.
On m’appelle parce que "ça marche pas". Je regarde la log: en 1h j'ai plus de 40 000 (quarante milles) JAVA NULL POINTER EXCEPTION.
J'envoie un extrait de la log au dev, il me répond "ce sont des erreurs normales, c'est autre chose qui pose pblm"
 
 

putain déjà avoir autant de NPE c'est une blague

  pas de post de ce genre à 16h50

Un coup de fouet par exception.
Arrondi à la dizaine supérieur.

et encore je vous parle pas des autres erreurs ... m'en fout j'avance mes scripts bash, si on me demande ce que j'ai branlé de l'aprem je dirai que je lisais la log mais qu'il m'a fallu 4h pour lire ce qu'elle a craché en 4 secondes.
De toute façon ça sera jamais la faute du dev' alors autant le charger. Je rédige le mail, je met le manteau, je dégaine les clés de la bagnole, j'appuie sur "entrée" et je pars en courant.

man at

 
y'a du   qui se perd  

 
oui je devrais ... mais bon, un clic sous LotusNotes, le temps que les bases se répliquent et que les clients se mettent à jour: personne aura mon mail avant un bon quart d'heure.    
 
Je suis cerné par des applis de merde    

Le problème du dev (et de tout le monde en fait, hein ) c'est en générale la hiérarchie va demander qqchose en visant toujours le moins cher possible.
Donc bah non, tu prends pas le temps de réfléchir forcément à toutes les implications de ce que tu fais. Et au fur et à mesure, t'as un historique long comme la bite de "spécifique".
 
Dans ma boîte (Atos, donc pas une petite SSII), tous les devs sont admins locaux. Je pense qu'on nous estime assez grand pour pas faire n'importe quoi. Et cela se passe très bien.

tu renvoies un "LOL" en taille 72 pis tu fais une regle pour renvoyer automatiquement un "va apprendre a coder d'abord" pour les mails venant de lui.

puis tu changes de boite

edit : et tu nous donnes le nom pour qu'on y aille pas.

Boarf, y'a pas mal de raisons qui peuvent expliquer que l'erreur est pas gérée. Et ils sont peut être en attente de pouvoir livrer le correctif.

C'est pas forcément 100% de sa faute

De toute façon, faut comprendre que globalement on est comme vous, on essaye de faire notre travail au mieux.
Mais entre les contraintes hiérarchiques, du client, du projet, du pognon, bah tu jongles pour faire le "moins pire possible".
 
Quand j'analyse mon code, il y'a plein de trucs moches/à refactoriser/mieux faire/etc, mais je n'ai absolument pas le temps. Et vu que ça fonctionne quand même bah... on me donne pas le temps.

a partir du moment que ca parle "d'erreurs normales", je reponds par des horions.  
 
c'est la chienlit cette philosophie et faut pas se laisser faire

Je dis ça parce qu'on a encore eu exactement ce cas là en PROD ya deux semaines je crois.
Un service externe qui livre sans nous prévenir, vire une info dans la réponse qu'il nous envoi (info à la base obligatoire hein , nommé comme ça dans les différents contrats d'interfaces, etc).
Du coup, des NPE qui arrivent de temps en temps. Comme cela n'a pas "vraiment" d'impact et que la livraison de notre composant coûterait trop cher, on attend la prochaine "vraie" livraison pour embarquer le correctif.
 
Et en attendant on a des NPE "normales"
 
Bon si on en avait 40k/h je pense qu'on aurait pu livrer notre fucking correctif

Personne ne connaitrait les mdp admin par défaut des copieurs réseaux (Konica C253 dans mon cas) ?
Où ceux que peuvent mettre les sociétés de location ?

12345678

Ah tiens, je ne l'ai pas essayé celui-là.
Vu qu'on peut taper les chiffres via le clavier physique mais que pour le reste c'est en tactile moisi, y'a de fortes chances qu'il ne s'agisse que de chiffres.

ou  987654321
ou les trucs qui se suivent sur le clavier etc ..

Ou si tu l'attaques en web c'est Admin/Admin.

 
Jconfirme.

 
C'est un peu plus compliqué que ça le contexte pro.... si on avait des tonnes de fric et des chefs sélectionnés parce qu'ils comprennent bien la technique, oui tout ca serait sous Unix, mais c'est pas le cas du tout.  Le fait que comme je l'ai dit 2 fois, d'autres équipes de dev. tout ce qu'il y a de plus compétents ont galéré à mort devrait vous faire réflechir au lieu de faire les nelson de base.  
 
Quand aux histoire de chemins en dur : je le dis et le repete, le principal problème concerne un produit du public qui met plein de chemins en dur dans les .bat les .config et les .truc , je ne peux rien y faire à part faire des arborescences bien propres et clair quand je l'installe (c'est à dire déjà en évitant de le mettre dans un sous rep  de Program Files : plus le chemin est court, moins on rame à relire)  
 
Bref, arretez de partir du principe que si j'ai des problèmes, c est que moi et nombre de mes collegues codent comme des porcs ...

Ici, on s'arrête là

Ca me fait penser à une fois où j'avais ça en prod., mais sans effet apparent. Mes chefs s'en foutaient donc royalement et en plus le dev était en cours d'externalisation chez CapGemini, mais j'ai pris le temps de chercher d'où ca sortait ( aucune stack java pour aider à comprendre ), donc j'ai quand meme ramé 1j pour voir où ca se passait, j'ai trouvé, indiqué où Cap devait corriger.  (ca venait d'un truc qui foirait dans catch{} mais qui était sauvé dans un finally{} d'où l'absence d'impact)
Le correctif est arrive 1 an et demi plus tard en prod.
Entretemps, on a eu sur le meme serveur d'app des freeze JVM qui avaient rien à voir, mais comme les nohup étaient bourrée de NPE, et que les chefs ont fait intervenir  un espece de cowboy avec une réput de sauveur de crises (qui s est avéré etre un charlatant très fort pour s'approprier le mérite des autres ... il sévit encore d'ailleurs) , ben le cowboy a passé 3j à nous faire chier avec ça, ca qui a retardé d'autant la résolution de la crise    

 
+1000 ( sauf qu en general, le code est pas de moi à l'origine )  
je suis en train de faire une liste de trucs à corriger/améliorer dans le logiciel pour lequel je bosse, j'en suis à une 40aine, je sais parfaitement que d'ici un an y en a aura pas plus de 5 pris en compte, et que d'ici genre 3 ans, ca serait miraculeux que la moitié passent.
Et pourtant, c'est une gène constante dans mon boulot qui consiste entre autre à chercher la source des problèmes ou pondre des specs nécessitant souvent de contourner ces trucs mal fichus....

pas la peine de te réfugier dans le jargon, hein. Vous codez et de temps en temps les admins remettent de l'ordre, voilà tout.

Ben tiens.
 
J attend toujours de savoir pourquoi le fait que les admins me forcent à mettre les trucs dans My Program Files plutot que sur mon E:\  va changer quoi que ce soit aux défauts du logiciel que j'utiliser et qui a des défauts d'exploitabilité à la base ou à la sécurité de mon code. Et en quoi ca va empecher les dev débutants pas sérieux (ou des prestas qui s'en foutent, ils se seront barrés depuis longtemps quand ca posera probleme) de mettre des repertoire versionGege5.8.2 dans l'arborescence, pour citer l'ex. pourri donné plus haut?  

Car UAC risque de se foutre en marche et ne passera pas le premier test avant déploiement de la MAJ.

UAC force maintenant les dev à programmer proprement.
Et ca ca les fait chier, mais cela aurai du être fait depuis fort longtemps !

Par exemple: ton E: peut tres bien etre une lettre d'un lecteur multicarte, ou une clef usb.

Developpe ce que tu apelles "programmer proprement" ?

jvois pas en quoi le mettre dans un sous-rep de programfiles complique la relecture comme tu l'as dis au dessus, surtout si les variables d'environnement sont utilisés... et encore plus pour un developpeur qui est habitué a lire du code.
 
Comment tu fais si y a pas de disque E:\ en prod ? sur le C:\ ?
 
et c'est evident, microsoft a créé une arborescence précise dans son OS simplement pour faire chier son monde...

Non mais de plus en plus, y compris sur certains serveurs (sous windows bouh) le C: est un ram disk (SSD ou autre), et donc tout balancer dans program files devient plutôt une mauvaise idée...
 
Pourquoi d'ailleurs windows a pas utilisé un système à la mac en glisser déposer, c'est rapide, propre, et t'en fait ce que tu veux au moins...

- foutre les fichiers ou ils doivent etre (les programmes avec les programmes, les documents avec les documents, les settings en registre plutot que sur un .ini qui se balade dans le rep windows)
- appeller les bonnes fonctions systeme plutot que bidouiller/faire desactiver les secu du systeme (mention speciale aux applis demandant l'admin local pour tourner...)
- se relire/se faire relire pour eviter les fautes d'inattentions/effets de bord/exceptions non gerées/buffers de saisie/memory leaks
- ne pas compiler en ignorant les warnings
- les erreurs normales, ca n'existe pas ca s'appelle du foutage de gueule

et on doit encore pouvoir en trouver ...

edit :
- le systeme est ton ami, doucement avec les ressources noyau

Je comprend pas ton "ramdisk (ssd ou autre)"    
T'es conscient que ya une grosse différence entre un ramdisk et un ssd ?
 
Et que, si sur un serveur, on installe la partition OS sur un ssd, c'est pas pour que l'OS en profite (non, un serveur ne se reboot pas tout les matins), mais pour que les applicatifs ou les fichiers en profitent ?
Et que, éventuellement, program files, ça se déplace si besoin ?

nan mais meme!
si tu utilises les variables d'environnement, t'en a rien a carer d'ou se trouve le systeme!!
il peut tres bien etre installé sur le Z:\ ta variable elle t'emmenera ou il faut et tu restes dans les clous de microsoft.

J'ai jamais parlé d'UNIX.

J'ai dit que tu avais une application "serveur" sur un"poste de travail" et que au lieu de pleurer sur l'équipe de migration qui a d'autres contraintes que débrouiller vos bidouillages, vous feriez mieux de mettre cette putain d'appli là ou elle aurait du etre : sur un serveur.

Que ce soit installé un windows2000 unLinux ou un XP n'a rien à voir dans le bordel.
 
Quand tu migres un serveur tu tests l'appli, tu regardes les impacts et tu fais gaffe aux contraintes.
Quand tu migres un parc de station de travail tu gères les applis corporates et les demandes de la direction pas les bidouillages de 10 PC d'une équipe font tu n'as jamais entendu parler.

Maintenant si tu préfères pleurer ici et dire qu'on fait les Nelson libre à toi, moi sur mon poste j'ai besoin de putty et RDP et j'ai accès à toute mes applis, un vrai miracle je dois être dans une boite de génies

Chez toi y a {nombre de développeurs} instances de {ton serveur d'application préféré} qui tournent sur tes serveurs de dév?
 

lol.

Tiens, j'ai eu ça y'a 2 semaines : coupure dans la nuit, les onduleurs ont évidemment pas tenus assez longtemps, et tout est reparti correctement... sauf 1 serveur... Un composant de la CM qui a lâché... Je revenais à peine de mes congés paternité, ça faisait bien plaisir...

Non par ce que c'est un fonctionnement totalement stupide.
Mais di c'était nécessaire oui probablement.
Par 1serveur physique par dev mais une instance ou une VM à défaut.

 
bah voila.  
 
Tout est dit.
Il existe depuis longtemps local settings et application data, mais peu de dev les utilisaient.
Pourtant c'etait fait pour.  Microsoft à durci le ton, et les .ini dans PF ou %systemroot%  c'est fini. Ah c'etait la facilité, mais il existait d'autre variable d'environnement.
 
 

et surtout la difference de temps entre faire propre et a l'arrache se rattrape laaaaaaaargement en debug/recette/mise en prod/maintenance
 
mais de la meme maniere que t'as des mecanos ou des platriers peintres qui bossent en salopards, t'as des programmeurs et des chefs de projet en carton qui traitent la qualité par dessus la jambe...

 
Faut pas venir bosser dans ma boite alors . . .  
Le pire reste qu'en tant qu'ex dév (je passe admin/dba) je fait remarquer à mes collègues que si ils sont obligés d'utiliser le compte admin pour des scripts sur le serveur, cela ne les empêche pas de les déposer dans le répertoire prévu pour au lieu de la racine, du %system%,%documents% (merci windows), sans parler des sorties qui se font au petit bonheur la chance.  
Je prie pour qu'un dév essaie 'explorer.exe' comme nom de document tiens . . .
 
Sans compter les dévs futés qui vont 'optimiser' les partages samba (en demandant les accès admin au cdp) et vont râler auprés du même cdp car 'rien ne marche' sur ces 'serveurs de merde'.
 
Encore mieux, les surdoués qui dupliquent sur les schémas standards des tables pour leurs extractions en bdd alors qu'ils ont une base dédiée rien que pour eux . . .
Le dév qui fait de la merde avec le produit, envoie un message à la terre entière (dont le client) pour dire que TU as fais de la merde.  
 
Le top restant les fonctionnels qui font des modifications désapprouvées par l'éditeur lui-même et s'étonnent que plus rien ne marche.