vendredi 24 avril 2009

Veille technologique semaine 17

Pour le bulletin de cette semaine, je vous propose les articles suivants :
  • c'est finalement Oracle qui va racheter SUN : 7,4 milliards de dollars. Les conditions de pérennités des produits SUN n'étaient pas suffisamment garantit par IBM (beaucoup de doublons). Quelques analyses du web.
  • Le programme des sessions de JavaOne 2009 pour début juin 2009 à San Francisco.
  • Les EJB 3.1 : la version 3.1 atteind un niveau de maturité suffisant ?
  • Un article sur l'inversion de dépendances DIP (à ne pas confondre avec l'injection de dépendance DI, que l'on ne doit pas confondre avec l'inversion de contrôle IOC).
  • La configuration de Spring par annotations : simplifier vous la vie.
  • un article théorique de Wikipedia sur la covariance et la contravariance et l'invariance : deux notions souvent méconnues que les langages (y comprit Java) propose partiellement. Java propose le return des méthodes covariant : une redéfinition d'une méthode peut déclarer retourner une sous-classe du return de la méthode qu'elle redéfinit. Une méthode peut également déclarer lever une exception d'une sous-classe des exceptions de la méthode qu'elle redéfini. Dans tout les cas, Java reste safe au niveau du typage statique.

Bonne lecture.


Oracle Buys Sun
Oracle Corporation (NASDAQ: ORCL) and Sun Microsystems (NASDAQ: JAVA) announced today they have entered into a definitive agreement under which Oracle will acquire Sun common stock for $9.50 per share in cash. The transaction is valued at approximately $7.4 billion, or $5.6 billion net of Sun's cash and debt. "We expect this acquisition to be accretive to Oracle's earnings by at least 15 cents on a non-GAAP basis in the first full year after closing. We estimate that the acquired business will contribute over $1.5 billion to Oracle's non-GAAP operating profit in the first year, increasing to over $2 billion in the second year. This would make the Sun acquisition more profitable in per share contribution in the first year than we had planned for the acquisitions of BEA, PeopleSoft and Siebel combined," said Oracle President Safra Catz.

"The acquisition of Sun transforms the IT industry, combining best-in-class enterprise software and mission-critical computing systems," said Oracle CEO Larry Ellison. "Oracle will be the only company that can engineer an integrated system – applications to disk – where all the pieces fit and work together so customers do not have to do it themselves. Our customers benefit as their systems integration costs go down while system performance, reliability and security go up."


Oracle rachète Sun
La nouvelle est tombée à la surprise générale : Oracle a racheté Sun.
Malgré les rumeurs persistantes de rachat par IBM qui courraient depuis quelques semaines, c'est bien l'éditeur du célèbre SGBD qui a mis la main sur le convoité créateur de Java. Le rapprochement de ces deux poids lourds du monde J2EE risque d'entrainer de profonds changements dans nos écosystèmes dans les mois à venir.


Oracle Buys Sun - Coverage from around the Web
In what could be the most important decision of the year, after weeks of speculation of IBM buying out Sun, which failed to produce a result, today Oracle have swept in and bought Sun. DZone has assembled a collection of news coverage and 'Tweets' from around the Web (this list will be updated throughout the week -- feel free to post additional links in response to this thread).


What's Going to Happen with OpenOffice, MySQL, SPARC?

With today's surprise announcement that Oracle will acquire Sun Microsystems, several questions were raised as to some Sun products, including MySQL, Solaris, and OpenOffice.org. Browsing around the net, there are several viewpoints on the future of these Sun products, and the OpenOffice.org team has even issued a statement itself.

Let's start with the OpenOffice.org team. They are optimistic about this announcement, and are happy that this marks the end of the uncertainty around Sun's future. "We've been very comfortable with the way that Sun set up the project and has kept a careful eye on us over the years," John McCreesh, OpenOffice.org's marketing lead, told ZDNet, "They'll be a hard act to follow, but we'll approach the future with optimism and an open mind."

A more problematic situation could arise for MySQL. What would Oracle, a company focussed on database products, see in the open source database MySQL? Software engineer Ryan Thiessen, an 11-year MySQL veteran, will be speaking at the MySQL Conference this week, and he wrote a blog post this morning, titled "Stunned".


I am stunned at the news that Oracle is buying Sun. This is not because I fear change or uncertainty, last time this year I was cautiously optimistic about Sun's purchase of MySQL. But not this year, it's fear and disappointment over what this means for MySQL.

