Peter Hendriks

Returned from the RSC: back to the rest of the world

peterhe — Tue, 09 Jun 2009 10:46:00 GMT

Well, the IBM Rational Software Conference 2009 is over again. It was once again a great conference with lots of interesting new developments and insights. The Jazz products are evolving very fast, and they really try to improve on weak points first and adding only features that are really useful and relevant in real life. I really like the "enterprise" focus of RSC, as much fun as dancing robots or spinning cubes are, it's much more interesting to see how technology and tools can be applied in real scenarios. For fun and entertainment, comedian Mitch Fatel cohosted with a reality show using real developers. Basically, just like on tv, the show was pretty corny, but fun when the developers started arguing and acting like idiots to win the discussion. Those developers were also attending/speaking, and it was funny to see some guy getting an evil eye all the time while doing lunch (tv will do that to you). The guys from Mythbusters were special guests, although it was a shame that they could not blow anything up on stage because of the fire department regulations. They did provide some insight on risk management, the process of creating experiments, and space ships fueled with poo.

When I was at the conference, I completely disconnected from the rest of the world to focus on all the content. Now that I am back, I am reading up on all the other interesting stuff that happened the last few weeks. European elections, JavaOne, Google I/O, a lot happened in such a short time. Google is moving more and more into the Java space, with the AppEngine Java offering and the exciting new Google Wave initiative, fully based on GWT. The Wave demos are a great showcase for GWT. A lot of the Google I/O sessions are already up on the web, and I'll soon here from my colleagues that visited JavaOne what happened over there. It's great that despite the economic crisis, innovation still happens!

Rational Software Conference 2009: Real, Smart and Green

peterhe — Tue, 02 Jun 2009 21:13:00 GMT

After a year, we're back in Orlando, home of Mickey Mouse, roller coasters, hamburgers and Coca Cola, and of course the IBM Rational Software Conference 2009. The conference is already well under way, it started last Sunday, but with an ever increasing count of sessions and events, my schedule does not permit a lot of blogging. The themes of the conference are Real, Smart and Green. Basically, Real is about practical, concrete value, Smart is about innovation and new areas of sofware usage, and Green is not wasting paper at the conference. The green part seems a bit funny when you hear it at the keynote: big plasma screens everywhere, airconditioning that requires wearing a sweater, even though outside it is 40 degrees celcius, and then a big show about how paper is saved and plastic bottles are banished.

Several new announcements were made. IBM is coming with a new cloud initiative, which should support hosting all kinds of customer applications, as well as the Rational Jazz based tools. This means new opportunities for management, monitoring and metering, as well as hosting and licensing models. The announcement is still very fresh, but it is an interesting model that will be interesting for lots of people, including smaller companies that don't want the hassle of managing infrastructure, or really big organizations that would like additional metering and governance for internal billing of server usage.

Also, IBM is expanding the portfolio with even more tools. The Tivoli systems management tools will now connect more and more with Rational, bridging the gap between software development and the production support organization. And Rational Insight will provide "executive dashboards" for management to bring together metrics from all kinds of tools and data warehouses, with analysis built in to assess the health of projects at a broad level.

Of course, lots of content on the development of existing products as well. Team Concert 2.0 has some exiting new features, and the work on the Jazz foundation means that the tooling integration will push to new levels in the upcoming Quality Manager and Requirements Composer releases. The Open Services Lifecycle Collaboration (OSLC) specification was just finalized at 1.0 last week. RTC 2.0 will comply with it, and there is a OSLC adapter for ClearQuest available as well. Interestingly, the Mylyn guys added support for OSLC to the Mylyn Eclipse plug-in. This means that everyone that supports OSLC will directly work with Mylyn. For Mylyn and the adopters, this could be a real winner, because right now, there are about 29 different adapters for Mylyn to support all kinds of task repositories.

Several other interesting things going on as well in the "agile" mentoring and guidance space. Adopting some of the agile ideas can be very hard to do, and there are several experienced speakers here with great ideas about moving agile forward, without being too naieve about it. All in all, a great conference so far, back to my busy schedule for the next sessions!

Jazz 2.0 release candidate

