J'avoue que c'est un problème ! je voulais surtout tester google app engine et me faire une idée de la solution.
L'intérêt était aussi pour moi d'avoir des données valides. Le SHA1SUM est forcement juste car je m'identifie auprès de google. Par contre, il faut en effet que je trouve du temps pour implémenter d'autres API d'authentification.
J'ai développé le projet Quatuo ( http://www.quatuo.com ) qui permet à tout le monde de publier son profil foaf. C'est aussi un crawler web qui cherche des profils et enrichit sa base de données de profils !
Les URL de données sémantiques lisibles sont dans le fichier sitemap.xml. Si les owners du projet lisent mon post, je serais enchanté qu'ils aillent lire les profils quatuo !
Il existe d'autres framework pour faire de l'AOP et de l'IOC mais c'est celui que nous avons choisi :)
Essayez nos deux tutoriaux sur Spring pour vous faire une idée de la puissance du truc !
je trouve ça plus propre que de faire des new partout, des try catch à chaque coin de rue et du code pour se connecter à la base, pour gérer la sécurité et autres trucs du genre.
Je suis pas d'accord avec vous, c'est plus que difficile, c'est impossible.
Si un logiciel tombe sur "ouvert le lundi mais, attention, pas pendant l'été !" il va pas pouvoir générer du XML pour expliquer cela. Il va même pas comprendre. Pareil pour les chambres d'hôtel ! comment parser un site pour connaitre le nombre de chambre d'hôtel, trouver les tarifs d'été, savoir si les chiens sont admis, tout ça en automatique, c'est impossible !
Contactez moi directement :) je vous donnerai le contact du comité régional du tourisme de Poitou Charente qui vous expliquera que c'est possible et qu'en plus, ça fonctionne depuis 3 ans :)
acogit permet tout à fait cela. Un site web peut aller modifier ces informations sur l'entrepôt de données et le même site web peut afficher les données provenant du site web.
En fait, il faut bien se dire que l'idée, c'est de centraliser l'informaton et de la standardiser.
Centraliser pour gagner du temps : arrêter de dupliquer les formulaires et le remplissage, on remplit une fois les données et elles sont accessible à tous.
Standardiser pour faciliter l'intégration : avec un format commun, n'importe qui peut utiliser les informations pour faire les traitements qu'ils veut.
Je suis décidément pas d'accord avec vous, au contraire, cet outil est né de la réalité du terrain. Cet outil est née de la constatation suivante : chaque "entité touristique" doit rentrer les mêmes informations dans plusieurs systèmes mais de différentes formes et de différentes manières.
L'idée ici, c'est de rentrer les informations de manière standard et d'avoir ensuite tous les autres systèmes qui viennent utiliser cette information.
Le système économise du temps. Un exemple, sur le site charente.com, les entités touristiques sont affichées sur une carte et bien, ces informations ont été récupérées automatiquement depuis l'entrepôt régional des données, le comité départemental de charente n'a plus à demander les informations vue qu'elles existent de manière standardisées et centralisées.
Croire qu'on pourrait récupérer les informations en regardant la structure du site web est plus qu'utopique.. comment une machine pourrait analyser le texte de n'importe quel site et en déduire les horaires d'ouverture et les ranger correctement pour qu'un outil puisse faire des requêtes !
et le format tourinfrance ne parle pas que des musées, loin de là.
L'application peut très bien permettre de donner les droits de modification des informations du musée à l'hôtesse d'accueil et elle remplit l'information sur la fiche, bref, elle devient propriétaire des informations de sa fiche.
Le développeur du site web du musée peut utiliser nos webservices pour afficher l'horaire sur le site web. Ce même développeur peut carrément rajouter la modification de l'heure d'ouverture dans le back office du site du musée et mettre à jour automatiquement acogit.
Je crois que vous comprenez vraiment rien à l'application :)
le format tourinfrance sert à décrire des objets touristiques (Hôtel, musée, camping...) au format XML. Je comprends donc pas bien votre idée de "moissonner du rss"
Et si vous aviez été un peu plus en avant dans votre étude de notre application, vous auriez vu qu'il y une API complète qui permet d'ajouter/modifier/supprimer des informations dans la base de données, donc n'importe qui peu mettre à jour les informations comme il le veut.. plugin, d'éditions, cms...
Voilà, étudiez un peu plus l'application et ses capacités :)
J'ai oublié Postgresql :) Même si l'application est indépendante de la base de données, c'est quand même PostgreSQL que nous avons retenu pour la prod.
Tomcat est un conteneur web, il permet de faire tourner des servlets et jsp (je fais vite hein, je rentre pas dans les détails...). Concrètement, Tomcat ne fourni par tous les services de la norme JEE. JOnAS lui fournit l'ensemble des services, donc le conteneur web et d'autres services (JMS, JCA...)
On a un socle technique basé sur JOnAS et on en est satisfait... mais c'est vrai qu'on réfléchit à passer à autre chose.. pourquoi pas un Jetty (on développe avec Hibernate/Spring/GWT).
mm où sont les logs ? où est la vérification que l'utilisateur a bien le droit de créer le client ? je te parle pas que du principe d'avoir un framework ORM, je te parle de la capacité à séparer le code et à l'appliquer comment on le veut sans avoir à mélanger métier et technique
Et je te signale que du coup, je vois pas en koi Java est plus verbeux, on on aurait pu faire
Client c = new Client("toto"); :)
ce n'est pas du tout ça, dans les applications, on essaye de séparer la logique métier et le code technique. C'est la base pour bien développer et être productif.
Et par sécurité, j'aurais du dire "Authentification/authorisation".
# Nous aussi :)
Posté par Stéphane Traumat (site web personnel) . En réponse à la dépêche Ces start-ups qui contribuent au Libre. Évalué à 6.
De notre côté, notre société Scub a libéré son usine logicielle Java libre Scub Foundation (une nouvelle version et un nouveau site sort fin janvier).
On a aussi développé Square : une solution de gestion de la relation client libre pour les métiers de l'assurance et des mutuelles. On a développé cette application avec l'un de nos clients. On finit le nettoyage des sources et on libère le tout début janvier.
http://about.me/straumat
# Mes slides d'introduction au web sémantique
Posté par Stéphane Traumat (site web personnel) . En réponse à la dépêche Jeudi du libre de décembre à Lyon : le web sémantique. Évalué à 2.
Si ça peut aider, j'avais fait des slides sur le sujet : http://www.slideshare.net/straumat/introduction-au-web-smantique
http://about.me/straumat
[^] # Re: Sources de données sémantique
Posté par Stéphane Traumat (site web personnel) . En réponse à la dépêche fise, un nouveau moteur sémantique RESTful et libre. Évalué à 2.
L'intérêt était aussi pour moi d'avoir des données valides. Le SHA1SUM est forcement juste car je m'identifie auprès de google. Par contre, il faut en effet que je trouve du temps pour implémenter d'autres API d'authentification.
http://about.me/straumat
# Sources de données sémantique
Posté par Stéphane Traumat (site web personnel) . En réponse à la dépêche fise, un nouveau moteur sémantique RESTful et libre. Évalué à 2.
Les URL de données sémantiques lisibles sont dans le fichier sitemap.xml. Si les owners du projet lisent mon post, je serais enchanté qu'ils aillent lire les profils quatuo !
http://about.me/straumat
[^] # Re: Mangez du XML
Posté par Stéphane Traumat (site web personnel) . En réponse à la dépêche Sortie de Scub Foundation Socle Technique Java Open Source. Évalué à 3.
http://www.scub-foundation.org/fr/doku.php?id=tutorial_sprin(...)
http://www.scub-foundation.org/fr/doku.php?id=tutorial_sprin(...)
http://www.scub-foundation.org/fr/doku.php?id=tutorial_sprin(...)
Voilà :)
http://about.me/straumat
[^] # Re: Mangez du XML
Posté par Stéphane Traumat (site web personnel) . En réponse à la dépêche Sortie de Scub Foundation Socle Technique Java Open Source. Évalué à 1.
Essayez nos deux tutoriaux sur Spring pour vous faire une idée de la puissance du truc !
http://about.me/straumat
[^] # Re: Mangez du XML
Posté par Stéphane Traumat (site web personnel) . En réponse à la dépêche Sortie de Scub Foundation Socle Technique Java Open Source. Évalué à 2.
http://about.me/straumat
[^] # Re: RESThub
Posté par Stéphane Traumat (site web personnel) . En réponse à la dépêche Sortie de Scub Foundation Socle Technique Java Open Source. Évalué à 2.
http://about.me/straumat
[^] # Re: Mangez du XML
Posté par Stéphane Traumat (site web personnel) . En réponse à la dépêche Sortie de Scub Foundation Socle Technique Java Open Source. Évalué à 2.
http://about.me/straumat
[^] # Re: moissonner du RSS
Posté par Stéphane Traumat (site web personnel) . En réponse à la dépêche Sortie de la version 1.6 d'Acogit. Évalué à 2.
Si un logiciel tombe sur "ouvert le lundi mais, attention, pas pendant l'été !" il va pas pouvoir générer du XML pour expliquer cela. Il va même pas comprendre. Pareil pour les chambres d'hôtel ! comment parser un site pour connaitre le nombre de chambre d'hôtel, trouver les tarifs d'été, savoir si les chiens sont admis, tout ça en automatique, c'est impossible !
Contactez moi directement :) je vous donnerai le contact du comité régional du tourisme de Poitou Charente qui vous expliquera que c'est possible et qu'en plus, ça fonctionne depuis 3 ans :)
http://about.me/straumat
[^] # Re: pas de collecte automatique
Posté par Stéphane Traumat (site web personnel) . En réponse à la dépêche Sortie de la version 1.6 d'Acogit. Évalué à 1.
En fait, il faut bien se dire que l'idée, c'est de centraliser l'informaton et de la standardiser.
Centraliser pour gagner du temps : arrêter de dupliquer les formulaires et le remplissage, on remplit une fois les données et elles sont accessible à tous.
Standardiser pour faciliter l'intégration : avec un format commun, n'importe qui peut utiliser les informations pour faire les traitements qu'ils veut.
http://about.me/straumat
[^] # Re: pas de collecte automatique
Posté par Stéphane Traumat (site web personnel) . En réponse à la dépêche Sortie de la version 1.6 d'Acogit. Évalué à 1.
L'idée ici, c'est de rentrer les informations de manière standard et d'avoir ensuite tous les autres systèmes qui viennent utiliser cette information.
Le système économise du temps. Un exemple, sur le site charente.com, les entités touristiques sont affichées sur une carte et bien, ces informations ont été récupérées automatiquement depuis l'entrepôt régional des données, le comité départemental de charente n'a plus à demander les informations vue qu'elles existent de manière standardisées et centralisées.
Croire qu'on pourrait récupérer les informations en regardant la structure du site web est plus qu'utopique.. comment une machine pourrait analyser le texte de n'importe quel site et en déduire les horaires d'ouverture et les ranger correctement pour qu'un outil puisse faire des requêtes !
et le format tourinfrance ne parle pas que des musées, loin de là.
http://about.me/straumat
[^] # Re: pas de collecte automatique
Posté par Stéphane Traumat (site web personnel) . En réponse à la dépêche Sortie de la version 1.6 d'Acogit. Évalué à 1.
Le développeur du site web du musée peut utiliser nos webservices pour afficher l'horaire sur le site web. Ce même développeur peut carrément rajouter la modification de l'heure d'ouverture dans le back office du site du musée et mettre à jour automatiquement acogit.
http://about.me/straumat
[^] # Re: pas de collecte automatique
Posté par Stéphane Traumat (site web personnel) . En réponse à la dépêche Sortie de la version 1.6 d'Acogit. Évalué à 3.
le format tourinfrance sert à décrire des objets touristiques (Hôtel, musée, camping...) au format XML. Je comprends donc pas bien votre idée de "moissonner du rss"
Et si vous aviez été un peu plus en avant dans votre étude de notre application, vous auriez vu qu'il y une API complète qui permet d'ajouter/modifier/supprimer des informations dans la base de données, donc n'importe qui peu mettre à jour les informations comme il le veut.. plugin, d'éditions, cms...
Voilà, étudiez un peu plus l'application et ses capacités :)
http://about.me/straumat
[^] # Re: Une administration oblige à publier sous GPL
Posté par Stéphane Traumat (site web personnel) . En réponse à la dépêche Sortie de la version 1.6 d'Acogit. Évalué à 1.
http://about.me/straumat
[^] # Re: Une administration oblige à publier sous GPL
Posté par Stéphane Traumat (site web personnel) . En réponse à la dépêche Sortie de la version 1.6 d'Acogit. Évalué à 3.
http://about.me/straumat
# Et PostgreSQL !
Posté par Stéphane Traumat (site web personnel) . En réponse à la dépêche Sortie de la version 1.6 d'Acogit. Évalué à 3.
http://about.me/straumat
[^] # Re: vs Tomcat
Posté par Stéphane Traumat (site web personnel) . En réponse à la dépêche JOnAS 5.1 M5 : Serveur d'application certifié Java EE 5 !. Évalué à 2.
http://about.me/straumat
[^] # Re: Passerelle Apache Felix?
Posté par Stéphane Traumat (site web personnel) . En réponse à la dépêche JOnAS 5.1 M5 : Serveur d'application certifié Java EE 5 !. Évalué à 2.
http://about.me/straumat
[^] # Re: SSS c'est Sea, Sex and sun ...
Posté par Stéphane Traumat (site web personnel) . En réponse à la dépêche Open Web Server 1.0 est libéré. Évalué à 2.
Et puis, en ce qui concerne le support de Java, tu peux prendre glassfish non ?
C'est aussi de chez SUN
http://about.me/straumat
[^] # Re: Hum...
Posté par Stéphane Traumat (site web personnel) . En réponse à la dépêche Sortie de Grails 1.0. Évalué à 6.
http://about.me/straumat
# UML
Posté par Stéphane Traumat (site web personnel) . En réponse à la dépêche Sortie de Netbeans 6.0. Évalué à 2.
http://about.me/straumat
[^] # Re: Prems
Posté par Stéphane Traumat (site web personnel) . En réponse à la dépêche Créer des Web services en deux clics (ou presque) grâce à Apache CXF et à la POA. Évalué à -1.
http://about.me/straumat
[^] # Re: Economies / dépenses
Posté par Stéphane Traumat (site web personnel) . En réponse à la dépêche Projet NACA : migration Mainframe IBM vers serveurs Intel/Linux. Évalué à 1.
Et je te signale que du coup, je vois pas en koi Java est plus verbeux, on on aurait pu faire
Client c = new Client("toto"); :)
http://about.me/straumat
[^] # Re: Economies / dépenses
Posté par Stéphane Traumat (site web personnel) . En réponse à la dépêche Projet NACA : migration Mainframe IBM vers serveurs Intel/Linux. Évalué à 2.
Et par sécurité, j'aurais du dire "Authentification/authorisation".
http://about.me/straumat