For the last part of this Hadoop series, I will introduce you the way to process graphs with Hadoop, through Apache Giraph.
In this second blog post concerning Hadoop, we are going to focus on the link between Hadoop and BIRT, the Eclipse-based reporting system. We will first present Hive, a component of Hadoop's ecosystem, then we will see how it can be connected to BIRT, and we will finish with an example that will illustrate more concretely how things work. If you missed the first episode, which is an introduction to Hadoop, its file system, and MapReduce, you can follow this link, to read the first part of this Hadoop blog post series.
Nous allons parler dans ce billet d'Hadoop, le framework Java d'Apache en vogue pour le traitement de données très volumineuses (pouvant aller jusqu'à plusieurs pétaoctets). Ce framework implémente notamment sa propre version de l'algorithme MapReduce, qui a été instauré par Google.
When a client connects to a RabbitMQ instance, it must be able to handle the failure of this instance. The cause of the failure can be an abrupt crash or a network glitch. These things happen, especially in cloud environments, where anything can die, anytime. Applications can't rely blindly on the middleware; the software must be able to recover from these kinds of failure, and not crash miserably. Let's see how a message sender can be made more robust and reliable with the RabbitMQ Java binding first, and then with the Spring AMQP project.
Lors de la What's Next, Jonas Bonér a présenté Akka, un framework facilitant la réalisation d'applications concurrentes, pouvant passer à l'échelle et tolérantes aux erreurs. Cet article tente de retranscrire le contenu de cette présentation.
This is the last part in a series of three showing how to build a simple JavaScript architecture.
After seeing how to create a NodeJS application to track tweets and send them to a Google Chrome Extension in real time, we are going to see how to store and query them using a MongoDB database.
For a better understanding, this post starts by explaining the basics of MongoDB and then deals with its integration in a NodeJS application.
In the first part of this series we saw how to create a simple Node server which tracks and broadcast tweets about the What’s Next event in real time.
In this one we’ll see how to develop a Google Chrome extension that will display the tweets thanks to the HTML5 notification API. The extension will also use the Local Storage API and the Socket.IO client side library.
This post is the first of a three-part series showing how to build a complete javascript architecture using :
To illustrate our architecture we are going to create a Node application that will track tweets about the “What’s Next” event and broadcast them in real time to the clients. The client will be a Google Chrome browser extension and will use two features of the HTML5 specification to display the tweets broadcasted by the server. In the last post I will introduce the MongoDB database, we will use it to store tweets and provide some statistics when the event ends.
Batch applications are quite common in IT systems: perhaps you won't have to write a whole batch application in your developper career but there are many chances you'll have some batch parts in your Web or desktop applications. Batch is about handling high volumes of data and a lot of things can go wrong or be tricky when it comes to batch: bad performances, very high memory footprint, complex recovery scenarios to avoid stopping a whole batch because of one bad item, etc. This article covers through a simple use case different approaches to tackle with batch applications. By comparing the runtime behavior of the approaches, we'll see the benefits on relying a batch framework like Spring Batch.
Jaxio viens d'annoncer que la société Steria utilise Celerio, le générateur de code Java, afin de développer BforBank, la première banque privée 100% en ligne du Crédit Agricole.
Ce générateur permet, depuis un schéma de base de données, de générer une application de mise à jour de la base. Cette application ainsi générée respecte les normes architecturales et patterns reconnus et est basé sur les technologies les plus courantes comme Spring, Spring WebFlow, Spring MVC, Spring Security et Hibernate. Il est ainsi plus aisé pour un développeur de répliquer ces patterns et d'enrichir l'application en focalisant sur les aspects métier.
Ce projet a ainsi pu passer en production seulement sept mois après l’écriture de la première ligne de code, Steria ayant pu se focaliser sur le développement des fonctionnalités métiers de BForBank.
La décision d’utiliser Celerio a été prise après avoir généré en ligne, sur www.springfuse.com, le socle technique d’une première maquette du projet. N'hésitez pas vous aussi à tester en ligne cet outil.
Cette Success Story sera présentée lors de la journée du « Model Driven » le 26 novembre 2009 à Issy-les-Moulineaux. Inscription gratuite
« billets précédents - page 1 de 2