peterhe — Sun, 17 May 2009 17:05:00 GMT

RC1 for Rational Team Concert (RTC) 2.0 was released yesterday. Even though it's only been a year since the 1.0 release, RTC got a lot of updates. First of all, there is now an Enterprise edition, which allows an unlimited amount of developers on a single server instance, a big improvement for large organizations with more than 250 developers. Cross-server and cross-project linking has been improved and formalized, one of the user-visible capabilities is that you can now create dashboards that contain information of several projects. This allows several interesting scenarios, such as a "Project of Projects" for a Project Office in a large orginization, or different companies with their own ALM deployments working together through the shared Jazz link.

All of the core components got some serious updates, but the Agile Planning Tool got the best screenshots. First, a new Standard-only feature calculates risk in the schedule based on the estimates and the planned dates:

Another fantastic feature, available in all RTC editions, is the "taskboard" view mode. This basically gives you a Scrum-sticky notes overview of the tasks. It looks really great on my big widescreen monitor at home:

There are a lot more new features, check out the new & noteworthy notes if you are interested. It's not just brand new features though, in the different RTC "editions" (free, small, org, huge), a lot of the checkmarks got to the left side. This means the Express versions now are a much improved option for a quick single-project off-the-shelf solution. If you haven't given RTC 2.0 some attention yet, be sure to take a look!

Why tools matter

peterhe — Sun, 03 May 2009 15:34:00 GMT

Improving software development productivity is a much discussed topic, with many different schools of thought. Some will say you need to get people who can "Hit the High Notes", others will focus on teamwork dynamics as a means to ultimate productivity, while some will emphasize that using the best tool out there is critical. A lot of these camps will often downplay the others, stating that their focus on productivity is the only one that really matters.

I think all aspects matter a lot, and depending on the situation, you should focus on different aspects. Small teams vs big teams vs novice teams vs experienced vs long vs short projects, etc. The important thing to recognize is the relations between them and how they compound or conflict with each other.

Tools play an important role here (with tools, I mean "automated" support, such as an IDE, build tool, version control, etc.). In my opinion, tools can determine the bandwidth of operational productivity. In other words, tooling will play a role in determining the barrier to entry to perform certain activities, and the maximum theoretical performance a team member can reach using the tool.

A nice example is creating a build. If properly tooled, everyone should be able to start an automated build with the press of a button (or even better, it just happens). Otherwise, creating a build may involve several complex steps, requiring specific knowledge and coordination, and is likely to be executed by a single team member as an "integrator" only. A properly automated build reduces the barrier to entry for the task of creating a build.

If a version control system does not support certain features (like atomic commit, for instance), or is very slow, this may limit the bandwidth of team members using the tool. Limited tool support incurs overhead in the form of error-prone behavior, complex workarounds, and increased waiting time.

Of course, tools are not the only potentially governing boundary factors for productivity. Just simple pen and paper are a great drawing tool, easy to use, very fast, and very mobile. On the other hand, it is difficult to navigate and search through paper drawings, or maintain them when something changes. Tools should always be viewed in the context of a given task and situation.

I tried to summarize this using this very sophisticated picture:

J-Spring 2009, full of surprises

peterhe — Wed, 15 Apr 2009 18:20:00 GMT

Well, it's spring again, so time for another NLJUG J-Spring event! The NLJUG J-Spring/J-Fall is the biggest Java event in the Netherlands, a one day conference held in Bussum. I am a regular visitor on this conference, interesting sessions, a good indication of the Dutch Java scene, and it's great to meet up fellow Java developers again. The conference was "sold out" (entrance is free to NLJUG members), but because it was nice weather outside, it was less crowded inside during the breaks than usual.

Data Context Interaction

For me, the conference started out with a talk on "Data Context Interaction" (DCI). Basically, this is supposed to be solving the problem that "typical" object oriented (OO) design mixes all kinds of stuff inside your domain objects. DCI completely separates each interaction, using simple techniques like a decorator, or a full-blown new programming environment called Object Teams (unfortunately, only the latter was demonstrated). I had a bit of trouble with the initial problem statement. In "good" OO principles (like SOLID, for instance), mixing unrelated stuff in the same object was already considered very bad! I agree with the stuff DCI proposes, but I do OO design this way in plain Java for years already, without needing fancy new languages or confusing new acronyms. As a research effort though, I am really interested if something useful will evolve from this new emphasis on a cleaner separation.

