re.  
 
Donc, viteuf.
 
Je n'encadre personne, et j'ai jamais encadré personne.
 
J'ai une responsabilité uniquement technique : cohérence des devs, des conceptions, etc.  
Sur un périmètre qui va du front (web : GWT + CSS, JS & co), jusqu'à l'entrée sur le serveur (donc je gère la session HTTP, l'exposition des services qui répondent aux requêtes HTTP, mais c'est tout : les appels de services applicatifs/métier, la persistance, tout ça, c'est pas mon domaine.
 
Mes activités :  
 
* maintenance et évolutions sur mon périmètre (a la louche 60k lignes de code), je qualifie les demandes JIRA, je chiffre les évols, et je décris les solutions de bugfix que je ne réalise pas.
* Support aux équipes de prod.
* gestion de l'incubateur (pour les devs réalisés dans les équipes destinés à être partagés ensuite) : assistance à la conception, revue de code, etc.
* revues de code, formations
* veille techno, r&d (a hauteur de 5j/an HAHAHA)
 
Après, j'ai aussi d'autres tâches : j'ai fait l'étude de choix de solution de remplacement du portail qu'on utilise (JBoss Portal), et le dev qui a suivi (un conteneur d'application home made, un truc à ~80 jours de devs, dont j'ai fait les 4/5°)
 
Donc voilà. La formation, le coaching (revues de code + debriefing qui va avec, l'aide à la conception, tout ça), j'adore ça, et les retours que j'en ai montrent que j'y suis plutôt bon.
La gestion de projet, j'ai eu à en faire sur le conteneur : j'ai pas été bon (cycle en V, j'ai pas été bon en reporting, ça m'emmerde)

j'ai du vérifier l'horloge de mon PC pour voir si je n'étais pas en 2006

j'ai du vérifier l'horloge de mon PC pour voir si je n'étais pas en 2006

nraynaud> t'es sur de pas vouloir revenir dans le coin? http://boston.craigslist.org/gbs/m4w/4716807484.html  

nraynaud> t'es sur de pas vouloir revenir dans le coin? http://boston.craigslist.org/gbs/m4w/4716807484.html  

comme les femmes qui préfèrent porter le voile, qui préfèrent ne pas travailler, ou qui préfèrent ne pas porter plainte pour viol conjugal
 
Ca fait des nanas qui a 40/45 n'ont plus d'enfants en bas age  à la maison et qui sont devenues inemployables, et donc encore plus dépendantes du revenu du mari
 
A note r aussi que l'ecart moyen entre les enfants, en france est de 2 ans et demi en gros ( http://www.insee.fr/fr/themes/docu [...] _id=ip1419 ) Avec un congé parental on voit qu'il est tout à fait possible d'enchainer les congés parentaux. Redurie la durée pour un parent peut donc avoir deux effets :  

• rapprocher les naissances
• rebosser un peu entre deux enfants
  

ben les gens qui foutent rien, c'est un peu le cancer de notre société, oui

Fig.1 : le célibataire sans enfant qui touche des indemnités chômage

...  
 
hohoho...
 
J'aime bien ne pas trop me tromper.
 
On vient de nous demander de proposer une solution pour remplacer une partie d'une appli web qu'on fait par une autre, écrite en Delphi et développée par une autre boite.
 
La stratégie du PDG est claire : ce qu'on peut trouver ailleurs, on ne le fait pas chez nous. Si c'est vrai niveau métier, je vois pas pourquoi ça serait pas vrai niveau technique aussi.
 
Là où je me marre, c'est que le mec nous a fait chier pendant des lustres comme quoi les applis qu'on fait avec notre framework sont moches - alors que bon, il avait validé les choix de la boite de design il y a 4 ans - et que maintenant, il accepte d'intégrer n'importe quel truc, même sans aucune cohérence de comportement, sans même parler de cohérence graphique, pourvu que ça lui fasse économiser des thunes.
 
[edit] Si j'ajoute à ça mon collègue qui vient de me signaler que je n'ai pas utilisé le bon format de mail pour demander une validation de mon dossier d'analyse (j'ai un SDK avec 4 méthodes à écrire, le modèle de doc fait 21 pages) Donc, il faut envoyer un mail pour demander qu'on me valide les specs. Ledit mail doit ensuite être copié dans le Sharepoint. Tout ça pour valider que OUI,on a bien demandé une validation. Qui est aussi écrite dans le doc lui même. Doc qui reste modifiable après coup, donc si un mec veut supprimer l'info comme quoi il a validé un doc, c'est open bar.
Vivement décembre.

'tain ça fait bientôt un an que je vois un psychanalyste 2 fois par semaine, j'ai un peu de mal à en voir les effets. Et on peut pas dire que j'ai pas laissé le temps au truc

et le consensus est qu'elle ont plus d'inconvenients que d'avantages si t'es en single-application (une seule application tape dans la db).

C'est ce que nous faisons, toutes nos requêtes sont des proc stock et à l'usage je ne vois pas bien quels sont les inconvénients et d'où vient ce consensus.  
 
En fait à l'usage, je n'ai trouvé que des avantages à cette manière de faire:
- les requêtes sont dans la base, pas dans le code applicatif, ce dernier ne fait que des appels de requêtes préparées. Pas de SQL dans le code applicatif ! La séparation entre le modèle de données et l'applicatif est nette, car on n'a plus qu'une interface. On pourrait changer le modèle de données de fond en comble, voire de SGBD sans changer une ligne de code de l'applicatif,
- on peut mettre à disposition des proc stocks différentes pour différents types d'utilisateurs. Les clients peuvent donc attaquer directement la base sans voir le modèle de données.
 
Cette façon de faire n'a posé absolument aucun problème à l'usage, à tel point que je pense maintenant que c'est la meilleure manière d'utiliser un SGBD.

un avantage que je peux y voir c'est aussi la frontière de transaction. Mais un gros inconvénient, c'est que les langages et l'infrastructure sn souvent à la con dans un SGBD.

- les requêtes sont dans la base, pas dans le code applicatif, ce dernier ne fait que des appels de requêtes préparées. Pas de SQL dans le code applicatif ! La séparation entre le modèle de données et l'applicatif est nette, car on n'a plus qu'une interface.

On pourrait changer le modèle de données de fond en comble, voire de SGBD sans changer une ligne de code de l'applicatif

- on peut mettre à disposition des proc stocks différentes pour différents types d'utilisateurs. Les clients peuvent donc attaquer directement la base sans voir le modèle de données.

Ceci étant, le principe de mettre le moins de code business que possible dans la BD reste valable. Les rares proc stock que l'on fait en dehors de pures requêtes, ce sont des trucs du style calcul de moyennes qui sont mieux faites dans la BD qu'en dehors.

Tu utilises des DTO, la séparation est tout aussi claire.

Tu changes 10kLOC de procédures stockées ou 10kLOC de code applicatif, elle est où la différence en dehors d'avoir un versioning chiant pour les procédures stockées? C'est quoi l'argument, que vous arrivez pas à créer des interfaces découplées par vous même et les procs vous y forcent?

T'as pas besoin de procs pour utiliser des roles.

Donc vos procs c'est juste un alias trivial sur une requête SQL?

Sauf que là, il n'y a pas besoin. Une couche de moins dans ton appli, c'est tjrs ça de gagné. Et pas besoin d'ORM.

D'une part, comme je l'ai dit plus haut, on ne met pas plus de code business dans la base en faisant comme ça qu'avant.
D'autre part, le versionning se fait sur les fichiers de DDL, ça n'est pas plus chiant que si c'est du Java.

Non, mais de cette manière, le client final peut attaquer directement la base de façon complètement contrôlée par nous. Il n'a aucune idée du modèle de données.

Bah non la couche est bien là, sous forme de stored procs au lieu de fonctions applicatives.

Sauf la partie qui te force à mettre à jour ta DB quand t'as une requête qui est pas la bonne.

Quel client final? T'as l'air de parler de multi (structure db unique, clients divers), ma remarque initiale était sur du single (avec une application en paire avec une DB), pas du multi-applicatif où la DB sert d'API.

Il n'y a qu'une appli. Mais effectivement, on peut dire qu'en présence d'autres clients c'est du multi applicatif. Ceci étant, je ne vois pas trop en quoi le fait d'être multi applicatif fait une différence.

En paired, la DB et l'application sont couplés et ont le même cycle de vie, les trucs sont dans l'un ou l'autre au besoin et généralement dans l'applicatif parce que c'est plus flexible, plus rapide à changer et plus facilement testable.
 
Si tu fais du multi (genre boite avec un gros datastore de tous les trucs internes et une multitude de consommateurs via divers produits ou services), tu dois présenter une api pour contrôler les accès et t'assurer que personne va aller faire le con (surtout si ce sont des tiers/externes qui écrivent les applis), tu veux potentiellement des rôles si les applis ont pas toute à accéder aux même trucs, si tu peux avoir du language-independent c'est encore mieux, ce genre de trucs. Tu peux monter une "application" qui sert d'API (RPC, REST, whatever) et va taper dans la DB, mais ça veut dire des pièces en mouvement supplémentaires, dans ce cas la DB peut faire le boulot d'API directement, d'autant plus avec des trucs genre les fdw postgres.

J'ai toujours eu l'impression que c'était plus simple de faire une appli avec ton langage habituel que de comprendre la doc des fonctions un peu avancées d'une DB. En particulier quand t'as un contrôle d'accès multi-couches, t'es jamais sûr que t'as bien compris la doc et que ce que tu as écrit correspond à ce que tu imagines que ça veut dire, et t'as pas vraiment le droit de te planter.

Tsss. La surface pro 3 elle déboite. Et tu peux faire tourner Eclipse dessus.

Et sinon, je tiens à dire que ça fait du  bien d'avoir un gouvernement qui sait prendre les bonnes décisions. Comme le fait d'accorder un royal 35€ d'alloc par mois aux familles qui touchent plus de 8000€ de salaire. Ca fait donc 0,4% de leur revenus. Vu ce que ces familles doivent cotiser en IR, je pense que le gouvernement (et ses députés) essayent un peu de me prendre pour un con, en faisant semblant:

• 1. que ces familles sont nombreuses et coûtent cher à la France.
• 2. Qu'on leur fait une fleur énoooorme en ne leur coupant pas les allocs.

Tsss. La surface pro 3 elle déboite. Et tu peux faire tourner Eclipse dessus.

Ouais, c'est parti... manque plus qu'une bonne fièvre Ebola dans le métro parisien et c'est la panique assurée.

c'est aussi la preuve que tous les noirs se ressemblent