Reprise du message précédent :

J'aurai tendance à dire jquery, eventuellement carrement un pack gnre twitter bootstrap pour te simplifier la vie au possible
http://jqueryui.com/demos/autocomplete/#custom-data
webstorm ( ou sa version avec python directement ) . Les versions EAP sont fourneis avec des clé valables 30 j

 
 
Mon premier reflexe serait d'etendre un widget dojo (http://dojotoolkit.org/reference-guide/dijit/form/ComboBox.html)

Nope, Sarkal. Face aux employés de la centrale, il a fait un numéro à se plier de rire tellement c'était forcé. En fait un numéro à la Méluche, ouais, mais moins en verve, plus à la Sarkal, quoi. Je pense que la vidéo va se retrouver sur le toituyau ou le mouvementquotidien d'ici pas longtemps.

Sinon, l'ami Serge a la main lourde sur le Fig, apparemment.

putain je comprend rien a ce post
t'es vraiment qu'un connard  

il vient plus ce connard de bl ?

 
Ya pas skype

 
barbapapaaaaaaa

http://www.thinkgeek.com/caffeine/wacky-edibles/ec0c/    

 
*note pour halloween*

trop flag, je voulais sortir ça pour la saint valentin

Déjà ça s'appelle Wireshark depuis 2006

Question d'archi (on a un gros débat en interne ).
 
Considérons 2 projets A et B développés par la même boîte (nous) qui sont gérés par des équipes de dev différentes, des process de maj différents...
Des données arrivent dans A et qui intéressent B.
 
Comment rendre les données accessibles à B de la manière la + propre ?
 

Si le truc est DB-driven proprement, avec tous les schémas bien définis et des stored procs pour agir sur les tables correctement ça peut passer d'avoir le serveur SQL en format d'échange, mais si c'est pas le cas vous allez surtout vous retrouver avec une base fuckée et deux applis dans les choux.
 
Et comme vous faites du symph + ORM, je doute que vous soyez DB-driven.
 
Quand à l'API, évite de l'appeler REST parce-que je doute qu'elle le soit

j'arrive pas à comprendre la description, ça sert uniquement à faire des mauvaises blagues ou c'est mangeable pour quelqu'un qui mange épicé couramment ? /muchacho/
 
edit: 1 million SHU , ok c'est immangeable

http://www.youtube.com/watch?v=1tRq8ExAHzk

il va en chier lui quleques heures plus tard  

 
Définis DB-driven
 
Et pourquoi ce serait pas du REST
 
Le risque qu'on voit avec l'accès direct en SQL c'est que A change son schéma sans nous prévenir et qu'il pète les appels de B, ce qui à mon sens est moins risqué avec des API (versionnées) de + haut niveau.

Si  a et b sont des projets symfony, ça veut dire que tous les contrôles d'intégrité sont fait par la couche en php par desssus  dès qu'on sort du simple champ de la clé étrangèe ou de la clé unique ( pas de procédure qui sont chargées de ça )
le risque que B démonte complètement la base de A est important
le risque que A pète la compatibilité avec B aussi

Mais les replications et les interface intermédiaires amènent aussi leur jeu de problème et de desynchros. Pourquoi ne pas passer par  une couche avec des vues readonly qui servent de sas et de contrat ( A doit maintenir ces vues mais peut continuer a faire évoluer son schéma si besoin , B ne peut rien toucher hors des vues )  ? En plus le cout de mise en place est ridicule

edit : typo

Toute la logique métier est encodée dans la DB, et toutes les contraintes & autres sont en place pour que tu puisses pas mettre la DB dans un état incorrect.

Parce qu'une API RESTful c'est notablement plus difficile que faire de jolies URLs, t'as intérêt à lire tout Fielding (thèse + blog) pour commencer

C'est une API dans tous les cas, d'une manière ou d'une autre si l'API est pas bien définie et bien testée, à partir du moment où le truc évolue B va s'en prendre plein la gueule. Et tu peux définir ton API SQL via des vues ou autres conneries du style qui resteront stable pour B même quand le schéma de A changera.

Après personnellement je suis plus pour une API externe, mais c'est parce que j'aime pas les DB et j'aime pas le SQL

Précision : B ne fait que de la lecture sur les données en question. Et A sera alimenté probablement par un ETL.

Lier deux S.I. comme ça, au niveau de leur schémas de donnée, c'est vraiment pas recommandé, et passer par une API c'est bcp plus sur.
Pour les deux.
En dehors du problème de changement de schéma unilatéral chez A qui pète tout ( ou partie) chez B, il y aussi le souci d'avoir des gens de B qui mettent à genoux ton/tes serveurs chez A (parce qu'ils  pondent du SQL comme des pieds, ou tout simplement qu'ils ne connaissent pas suffisamment le schéma de A avec ses index, notamment, ou parce que A est très orientée transactionnel, bcp de maj donc, et les requetes venant de B vont être comme un grain de sable qui va gripper A )
 
Vaut mieux découpler les deux, surtout si l'un des deux projets a déjà une certaine ampleur (à plus forte raison, si c'est le cas des deux).
 
La réplication, mouais, si vous avez pas le choix, et que vous êtes dans un cas simple (réplis entre bases sur un même serveur voire site à la rigueur), mais l'API bien définie (proc stock,vue, etc ...) c'est franchement préférable ( à moins que les outils de réplication aient bcp changés ces dernière années .... )
 
En résumé, tout comme Masklinn

heu ... tout le temps en ETL ?