Web Beans

Next was a talk on the JSR-299 "Web Beans" specification. Basically Web Beans is the best of Guice and Seam (both inspired by Spring), mixed together in a single Dependency Injection standard. This talk was a real meat grinder, the speaker had little mercy for any listener that did not have intimate knowledge of Seam/Guice, and crammed the entire spec in the talk (and the spec is pretty big). Fortunately, I did know enough about Guice and Seam and managed to keep up the entire session. Web Beans will be great when it's done (no date is set on that, but not likely this year), especially if it works on Java SE as well. It's a nice clean spec so far: easier than Spring and Seam, more powerful and complete than Guice.

Pragmatic Model Driven

The revival of model driven development was apparent on this J-Spring too. Jos Warmer did the afternoon keynote on a new framework called Mod4J, which is basically an out-of-the-box DSL and code generation tool to work model driven using predefined DSLs. Another talk by Richard and Tony in the afternoon relied on a more low-tech technique by using out-of-the-box Enterprise Architect capabilities in conjunction with Freemarker templates. Both approaches each have their pros and cons, but both did model driven only for the simple boilerplate code, no ambition to replace coding completely, or rely on very abstract models written by non-programmers. Very interesting stuff, meta-models seem pretty easy, especially in Enterprise Architect, so basically, this stuff relies on easy to understand code generators to be accessible to the average programmer. I talked a bit with some of the model driven guys, but since they have been investigating and experimenting with this stuff for years, to them, everything seems easy.

The demise of the Swing JSRs

Finally, I visited a talk on the JSR-296 "Swing Application Framework" spec, by Karsten "JGoodies" Lentzsch. Karsten is a great presenter and a real Swing guru so I never miss one of his talks. This talk was especially interesting though, because although he did explain the spec, he basically said that it was dead. Sun re-prioritized on JavaFX, and abandoned some important Swing JSR specifications. According to Lentzsch, you'd be better off right now if you roll your own framework for serious Swing applications instead. It's surprising to hear a member of a spec expert group say: don't use this spec! Refreshingly honest though, which is loads better than hollow promises of Sun on this subject.

Still, the JSR is a great inspiration for solving common problems, although Karsten pointed out some things he did not agree upon (like resource bundle injection). Karsten did say some nice things about Eclipse RCP too, stating that as the only real alternative for plain Swing for now, interesting to hear from a Swing guru (both Netbeans RCP and JavaFX were mentioned). Finally, he did mention the Eclipse JFace data binding too, as a cleaner and more powerful alternative to the JSR 295 "Beans Binding" spec (dead now, too). Since JFace data binding is pluggable, it can be used outside Eclipse as well, and Karsten mentioned the UFace project (Swing and GWT bindings) as something very interesting to watch in this space. UFace, though, has not released any downloads as of yet, so right now, you have the choice between a JSR that is dead, a new generic framework that is not yet available, or just plain old JGoodies for Swing data binding.

All in all, an interesting and surprising day at J-Spring. See you next J-Fall!

Google AppEngine for Java: the cloud keeps getting bigger

peterhe — Wed, 08 Apr 2009 19:06:00 GMT

Google joined the cloud computing turf a year ago with "Google AppEngine", a framework to enable relatively simple applications to be deployed directly in the cloud. Google AppEngine only supported Python as the programming language, and required the use of very specific API code, that basically meant that if you wrote something for AppEngine, it would not run anywhere else.

Since its inception, Google always Java promised support for AppEngine. Today, Google announced the first preview for Google AppEngine for Java. Interestingly, unlike the Python API, the Java edition of AppEngine uses a lot of Java EE standards: WAR, JPA, Servlets, JSP, etc. This means that it is easy to program if you already know Java EE, and it is easier to migrate to or away from AppEngine. The Java edition promises support for data storage, authentication, in-memory-caching and probably other features of AppEngine, like scheduling, will be supported as well. The Google Web Toolkit (GWT), Google's AJAX Web framework for Java, can be used in AppEngine too. See this intro movie for more information (captioned, no need for sound).

