Reprise du message précédent :
AU boulot on a un trombinoscope du service.
 
Nom, prénom, service, photo type photo d'identité.
Une 30aine de photos, 84Mo. Fichier word.

Un client a une appli de traitement d'images sur son PC. Jusque là, rien que de très normal.
 
Pour une raison encore non déterminée, son scanner diapos a été installée sur un serveur. Qui n'est pas sur le même site géographique.
 
Pour une raison tout aussi indéterminée, le client se connecte en TSE sur le dit serveur.
 
Et de m'appeler pour me demander s'il peut scanner ses diapos depuis son PC.
 
Je lui ai répondu "oui, si vous tendez la main suffisamment loin".

L'intérêt d'installer le scanner du gars sur un autre site, c'est quoi déjà ?

Pour les novices, je propose souvent Fileminimizer (dispo ici)
C'est gratuit et je pense qu'on peux pas faire beaucoup plus simple du coups les users sont content ^^. Par contre je crois qu'il faut faire gaffe aux sélection de "modules complémentaires" pendant l'installation.

NOn mais là il suffit de cliquer sur la première photo qui tombe, faire "compresser" "appliquer à tout" et basta

Alors vu qu'ils sont un tas à devoir scanner, je subodore que y'a un génie qui a cru bon de partager le matériel entre tous les users.
Et qui dit partage dit serveur, c'est bien connu.

En même temps partager un scanner, ou c'est le super combi photocopieur/imprimante qui le gère avec envoi par mail ou autre et c'est bon, ou sinon c'est pas prévu à la base dans les OS donc une machine commune sur laquelle le scanner est installé c'est une solution adaptée, surtout que j'ai toujours vu ça pour des trucs style instrument de laboratoire  

Bah que ce soit un multi ou autre, le poser là où aucun user ne peut soulever le couvercle pour mettre les docs sur la vitre, comment dire...
 
Le gars qui a fait ça peut changer de métier, et très vite.

Ouais enfin dans tout ça, le plus débile c'est quand même le gars qui veut scanner ses diapos sur un scanner qui est juste à 15km de son bureau.
 
Y'a des lundis où on aimerait bien être déjà au vendredi.    

 
et personne pour monter un pauvre site web pour que ce soit plus pratique (déjà pas la peine d'ouvrir word ...)

Ouais, pis c'est bien mieux d'ouvrir IE6 !  

j'aurais dû y penser ... ce qu'on a là et qui est il me semble pas si dur que ça à faire si t'as un peu de moyen (c sur que si t'en es à faire un trombi sous word faudrait ptet que je revoie les prétentions à la baisse), c quand meme vachement pratique parce que ça donne le nom du mec, son site, son intitulé de poste (plus ou moins bidon), et son équipe. de son équipe en cliquant tu retrouves ses collègues et son responsable, et tu peux aller comme ça d'un mec à l'autre, d'une équipe à l'autre et d'un responsable à son N+2, +3 ...

je trouve ça pratique

... jusqu'au moment où tu tombes sur les mecs du dev, qui ont une organisation bcp plus "souple" (qui a dit "bordélique" ?), avec un N+2 qui a en responsabilité hiérarchique directe de l'ensemble de ses troupes. et des N+1 qui changent suivant les projets ...
mr tartempion est N+1 sur le projet X et dev pour mr tartemdame sur le projet Y ...

  M Misato, vous m'avez convaincue.
Fichier->Enregistrer sous-> *.html

Ils sont 30..... à tout casser il y en à un seul qui à les connaissances pour le faire et je suis sur qu'il à des projets plus intéressants en attente.    
 

 
... le pire, c qu'il y a de fortes chances que ça se termine comme ça
 

 
ouais, c ce que je me suis dit après coup

C'est pas vraiment une "phrase" mais pourquoi pas
 
Dans mon ancien boulot, mon "chef de projet", si on peut l'appeler comme ça, avait réussi à inclure cette merveille dans le code de notre application :
 

 
Je vous explique, c'était pour une application de comptabilité, on avait :
Une table écriture (Environ 100K lignes)  
Une table ligne_ecriture (Environ 1M de lignes)
Une table exercices (Environ 10 lignes).
 
Passons sur les immondices genre requête écrite à la mano dans une appli Java avec noms de colonnes en dur etc, l'envoi de requête avec les paramètres convertis en String (parce que rajoutés après avec des append), etc.
 
