- la soirée Scala du JUG de PARIS, vous pouvez aller voir les slides sur internet http://www.slideshare.net/guest2df4a547/13042010-scala-paris-jug-nicolas-jozwiak-romain-maton
- Un article sur la dette technique et l'architecture logicielle.
- Le JDK 6 update 19 et le mélange des Heavyweight et Lightweight Components : les spécialistes IHM apprécierons.
- Une série d'article au sujet de JavaFX qui sort en version 1.3 : compléments, amélioration de perf, ... ainsi que le top 10 des nouveautés.
- Google Chrome supprime l'affichage du http:// dans l'URL : premier navigateur grand public ?
- Le logiciel et la complexité : d'où vient la complexité ? C'est un point de vue apparemment relatif ?
- Les tests automatique des IHM : il ne faut pas se tromper d'objectif ? C'est un sujet d'actualité.
- Une Refcard sur le GUI en Java : Swing et SWT.
- La programmation concurrente en Java : ou en est-on ? Interview.
Bonne lecture.
Scala :
La soirée Scala du Paris JUG a eu lieu ce Mardi 13 Avril, et à ce titre nous tenions à
remercier les organisateurs de cet événement ainsi que les personnes présentes dans la salle.
Philippe Kruchten on Architecture and Technical Debt
If you ignore architecture and rush into software development by trying to drive software development solely with the functional visible part of it, you are running very rapidly into technical debt.
Mixing Heavyweight and Lightweight Components
Historically, in the Java language, mixing heavyweight and lightweight components in the same container has been problematic. However, as of the JDK 6 Update 12 and JDK 7 build 19 releases, mixing heavyweight and lightweight components is easy to accomplish. This article explains some details you might need to know.
A Bit of History
There are two kinds of graphics components in the Java programming language: heavyweight and lightweight. A heavyweight component is associated with its own native screen resource (commonly known as a peer). Components from the java.awt package, such as Button and Label, are heavyweight components. Third-party heavyweight components, such as the following, are also becoming increasingly popular:
- Java Binding for the OpenGL API
- JDesktop Integration Components (JDIC) project
- JRex , a browser component created in the Java language
A lightweight component has no native screen resource of its own, so it is "lighter." A lightweight component relies on the screen resource from an ancestor in the containment hierarchy, possibly the underlying Frame object. Components from the javax.swing package, such as JButton and JLabel, are lightweight components.
The JavaFX 1.3 release is a significant update featuring:
- New and enhanced support for UI controls, CSS, and programmatic layout
- A native JavaFX font family called Amble
- Support for the development of TV applications, including a new TV emulator
- Enhancements for mobile applications, with the availability of the mobile emulator on the Mac platform
- Support and improved editing features in NetBeans IDE 6.9 Beta
- New features and enhanced performance in JavaFX Production Suite
- Bind performance: 2-3x faster
- Applet start-up time: 20% faster (with Java SE 6u18+)
- Text Animation: 5-10x faster (frames per second)
- Highly complex animations: up to 10x faster (frames per second)
- Memory usage: 20-33% reduction (real-world apps, with Java SE 6u18+)
- UI Controls: 50% faster, 33%-50% less memory (typical)
JavaFX 1.3 Top 10
JavaFX 1.3 has just gone live on JavaFX.com. This release is deceptively small, but
has an enormous number of changes under the hood. In this post I will take you
through the Top 10 major features, giving you background information I learned from
working with the JavaFX team, and flooding you with details on interesting tidbits
you might otherwise miss.
Google Removes http:// from Chrome
posted by Thom Holwerda on Sun 18th Apr 2010 11:57 UTC, submitted by Anonymous
Now this is something that I find really interesting. We all know and love Google Chrome/Chromium (and if you don't, you're demonstrably wrong), but Google recently made a change in the developer version that ruffled some feathers: the URL field will no longer show the "http://". This made a lot of people very upset.
For a while now, Mobile Safari has been doing something similar, although I do think in that case, it's about saving space. On Mobile Safari, the scheme is hidden until you tap the URL field to edit. The developer version of Google Chrome takes this a step further, and omits the scheme completely. Bug reports were filed, and in true internet fashion, discussion ensued.
A few things need to be made clear about Chrome's implementation of this feature. The first thing that jumped into my mind was this: some applications, whether they be web or real ones, actually require you to add the scheme (for instance, to autoparse URLs). Google claims to have solved this issue by adding the scheme to your clipboard when you copy and paste URLs from the URL field, however, this behaviour is currently broken in many clipboard implementations. Another thing that you should be wondering about now is what they do with other schemes like ftp, https, and gopher. The solution here is decidedly simple: those will still be shown.
The reason behind this change is obvious: the URL scheme bears little meaning to most people using a browser - they know it's there and how to type it, but it doesn't indicate anything to them. Since computing has been about abstracting away complexity for a while now, it was only a matter of time before browser makers started removing this piece of web history.
That being said, I'm not at all in agreement with the "solution" Google is presenting here. Hiding complexity is not a solution - it's just hiding something. It's like Mac OS X hiding away the UNIX file system layout madness with a layer of kid-friendly directories; it only makes things look pretty - it doesn't actually solve the underlying problem. You can cover up that pile of mangled corpses in your bedroom with a flower-patterned table cloth, but that doesn't actually address the problem of there being a pile of mangled corpses in your bedroom.
Since 99.999% of the people only ever encounter http://, ftp://, and https:// (did I forget any?), why not create a standard set of easy-to-understand icons to replace them, in cooperation with other browser makers? I mean, if Mozilla and Microsoft can agree on the RSS icon (2005, people, that's how far back my OSNews memory goes!), surely we can all get along and do something similar here? Most browsers show a lock icon anyway when browsing to an https site, so this shouldn't be too big of a deal, right?
URL bar no longer shows http://
Complexity is the Problem
Who really believes that complexity is not a problem?
The complexity of modern software is a problem. Some say that it might be THE problem.
From the Editors: OSGi is too complex
Any Java developer, especially one who works with open-source software, will tell you that being the build monkey is a thankless job. You spend all of your time digging through Ant XML files and pulling down the proper classes and methods from constantly updated libraries and packages around the Internet and your internal repositories. Isn't there anything that can save Java from the endless complexity of dependencies?
Well, there's the OSGi development model, which was hailed as the enterprise developer's way to make a modular Java server application without the never-ending burden of dependency wrangling. OSGi promises sane dependency injections with tightly integrated modular code—and the ability to hot-swap code in and out of a running application server without the need for a restart. It's everything Java developers have asked for, right?
Well, yes and no. Yes, in that OSGi is supported by the Java industry, and in that software companies have begun building OSGi support into their servers and development tools. No, in that few enterprise developers seem to be adopting OSGi.
Why is that? We believe that OSGi, rather than simplifying server application development, has actually made it more complex, and there aren't sufficient benefits to justify the added complexity.
The industry seems to understand the problem. SpringSource donated its DM Server to the Eclipse Foundation earlier this year to spur enterprise uptake of OSGi, and even Eclipse Foundation director Mike Milinkovich admits there's a lot of work left to be done to expand enterprise uptake of the OSGi development model.
OSGi: Complexity is NOT The Problem
The editors at SD Times have proclaimed that OSGi is too complex. Unfortunately, they miss the mark, and the following statement taken from the article is misleading.
We believe that OSGi, rather than simplifying server application development, has
actually made it more complex, and there aren't sufficient benefits to justify the
added complexity.
This statement should have been tempered with context. It is not universally applicable, though is made to sound as if it were. OSGi may face challenges, but complexity of the OSGi framework is not one of the long-term inhibitors to adoption.
Comment faire des tests d'IHM sans se tirer une balle dans le pied ?
L'automatisation des tests d'IHM est souvent une mauvaise idée. Le constat est très souvent le même : bien que simple à mettre en place en général, leur apport est souvent mineur par rapport à leur coût (je vous dirige vers l'excellent article de Robert Martin pour creuser le sujet). Comment faire si l'on veut cependant s'engager dans cette voie?
Dans cet article, Gojko Adzic (commiter fitnesse et auteur du livre passionnant "Bridging the communication gap"), nous livre des pistes pour maximiser le retour sur investissement sur ceux-ci. Tout d'abord, ne surtout pas partir sur de l'enregistrement brut des cas de tests les uns après les autres (avec Selenium IDE par exemple). C'est dans ce cas-là que l'on se tire une balle dans le pied. Les coûts de maintenance explosent et l'intérêt des tests est remis en question au fil du temps.
La clé est de représenter les tests d'IHM sur plusieurs niveaux :
- Règles métiers
- Worfklows
- Technique
Le but de cette approche est de faire en sorte que les tests restent compréhensibles (bon courage pour aller comprendre la règle métier cachée derrière une centaine d'instructions Selenium) et surtout de promouvoir la réutilisabilité afin de garder la main sur la maintenance des tests.
Ruining your Test Automation Strategy.
Everybody wants a test automation strategy nowadays. The reason is clear. It take a lot of effort to run a suite of manual tests; and that effort has be be repeated several times per year. Consider the fate of this poor customer of mine. The picture you see here is simply the Table of Contents of his manual test plan. That plan has tens of thousands of individual manual tests. It costs them millions of dollars to execute, and they must execute it many times each year.
How to implement UI testing without shooting yourself in the foot
I'm currently interviewing lots of teams that have implemented acceptance testing for my new book. A majority of those interviewed so far have at some point shot themselves in the foot with UI test automation. After speaking to several people who are about to do exactly that at the Agile Acceptance Testing Days in Belgium a few weeks ago, I'd like to present what I consider a very good practice for how to do UI test automation efficiently.
I've written against UI test automation several times so far, so I won't repeat myself. However, many teams I interviewed seem to prefer UI level automation, or think that such level of testing is necessary to prove the required business functionality. Almost all of them have realised six to nine months after starting this effort that the cost of maintaining UI level tests is higher than the benefit they bring. Many have thrown away the tests at that point and effectively lost all the effort they put into them. If you have to do UI test automation (which I'd challenge in the first place), here is how do go about doing it so that the cost of maintenance doesn't kill you later.
Getting Started with Java GUI Development
For standalone Java desktop application, developers have two main options. You can use Java Swing, built into the JDK, or you can use the Standard Widget Toolkit (SWT) from Eclipse. Both approaches share some commonality, but each has its own advantages and methods. This DZone Refcard provides a reference on how to use both technologies; the first half of the Refcard will cover Swing, with SWT forming the second .half.
Billy Newport Discusses Parallel Programming in Java
There are several approaches right now to doing parallelism, there is the actor model, there is message passing, there are many different languages that are doing many different things. Which do you think is most likely to be the best match for Java?
Aucun commentaire:
Enregistrer un commentaire