The AppEngine Java preview includes an SDK, complete with Eclipse support and a local sandbox environment. The "preview" program just got started, so there are limited slots for hosting applications. Claim your slot on the AppEngine page and start writing some cool Java apps!

The user interface beyond Star Trek

peterhe — Sun, 15 Mar 2009 18:07:00 GMT

Everyone knows about Star Trek and the science fiction genre. Science fiction plays with future technologies that do not exist yet. While not everything in Star Trek has now been invented, when it comes to user interfaces, we are pretty close. We now have touch-screen, very small computers, voice commands and rich real-time 3d visualization (real life proof of this: the Star Trek Flat).

Well, Star Trek will need to update real fast. The computer industry is still rapidly evolving, and pretty soon, the post-Star Trek user interfaces might emerge. A great example is the Sixth Sense research project. This is a portable image recognition and projecting device, that provides in-context display and can be used using gestures, projected surface interaction, or simply holding objects in front of it. See this TED presentation for more information and some great demos. It will be interesting, when this becomes mainstream, how much of current UI frameworks can be reused to build the next-gen interfaces.

Manifesto for Software Craftsmanship

peterhe — Sun, 08 Mar 2009 14:06:00 GMT

By now, everyone in the software development industry probably heard about "agile" development, formally described in the Agile Manifesto. Agile was a rebellious response to the continuing push of vendor-driven processes and procedures, which seemed to balloon in its efforts to describe every complex artifact and activity, preventing professionals to think up more simple solutions for the problems at hand.

The agile manifesto is a call to action to emphasize several points the big-process guys seemed less important. It's about relying less on a big tell-me-all-do-nothing-without-it process, complex tooling, huge documents without any real proof, a detailed contract and planning set in stone. Agile states that these concepts are at odds with the very nature of software development, yet were at the time (and still are at a lot of places) commonly practiced.

Whether agile is right about this (I think it is) has always been controversial and a source of heated discussions. This seems strange: if you consider "change" in a software development project as inevitable as "gravity" in the real world, you would expect no real debate on something so obvious. However, unlike falling apples, most problems and forces in software development are more abstract and subtle, and solutions often seem counter-intuitive.

Another controversy in the software development industry is about quality. To a lot of people, quality costs money, and lower quality equals cheaper production equals money saved. This very simplistic thinking leads to spending less on qualified developers, less solid testing and/or improving based on test results, less on learning, coaching and/or improving, less on usability and creative, but risky solutions.

Again, the opposite is true. High quality means better efficiency because of the extra reuse opportunities, a more predictable schedule (less meetings and re-prioritizing efforts), less re-work on testing, fixing bugs, and testing again, and higher return on investment in production, because of better features, less failures and greater user satisfaction. Actually, the best way to waste money is try to achieve the lowest quality possible, something the manufacturing industry already knows for decades.

To emphasize the value of quality and a professional attitude when developing software, the Manifesto for Software Craftsmanship has been created by the software craftsmanship group. Based on the Agile Manifesto, this manifesto declares that in order to be agile, you have to be professional. Probably, like the agile manifesto, it will lead to some heated discussions, with dogmatic enthusiasm and stubborn rejections. I think it's a just cause though: it's not just what something costs by the hour, but also what it delivers in return. If you agree that craftsmanship matters when developing software, sign the manifesto to show support!

Java 7 and the Elvis operator

peterhe — Mon, 02 Mar 2009 18:53:00 GMT

With Java 6 out for quite a while now, Java 7 is finally looming closer for a release due in early 2010. Most of the big changes are either scrapped (like support for closures or a standard module system), or actually pushed into a Java 6 update (the new G1 garbage collector is coming in update 14).

Not all is lost on Java 7 though. Along with several API updates and JVM/tooling improvements, there are also some language changes expected. These are gathered in "Project Coin". The clever name implies that each proposal involves "small" change, and refers to the proverb "to coin a phrase".

One of the proposals is the new "Elvis" operator. It involves using the question mark as a shorthand to check for null scenarios. One of the expressions is this one:

