'jour
 
Sous quel terme vous regrouperiez les champs age, height, weight, gender ? Pour un être humain
C'est pas le métabolisme, mais je sèche sur une terminologie exacte.

Sauf que si les gens ne prennent plus les TEC ça va faire une augmentation assez violente du nombre de véhicules mais c'est pas comme si le réseau routier/les parkings étaient déjà saturés dans les grandes villes heureusement.

Donjons et dragons Nan mais personal characteristics moi ça me semble bien

 
biométrie
 
quel domaine métier ?

http://www.sts116.com/img/images/c_1_130717090112.png
 

http://tourdefrance.blog.lemonde.f [...] %CC%81.jpg
 
Et même pas ivre en plus
Merci, Hollande !

Si y'a pas de pace obligatoire c'est gérable, je l'ai fait à 12 ans.

Ouais mais tu construis pas une nouvelle config pour qu'elle soit juste bien aujourd'hui et demain.
Enfin sauf si t'as beaucoup d'argent à y mettre.
Mon dernier bloc CM/proc/RAM il a duré 5 ans. Dans 5 ans c'est pas dit que 16Go ça soit pas véritablement utile.
Puis ça donne de la liberté pour expérimenter des trucs quand on est dev.
 
Effectivement là tout de suite, sur les 16Go j'ai pratiquement 10Go marqués comme "Free" par Windows, soit de la RAM totalement inutilisée.

Toi tu te fais plaisir avec la prime vacances/le 13 eme mois

http://www.sts116.com/img/images/c_1_130717090112.png
 

 
t'utilises trop d'api que tu maîtrise pas    

Je pense pas. A mon avis, c'est plutôt le signe qu'il faut qu'il lache les properties et qu'il passe à une base de données. Un truc stable et réutilisable, bien sûr, genre PostgreSql. Par dessus, il n'a qu'à mettre un Hibernate pour gérer l'ORM, et par dessus, il utilise un wrapper pour garder la compatibilité ascendante avec les properties, genre Spring pour faire de l'IOC. En plus, il me semble que ces frameworks-là sont tous compatible avec commons-logger et jmx pour pouvoir les configurer. Et maven pour gérer les POM et les dépendances, en particulier vis à vis des bonnes versions de Xerces et Xalan.
 

Je pense pas. A mon avis, c'est plutôt le signe qu'il faut qu'il lache les properties et qu'il passe à une base de données. Un truc stable et réutilisable, bien sûr, genre PostgreSql. Par dessus, il n'a qu'à mettre un Hibernate pour gérer l'ORM, et par dessus, il utilise un wrapper pour garder la compatibilité ascendante avec les properties, genre Spring pour faire de l'IOC. En plus, il me semble que ces frameworks-là sont tous compatible avec commons-logger et jmx pour pouvoir les configurer. Et maven pour gérer les POM et les dépendances, en particulier vis à vis des bonnes versions de Xerces et Xalan.
 

Je pense pas. A mon avis, c'est plutôt le signe qu'il faut qu'il lache les properties et qu'il passe à une base de données. Un truc stable et réutilisable, bien sûr, genre PostgreSql. Par dessus, il n'a qu'à mettre un Hibernate pour gérer l'ORM, et par dessus, il utilise un wrapper pour garder la compatibilité ascendante avec les properties, genre Spring pour faire de l'IOC. En plus, il me semble que ces frameworks-là sont tous compatible avec commons-logger et jmx pour pouvoir les configurer. Et maven pour gérer les POM et les dépendances, en particulier vis à vis des bonnes versions de Xerces et Xalan.

 
Tu travailles sur mon projet?

Vala Comme ça hop, tu codes tous tes handlers (et tes factories) en XML et t'as directement accès aux properties dans ton code. L'avenir, quoi.

  mauvaise langue

Ben du coup, y a moins de code, y a que de la configuration en XML. Et ça lui permet quand même d'assembler ses propriétés comme les pièces d'un Lego et de garder la main sur l'évolution de l'architecture. Si demain il a besoin d'aller les chercher sur le cloud via un WebService par exemple.

Ben du coup, y a moins de code, y a que de la configuration en XML. Et ça lui permet quand même d'assembler ses propriétés comme les pièces d'un Lego et de garder la main sur l'évolution de l'architecture. Si demain il a besoin d'aller les chercher sur le cloud via un WebService par exemple.