When I read this as a rumour a few weeks ago I thought it was a joke of an idea. Why would a high margin software company want to buy a declining hardware business, even if that hardware is great? As for their software, I cannot imagine that Oracle is interested in Java, MySQL, etc as revenue generating products, it would just be a tiny blip for them.

Another line of thinking goes into another direction than Thiessen's. Oracle serves the higher end of the database market, compared to MySQL which focusses on the lower end of the same market. With round and about 11 million installations, MySQL offers Oracle a lot of leverage in a market they previously didn't really took part in. "While no one could ever rightfully claim that MySQL threatens Oracle's higher-end database offerings, its addition to the portfolio gives Oracle additional leverage in a market with significant growth potential," Independent analyst Carmi Levy told BetaNews, "The MySQL installed base of approximately 11 million gives Oracle sales teams fertile opportunity to have conversations they haven't previously had."

Personally, I fear the future of the SPARC platform. SPARC hasn't exactly been doing stellar lately, and has all but vanished from the workstation segment. In the high performance computing market, it isn't doing very well either; in 2002, 101 of the Top 500 supercomputers were SPARC-based - now, that has dropped to just one. Developing and maintaining your own architecture is a costly business, especially in the face of cheap x86 processors.

As a final note, both IBM and Microsoft were surprised by the announcement. "I just learnt it [...] I need to think about it. I am very surprised," Steve Ballmer told Reuters. Apparently, IBM was surprised as well; they were still hoping to buy Sun.



JavaOne 2009 : le programme des sessions

L'annonce du programme des plus grosses conférences du monde Java est toujours intéressante car elle permet d'observer les tendances du moment, du point de vue des organisateurs tout du moins.

Celui de JavaOne 2009 est maintenant connnu. L'observation de ce programme permet de constater que certaines technologies sont particulièrement mises en avant :

  • JavaFX : incontestablement le sujet majeur de ce JavaOne, faisant de cette conférence le bras armé de Sun pour la mise en oeuvre de sa très agressive stratégie marketing. En effet tous types de sessions confondus (BOFs, conférences techniques, Hands on, …), on compte pas moins de 40 sessions dédiées à JavaFX sur les 350 que comptera au total cette édition de JavaOne.
  • JEE 6 et JDK7 : assez logiquement, du fait de leur planning de finalisation, ces deux technologies sont très présentes grâce à des sessions dédiées à chacune de leurs composantes.
  • Rest et Cloud Computing : en terme d'évolution de l'architectures des applications, le Cloud Computing et Rest sont les deux concepts qui semblent destinés à marquer le plus l'année 2009 et JavaOne s'en fera donc l'écho.
  • Complex Event Processing : cette technologie, consistant à analyser les évènements d'une EDA, n'est pas nouvelle, il en est question depuis plus de 5 ans. Toutefois elle connaît un nouvel essor depuis peu. Après avoir fait une apparition lors de Devoxx en décembre dernier, c'est maintenant JavaOne qui va lui consacrer 4 sessions contre aucune lors de sa précédente édition.

EJB 3.1
Enterprise Java Beans (EJB) is a server-side component architecture for the Java Enterprise Edition (Java EE) platform, aiming to enable rapid and simplified development for distributed, transactional, secure and portable applications :
  • No-Interface View
  • Singleton
  • Asynchronous Invocations
  • Global JNDI names
  • Timer-Service
  • EJB Lite
  • Simplified EJB Packaging
  • Embeddable EJB Containers
  • Best of the Rest
  • Conclusions


Examining the Dependency Inversion Principle

The Dependency Inversion Principle is defined as follows:

  • A. High-level modules should not depend upon low-level modules. Both should depend upon abstractions.
  • B. Abstractions should not depend upon details. Details should depend upon abstractions.

In conventional architecture, higher-level components depend upon lower-level components.

Conclusion
The Dependency Inversion Principle sets forth a design strategy for allowing higher-level modules to be easily reused by reversing conventional dependency relationships, though at times dispensing with the ability to reuse equally valuable lower-level modules. While lacking the notion of dependency inversion, a combination of the Separated Interface pattern with the Adapter pattern can be leveraged to achieve the same design goals without the negative consequences of coupling lower-level components unnecessarily. Nevertheless, the strategy set forth by the Dependency Inversion Principle offers a good intermediate level approach for decoupling the higher-valued components within an application.