On parcourt ici un join de 1 million de lignes pour trouver l'exercice code (= une année, genre 2007) maximum (soit l'année la plus récente où il y a eu une écriture, donc). C'est à dire l'exercice courant.
 
Au lieu d'aller simplement dans la table exercice, qui possède une colonne "courant" avec un booléen true/false.

Le plus choquant ce sont les noms de méthodes en franglais je trouve

Aussi, mais pour moi c'était loin d'être le plus choquant.  

 
où ça ?

La dernière, setDernierExercice.

 
Bha non, c'est une convention de setter/getter, rien d'anormal justement

Le français dans le code ça fait toujours bizarre je trouve. Que ce soit les variables, les fonctions ou les base de données.
Dans mon code à part une variable "trapèze" juste pour le fun de pouvoir utiliser des noms de variable unicode en C# j'ai tendance à tout mettre en anglais (puis "trapezium" c'était trop moche).

Par contre pour la remarque la requête et les noms de colonne dans le code, ça ne se fait pas comme ça en Java ?  
J'ai toujours fait ça en Delphi et en C#

C'est une convention mais j'ai aussi toujours préféré le "tout anglais" (même si c'est pas toujours facile quand tu as des entités très "métier", souvent dures à traduire).
 

 
C'est à dire que dans une grosse appli Java, j'ai tendance à utiliser JPA par exemple, pour s'affranchir de la base de données!
 
Tes requêtes sont toutes regroupées, tu travailles avec des Entity (des objets java), c'est plus rigoureux, ça évite d'avoir des requêtes en String en dur éparpillées dans l'appli, entre autres.

 
Ha mais je reste d'accord, par habitude j'ai toujours tout en anglais dans mon code, mais si je tombe sur du code français avec un setMachin ou getTruc à la place de setSomething ou getDummy bha ça choque pas, du moment que le reste est cohérent

Ouais moi je fous tout ce qui est requêtes dans un (ou plusieurs) objets dédiés aux accès DB pour justement éviter d'en foutre partout dans l'appli

Chez nous c'est l'inverse : sur les très gros modèles de données, on fait bien gaffe de ne pas utiliser de framework d'abstraction à la mord-moi-le-zguègue histoire de conserver un semblant de performance ... et aussi parce que sinon, on se retrouve avec des développeurs de 40 balais qui sont pas foutus de faire un DECODE, donc forcément quand faut aller dans la DB pour aller résoudre un problème de production, y'a plus personne
 
Paske bon, si ton modèle s'y prête pas, JPA c'est carrément pas jouable

 
Proc stock + ORM et t'as pas une ligne de SQL dans l'appli hein

1/ Encore faut-il que ton modèle de données s'y prête
2/ Parfois le besoin en tuning ou en complexité de query défie l'entendement
3/ Et avoir du SQL bien centralisé dans son appli ce n'est pas mal  

 
Proc stock et c'est tout  

Ben je parlais de ORM, "proc stock" je vois pas
 
Mais bon bref, je compte plus les brouettes d'experts de tout poil qui sont passés sur mon système, tous convaincus que le SQL explicite c'était mal et qu'ils avaient un framework qui allait bien pour résoudre un problème que je n'avais pas : sans exception, ils en sont tous revenus. On a des besoins très très particuliers, jusqu'à présent on a rien trouvé qui pourrait faire mieux que le full custom.
 
Et comme je disais, pour nous c'est en plus du reste une question de compétence : quand ça merde, on a tellement d'interactions avec tout un tas de systèmes que c'est la DB qui contient la vérité vraie ... donc faut être plutôt affûté en SQL, ce que de moins en moins de devs sont, en grande partie à cause de framworks qui rendent abstraite la couche de données.
 
EDIT : proc stock =  procédure stockées ? Si c'est de ça dont on parle, effectivement on en utilise.

 
Procedure stockée quoi !

Chez moi on dit "stored proc"
 
oué, ben comme je disais on en utilise plein, mais pas pour enlever le SQL du code Java, car si c'est bien fait c'est pas une honte d'en avoir  

C'est toujours une honte d'utiliser du Java. Toujours

J'aurais bien utilisé C#, mais je suis pas sûr que ça tourne sur nos serveurs de prod Linux. Et on a enterré hier le dernier développeur C++ dans le cimetière des langages morts, juste à côté du carré des cobolistes

LE_CODE

LE comme Ligne Écriture

   
 
c'est encore pire en fait

 
C'est cohérent avec le reste
 
Bon, ça reste dégueulasse, mais tout ce que vous critiquez tombe à coté du réel problème