Pour le bulletin de la semaine 27 et 28, je vous propose les sujets suivants :
Bonne lecture
Twitter Shifting More Code to JVM, Citing Performance and Encapsulation As Primary Drivers
While it almost certainly remains the largest Ruby on Rails based site in the world, Twitter has gradually been moving more and more of its stack to the JVM. The change is partially motivated by oft-cited advantages of the JVM, such as performance and scalability, but is also driven by a desire for better encapsulation of individual services, and other architectural concerns.
Closures for Java "BGGA" project
A Definition of Closures
There has been some confusion over our proposal to add closures to the Java Programming Language. After all, doesn't Java already have closures in the form of anonymous inner classes? What is the point of adding something to the language that it already has? To some there appears to be a lot in the proposal that has nothing to do with closures, including the control invocation syntax, null as a type, Unreachable, throws type parameters, function interface types, and "nonlocal" returns. In my Javapolis talk I tried to give an explanation for why these features are in the proposal from the practical point of view of what kinds of things would be possible that were not formerly possible. But that begs the question: why do we call it "Closures" for Java? In this blog post I'll try to show how the definition of closures relates to the features of the proposal, and identify which features of the proposal do (and which do not) result from the definition.
WindowBuilder Pro Quick Start
Paris JUG "Cloud"
Voici la retranscription de la soirée du Paris JUG du 5 juillet, dédiée au Cloud.
A l'origine, seul Patrick Chanezon devait intervenir, mais toute la clique du cloud à
la Française ayant été prévenue de la soirée, ce sont finalement 6 speakers qui se
sont partagés la scène - même si les derniers ont dû parler très vite compte tenu du planning particulièrement serré !
Cloud par-ci, cloud par-là, tant et si bien qu'en sortant il pleuvait... Les aléas de la
météo font parfois écho à ceux de la technique.
IKVM Introduction
IKVM.NET is an implementation of Java for Mono and the Microsoft .NET Framework. It includes the following components:
UML for the Software Developer, Part 1: Building Classes
Whatever language you code in, however you feel about documentation, and whichever process you ascribe to—you will need to model. Whether those models are in a formal charter, reference document, part of a diagram, or on the back of a napkin, you as a software developer will end up using models or modeling yourself.
Why do we need to model software? After all, aren't the acts of coding and refactoring of that code enough? That depends on what is meant by enough! You could code up some software, hand it in, and go through a constant refactoring process with the client. This is how most software is developed today. However, times are changing. A decade ago, a game would have been developed by a single developer in the basement. Graphics were primitive and it was enough to produce a few sprites, some cute screens, and an occasional story line.
UML for the Software Developer, Part 2: Mastering Associations
Associations are a key part of the UML lexicon. Use them to define the ways in which your application's classes communicate. In this article you'll see that adding a database introduces design patterns for the first time using the façade pattern.
by Mark Goetsch lasses are only the first step to understanding UML. In my last article I discussed classes in UML and how they are coded using C#. In this article I will tie-up a few loose ends by describing how classes are arrived at and then march into how they relate to each other in UML using associations.
UML for the Software Developer, Part 3: Aggregating
Part 3 of this series on UML tackles aggregation, which is a special form of association.
Part 2 showed you how associations related one class to another, but this article shows that associations are not strong enough when you need to specify ownership.
In Part 2 we looked at associations, which are nothing more than references, but they can be directional and represent multiplicity. If we were restricted to our ability to generate code using UML this would be sufficient. If we
are offering guidance on how the application should be built, as well as auto-generated code, we need something more.
To continue with examples from the previous articles, your friends at Rich Men, Inc want to start tracking what stocks they buy for their clients. Ideally they would somehow offer some aggregated values for all of the stocks that a client has in order to boost their value to the client.
UML for the Software Developer, Part 4: Deployment Diagrams
Deployment diagrams act as the link and reference point between how the system is built and where it is displayed. Learn how capacity planning, n-tier development, and coordination of tasks between different teams can all benefit from these diagrams.
So far, you and I have journeyed through the realm of class diagrams. Classes are a good start for understanding how an application is hooked together, and while they describe the static relationships between the objects in the system, classes are just an abstraction of the software itself. What happens after the classes are
built? The answer is, of course, that they need to be deployed. But where? How do I model deployments? The answer is a new diagram type—the deployment diagram.
Deployment diagrams are one of the least understood—and most important-diagrams in the UML pantheon. Many developers don't even know what they are, yet consider themselves experts in UML. The purpose of a deployment
diagram is to model the execution environment for a project. They can also be used to describe the enterprise environment, but this is more the enterprise architect's domain.
UML for the Software Developer, Part 5: Component Diagrams
Their ability to show interdependencies between applications' components make
component diagrams invaluable. They can however be surprisingly complex. Find out how to use the right architectural patterns within your component diagrams to make them manageable.
According to Clemens Szyperski (author of "Component Software—Beyond Object-Oriented Programming,"), software components are binary units of independent production, acquisition, and deployment that interact to form
a functioning system. He continues to add that a software component can be deployed independently, is a unit of third-party composition and has no (externally) observable state. In UML we use component diagrams to break down systems into understandable chunks that show the dependencies between components.
Do not return in a finally block: return will swallow your exceptions
I was recently working on a code, which was failing without giving any exception.
So I had to add lots of logging to the code, to see where is the bug. I caught nothing via this method.
So I decided to check out the module source code and yeah finally I found it while
debugging. The module was correctly implementing what was required and
generating the required Exception as expected.
- Le site Twitter qui passe du langage Ruby au langage Java, pour des raisons de performance mais aussi de maintenance plus productive avec un langage à typage fort : Java par rapport à un langage à typage faible : Ruby.
- Deux articles au sujet des expressions lambda ou closures : explication et historique.
- La version 3.7 d'eclipse qui vient de sortir inclus un composeur visuel pour les IHM en Swing, SWT (Standard Widget Toolkit) ou GWT (Google Web Toolkit) : WindowBuilder.
- Le compte rendu du club Java de PARIS pour la soirée sur le cloud : résumé.
- Un article sur la machine virtuelle IKVM qui est capable de faire tourner du byte code Java sur la machine virtuelle DotNet. Il est possible d'utiliser le framework DotNet avec du code source Java.
- Cinq articles qui résume la modélisation UML pour les développeurs Java.
- Un exemple de code Hello World en Java et en Ruby
- Un article sur Java qui explique pourquoi il est interdit de faire un return ou de lancer une exception dans un bloc finally.
Bonne lecture
Twitter Shifting More Code to JVM, Citing Performance and Encapsulation As Primary Drivers
While it almost certainly remains the largest Ruby on Rails based site in the world, Twitter has gradually been moving more and more of its stack to the JVM. The change is partially motivated by oft-cited advantages of the JVM, such as performance and scalability, but is also driven by a desire for better encapsulation of individual services, and other architectural concerns.
Closures for Java "BGGA" project
- BGGA closures specification: Closures for the Java Programming Language (v0.5)
- Doug Lea's jsr166y fork-join concurrency framework: without function types and with function types. Get the code here.
- Latest openjdk prototype: http://www.javac.info/closures.tar.gz (updated 2008-08-11)
- Neal's talk about BGGA closures with Q&A
- Differences between the openjdk prototype and the spec (v0.5)
- Open issue list: Closures: Open Issues (v0.5)
- Homepage for the openjdk closures project
- A library for functional programming.
- A definition of closures
- comment on extension methods
A Definition of Closures
There has been some confusion over our proposal to add closures to the Java Programming Language. After all, doesn't Java already have closures in the form of anonymous inner classes? What is the point of adding something to the language that it already has? To some there appears to be a lot in the proposal that has nothing to do with closures, including the control invocation syntax, null as a type, Unreachable, throws type parameters, function interface types, and "nonlocal" returns. In my Javapolis talk I tried to give an explanation for why these features are in the proposal from the practical point of view of what kinds of things would be possible that were not formerly possible. But that begs the question: why do we call it "Closures" for Java? In this blog post I'll try to show how the definition of closures relates to the features of the proposal, and identify which features of the proposal do (and which do not) result from the definition.
WindowBuilder Pro Quick Start
Paris JUG "Cloud"
Voici la retranscription de la soirée du Paris JUG du 5 juillet, dédiée au Cloud.
A l'origine, seul Patrick Chanezon devait intervenir, mais toute la clique du cloud à
la Française ayant été prévenue de la soirée, ce sont finalement 6 speakers qui se
sont partagés la scène - même si les derniers ont dû parler très vite compte tenu du planning particulièrement serré !
Cloud par-ci, cloud par-là, tant et si bien qu'en sortant il pleuvait... Les aléas de la
météo font parfois écho à ceux de la technique.
IKVM Introduction
IKVM.NET is an implementation of Java for Mono and the Microsoft .NET Framework. It includes the following components:
- A Java Virtual Machine implemented in .NET
- A .NET implementation of the Java class libraries
- Tools that enable Java and .NET interoperability
UML for the Software Developer, Part 1: Building Classes
Whatever language you code in, however you feel about documentation, and whichever process you ascribe to—you will need to model. Whether those models are in a formal charter, reference document, part of a diagram, or on the back of a napkin, you as a software developer will end up using models or modeling yourself.
Why do we need to model software? After all, aren't the acts of coding and refactoring of that code enough? That depends on what is meant by enough! You could code up some software, hand it in, and go through a constant refactoring process with the client. This is how most software is developed today. However, times are changing. A decade ago, a game would have been developed by a single developer in the basement. Graphics were primitive and it was enough to produce a few sprites, some cute screens, and an occasional story line.
UML for the Software Developer, Part 2: Mastering Associations
Associations are a key part of the UML lexicon. Use them to define the ways in which your application's classes communicate. In this article you'll see that adding a database introduces design patterns for the first time using the façade pattern.
by Mark Goetsch lasses are only the first step to understanding UML. In my last article I discussed classes in UML and how they are coded using C#. In this article I will tie-up a few loose ends by describing how classes are arrived at and then march into how they relate to each other in UML using associations.
UML for the Software Developer, Part 3: Aggregating
Part 3 of this series on UML tackles aggregation, which is a special form of association.
Part 2 showed you how associations related one class to another, but this article shows that associations are not strong enough when you need to specify ownership.
In Part 2 we looked at associations, which are nothing more than references, but they can be directional and represent multiplicity. If we were restricted to our ability to generate code using UML this would be sufficient. If we
are offering guidance on how the application should be built, as well as auto-generated code, we need something more.
To continue with examples from the previous articles, your friends at Rich Men, Inc want to start tracking what stocks they buy for their clients. Ideally they would somehow offer some aggregated values for all of the stocks that a client has in order to boost their value to the client.
UML for the Software Developer, Part 4: Deployment Diagrams
Deployment diagrams act as the link and reference point between how the system is built and where it is displayed. Learn how capacity planning, n-tier development, and coordination of tasks between different teams can all benefit from these diagrams.
So far, you and I have journeyed through the realm of class diagrams. Classes are a good start for understanding how an application is hooked together, and while they describe the static relationships between the objects in the system, classes are just an abstraction of the software itself. What happens after the classes are
built? The answer is, of course, that they need to be deployed. But where? How do I model deployments? The answer is a new diagram type—the deployment diagram.
Deployment diagrams are one of the least understood—and most important-diagrams in the UML pantheon. Many developers don't even know what they are, yet consider themselves experts in UML. The purpose of a deployment
diagram is to model the execution environment for a project. They can also be used to describe the enterprise environment, but this is more the enterprise architect's domain.
UML for the Software Developer, Part 5: Component Diagrams
Their ability to show interdependencies between applications' components make
component diagrams invaluable. They can however be surprisingly complex. Find out how to use the right architectural patterns within your component diagrams to make them manageable.
According to Clemens Szyperski (author of "Component Software—Beyond Object-Oriented Programming,"), software components are binary units of independent production, acquisition, and deployment that interact to form
a functioning system. He continues to add that a software component can be deployed independently, is a unit of third-party composition and has no (externally) observable state. In UML we use component diagrams to break down systems into understandable chunks that show the dependencies between components.
Do not return in a finally block: return will swallow your exceptions
I was recently working on a code, which was failing without giving any exception.
So I had to add lots of logging to the code, to see where is the bug. I caught nothing via this method.
So I decided to check out the module source code and yeah finally I found it while
debugging. The module was correctly implementing what was required and
generating the required Exception as expected.
Aucun commentaire:
Enregistrer un commentaire