Pour le bulletin de cette semaine, je vous propose les sujets suivants :
- Microsoft a fait une démonstration de Windows 8 sur processeur ARM.
- Les mémoires flash gravées à 20nm annoncées par Intel.
- Un nouveau langage de programmation (un de plus) : Ceylon. Le compilateur de ce langage génère du byte code JVM. Depuis 1998, les runtimes JVM (Java) et CLR (DotNet) sont les runtimes cibles de différents langages, il est plus facile de faire un nouveau langage car il n'est plus nécessaire de faire les runtimes. Il faut juste faire la théorie du langage et le compilateur correspondant (plus quelques API de base). La conséquence est que l'on va avoir un nouveau langage par ans. Bientôt chacun son langage ? (chacun son DSL ?).
- La stratégie d'Oracle sur la plateforme Java : par Oracle : 1,5 milliards de dollars de R&D sur la plate-forme Java.
- La préparation de JEE7 (Java Enterprise version 7) prévue pour 2012.
- Quels est la mission du développeur de logiciel : Rentability, quality and maintainability.
- Après un premier article sur la nécessité de modéliser un système logiciel, le deuxième article explique la différence entre une donnée, un traitement et les objets. C'est très important de bien séparer ces concepts pour bien construire une architecture logicielle qui sépare correctement les responsabilités de chaque partie. A lire attentivement. Je suis intéressé par vos remarques.
- Une série d'articles au sujet de Protocole Buffer de Google qui est une technologie qui permet d'échanger des données entre langages différents, avec gestion du changement de version. Cet encodage binaire est 20 à 100 fois plus rapide que le XML des Web Services (on s'en serait douté). Google n'a pas souhaité faire une usine à gaz (principe KISS : Keep It Short and Simple).
- La classe JLayer du JDK 7 : pour décorer vos composants Swing.
Microsoft a un Windows tournant sur les processeurs ARM
On savait déjà que Windows 8 serait aussi développé pour fonctionner avec les processeurs ARM. Microsoft en serait plus qu'à l'état de projet. Ils auraient une version de Windows capable de tourner sur un processeur ARM cadencé à 1 GHz.
Visiblement, la société n'en peut plus de dépendre autant d'Intel qui a tant de mal à faire autre chose qu'une pâle figuration dans le monde des tablettes, même s'ils travaillent très dur à fabriquer un processeur X86 ayant un rapport consommation puissance aussi favorable que les puces d'ARM.
C'est donc la fin d'un dogme pour Windows. Mac OS a tourné sur des processeurs 68000, Power PC et Intel, Linux a vu encore plus large, Windows était encore le seul aussi ancré dans deux architectures : x86 et Alpha (windows NT).
Intel et Micron annoncent de la mémoire Flash NAND gravée en 20 nm
Intel et Micron ont dévoilé une technologie de production permettant de fabriquer de la mémoire Flash NAND MLC 8 Go gravée en 20 nm, qui pourra trouver sa place dans de futurs smartphones et tablettes, ou dans des disques SSD.
Ceylon JVM Language
Given as a talk at QCon Beijing, Gavin King presented the Ceylon programming language, which he has been working on at Red Hat for the last couple of years. The news was picked up via twitter, and now a number of sites are reporting it, including Lambda the Ultimate, Slashdot and Reddit and YCombinator Hacker News. As a result, Gavin has posted a a post specifically on Ceylon with references to the presentations that caused the stir. He also makes clear that it was never designed as a Java killer:
Some insights from Oracle on the their plans for Java
Henrik is Oracle's director of Java platform strategy - and an official spokesperson
from Oracle, able to pronounce on behalf of Oracle regarding Java. Henrik was able to give us the following insights (some of which you may have heard before):
Jerome Dochez Discusses Early Plans for Java EE 7, Planned to Ship in 2012
One of the main themes for Java EE 7 is the Cloud. How does running an application on the Cloud differ from running it on an existing Java EE container?
What is the mission of any software developer?
In software development there are only three measurable areas that encapsulate all that is important in an application: Rentability, quality and maintainability.
From these metrics, is important to understand two things:
- Rentability is the most important metric. No rentability = failure.
- Quality and maintainability are only important because they have an impact in the rentability. They basically represent the cost of maintaining and fixing the application.
Objets, données, traitements et modélisation
Ah l'objet ! C'est super !
La réunification des données et des traitements, le tout en un. Fini les données d'un côté et les traitements de l'autre, « has been » tout ça, vive l'avènement de l'objet et de la modélisation objet. Moi, Monsieur, je pense Objet, je modélise Objet, je programme Objet, je dors Objet, je mange Objet, je m'habille Objet, je bois Objet, je… Euh, j'y vais un peu fort là !
On constate souvent ce genre de discours, sauf les quelques derniers mots peut être, et cette opposition qui est faite entre l'objet et le légendaire couple données-traitements. On fait d'ailleurs souvent ce raccourci pour définir ce qu'est un objet : « c'est comme une donnée avec les traitements en plus ». Sommes nous vraiment sûrs que cette explication ou cette opposition soient justes ?
Maîtrisons-nous réellement la portée de ce raccourci : « c'est comme une donnée avec les traitements en plus » ? La fusion complète des données et des traitements est-elle réelle en objet ?
Essayons donc de voir quelle est la vraie nature de l'Objet et en quoi l'approche objet a apporté de la nouveauté dans nos pratiques d'informaticiens (et ciennes bien entendu !) Qu'est ce qu'un objet ?
Protocol Buffers, la solution de Google pour gérer la sérialisation de structure de données
Le Journal Du Net a annoncé que Google souhaite offrir une alternative à XML.
Pour gérer l'échange de données d'une application à une autre (avec des langages d'implémentation différents), le format XML s'impose de raison pour structurer les messages échangés. Après avoir défini une structure pivot pour l'échange de message, chaque application implémente un parseur afin de sérialiser et desérialiser les messages entrants et sortants.
Google met donc à disposition Protocol Buffers, qu'ils utilisent en interne (ils ont plusieurs milliers (12 183) de descripteurs .proto dans leur base de code), en fournissant une alternative plus performante et plus simple que la sérialisation XML. Comme le XML, Protocol Buffers a pour ambition d'être portable d'une plateforme à une autre, et d'un langage à un autre (aujourd'hui les langages supportés sont C++, Java et Python).
Protocol Buffers fonctionne de la manière suivante :
- On réalise un fichier de grammaire .proto
- On génère la structure de données à partir de ce fichier de grammaire, dans le langage de destination souhaitée : C++, Java ou Python
- On génère le parser à partir de ce fichier de grammaire, dans le langage de destination souhaitée : C++, Java ou Python
Le mécanisme est légèrement différent d'une solution basée sur XML. En effet, en XML, il n'y a pas la deuxième étape : la génération de la structure de données. Cela permet à Protocol Buffers d'avoir des messages plus petits qu'un fichier XML (en terme de taille en octets). Cependant, les messages sont moins lisibles pour l'homme, mais un outil est mis à disposition pour pallier à ce frein (si c'est un frein).
Les objectifs affichés de Google avec Protocol Buffers sont d'avoir une solution de sérialisation/desérialisation de message :
- 20 à 100 fois plus rapide qu'avec des fichiers XML
- Avoir du code plus simple et plus facile à maintenir que des solutions autour d'XML (parser XML, …)
- Il est possible de mettre à jour la structure de données sans casser les applications qui ont été compilées sur une version plus ancienne
Annonce sur le blog Google Open Source
Protocol Buffers: Google's Data Interchange Format
At Google, our mission is organizing all of the world's information. We use literally thousands of different data formats to represent networked messages between servers, index records in repositories, geospatial datasets, and more. Most of these formats are structured, not flat. This raises an important question: How do we encode it all?
Protocol Buffers
Welcome to the developer documentation for protocol buffers – a language-neutral, platform-neutral, extensible way of serializing structured data for use in communications protocols, data storage, and more.
This documentation is aimed at Java, C++, or Python developers who want to use protocol buffers in their applications.
This overview introduces protocol buffers and tells you what you need to do to get started – you can then go on to follow the tutorials or delve deeper into protocol buffer encoding. API reference documentation is also provided for all three languages, as well as language and style guides for writing .proto files.
What are protocol buffers?
Protocol buffers are a flexible, efficient, automated mechanism for serializing structured data – think XML, but smaller, faster, and simpler. You define how you want your data to be structured once, then you can use special generated source code to easily write and read your structured data to and from a variety of data streams and using a variety of languages. You can even update your data structure without breaking deployed programs that are compiled against the "old" format.
How to Decorate Components with JLayer
This section was updated to reflect features and conventions of the upcoming Java SE 7 release. You can download the current JDK7 snapshot from java.net.
The JLayer class is a flexible and powerful decorator for Swing components. It enables you to draw on components and respond to component events without modifying the underlying component directly.
The JLayer class in Java SE 7 is similar in spirit to the JXLayer project at java.net. The JLayer class was initially based on the JXLayer project, but its API evolved separately.
This document describes examples that show the power of the JLayer class. Full source code is available.
Aucun commentaire:
Enregistrer un commentaire