C'est exactement ça. Je sais même pas quoi répondre quand on me dit ça, car à chaque fois qu'on me répond "mais c'est plus maintenable donc c'est mieux", et ça me cause un brain freeze et une soudaine dépression.

Ba réfléchis, c'est juste un XML à modifier au lieu de patcher du code. Donc c'est mieux, CQFD.

C'est complètement modulaire et scalable, c'est vraiment nickel. Par contre, PostgreSQL, je te trouve un peu léger. Ca absorbera pas la montée en charge si tout le front vient à taper dessus. Un peu d'Oracle ou de Sybase plutôt, non ? M'enfin du point de vue dev ça change rien, grâce à son ORM, il s'en fout.

Ba réfléchis, c'est juste un XML à modifier au lieu de patcher du code. Donc c'est mieux, CQFD.

Encore mieux, tu mets ça dans une table comme ça c'est modifiable à chaud en cas de problèmes. Faut prévoir un refresh du cache en jmx par contre.

C'est complètement modulaire et scalable, c'est vraiment nickel. Par contre, PostgreSQL, je te trouve un peu léger. Ca absorbera pas la montée en charge si tout le front vient à taper dessus. Un peu d'Oracle ou de Sybase plutôt, non ? M'enfin du point de vue dev ça change rien, grâce à son ORM, il s'en fout.

 
Postgres c'est quand même très puissant   On est loin du truc léger

 
C'est exactement ça. Je sais même pas quoi répondre quand on me dit ça, car à chaque fois qu'on me répond "mais c'est plus maintenable donc c'est mieux", et ça me cause un brain freeze et une soudaine dépression.

Même pas. (1) Dans l'appli on a un ApplicationParameterServiceBean qui est injecté par IOC et qui sert à récupérer (2)les données d'un table de config, en passant par hibernate bien sûr,  compilé avec maven et qui loggue avec log4j. J'invente rien

C'est là qu'on voit que php cherche à rattraper java - avec un framework moderne tu passes plus de temps à comprendre comment modifier quel fichier de conf pour que tout fonctionne "tout seul" qu'à coder...

Et au final, tu "codes" des fichiers des conf. Mais comme ceux-ci ne sont peut être pas soumis aux même processus que les sources (versionning, review, tests), certains sont heureux de pouvoir de nouveau faire les chose simplement. Jusqu'à ce qu'une modif faite en live en prod pète tout.

C'est complètement modulaire et scalable, c'est vraiment nickel. Par contre, PostgreSQL, je te trouve un peu léger. Ca absorbera pas la montée en charge si tout le front vient à taper dessus. Un peu d'Oracle ou de Sybase plutôt, non ? M'enfin du point de vue dev ça change rien, grâce à son ORM, il s'en fout.

 
d'ailleurs,  je connais un hôpital de la région du nord qui se prend des recommandé d'Oracle dans la gueule.
Apparemment, Oracle et les VM ça change-rait un peu la tarification, et les équipes infra auraient abusées en montant des serveurs de test un peu partout
 
Le DSI respire la joie, et passe ses journées avec le DAF et service juridique de l’hôpital    
On leur demande 1myon

Et au final, tu "codes" des fichiers des conf. Mais comme ceux-ci ne sont peut être pas soumis aux même processus que les sources (versionning, review, tests), certains sont heureux de pouvoir de nouveau faire les chose simplement. Jusqu'à ce qu'une modif faite en live en prod pète tout.

d'ailleurs,  je connais un hôpital de la région du nord qui se prend des recommandé d'Oracle dans la gueule.
Apparemment, Oracle et les VM ça change-rait un peu la tarification, et les équipes infra auraient abusées en montant des serveurs de test un peu partout

Le DSI respire la joie, et passe ses journées avec le DAF et service juridique de l’hôpital  
On leur demande 1myon

Bon, y'a la moitié du topic dans la santé, si j'ai bien compris... Comment ca se fait ? C'est un milieu de branleurs ?

http://www.youtube.com/watch?v=_XtpYGHJ34w
 

Bon, y'a la moitié du topic dans la santé, si j'ai bien compris... Comment ca se fait ? C'est un milieu de branleurs ?

Bon, y'a la moitié du topic dans la santé, si j'ai bien compris... Comment ca se fait ? C'est un milieu de branleurs ?

(2) si on parle du même projet, c'est cette partie là qui est bien pourri : le schéma de la table est giga pourri. Le mec étant "expert" hibernate, il a fait un truc tout pourri qui implique 2 tables (oui, 2) pour avoir une table de config clé/valeur.