?:

If you look sideways, it's Elvis! I really am not that fond about this kind of programming, but having something called the Elvis operator as a new feature is reason enough for me to migrate asap. ;) I hope other language additions will get a similarly cool name.

JUnit to the Max

peterhe — Mon, 09 Feb 2009 20:08:00 GMT

I just stumbled upon a cool new project from JUnit grandfather Kent "XP" Beck. It's called JUnit Max and basically introduces the "Run tests on save" feature in Eclipse. This means you don't have to think about running tests, they always run. The tests are run in fail-first order, so if you're in the change/retry cycle of fixing a test you get immediate feedback. See the link for a slidecast explaining the product. The licensing model for the beta is a bit strange: 2 dollars a month! I think it's a great concept though: it promotes more running of tests and adds another argument to why unit tests should run isolated and as fast as possible.

Not doing something costs time and money, too

peterhe — Sun, 01 Feb 2009 23:11:00 GMT

A recent podcast of Joel "On Software" Spolsky and Jeff "Stackoverflow" Atwood stirred up a bit of a debate. Joel goes into a big rant against Unit Tests and the SOLID design principles. Robert "Uncle Bob" C. Martin, author of both the SOLID design stuff and also professional TDD zealot already responded, attacking the points Joel made.

First of all, I do understand the point Joel and Jeff are trying to make. Both unit testing and architecture can be over-emphasized and that will do more harm than good. Like everything else, solutions sold in black and white are usually some shade of gray in the real world. However, to get the point across, you sometimes tell things a bit more simple and extreme.

Joel should be sensitive to this, as most of his articles, including the Joel Test, are structured exactly the same. Unfortunately, Joel seemed to lose patience when hearing about things like test everything and decouple everything. In the talk they use weird examples that have very little to do with the original ideas behind the concepts. I hear these so called Straw Man arguments (proving a point by using a wildly exaggerated example) quite often regarding testing and design. but I was just as shocked as Uncle Bob to hear them from someone like Joel Spolsky, who can be considered a very public software development figure.

Basically the argument against unit testing and SOLID made is: "it's too much extra work". Joel goes on and on about how many millions of interfaces he would need and that all of his thousands tests break when he makes a single change. Of course these are wild examples that have very little to do with the real world, but what I am really missing is: what do you have to do instead, when not doing tests and abstractions? Joel only evaluates the costs of unit testing and proper architecture, but not the benefits.

Not doing unit tests will save you the time to write and maintain unit tests. However, unit tests have a certain goal (to validate if a single piece of code works). If you no longer write unit tests, how will you achieve this goal? A manual test will likely take at least 10 minutes (fire up the modified system, navigate to the proper user interface, enter some data, evaluate response). Writing a single unit test, on average, takes the same amount of time. However, in the debug/retry cycle, unit tests really start winning out. Afterward, unit tests can be recycled over and over, to immediately detect when a code change causes something to break.

With these productivity increases and risk mitigation, I can understand why someone would like as much unit testing as possible. Unit tests are great for testing what a developer can reason about and only involve the isolated unit. Unfortunately, there are more problem classes in a system, such as "is this user interface pretty", or "if I put X and Y together, will they work together". Code that deals with these kinds of problems may be impossible to unit test, or doing so would be extremely verbose and non intuitive. I would agree that it would be more efficient to skip unit testing for this kind of code, and test these attributes using other forms of testing instead.

At the end Jeff closes with a Frank Zappa quote: "Nobody gives a crap if we're great musicians.", concluding that users really don't care about code quality. Somehow, this part seems to suggest that if you care about unit testing and proper design, you can't care about anything else. That strikes me as a bit narrow-minded: it's not like testing and caring for user needs are mutually exclusive? Also, even Frank Zappa probably would have checked the sound before a performance, and look into the mirror before he went on stage. Because Frank Zappa knows the quality of his mustache matters, and not looking in the mirror is not an option.

Why traffic lights are evil

peterhe — Sun, 04 Jan 2009 17:26:00 GMT

