Java with Spring just as productive as a 4GL RAD tool

31 July 2005

Java with Spring just as productive as a 4GL RAD tool by Erwin Bolwidt and Vincent Partington.

Java is known for its platform portability, its scalability, and the large number of libaries and tools available for it. However it is oft maligned as not offering sufficient productivity especially when compared to 4GL RAD tools or the .NET framework. During the 2005 Dutch RAD Race we proved that Java beats the .NET framework and measures up to the best RAD tool, without sacrificing quality and flexibility.

The secret : Spring + Hibernate + Tomcat + Eclipse with WebTool and Hibernate Synchronizer. They point out time loss in GUI and propagating changes through the layers.
Source : Software Documentation Weblog.

Ontology is overrated: categories, links, and tags

31 July 2005

From Clay Shirky : Ontology is overrated: categories, links, and tags.
I quote : “It’s all dependent on human context. This is what we’re starting to see with, systems that are allowing for and aggregating tags. The signal benefit is that they don’t recreate the structured, hierarchical categorization so often forced onto us by our physical systems. Instead, we’re dealing with a significant break — by letting users tag URLs and then aggregating those tags, we’re going to be able to build alternate organizational systems, systems that, like the Web itself, do a better job of letting individuals create value for one another, often without realizing it.”
Still, I think that he underestimate the value of Ontology to build concept and extract a meaning from the chao.
Form : 18 pages with graphics.
Source : Column Two : News and opinion on all things KM & CM.

Characterizing People as Non-Linear, First-Order Components in Software Development

31 July 2005

Alistair Cockburn has reviewed three dozen projects and methodologies over 20 years. I quote his conclusions :

  1. We are sensitive to communication timing and modalities. The prediction is that physical proximity and ease of communication has dominant effect.
  2. People tend to inconsistency. The prediction is that methodologies requiring disciplined consistency are fragile in practice.
  3. People vary, not just daily, but from group to group. Methodologies don’t currently, but do need to deal with this cultural variation.
  4. People like to be good citizens, are good at looking around and taking initiative. These combine to form that common success factor, “a few good people stepped in at key moments.”

Characterizing People as Non-Linear, First-Order Components in Software Development.
Form : 9 pages (I had to copy and paste the whole text in OpenOffice in order to get a readable printout !)
Source : I saw a reference to his article on the TheServerSide.

One or many IDE ?

22 July 2005

Should a team use only one IDE, one OS and one JVM ?
At first it seemed right to me. It should even use the same installation path, so a clean checkout from the source repository won’t lead to a lot of running around and manually editing jdbc driver paths …
Then some argue that :
– only separate build server and build management guarantee project integrity; there should be no IDE specific whatsoever;
– keep developers happy;
– guaranties that project is IDE agnostic;
– helps having straightforward and well understood (and documentd) build/deploy process;
Same is applicable to OS, with Ant/Maven Java project can be pretty much OS independent and it is not that hard to maintain a bit if OS dependency if necessary. It actually may help streamlining and adressing such spots if team pays enough attention.

There are two points there : since developers are key to success, you shouldn’t put barriers to them and, as underline by the first comment, should the build process rely on the IDE ?

So the debate is open.

Why J2EE Projects Fail

22 July 2005

Experts from the comments on Symposium Presentation: Rod Johnson – Why J2EE Projects Fail

A short list :

  1. People !
  2. Business Knowledge of development team
  3. Communication with users
  4. Iterative Development
  5. Finalizing UI upfront

The long list by raj kul (Swarraj) :

  1. Gap between Business Analysts and Technical Architects: Business Analysts need to translate the business requirements in simple language which can be clearly understood by the Technical Architects. On the other hand, the Technical Architects need to have some understanding on the business domain. Both of them can come up with simple glossary documents covering ‘Business Terminology’ and ‘Technical Terminology’ which will help them to understand what the other person is talking.
  2. Missing Non Functional Requirements: J2EE may not help in achieving NFRs in the end. Yes, few parameters can be tuned to achieve few of the NFR goals. Critical NFRs must be clearly understood in the initial stages and should be considered in the Architecture / Design / implementation / QA-Testing stages. Project is considered as failure when the NFRs are missed by huge margins.
  3. Architects role: Technical Architect plays a major role in overall application success. Architect needs to put the application building blocks in place by considering NFRs, possible appropriate J2EE technologies, etc. Architect should evaluate multiple possible options before settling on
    any one approach including partitioning of application / technology choice (J2EE != EJB) / communication protocols, etc. Architect should deliver detailed architecture and design documents well in advance which can be reviewed and discussed with senior members of team
  4. Understanding of J2EE technologies: Not everybody from the development team is J2EE expert. Few of the members may be new to J2EE and needs to gear / brush up J2EE skills. Simple crash course on the project specific technologies and J2EE best practices will definitely help before the actual development starts.
  5. Ongoing code review: The ongoing code reviews will help to verify that standard J2EE best practices are in place, design patterns are implemented correctly, coding standards are followed throughout the application, etc.
  6. Use of productivity tools: Project teams should incorporate productivity tools in their development environment. These tools can include XDoclet, Checkstyle, PMD, Jalopy, etc. The team should have standard development IDE and build system in place.
  7. Continuous testing and QA: Iterative and incremental development will achieve continuous testing and QA of deliverables. Standard bug tracking system should be in place and quality champions should track the overall progress with respect to quality. Application developer should spend time on unit testing. JUnit kind of unit testing frameworks should be made mandatory in project.
  8. Adherence to J2EE specifications: Project teams need to stick to J2EE specifications and not to the underlying container specific APIs. These APIs are good in short term but in long term they will act as trap and you will loose WORA facility guaranteed by Java / J2EE.
  9. Simple but working approach: Client needs working solution not the big technology stack. Over-designing the applications will not only take more time but will increase the chances of failure. Client requirements can be broken down in small sub systems and releases should be planned in such a way that client will get started on the application early. Even in small blocks when client see the working system, his and development team’s confidence will go up and obviously the chances of success will go high.
  10. Use of Open Source components: Do not build everything on your own. There are several J2EE related open source technologies available on web. Use them (after evaluation and testing obviously) wherever possible. You can also modify them if needed for your application needs. This will help in saving development time. For example, displaytag utility can be used as navigational component.

Finally, I like this one : “There are too many theories, patterns and methodologies floating in J2EE world that divert attention away from the goal of the project.”

Calling all CSS-Savvy Designers

22 July 2005

Calling all CSS-Savvy Designers by the Web Standards Project BUZZ.

It isn’t often one gets the opportunity to help define the tools you’ll be using in your job, and this is a golden opportunity. There’s quite a thread already started, but really it’s nowhere near as exhaustive as one would expect for such a significant request. Let’s change that, pronto: add your comments to his post and tell all your friends


Google Sitemaps

18 July 2005

Google Sitemaps allows you to inform search engines about URLs on your websites that are available for crawling. In its simplest form, a Sitemap that uses the Google Sitemap Protocol is an XML file that lists URLs for a site.
One more thing to maintain, is is really worth it ?