Spring Annotations
Depuis ses débuts, le moyen le plus courant de configurer Spring a été basé sur XML.
Mais comme les développeurs sont apparemment lassés de naviguer sans fin à travers un dédale de crochets, des utilisateurs ont commencé à chercher d'autres moyens pour connecter leurs beans dans leurs applications basées sur Spring.

Spring a répondu avec des options de configuration basées sur les annotations.
Dans cette carte de référence, vous trouverez un guide à l'ensemble des annotations proposé par Spring 2.5.


Covariance and contravariance (computer science)
From Wikipedia, the free encyclopedia

vendredi 17 avril 2009

Veille technologique semaine 16

Pour le bulletin de cette semaine, je vous propose les articles suivants :

  • Google et son hébergement d'application avec Google App Engine : depuis l'annonce par Google, un certain nombre de retours d'expériences sont publiées. Toutes relativement positives. C'est bien une annonce majeur dans l'hébergement d'application sur une JVM. Il faut bien comprendre que, en plus du langage Java, JRuby et Groovy sont aussi accueillis. Bientôt scala et peut-être Jython ?
  • Toujours Google, avec la sortie de la plate-forme Java pour les smart phones : Androïde en version 1.5.
  • Enfin Terracotta qui sort la version 3 du produit Terracotta DSO (Distributed Shared Object). Cette solution de distribution d'objets (réplication entre JVM) a fait de très gros progrès en terme de performance : plus de 2000 transactions par seconde par core de CPU. Cette solution est toujours la plus performante en terme de productivité avec plusieurs ordre de grandeur.

  • Le profile UML pour les architectures SOA est proposé par l'OMG : SoaML. On peut remarquer la présence de THALES et Softeam comme contributeur à cette spécification.
  • Les chercheurs d'IBM qui prédisent la fin de la loi de Moore !
  • Un article au sujet des langages de description d'architecture logiciels. On peut constater que l'industrie du logiciel est à la préhistoire de ces pratiques, et que la séparations des préoccupations est encore très loin d'être mise en oeuvre. Le mélange du code métier avec le code technique fini par être un amas de code inextricable. L'architecture logicielle est encore trop dépendante des socles techniques, alors que le cycle de vie de nos systèmes est supérieur à cycle de vie des technologies : il faut se débarrasser de cette dépendance et avoir un langage de description de l'architecture logicielle qui soit agnostique (ne connais pas et ne veut pas connaître : pas de dépendance) du socle technique.
  • SUN prépare la prochaine session de JavaOne pour Juin 2009 à San Francisco : la plus grande exposition du monde Java.

  • Un article sur le prochain garbage collector du JDK 7 porté sur le JDK 6 update14 (bientôt disponible). C'est un très grand progrès sur la réduction du temps de latence lié au garbage collecteur : réduction jusqu'à un rapport 10. Avec un article technique qui complète.
  • Une doc sur JUnit et EasyMock : à grader à coté du clavier.
Bonne lecture.

Google App Engine pour Java et Groovy

Google App Engine, solution de Cloud Computing proposée par Google supporte depuis la semaine dernière (en plus du langage Python disponible depuis un an) le langage Java. Cette solution permet dorénavant de déployer son application web à base de servlets (sous forme de war) sur un serveur virtuel hébergé sur l'infrastucture de production de Google (Google a donné la semaine dernière un compte Google App Engine Java aux 10 000 premiers inscrits).

Google met en avant les avantages suivants :

La facilité d'utilisation via un SDK très documenté et des plugins Eclipse.
La scalabilité gérée de manière transparente et automatique
La fiabilité et la performance fournies par les infrastructures de Google
Enfin, App Engine est gratuit si votre serveur n'excède les 500 Mo de stockage et 5 millions de page visualisées par mois

Google fait une entrée de manière fracassante dans le marché du cloud computing "Java" (Amazon EC2, etc.. ) et propose une offre séduisante où chacun peut créer, tester et déployer son application facilement. La création d'un projet App Engine sous Eclipse via le plugin est simple et le déploiement sur App Engine s'effectue en un seul clic.

Quelques liens utiles :

vous pouvez trouver une description très complète de la solution (en Français) sur le blog de Frank Arnulfo
David Gageot a mis en ligne une feuille Google Spreadsheet qui liste les librairies et frameworks Java supportés par Google App Engine
Groovy est également supporté, retrouvez l'annonce sur le blog de Guillaume Laforge