A few days ago I had to take a drive from Den Bosch to Tilburg (A65). If you know that little piece of road, you know there are a lot of traffic lights. I understand the value of traffic lights: they reduce accidents and distribute a fair opportunity for people to cross the road. If you'll ever drive on the A65 however, you'll notice that the abundance of traffic lights really slow you down. Also, you'll notice people pushing to get to the green light in time, slowing down only at the last minute, creating dangerous situations. If you think about the environment (who doesn't these days) you'll get annoyed by the senseless pollution of extra slowing down and speeding up needed (not to mention that traffic lights consume quite a bit of electricity too). So, why are there that many traffic lights?

The traffic lights on the A65 were the easy way out for the people that designed that piece of road. They basically had three choices: provide less intersections, provide bigger intersections with on-ramps and off-ramps that do not need traffic lights, or put up traffic lights. At the time, roundabouts were considered evil because they were different from modern standards, so I don't count that as a choice. Obviously, less intersections would mean people near the road would get angry, because they would need a detour. Bigger intersections would be more expensive, and make people that live by the road angry, because their houses would need to be demolished to make room. So, traffic lights were placed, making everybody that actually uses the road angry instead. Law and politics often lead to such awful compromises.

Traffic lights are common in a software development project as well. Basically, a traffic light is a control point that controls the flow of action in a certain process step. The control point works like this:

