Editor's Daily Blog

Late 4 Work

Organizing your development teams

An interesting question once you have more than a few developers on your project is how to arrange them. Yes, you want to pair people to their talents, but how are you going to get them to work with each other? Are the server guys going to play keep-away from the client team? Are the database developers one-trick ponies, or can you get them to help out on other parts of the system? Do you want developers to have a broad top-to-bottom understanding of the application, or keep them in their own little silos and really focused on one distinct area? And how much does your development methodology -- whether waterfall, XP, cowboy, or something in between -- determine your personnel policies?

These are the questions that John Ferguson Smart focuses on in his blog Architecture-Oriented or Feature-Oriented - how do you organise your development teams?

Traditionally, there are two fundamental approaches when it comes to organising your development teams: the Architecture-Oriented approach and the Feature-Oriented approach. The first priviledges teams that focus on the different architectural layers or components, whereas the second prefers to organise teams around deliverable application features.

Which works best? Not to give too much away, but the best answer might be a hybrid approach:

Personally, I prefer the flexibility of the Feature-Oriented approach, but keep a healthy respect for the clean architecture that is fostered by an Architecture-Oriented approach. One possible compromise that I have used on some of my projects goes along the following lines...

Also in today's Weblogs, Alexander Potochkin's JXLayer 3.0 - LockableUI compiles up-to-date information about one of SwingX's most difficult features, "so forget about the blocking glassPanes, input verifiers, old JXLayer API and let's start."

In JEDI Certification - Help the Brazil community to build the certification exams for JEDI, Daniel Wildt asks, "Do you know JEDI project? Do you want to help Brazil community to build the certification test for JEDI modules? Your time has come! So, study JEDI modules and send out some questions for us!"

In Java Today, Patch 2 for NetBeans 6.1 is now available. The patch includes bug fixes in modules for BPEL, C/C++, Composite Application, Database, Editing Files, GlassFish, IDE Platform, JSF, Java, Java Debugger, Java Profiler, Mercurial, NetBeans 6.1, NetBeans Plugin Development, Platform, RESTful Web Services, Ruby, SOA, Spring Web MVC, Visual JSF, WSDL, Web Applications, Web Services, XML and Schema. To obtain the fixes, the NetBeans IDE must be installed and running. You can download the fixes through the IDE's Plugins Manager.

The Aquarium points out a tip for Running VisualVM on MacOS X: "I wrote about VisualVM yesterday (entry) but I had missed Octavian's Introduction where he gives instructions on how to use VisualVM on MacOS X. As a reminder, to run the VisualVM client you need a recent JVM, so you will need to use the latest JVM from Apple, but the app can run in a variety of JVMs, remote or local to VisualVM. VisualVM can even save the data into a snapshot and process it offline."

InfoQ explains the next concept that might be standardized in Java concurrency: Phasers. As explained in New Java Concurrency Feature: Phasers, Doug Lea, the spec lead of the JSR 166 concurrency utilities, posted on the 166y concurrency-interest mailing list this week regarding the feature. "The flexible barrier functionality that was previously restricted to ForkJoinTasks (in class forkjoin.TaskBarrier) is being redone as class Phaser (targeted for j.u.c, not j.u.c.forkjoin), that can be applied in all kinds of tasks."

This week's Spotlight is on the Java Native Access (JNA) project, which provides Java programs easy access to native shared libraries (DLLs on Windows) without writing anything but Java code--no JNI or native code is required. This functionality is comparable to Windows' Platform/Invoke and Python's ctypes. Access is dynamic at runtime without code generation. JNA's design aims to provide native access in a natural way with a minimum of effort. No boilerplate or generated code is required. While some attention is paid to performance, correctness and ease of use take priority.

In today's Forums, michael_heinrichs spots a dangerous technique in Re: Strange: AWT-EventQueue-0 and incorrect display in JavaFX table. "The first issue I noticed is you are using a Java-Timer together with JavaFX. That is pretty evil and should be avoided. It is very likely you are running into some synchronizations issues (might even be the root cause of the problem here.) I suggest to write the StockFeederMock in JavaFX using a Timeline. Switch to compiled JavaFX and to the new UI-library (packages javafx.gui.*)."

nileshpereira forsees severe Palm porting problems in Re: Volunteer needed to port phoneME Advanced to Garnet OS / Palm OS. "Unfortunately, all the old code you find out there is m68K-palmos code, which is not going to be of much use beyond implementing the CDC GUI. All the heavy lifting of the CVM will only be possible using arm-palmos code, of which there is precious little information. None of the toolchains like Palm's SDK or Prc-Tools work out of the box and create working arm-palmos code, as they haven't been updated for many years. Even worse is that there is no way to test the arm-palmos code except on the device, as the Palm Simulator is only able to execute m68k-palmos code. Infact, I think the only way to get working arm-palmos code is to build Prc-Tools from scratch and apply your own patches onto it, which is what Tom Borris has done for his SDL port."

Robin Chaddock points out challenges imposed by CLDC's limitations in Re: Java ME and remote classes. "CLDC does not provide java.lang.ClassLoader, and so provides no mechanism for runtime definition of Java classes. CLDC also does not support java.rmi. Therefore, implementing what you describe in the way you describe it is impossible. Obviously there are other ways of achieving this functionality (running arbitrary code on a thin client) but you'll no doubt find them restrictive, cludgy and inefficient. A better solution would be to target CDC rather than CLDC., where all of the api functionality you require is exposed. (with the rmi package itself being an optional addition)."

Finally, demonduck vents some serious plug-in frustration in Just updated to 1.6.0.7 -- it sucks worse than 0.5. "What are you people doing? 0.7 draws half as fast as 0.5 and 1.6.0.5 was already slower than 1.5.0.13. http://pancyl.com/VSync.htm draws half as fast as in 0.5 and 0.5 is about half as fast as 1.5.0.13. What are you doing??? Are you trying to put us all out of business? And the LiveConnect bug is still disabling JavaScript <-> applet communication."

Current and upcoming Java Events :

• July 15 - JUG Genova meeting on Google Web Toolkit (GWT)
• July 18-19 - Salt Lake Software Symposium 2008
• July 21-25 - O'Reilly Open Source Convention 2008
• July 25-27 - Central Ohio Software Symposium 2008
• July 25-27 - Desert Southwest Software Symposium 2008
• August 1-3 - Central Iowa Software Symposium 2008
• August 4-8 - Java Training Philippines
• August 8-10 - Atlantic Northeast Software Symposium 2008
• August 11-15 - Struts Training Philippines
• August 15-17 - Southern Ohio Software Symposium 2008
• August 18-22 - J2EE Training Philippines
• August 25-28 - Dev Week India 2008
• September 29-October 1 - The Ajax Experience

Registered users can submit event listings for the java.net Events Page using our events submission form. All submissions go through an editorial review before being posted to the site.

Archives and Subscriptions: This blog is delivered weekdays as the Java Today RSS feed. Also, once this page is no longer featured as the front page of java.net it will be archived along with other past issues in the java.net Archive.

Comments

This work is licensed under a Creative Commons License.