AppEngine et Azure, la synthèse
  • Pourquoi cette annonce est-elle affichée partout comme une révolution ?
  • Quelles sont les implications pour les entreprises et le logiciel en général ?
  • Pourquoi ferais-je confiance à Google pour héberger mon SI ?
  • Que vaut la plateforme technique GAE/J de Google aujourd'hui ?
  • Comment se situe AppEngine par rapport à Azure ?
  • Le mot de la fin ...

Google App Engine et Java: une révolution ?
  • GAE c'est quoi ?
  • Contraintes et persistence de données
  • Console d'Administration
  • Versioning
  • Développement/Déploiement & GWT:
  • Coûts ?
  • Ouverture de GAE à d'autres langages
  • Cron , Secure Data connector
  • Conclusion : Révolution ?

Mobilité Preview d'Android 1.5

En attendant la sortie finale d'Android 1.5 (Cupcake) à la fin du mois, Android Developers Blog annonce la sortie d'une pré-version du SDK 1.5 pour les développeurs d'applications Android.
Parmi
la liste complète des nouveautés d'Android 1.5, cette pré-version du SDK propose notamment:

  • le clavier virtuel
  • le développement de widgets pour l'écran d'accueil (à l'image de l'horloge ou du widget de recherche qui existent déjà dans Android)
  • la fonctionnalité live folders
  • la reconnaissance vocale

Ce nouveau SDK propose également une avancée intéressante : la possibilité de gérer plusieurs versions du SDK en parallèle, par exemple ici les versions 1.1 et 1.5. Les développeurs pourront donc tester leur application sur plusieurs environnements sans manipulations fastidieuses.
Afin de commencer à tester vos applications sur cette nouvelle version d'Android, vous pouvez télécharger ce SDK 1.5
en cliquant ici.


Terracotta Distributed Shared Objects 3.0 released
Terracotta has announced the release of Terracotta 3.0, adding a new operations center, a very nice developer console that shows you the health and performance of your cluster, and adding many new certified platforms.

Terracotta provides a distributed object heap, where you specify a set of instances and class types as being shared among various JVMs. The client connects to a DSO server in a form of hub and spoke network architecture, and any changes to the shared objects get propagated to every other participating client JVM.

The servers can be striped and can also manage hot failover between primaries and backups.

The developer console looks particularly nice, showing heap and runtime statistics information, as well as diagnostics covering your cluster performance.

DSO comes in an "ES" edition, which is OSS and lacks some of the more sophisticated networking capabilities, and also has commercial versions which provide access to the full feature set.


UML-based SoaML attacks SOA services modeling issues
SOA has made progress through the years without an associated language - and some people would say a SOA language in itself would not be a good idea, thank you very much. But what about a UML profile that might help architects and developers better describe the services at the heart of SOA?

That is in part the goal of SoaML, the Service oriented architecture Modeling Language. This spec, fashioned as a profile of UML, has spent a couple of years going through the standards processes of the Object Management Group (OMG) and appears to be nearing finalization. Sponsors include Capgemini, EDS, IBM, ModelDriven Solutions, and others.

The SoaML cause last month advanced further when the NoMagic modeling concern bundled open-source ModelPro with SOAML in its Cameo SOA+ suite. This combo supports a graphical approach to services modeling.





Report: IBM researcher says Moore's Law at end
Moore's Law is maxing out. This is an oft-made prediction in the computer industry. The latest to chime in is an IBM fellow, according to a report. Intel co-founder Gordon Moore predicted in 1965 that the number of transistors on a microprocessor would double approximately every two years--a prediction that has proved to be remarkably resilient. But IBM Fellow Carl Anderson, who researches server computer design at IBM, claims the end of the era of Moore's Law is nigh, according to a report in EE Times. Exponential growth in every industry eventually has to come to an end, according Anderson, who cited railroads and speed increases in the aircraft industry, the report said.


Architecture as Language :
Architecture is typically either a very non-tangible, conceptual aspect of a software system that can primarily be found in Word documents, or it is entirely driven by technology ("we use an XML architecture"). Both are bad: the former makes it hard to work with, and the latter hides architectural concepts behind technology hype.

What can be done? As you develop the architecture, evolve a language that allows you to describe systems based on this architecture. Based on my experience in a number of real-world projects, this makes the architecture tangible and provides an unambiguous description of the architectural building blocks as well as the concrete system while still staying away from technology decisions (which then can be made consciously in a separate step).