The control is usually performed by a different person than the person whose work is controlled.
The control consists of a check against a simplified representation of reality.
The result of the control is usually a simple redirection (do this, don't do this).

Depending on your organization, this may be happening very often or only once in a while. Like the traffic light, a control point may have its uses. However, it always has downsides:

The control point will slow down the work being controlled. This means the work is in progress longer and the return on investment will be later. Responding to changes will take longer.
The control point will cost extra resources. Performing the control action will take additional time without adding value to the product. Slowing down and speeding up before and after the control point requires additional resources as well.
The control point will almost always simplify decisions to a point where not all the information available is used, thus increasing the risk of sub-optimal result. It will be something like running a static check list or a manager needing to sign off.
The control point reduces the opportunity of initiative of the person whose work is controlled. He/she will no longer feel responsible and is expected to blindly follow the result of the control.

I need to re-emphasize that control points are needed at times. Sometimes, laws require them, or they are needed to prevent catastrophic events (like a car accident). However, control points are often a result of excessive prevention strategy (not every problem is worth preventing), lack of trust, lack of skill, lack of delegation, or lack of communication. When you hit a traffic light in you organization, it may be worth thinking about:

Why is an explicit control needed? What is lacking in skill, available information or decision powers in previous steps? Is a control point the only way to cross this gap?
What is the risk being prevented? How expensive is it, in terms of money, time, damage, etc? What is the chance of the risk occuring with and without the control point?
What is the cost of the control point? How much overhead does it impose on the project? Did you calculate this overhead in your estimations and budget as well?
Can you optimize the control point? This can be done using automation or optimizing information flow for instance. Note that batching is almost always a very bad optimization strategy in a software development project.
Can the control point be circumvented? At times, it may be legitimate to ignore a control point, for example because of time constraints (an ambulance en route to an accident). How often is the control point circumvented? Is the circumvention explicit and accepted, or does it happen under the radar?

I think a lot of traffic lights would not be needed if the roads would be constructed just a little bit different. Sure, it would be more complex to build roads, but the result would be more efficient roads. With traffic lights, the roads jam up pretty fast, requiring even more roads with even more traffic lights!

The future of Java modular development: Jigsaw or OSGi?

peterhe — Mon, 08 Dec 2008 11:31:00 GMT

What Java still lacks is a standardized module system to describe and manage dependencies with. This often leads to "jar hell", a jungle of jars needed on all kinds of locations, hard to manage classloaders and all kinds of ad-hoc dependency declaration mechanisms like Maven and Ivy.

Sun has worked for a while on JSR 277, a new standard for declaring and using modules in the Java platform. A module would be a jar with some extra information on its identity, version number, dependencies, etc. JSR 277 always was controversial, because a similar specification already exists: JSR 291 or OSGi. OSGi originated in embedded development, but is now widely used in mobiles, the Harmony Java VM, Eclipse products, Spring and most application servers, including the new Sun Glassfish v3 server. Where JSR 277 demanded additional language and runtime features, OSGi runs in Java 1.1 and up using the basic metadata and classloader features already available, and can host other languages as well.

Mark Reinhold blogs about a new project Jigsaw that will provide modularity support for the Java platform. The JSR 277 project will be discontinued. As announced in they blog Jigsaw will NOT be part of the official Java specification. That means Java VMs of IBM and Oracle (JRockit) do not need to support it. If Jigsaw will make the cut for Java 7 is not decided yet.

To me, a Java module system (like .NET already has for years) was the most important new feature of Java 7. Now that it is dropped, I think OSGi will become even more popular. It is an official specification, works today and already has tool support, like the Eclipse PDE and the Maven Tycho plug-ins. Products like server-side equinox and Spring DM server are already available, providing Java EE container support for modules. By the time that Sun finally decides on a module system for Java, will it really matter?

Visual Studio integration for Jazz beta available

peterhe — Sun, 16 Nov 2008 16:55:00 GMT

There now is a beta version available for Jazz / Rational Team Concert integration in Visual Studio. See this video for more information. I've seen the VS client in action at the RSDC. It's still pretty limited compared to the Eclipse based tooling, but good enough for developers to just work with the version system and some quick work item management. As with everything else involving Jazz the beta is available for download, but you'll need a free jazz.net account to get to it.

J-Fall 2008

peterhe — Wed, 12 Nov 2008 20:17:00 GMT

I visited J-Fall 2008 today, another successful Java conference organized by the NLJUG. J-Fall/J-Spring are the biggest Java events in the Netherlands, it's always fun to visit, see what the latest developments are, what people are doing and how crazy the conference booths are. Although actually the booths were pretty quiet this time, which is a big plus, because it's a lot easier to talk without all kinds of loud bells and other noise going on.

There was a lot of attention for JavaFX (Sun) and Flex/Flash (Adobe). It's kind of funny to watch Adobe (also mac dudes paint tool vendor) really trying to show Flex as being more "Enterprise worthy", while Sun (also building operating systems for nuclear submarines) pushing JavaFX as a cool tool to draw animating pictures and circles. I do want to give special credit to Sun though for some really cool demos that actually worked this time! Chuk Munn-Lee, a Sun JavaFX engineer, did a few sessions with some nice humor and a really fast demo during the second keynote. Knowing how hard it is to keep typing straight while presenting on a big screen, and that Chuk was banging away on some nightly unstable builds of both Netbeans and JavaFX, that was pretty impressive.

There also was a session about IBM Jazz. I think that's great as Jazz is a big step forward in ALM tooling, especially for Java projects. IBM is once again leading on features and vision, pushing competitors harder to innovate as well. After a couple of years of relatively few innovations in the tooling space, I think the upcoming period will be a lot more interesting.

On the other hand, I missed some topics as well. Nothing on the coming soon release of Java EE 6, or information about the new Glassfish v3 "prelude" version that was released last week. No sessions on what Spring is up to with their new "DM" server and new commercial offerings strategy, which scared a lot of users in the past few months. Although all the sessions I have seen were on the okay to excellent scale, some talks in my opinion did go out on a limb without a lot of actual real-life experience with the topic. I think it is fine to talk about new tools without much experience (what else can you expect?). However, I think it's very important to recognize that sometimes new technology is interesting and useful, but not (yet) something that can be recommended to the masses. I keep being impressed by the quality of the questions from the audience at NLJUG events though, and with some tough questions, presenters did not get off the hook easily.

When walking on the pavillion I did have some nice conversations with people about what they were actually doing with new methods and technologies. A nice example was the Adobe showcase booth, where ISVs showed their real life products based on Flex. I talked a bit with a vendor that supplies software for payed parking lots. Payed parking lots are a serious frustration for me lately, because really often, it just doesn't work, so I immediately got interested. It's nice to hear about actually using agile concepts and Flex in relatively tough projects like parking lot automation, and how they dealt with some of the problems they faced. For me, a separate spot for showcases are a keeper for next NLJUG events. See you at the next J-Spring!