Le paradigme est pensé pour pouvoir réutiliser Mapper et Reducer indépendamment et le langage Java permet l’héritage. Une fois la boite à outil constituée, l’écriture de nouveaux MapReduce en Java devient dans la plupart des cas concise et facilement utilisable par de nombreux développeurs.

De plus, il ne faut pas oublier de limiter au maximum les opérations de lecture, car cela représente un coût important en performance et donc en prix. Java permet d’avoir un maximum de contrôle sur ce point. Ce sujet est évoqué en fin de post et je crois qu’il mérite un billet à part entière.

Avec le niveau de détail de votre question, je vous recommanderais de regarder les offres de PaaS java :

• CloudBees : le premier PaaS Java production ready,
• CloudFoundry : le PaaS Java de VMware / Spring Source (encore en beta),
• OpenShift : le PaaS Java de RedHat.

Cyrille

Existe-t-il bien un Clojure User Group sur Genève ?
Je serais intéressé.

Comment vous contacter ?

Du coup, je suis à la recherche d’informations pour faire du TDD lorsqu’on souhaite faire de la persistance qui a des impacts non seulement sur les DAO mais aussi sur les managers/services spring (car les @Transactionnal sont souvent sur eux).

@Ugo : Sanlaville parlait d’utiliser @Transactionnal pour obtenir des tests parallélisables. dans tous les cas les tests présentés sont déjà des tests d’intégration : ils démarrent une base de données, hibernate et spring ..ça commence à faire

@Jean-Michel : je préfèrerai également travailler en ruby que j’ai pratiqué sur des projets personnels. En ce moment je suis passé à scala qui permet lui aussi des dsl bien plus concis, le typage fort en plus. Mais le nombre de projets dans ces technologies en france reste faible

comment faire une interaction entre drools et une interface et avec quel outil je construit l’interface?

merci

,J’ai bouffé 5 ans de java de 2001 à 2006 et c’est fou ce que java / spring peut etre verbeux et long …

hibernate =>http://datamapper.org/
db unit => https://github.com/thoughtbot/factory_girl/blob/master/GETTING_STARTED.md
parallel => https://github.com/grosser/parallel_tests

les start ups adorent ruby, le gouvernment anglais aussi : https://github.com/alphagov

Sinon, je me pose actuellement la question comment on peut faire des tests unitaires avec des transactions (par exemple avec Spring/Hibernate et annotation @Transactional). Si tu as des idées ou des liens, je suis preneur.

L’équipe Apache JMeter a le plaisir de vous annoncer la sortie d’Apache JMeter 2.6 r1237316.

Cette version apporte des améliorations notables ainsi que des corrections de bugs.

La liste exhaustive des changements se trouve à cette adresse:
http://jmeter.apache.org/docs/changes.html

Une nouvelle section « New and Noteworthy » agrémentée de copies d’écran montre les nouveautés importantes de cette version.

Cette version peut être téléchargée depuis:
http://jmeter.apache.org/download_jmeter.cgi

Il est conseillé de vérifier les signatures en utilisant le fichiers KEYS .

L’équipe JMeter

J’ai repris la métaphore du bus pour CDI ex-WebBeans, pas pour le sous-ensemble « notifier/observer » que vous citez.

C’est même un peu déroutant et faut faire attention quand on refactorise/change le code. C’est là que les tests d’intégration sont utiles…

« Le container CDI gère le cycle de vie des beans par rapport à des contextes web (Request, Conversation, Session, Application) – Le premier nom était « Web Beans ». »

oui, d’ailleurs, j’avais vu dans CDI ex-WebBeans un « kind of a Java application bus (somewhat similar to CORBA) », un genre de bus de composants ou d’events revisité à la sauce Java et qui permet de « coller » ou, plus simplement, de relier ces différents composant ensemble : http://www.jroller.com/dmdevito/entry/seam_is_a_kind_of

Oui, je corrige ma question initiale:
Est-ce que les extensions de CDI pourraient appartenir à une catégorie autre que les 3 catégories (de fonctionnalités) suivantes pour CDI : DI + AOP-like + EventBus ?
Merci

IMHO ce qu’apporte @Configuration par rapport à @Inject, c’est que tu maitrise entièrement ton graphe d’objet et surtout, tu as une erreur de compilation quand tu ajoutes un argument à ton constructeur (et aussi, ton code n’est pas pollué d’annotation dans tous les sens…)

Pour (essayer) de répondre à ta question, les extensions vont fournir des nouveaux composants (tout fait) au framework. Je prend des exemples de Seam3 (que j’ai déjà un peu manipulé): Cron Module, Social Module, Mail Module …

Un peu comme ce qu’il y a dans le monde Spring… En gros CDI c’est peu pensé pour être le Spring-killer (impression personnelle)

Enfin, pour ceux que CDI intéresse je vous conseille de lire la specs. Elle se lit très bien (comparée à d’autres) avec des exemples de codes. un vrai « user guide »

@Dominique De Vito: En effet, CDI implémente en quelque sorte DI. DI n’est finalement qu’une spécification décrivant une sémantique (des annotations) pour l’injection de dépendances.
Je crois qu’il manque un mot dans ta question, je ne suis pas sûr d’en comprendre son sens. En tout cas, les extensions CDI font partie intégrante de la spécification CDI via un SPI (service provider interface). Et, elles utilisent le « bus événementiels » de CDI.

Est-ce que les extensions de CDI pourraient appartenir à une catégorie que ces 3 catégories là ?

Merci

Perso, avec Java EE, pour faire mes tests unitaires, je fais du mock (Mockito).
Et je définis ces mocks uniquement en Java, sans Spring, car c’est toujours plus rapide de configurer mon mock en Java qu’en le définissant en XML avec Spring.

Bref, je ne vois pas ce que Spring pourrait m’apporter de plus pour les tests unitaires. De fait, pour mon projet actuel, Spring n’est plus utilisé pour nos tests unitaires.

Sinon, la section « Définir une implémentation alternative avec @Alternative » semble offrir une voie pour définir, avec CDI, une implémentation ad hoc pour les tests.

Pour ma part, avec spring, tomcat met 22s à démarrer pour une appli de 80000 lignes qui contient session factory avec 290 entities (je dirais à vue de nez que 50% du temps = liquibase qui vérifie qu’il n’a rien à faire, 30% = hibernate; 10% = openoffice, 10% = instantiation de spring, notamment scanning des @Configuration et @Contrller).

Néanmoins, je redémarre peu souvent : je développe en TDD la logique métier qui est exposé via un ws rest json.
Ensuite, le gui est entièrement en php+js => pas de rédémarrage.
En moyenne, je dois redémarrer 8 fois par jour…