... They had no language to talk about the system...

This is actually a very common observation when I arrive in projects to help out. And of course this is something which I think is a huge problem: if you don't know the kinds of things from which your system will be composed it is very hard to actually talk about, describe, and of course build the system consistently. You need to define a language.

...

Conclusion
Using the approach, we were able to quickly get a grip towards the overall architecture of the system. We also were able to separate what we wanted the system to do from how it would achieve it: all the technology discussions were now merely an implementation detail of the conceptual descriptions given here (albeit of course, a very important implementation detail). We also had clear and unambiguous definition of what the different terms mean. The nebulous concept of component has a formal, well-defined meaning in the context of this system.




Java + You = Innovation
It's that time of year again. The 2009 JavaOne conference takes place at the Moscone Center in San Francisco from June 2-5 and is being sponsored by Intel (a Platinum sponsor), JBoss, and Sony Ericsson. This year's technical and Birds-of-a-Feather (BOF) sessions are organized around four topics: Rich Media Applications and Interactive Content; Mobility; Services; and Core Technologies.



Sun's Garbage First Collector Largely Eliminates Low Latency/High Throughput Tradeoff
Sun's Garbage First garbage collector
(hereafter referred to by its nickname G1) is the new low latency garbage collector planned to replace CMS in the Hotspot JVM. It is a server-style collector, targeted at multi-processor machines with large amounts of memory. There are two major differences between CMS and G1. The first is that G1 is a compacting collector. Compacting, a process by which live objects are moved over free memory space towards one end of the heap so that the other becomes one contiguous free area of memory, is important in long running applications because it is inevitable that the heap will fragment over time. G1 compacts sufficiently to completely avoid the use of fine-grain free lists for allocation, which considerably simplifies parts of the collector and mostly eliminates potential fragmentation issues. As well as compacting, G1 offers more predictable garbage collection pauses than can be obtained with the CMS collector and allows users to set their desired pause targets. This strong determinism gives G1 some of the characteristics of a true real-time collector but it isn't genuinely hard real-time since factors like OS scheduling still mean that the pauses cannot be guaranteed. It is however considerably easier for developers to use than the Java real-time products since existing code is able to take advantage of the improved performance that it offers without needing to make any code-level changes. G1 uses a number of interesting techniques, based on global marking information and other metrics, to prioritise regions for collection according to their GC efficiency. A previous InfoQ article provides more of the technical details.


JavaOne: Garbage First
Sun's HotSpot Garbage Collectors can be divided into two categories: The young generation and the tenured generation. The majority of allocations will be done in the young generation, which is optimized to have a short lifetime relative to the interval between collections. Objects that survive several collections in the young generation get moved to the tenured generation, which is typically larger and collected less often. The young generation collectors are Serial, ParNew and Parallel Scavenge. All three are stop-the-world copying collectors. Serial uses a single GC thread, whilst ParNew and Parallel Scavenge both use multiple threads. The tenured collectors all use a mark-sweep-compact algorithm. Again three are currently in use: Serial Old, which is another single GC thread, Parallel Old which using multiple GC threads and CMS, a mostly concurrent low pause collector. Garbage First aims to replace CMS and takes a somewhat different approach, straddling the young generation - tenured generation boundary.


JUnit and EasyMock
Unit testing and test driven development are proven ways to improve both the productivity of a developer and the quality of their software. JUnit and EasyMock are the predominant choices for testing tools in the Java space. This reference card will guide you through the creation of unit tests with JUnit and EasyMock. It contains detailed definitions for unit testing and mock objects as well as a description of the lifecycle of each. The APIs for both JUnit and EasyMock are covered thoroughly so you can utilize these tools to their fullest extent.

vendredi 10 avril 2009

Veille technologique semaine 15

Pour le bulletin de cette semaine, je vous propose les sujets suivants :
  • IBM ne rachètera pas SUN : aucun accord n'a été trouvé.
  • l'extension internet .tel a été ouverte en mars dernier : pour devenir l'annuaire universel du Web ?
  • La plus grosse annonce de cette semaine, pour la communauté Java, est faite par Google qui propose un hébergement d'application sur ses serveurs avec un runtime Java : JVM. La Google App Engine acceptais précédemment uniquement du Python. Elle propose maintenant tous les langages qui s'exécutent sur une JVM : Java évidemment mais aussi Groovy, JRuby, ... C'est une ouverture très importante de Google pour les développeurs d'application serveurs. Des ressources CPU, disque, bande passante avec des quotas est accessible gratuitement, des ressources supérieures sont payantes.
  • Un article sur les cinq models de développement : lequel préférer vous ?
  • Un résumé sur le langage Java et quelques API : à garder à coté du clavier.
