[blabla@olympe] Le topic du modo, dieu de la fibre et du monde

Recherche :

Sujet auquel vous répondez
Sujet : [blabla@olympe] Le topic du modo, dieu de la fibre et du monde
uriel	nraynaud> t'es sur de pas vouloir revenir dans le coin? http://boston.craigslist.org/gbs/m4w/4716807484.html [:raphfromthesouth:1]

Votre réponse

Nom d'utilisateur

Pour poster, vous devez être inscrit sur ce forum .... si ce n'est pas le cas, cliquez ici !

Le ton de votre message

Votre réponse

Smilies

Liste des smilies perso
Wiki smilies
Chercher un smiley

Options

Activer votre signature
Désactiver les smilies
Activer la notification par email du sujet

Aperçu

Vous avez perdu votre mot de passe ?

Vue Rapide de la discussion

nraynaud

uriel a écrit :

c'est aussi la preuve que tous les noirs se ressemblent [:spamafote]

ouais, je crois qu'il y a vraiment un gros problème racial derrière tout ça, genre ils voulaient poursuivre le mec qui est mort au Texas. Mais le mec qui a été faire un petit tour en Grèce il y a quelques années avec une tuberculose multi-résistante il a pas vraiment suscité de réponse judiciaire alors qu'il a mis en danger beaucoup plus de monde.

uriel

c'est aussi la preuve que tous les noirs se ressemblent [:spamafote]

uriel

el muchacho a écrit :

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

http://www.boston.com/health/2014/ [...] n_headline

Citation :

A woman was reported to be throwing up. Boston Public Health Commission spokesperson McKenzie Ridings told Boston.com that Boston EMS was called to evaluate a woman who was ill on the Orange Line. She was taken via ambulance to Boston Medical Center. Service resumed on the T by 11 :41 a.m. according to the MBTA.

Transit Police told Boston.com that a bystander called 911 around 11 a.m. saying “there’s a woman from Liberia here and she has Ebola.” Both claims were wrong. Boston EMS responded and asked the woman routine medical questions and determined she was of Haitian descent.

avec la periode de la grippe qui vient, ca va etre un beau bordel [:theepsilon]

(note: le T c'est le metro local)

ratibus

Lam's a écrit :

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

Trop cher :o
Ipad air 2 64Go : 605€

flo850

Lam's a écrit :

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

clair
Ou webstorm
D'ailleurs, elle n'était pas sensé être a ta femme ?

Lam's a écrit :

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.

Un peu comme le 1.96€ de supplément familiale que tu touches avec le premier enfant
La , on est complètement dans la mesure symbolique

Par contre ces 35€ génèrent toujours une charge de travail/verif et donc un cout pour la société

masklinn

nraynaud a écrit :

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.

Dans le cas 2, la DB devient effectivement ton langage habituel, si t'es côté provider tu fais tout via elle.

nraynaud

masklinn a écrit :

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.

masklinn

el muchacho a écrit :

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.

Lam's

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.

Lam's

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

ratibus

Bon je crois que je vais refresh mon ipad 1 avec un air 2 ou un mini 3.

el muchacho

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

vapeur_cochonne

ebola [:totoz]
bon j'espere que ça va lancer le tv travail chez nous

R3g	http://www.amazon.fr/meinLiLaLu-Co [...] B000OROBMM [:le kneu]

el muchacho

masklinn a écrit :

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

Certes. Mais je trouve que le code est plus propre quand toutes les requêtes sont regroupées dans quelques fichiers SQL.

masklinn a écrit :

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

Ben tu la testes un peu avant, hein... et la MAJ de la BD fait partie du cycle de vie normal de l'appli. Celle des proc stocks n'est pas le plus chiant, loin de là.

masklinn a écrit :

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.

masklinn

el muchacho a écrit :

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.

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

el muchacho a écrit :

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.

Sauf la partie qui te force à aller altérer ton schéma quand t'as une requête qui est pas la bonne, ou que t'as besoin de données existantes dans un nouveau format.

el muchacho a écrit :

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.

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

el muchacho

masklinn a écrit :

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

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.

masklinn a écrit :

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?

masklinn a écrit :

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

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 sous-jacent.

masklinn a écrit :

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

En gros oui. Les requêtes se trouvent dans la base, et l'appli n'en voit que l'interface, style "getMeDisAndDat(timestamp t1, timestamp t2)". A l'usage, c'est pareil que d'appeler un service externe. On gagne sur tous les tableaux.

masklinn

el muchacho a écrit :

- 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.

Tu utilises des DTO ou des vrais modèles (ORM-style), la séparation est tout aussi claire.

el muchacho a écrit :

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

Tu changes 10kLOC de procs ou 10kLOC de code applicatif, elle est où la différence en dehors d'avoir un versioning chiant pour les procs? 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?

el muchacho a écrit :

- 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.

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

el muchacho a écrit :

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.

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

el muchacho

nraynaud a écrit :

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.

PL/machintruc [:spamafote]

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.

nraynaud

el muchacho a écrit :

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.

flo850

Apple innove a mort

IPad avec touchid? Refresh du mini ? Écran 5k avec une connectique nouvelle non compatible avec l'existant ?

el muchacho

masklinn a écrit :

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.

masklinn

'tin l'event apple il est chiant comme la mort, ils ont passé 20mn à répéter des trucs de WWDC et de l'event de septembre [:ciler]

nraynaud

bof, ça me coûte moins cher que d'aller voir ma nana aux US. en fait j'ai pas de problèmes d'argent, ou plu exactement je crame tout, mais c'est pas vraiment à cause de facteurs externe, c'est mes achats compulsif à essayer de remplir mon appart' de conneries.

sligor

nraynaud a écrit :

'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 :/

tu ne te sens quand même pas plus léger ? :)

Spoiler :

financièrement parlant

nraynaud

'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 :/

flo850

http://upload.wikimedia.org/wikipe [...] d_Boss.jpg

gfive

:??:

masklinn

gfive a écrit :

...

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.

Tu bosses sous un vrai PHB en fait.

nraynaud

mechkurt a écrit :

[:cbrs]

et je peux te dire qu'on parle pas du SMIC [:filter]

mechkurt

R3g a écrit :

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

[:cbrs]

nraynaud

enfant reconnu [:aloy]

ceci dit, je suis pas pressé d'en avoir, j'ai vraiment pas envie que le sauvageon bruyant ça soit le mien [:mlc]

R3g

nraynaud a écrit :

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

Fig.1 : le célibataire sans enfant

nraynaud

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

R3g

flo850 a écrit :

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

Oui, donc en fait on postule que les femmes qui prennent un congé parental trop long c'est une mauvaise chose pour la société. C'est quand même un gros changement de paradigme.

Note que pour le premier enfant, c'est un an seulement.

nraynaud

uriel a écrit :

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

J'arrive [:filter]

drasche

uriel a écrit :

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

Les méthodes de drague varient je vois :o

sligor

Harkonnen a écrit :

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

forcement:

Citation :

* veille techno, r&d (a hauteur de 5j/an)

gfive

Harkonnen a écrit :

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

bah une fois tous les 8 ans, changer, spas mal :o

Harkonnen

gfive a écrit :

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

uriel

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