Pour les données en question oui c'est probable. Pourquoi ?

En général, un SGBDR qui fonctionne en transactionnel à hautes dose, ça aime pas trop être interrompu pour faire autre chose, surtout des requetes significatives

Vaut mieux séparer les deux

les process d'alim de A fonctionnent 24/24 ?

Concernant la réplication à partir de A, si A est alimenté par disons des batchs qui importent/mettent à jour des quantités significatives de données à chaque fois, y'a de bonne chance d'avoir des emmerdes
Si vous avez pas un DBA qui suit derrière (et même avec ça, c'est une grosses source d'ennuis bien souvent) et bichonne la réplication, ça va pas être terrible
 
Tout dépend des volumes importés/mis à jour dans A par chaque process d'import

http://www.kickstarter.com/project [...] -adventure
 
Le million le million le million

J'imagine que ce n'est pas envisageable que l'ETL alimente aussi B ?  
Vous utilisez quoi comme ETL?  
ici on use et abuse d'une solution propriétaire et  on fini par en toucher les limites ( temps de réplication qui grossisent, problème de desynchros rares, mais penibles, .... )

Wow, moi qui m'imaginais que le suicide de son épouse était un truc à faire cogiter un homme pendant des années, je suis heureux de voir que Luc Chatel est déjà sur pied...

Putain c'était du solide à l'époque les frigos... j'viens de me coincer le doigt dans le mécanisme de la poignée de porte, ça m'a fait un trou dans l'ongle du pouce (Also, aïe... )

 

 
(Sinon, useless fact : http://www.kickstarter.com/ & http://remixjobs.com/ )

Frigidaire est plus fort que toi ! A l'époque, on construisait pour que ça dure, quitte à ce que ça soit cher à l'achat, pas pour que ça dure "environ 10 ans".

 
Ouais, ca vaut le détour, comme boutique. Pas trop loin de chez eux non plus, y'a aussi Retro Games, au 41 de la rue Basfroi. Ils vendent quelques cartes mères Jamma (MVS ou CPS2 par exemple) et des jeux sympa qui vont dessus (Pro Gear No Arashi, par exemple, mais à quel prix ... )
 
Edit : typo

preums

3. Vendez un eai avec
4. plus serieusement, B ne tape pas dans le schema de A, mais A peut eventuellement exporter des services en pl/sql, ca elimine un peu de friction.

Pour être plus clair, parce que le site n'est pas franchement explicite, le magasin Neo-Legend ressemble à première vue à une simple salle de jeux, avec de nombreuses bornes d'arcade, mais aussi des flippers de café. Mais à y regarder de plus près, on se rend vite compte que ça n'est pas exactement ça: tous les appareils sont à vendre, aux alentours de 2000 euros. Et pour les bornes d'arcade, ce sont effectivement de vraies bornes d'arcade, mais modifiées pour inclure un émulateur ou une console. Le résultat est absolument parfait, on a effectivement une borne Pac Man vintage, mais avec une soixantaine de jeux d'époque. Il y a aussi des bornes plus modernes avec une Xbox 360 dedans.

http://www.challenges.fr/economie/ [...] me-si.html
 
les grandes manœuvres en coulisses

Ouïe... Bon je te fais un fast forward de ton orga dans 10 ans si vous choisissez l'approche 1 (vécu dans mon ancienne boîte, et crois pas que le readonly te protège ) :
- pour modifier le schéma de A tu devras demander l'autorisation de 10 autres applis
- si tu dois discontinuer A, bonne chance
- pense à engager / réserver le temps d'un bon DBA
- pense à tes backups

Je choisis L'approche 2 sans aucun problème, qui expose une API propre codefinie avec les projets intéressés...

J'ai un processeur à donner, pour cause de carte mère qui a fumé (j'aurais surement dû garder le proc et acheter une carte-mère compatible, mais bon j'ai préféré opté pour la soi-disant évolutivité, genre je vais changr un jour de proc...)
 
Enfin bon voilà, c'est un Athlon II X4 620, je l'envoie en lettre simple sans le ventirad parce que ça rentre pas dedans.

tu veux pas plutôt te procurer ça ?

http://www.youtube.com/watch?v=D7t [...] re=related

edit: bah voila http://www.hotsauce.com/16-Million [...] als1.0.htm

 
Ce serait toujours mieux que mon E6300 ?
Faudrait que j'achète une carte mère ATX AM3 :x

La solution de proposer des vues comme API est pas mal en terme de performances.
Par contre, en autorisant B à aller taper dans leur base, A perd le contrôle sur le modèle de données, et tôt ou tard, il y aura des tensions entre les deux équipes, parce que B outrepassera les limites qu'on leur aura imposées, c'est quasiment inévitable. Le mieux est alors de changer l'organisation et de créer une équipe intermédiaire qui a le contrôle sur la base, et qui gère les changements à la demande des deux équipes. Mais on risque alors de retomber dans le syndrome de la BD usine à gaz, car désormais, B se sent sur un pied d'égalité et demandera de pouvoir accéder en écriture. Si ça reste exceptionnel, c'est jouable, sinon c'est le début de la galère, et comme Jubi, je suis d'avis que ça commence comme ça avec une API de 3 requêtes, et que dans 5 ans (même pas dans 10), vous aurez 2 applis totalement liées. Le SOA a été inventé pour éviter cela, il a un coût en terme de performances, mais est quand même nettement plus flexible en terme d'organisation et de maintenance.