Bonne lecture


IBM-Sun Takeover Talks Collapse
IBM's talks to acquire Sun Microsystems have broken down according to media reports.


Le '.tel' peut-il devenir un annuaire global ?
C'est une extension Internet complètement atypique, sans sites et sans emails,
qui a en plus la bonne idée de sortir en plein milieu de la crise.
Pourtant, le '.tel' semble rencontrer le succès. Son but : devenir l'annuaire universel du Web.


La syntaxe d'un nom de domaine .tel
Un nom de domaine .tel doit remplir un certain nombre de conditions syntaxiques afin que son enregistrement soit accepté :
- il doit contenir un minimum de 3 caractères à choisir parmi les lettres de "a" à "z" ou de "A" à "Z" (en ASCII standard US) , les chiffres de "0″ à "9″ et le tiret ("-")
- il ne peut contenir plus de 63 caractères (sans compter l'extension .tel)
- il doit contenir au moins une lettre de "a" à "z" ou de "A" à "Z" (en ASCII standard US)
- il ne doit pas commencer ou se terminer par un tiret ("-")
- il ne doit pas contenir un tiret ("-") en 3
ème ou 4ème position
- il ne doit pas être exclusivement composé de chiffres
Ce qui laisse tout de même un nombre respectable de possibilités et de la place pour faire preuve d'imagination et de créativité …

Seriously this time, the new language on App Engine: Java
Today, we're very excited to announce the availability of a new programming
language for Google App Engine. Please welcome the Java runtime!


App Engine Java Overview
"With App Engine, you can build web applications using standard Java technologies and run them on Google's scalable infrastructure. The Java environment provides a Java 6 JVM, a Java Servlets interface, and support for standard interfaces to the App Engine scalable datastore and services, such as JDO, JPA, JavaMail, and JCache.":

App Engine uses the Java Servlet standard for web applications. You provide your app's servlet classes, JavaServer Pages (JSPs), static files and data files, along with the deployment descriptor (the web.xml file) and other configuration files, in a standard WAR directory structure. App Engine serves requests by invoking servlets according to the deployment descriptor.

The JVM runs in a secured "sandbox" environment to isolate your application for service and security. The sandbox ensures that apps can only perform actions that do not interfere with the performance and scalability of other apps. For instance, an app cannot spawn threads, write data to the local file system or make arbitrary network connections. An app also cannot use JNI or other native code. The JVM can execute any Java bytecode that operates within the sandbox restrictions.

I also just noticed that Google turned on billing while I wasn't looking, so it's now possible to pay for additional quota(CPU, bandwidth in/out, storage, and e-mail) if the initial free allotment doesn't suffice.


Run your web applications on Google's infrastructure.
Google App Engine enables developers to build web applications on the same scalable systems that power our own applications.


Google Plugin for Eclipse
The Google Plugin for Eclipse is the fastest way to start developing Google Web Toolkit and App Engine applications, allowing you to go from installing the plugin to deploying an Ajax "Hello World" in a matter of minutes. Simply install the plugin and get started. If you don't have the GWT and App Engine SDKs installed, the plugin can take care of that for you.


Java et Groovy sont maintenant supportes par Google App Engine
Google vient de rendre disponible un ensemble de nouvelles fonctionnalités pour Google AppEngine : support des batchs cron, import/export depuis la base de données, middleware permettant de rendre accessible des données derrière votre firewall et support du runtime JAVA.

Google fournit aussi un trés bon plugin pour Eclipse qui permet :

  • de créer un projet AppEngine
  • de tester l'application sur un runtime local
  • de déployer l'application sur AppEngine
Enfin, l'internet s'ouvre aux développeurs java, Groovy et JRuby !

A noter que SpringSource a travaillé pour que Groovy soit supporté et ça marche...

Le service ne sera ouvert qu'a quelques développeurs dans un premier temps, c'est ici :

http://appengine.google.com/promo/java_runtime


Google Brings App Engine's Pros and Cons to Java
Google has broadened their Google App Engine (GAE) support to include Java in addition to Python. This addition brings a large set of Java ecosystem related tools, frameworks, and languages (like JRuby and Clojure) along for the ride. However, it also imposes a number of limitations on the GAE. Java applications to further Google's ability to scale and cluster them with minimal effort.


Google App Engine for Java: TSS First Look
Google App Engine celebrates its first anniversary with a slew of announcements that increase the robustness (and enterprise appeal) of Google App Engine: flexible pricing, real cron support, ability to import/export data, a secure data connector, and the main feature: 100% Java App
Engine.


Dynamic languages on Google App Engine - an overview
Google has released App Engine support for Java. This is obviously very cool - and I¡¯ve spent a few weeks testing several things using it. It should come as no surprise that my main goal with this investigation has been to see how dynamic languages fit in with the Java story. The good news are these: JRuby works very well on the infrastructure.


5 types of Model Driven Software Development

  • Programming - the manual work
  • Code generation - automation
  • MDA - abstraction
  • DSL - specializing
  • MDE - from problem to solution

What approach do you prefer and why?



Core Java
  • Java Keywords
  • Standard Java Packages
  • Character Escape Sequences
  • Collections and Common Algorithms
  • Regular Expressions
  • JAR Files

vendredi 3 avril 2009

Veille technologique semaine 14

Pour le bulletin de cette semaine 14, je vous propose les sujet suivants :
  • un premier article au sujet du développement au forfait qui n'est pas compatible avec les besoins d'itérations des méthodes agiles (modification des spécifications).
  • un article sur les problème de mesure de la qualité (et la non qualité) pour pouvoir réduire cette non qualité. Il faut des critères mesurés par des outils.
  • Quatre gurus donnent leur point de vue sur la qualité du code.
  • Premier chapitre du livre "Coder propement" : Introduction. La lecture de ce livre est fortement recommandé à tous ceux qui manipule du code.
  • Un petit memo sur les 23 design patterns du Gang Of Four (GOF).
  • Encore quelques articles au sujet du JDK 7 :
    • Le JDK 7 en open sources
    • le projet coins : fin des proposition d'évolution du langage
    • le JDK 7 et les performances d'accès aux tableau et sur l'arithmétique
    • le projet de modularisation du JDK
    • Un article sur les enumérés dynamique.

Bonne lecture



Pourquoi les projets agiles ne peuvent pas (vraiment) être menés au forfait.
En matière de sous-traitance du développement logiciel, la pratique contractuelle la plus fréquente est celle dite du projet au forfait. La notion de forfait n'a, en principe, pas de rapport avec le processus de développement ou les pratiques d'ingénierie utilisée dans la réalisation du projet. Il s'agit simplement, dans l'esprit des contractants, de fixer les contours exacts de leur relation commerciale, et de définir leurs obligations mutuelles – en terme de coûts, de délais, de mode de paiement et de livraison.
Ce processus de développement est aujourd'hui fortement remis en question, sous le constat empirique de son échec relatif, et sous l'impulsion des méthodes agiles. Je pense quant à moi que la "cascade" sera perçue dans quelques années comme l'aveuglement juvénile d'une industrie encore adolescente, à la recherche de son identité.
La question qui nous intéresse ici est de savoir si le projet au forfait survivra à la cascade.


Mesurer la qualité d'un projet pour le désendetter

En ingénierie logicielle, tant qu'un projet se développe, la dette technique s'accumule inexorablement. Les sessions de refactoring sont là pour contrebalancer cette tendance et leur mise en place régulière garantit la maintenabilité du projet. Mais ce qui est délicat avec la dette technique, c'est qu'elle n'est pas vraiment mesurable, et comme l'iceberg, on n'en voit que la partie émergée. Résultat, le refactoring est souvent sous estimé et mal maitrisé. Si on ajoute à cela une mauvaise couverture de test, refondre le code applicatif fait peur, fait mal.


Plus personne n'a l'audace de le tenter, et à long terme, c'est la banqueroute assurée du projet.


L'objectif de cet article est de proposer une approche efficace pour savoir comment attaquer efficacement un grosse refonte d'un code mal couvert par les tests. Cette tâche technique est divisée en plusieurs problématiques : comment déterminer les zones de risque du projet, trouver où poser les tests pour sécuriser l'étape de refactoring et trouver les zones à refactorer.



The Developer Insight Series, Part 1:
Write Dumb Code -- Advice From Four Leading Java Developers
Most performance problems these days are consequences of architecture, not coding -- making too many database calls or serializing everything to XML back and forth a million times.
While we write code to run on a machine, the primary consumers of code are humans
.


Coder proprement

La maîtrise de l'art du métier englobe deux parties : connaissances et travail. Vous devez acquérir les connaissances concernant les principes, les motifs, les pratiques et les heuristiques connus de l'artisan, et vous devez également polir ces connaissances avec vos doigts, vos yeux et vos tripes, en travaillant dur et en pratiquant.

Je peux vous enseigner la physique qui permet de rouler à vélo. Il est vrai que les mathématiques classiques sont relativement simples. Gravité, frottements, moment angulaire, centre d'inertie, etc. peuvent être expliqués en moins d'une page d'équations. Grâce à cette formule, je peux prouver qu'il vous est possible de rouler à vélo et vous apporter toutes les connaissances dont vous avez besoin pour ce faire.
Néanmoins, vous tomberez immanquablement la première fois que vous grimperez sur la bicyclette.

Écrire du code n'est pas si différent. Nous pourrions rédiger tous les bons principes d'écriture d'un code propre et vous faire confiance pour réaliser le travail (autrement dit, vous laisser tomber lorsque vous monterez sur le vélo), mais quelle sorte de professeurs serions-nous alors et quelle sorte d'étudiant seriez-vous ?


Apprendre à écrire du code propre est un travail difficile. Cela ne se limite pas à connaître des principes et des motifs. Vous devez transpirer. Vous devez pratiquer et constater vos échecs. Vous devez regarder d'autres personnes pratiquer et échouer. Vous devez les voir hésiter et revenir sur leurs pas. Vous devez les voir se tourmenter sur des décisions et payer le prix de leurs mauvais choix.



ABOUT DESIGN PATTERNS

This Design Patterns refcard provides a
quick reference to the original 23 Gang of Four design patterns, as listed in the book Design Patterns: Elements of Reusable Object-Oriented Software. Each pattern includes class diagrams, explanation, usage information, and a real world example.


Java 7: new coffee
Big changes
JVM changes
Project Coin
Conclusion

The biggest difference compared to previous Java releases is the fact that all development is done in the open. Most of it will be part of the OpenJDK project, and otherwise as part of the Java 7 project. The OpenJDK development release, which already contains some improvements for Java 7, can be downloaded and installed at this very moment. So check it out if you want to try the new features!



Project Coin: The Call for Proposals Phase is Over!
Project Coin's call for proposals phase is now over! Thirty four days long, the proposal period included nearly 70 proposals being sent to the mailing list, 19 coming in over the last two days, and over 1100 messages on the list discussing those proposals and related topics. With the flurry of pre-deadline activity over, the more deliberative task of finishing reviewing and evaluating the proposals awaits.



JDK 7 Twice as Fast* as JDK 6 for Arrays and Arithmetic
The 7th version of the Java Developer's Kit (aka JDK 7) delivers quite a speed boost over JDK 6 array accesses. For us, this is huge. It's like another year and a half of Moore's law for free.


Java's always suffered relative to C in straight matrix multiplication because Java does range checks on every array access (set or get). With some clever static and run-time analysis, Würthinger et al. are able to eliminate most of the array bounds checks.



Project Jigsaw

Vision The JDK is big—and hence it ought to be modularized. Doing so would enable significant improvements to the key performance metrics of download size, startup time, and memory footprint.

Java libraries and applications can also benefit from modularization. Truly modular Java components could leverage the performance-improvement techniques applicable to the JDK and also be easy to publish in the form of familiar native packages for many operating systems.


Finally, in order to realize the full potential of a modularized JDK and of modularized applications the Java Platform itself should also be modularized. This would allow applications to be installed with just those components of the JDK that they actually require. It would also enable the JDK to scale down to
smaller devices, yet still offer conformance to specific Profiles of the Platform Specification. Okay—so where do we start?


Dynamic enums in Java

The introduction of Enums in Java 5 finally provided a powerful (and slightly magical) way of modelling fixed sets. One can have too much of a good thing, however, and in some situations an enum is a little too fixed to be convenient. Here, I'd like to discuss a pattern I'll call - for want of a better name - the dynamic enum, that addresses this issue.

"'Dynamic enums'? Isn't that a bit like 'type-safe scripting language' or 'fully-specified requirements'?" Well, let me try to outline the intended purpose of a dynamic enum: