Skip navigation

I was doing some C++ hacking today, and I added the traditional:

#ifndef MYINTERFACENAME_H
#define MYINTERFACENAME_H

preprocessor magic in my .h file and it occurred to me: normally I don't even question having to type such nonsense in C++, I just live with it. Exploring this train of thought more completely, I realized that C++ has never gone through a concerted ease-of-development effort as Java has been going through over the past few years. Why is that? Is it because Mr. Stroustrupdoesn't care about the corporate developer? Is it because no one company is betting its future on the success of C++, and therefore there is no need to expand the ranks of the developer?

Technorati Tags: edburns
javaserverfowner

All Hail TDD! Blog

Posted by javaserverfowner Mar 14, 2005

Way back in October 2002, I had the enviable position of ramping up the development effort for the Sun RI for JavaServer Faces. At that time, Test Driven Development (TDD) was just starting to catch on, and I used my position as team leader to mandate (HA!) that we would use TDD on the project. I realized that for any mandate to succeed, it must be easy to implement, so the team and I invested in building the infrastructure iteratively growing our test codebase. I can't tell you how many times that investment has paid off, but I'll tell you one time: right now.

While implementing Adam Winer's proposal for fixing the State Saving Window Id problem, I came across a corner case not covered explicitly in the proposal. Basically, the proposal re-allocated some responsibilities and neglected to re-allocate this one corner case, which happened to be caught in an HTMLUnit test, written by Craig, I think. Unfortunately, the net effect of this neglect was to throw the webapp into an infinite loop. It was very easy to re-produce: just visit the prefix mapped webapp and include only the servlet-mapping with no trailing slash and no viewId. Thanks to the unit test, I quickly found and fixed the problem, without introducing the bug into the code.

Next month I'll have the opportunity to ask questions in real-time to John Loiacano, Sun's head of Software. I usually can come up with tough questions on my own, but since I got into blogging, I thought, "why not see what the world wants to know?" So, please leave a comment with your questions, if you are so inclined. I can't commit to publishing any answers in this forum, but who knows, perhaps I'll run into you at a conference and we can talk off the record. In person, I can exercise the usual discretion when talking about such things, which isn't as easy in a blog. Ed  

http://www.ddj.com/documents/s=9211/ddj050201dnn/

I know I'm late to the party on this article, so please excuse my tardiness.

I'd like to offer my thoughts on how Microsoft and Sun have approached the problem of bringing more "ease of development" to their respective platforms. According to Mr. Grimes's article, Microsoft marketing was behind the introduction of VB.NET. Their motivation was to free the massive numbers of developers they had won with VB from the shackles of a single-threaded non-OO language, while still retaining those massive numbers firmly in the Microsoft development camp. Their approach to do this was marketing driven, and resulted in the creation of a backwards incompatible language, with an implementation of inconsistent quality, that is marketed as being backwards compatible with VB. Sun's motivation for "ease of development" was, "we have a great, powerful, easy to use, language, but damn, look at all those VB developers!" Sun's approach, rather than being marketing driven, was engineering driven. We chose to develop easy to use tools and technologies (like Java Studio Creator and DASL) and add selective, highly considered, features to the core language. I contend that right now Sun's approach has yielded a more successful result in terms of "ease of development", and it's starting to yield a good result in terms also of developer capture as well.

Gregor Hohpe SOA - Same Old Architecture

I often have angst about how my relatively narrow focus on web
presentation technologies, and faces in specific, is potentially career
limiting.  Therefore, I'm taking steps to look up and look around.
Mr. Hohpe's talk is such a step.  He has so much to say about SOA, and
appears to understand the software development practice on its own very
well.  So attending the talk, while I won't retain nearly all of the
content, is very valuable.  I'll put his book Enterprise Integration
Patterns on my Safari bookshelf.

By the way, I think it's really great that Sun pays for all of its
employees to have access to the Safari Books service.

Regarding the talk itself, a good point that ties into my angst is that
architectural patterns don't evolve that fast, but the vendor economics
dictates that they want their products to evolve and sell quickly, so
they spin it so the state of the art seems to be evolving very quickly.

Keynote panel

Q: Motorola guy: Why should I believe that J2EE will withstand the .NET
onslought?

A.Cliff: IBM

A.Mark: people may not want vendor lock-in.  People aren't putting all
their IP into .NET.  

A.Rod: projects are succeeding

A.Cliff: Band together to fight MS.  JCP.  Open Source influencing JCP.

A.Gregor Hohpe: JCP: give us your idea, Sun owns it.  MS: give us your
idea, we hire you.  It's about developer mindshare.  The stuff that is
most pervasive, is the stuff that's no-one talks about any more.  Cobol,
C++. There aren't that many Cobol conferences, but many businesses are
running their businesses on it.  People like choices, but not too mant
choices.  

A.Linda: agree.  We have a competitive technology market of our own,
therefore, we have the benefit of having these technologies compete
against each other.  

A.Mark: No one does COM any more?

A.Gregor: doch.  But new development is outweighed by maintenance many
times over.  There is lots of COM out there.  MS did lose some of the VB
community with ASP.NET.  

Floyd: MS has sent out invitations to developers that are neutral to
hostile to .NET.  

Rod: there is some growth in .NET open source things.  How long will EJB
and J2EE live?

A.Dion: waiting for the next thing.  

A.Mark: Look at core of Java and MS.  Java: boundaires: JVM, libraries.
Enables independent evolution.  .NET: boundary is Windows.  Can't evolve
independently.  Personal: but can't MS just introduce this boundary?

A.Rod: MS community is very pragmatic.  Let's learn from it.  

Audience: I like SOA.  Why are you guys dissing it?

A.Gregor: It's coming, but it's not displacing.

A.Rod: SOA is coming, but slowly than it seems.  J2EE App Server is
becoming a commodity.  

Q: Does it make sense to bring in loosly typed objects directly into
Java?  

A.Mark: JAXB is going to this.  

A.Cliff: Apache XMLBeans is out there.

A.Dion: EcmaScript for XML, E4X, has this.  

Q.Rod: What's happening with Groovy?

A.Dion: It's a JSR, it shouldn't be.  What else can we do on the JVM.

A.Cliff: Open source is a better venue for early collaboration than JCP,
because the vendor nature of JCP.

Q: J12004: we're going after MS developers.  It hasn't happened.  Why?

A.Gregor: Java makes people waste too much time on versionitis.

A.Mark: He thinks the component area with JSF is where we can make some
headway.    

A.Rod: Tools are still not as good as MS.

Q.Nike: missing in java: the nightly batch run.  Not a lot of support
for transactionality from a batch process.  

A.Rod: Agree.  We're not giving any attention.

A.Mark: Agree.  Platform is oriented to interactive "real time" apps,
not batch apps.  

Q. Putting JSF into J2EE seems to be a marketing thing.  Will this have
a negative framework for other frameworks?

A.Cliff: Still the same.  People will choose, even if it's in J2EE.  

A.Rod: Persistence: there is some clarity in the winner.  In the web
space, not yet.  It'll be interesting to see who wins.  

A.Mark: I don't think that bundling JSF won't stop other frameworks from
existing out there.

A.Dion: Depends on the kind of app you're building.  



  Tapestry Overview

    Component-based

    Minimizes java coding

    Developer Focused

  Benefits

    Simplified, readable HTML

    True separation of MVC

    minimal java coding

    Great I18N
 
    Great developer feedback (fix)

    True component reuse

  Simple Forms

    Login page

  WAR layout

    Page is three:

      HTML file, the view

      Java Code

      XML file that tie two together

  Start with Plain HTML

    Mark tags as components by giving them the jwcid attrs.  There is a
    standard set of components that can be bound to html elements

    OGNL does the value binding with the value attribute.

  Create the XML part.  

    Identifies the java class

    (problem) three artifacts for the page

  Create the Java Part

  Q.1 Is there a scoped namespace facility?

  Listeners are constrained to be a certain type.  

  Q.2 Are there any other kinds of listeners?

  Has the concept of an active page.

  Validation

    Error message is per page.  Can there be per-component error
    messages? Yes.  He mentions lots of things that can be done with the
    implementation.  More components.  

    Client side validation, is easy to do.  Just turn it on.

  Has conditional tags.  This is done by having <span> with id

  (copy) When displaying the error page:

    Line precise error message

    Display evey possible piece of info you have.  Query params, system
    properties, etc.  

    Only do this during development.

  The incorrect page pooling problem shouldn't happen
 
  Q.3: Are all beans defined in .page files?  Can you have app session,
  scoped beans?

  Mega Components

    Table Component

      They have per-cell renderer.

    Palette: does some AJAX stuff

  Principles

    Simplicity

    Consistency

    Efficiency

    Feedback
Rod Johnson

  - Agile J2EE has saved the J2EE platform from destroying itself via
    its own best practices (blueprints).

  - AOP 

    Not growing as fast as he expected, but it will continue to grow

    AspectJ 5.0 will be the definitive AOP framework going forward

    Standardization?

      Hard to see the benefit now

    JCP standardization not appropriate for AOP.  AOP is not
    language-specific.

    Proxy-based AOP: a transitional technology

    Implications of AOP for app servers

    - We'll see an evolution from a monolithic container to a service
      integration point.  I think he's saying the app server is being
      commoditized.

    Technologies to watch

      IoC/Dependency injection

      TDD

      O-R mapping.  

      Post struts 1.x web technology

      Value add web technologies

        Struts 2.0 is moving into workflow

        Beehive

        Spring is adding web flow technology

     Rich Client

     Technical skills to acquire

       Frameworks/methodologies

       Ability to set and ensure project direction

       Offshoring: it's coming, if you know to leverage, you'll have a
       job

To round out the day's sessions, I attended two from Cameron Purdy of Tangosol. His first, on peer to peer, was quite excellent, though I expect many found it rudimentary. I, having been so focused on Faces in recent years, found it very informative. It was nice to go back to my old days as a network programmer at NCSA when he talked about IP multicast and its applications to clustering. Following that talk, was another with Mr. Purdy, this time joined by Patrick Linksy, of SolarMetric. Here they presented their collected wisdom about achieving performance and scalability in a J2EE app. This talk was chock full of war stories, which I found very interesting. The evening party was quite enjoyable, taking place in the private pool area behind the hotel. It was reserved exclusively for TSSJS guests and featured fine hors  

Rod Johnson, why J2EE projects fail

I. Enterprise Development is Hard

  A. Why

     May integrate disparate systems

     Hard performance problems

     Complex domains

  B. hard to test

  C. Hard to maintain

    Software is never finished.  Maintenance accounts for the bulk of
    effort

II. J2EE is not a panacea

  High failure rate

  Good technology doesn't guarantee success

  Bad technology does guarantee failure

III. It is possible to succeed in J2EE

  Sound fundamentals

  More mature app servers and tools

  More mature developers.

  Recounted anecdotes around impl problems a while ago.  

IV. General reasons for failure

  1. Poorly understood requirements

    Nothing to do with J2EE

  2. Ideology (come back to this)

     What constituted a pure J2EE system

       RDBs are evil

       Java is the center of the world

       J2EE is distributed, so everything is remote.

       * Technology is more important than the problem

  3. Lack of attention to performance

  4. Bad team dynamics

    God-like architect

    Too big a team

    Overworked team (reactive v. strategic modes)

V. Technical reasons

  Missed deliverables

  Too much code

  Take small example and extrapolate when it doesn't scale

VI. Requirements

  There are less excuses for technical failure

  He emphasized the importance of communication, more important than
  technical.  The importance of working with your manager.

VII. Requirements checklist

  Do we know what the application should do?

  How it should do it?

  Whether does it does it?

  Also mentioned the importance of testing.

VII. Solutions

  Establish Continuall feedback

  Listen to business

  No waterfall usage

    J2EE is particularly ill suited to waterfall

  Educate the business about the process.  

VIII. Ideology part II

  Lots of it is kinda receding, he thinks this recession is one of the
  reason that more J2EE projects are succeeding.

IX. Lack of attention to performance

   one of the key failure causes

   "First get it to work, then optimize"

   Use architectural approaches that allows a degree architectural
   refactoring.  Such as?

     Loosely coupled layers (but be mindful of performance)

X. Team dynamics: the God-like architect

  Politically astute, technically not.

  Two varieties

    non-coding: powerpoint, UML, (motivation: not enough), big picture
    only

    The prescriptive framework builder: obsessed with the small and big
    picture.  Cares about controlling every aspect of the programmer's
    life.

      The myth of the code monkey: they exist to knock out code.  

    The framework builder believes that his main role is to prevent
    developers from doing things.  This is not how to develop
    frameworks.

   Successful Frameworks make best practice easy to do, but doesn't get
   in the way of developers doing whatever they want.

XI. Team Dynamics: Consequences of prescriptive framework builder

   Team morale plummets

   People leave

XII. TD: Loss of communication

  His view of the architect is that they can actually do any role on the
  team.  There must be mututal respect.  Communication is essential to
  success.  He listed an example of bad communications

XIII. TD: too big a team

  Scale the team up at a managable level.  Do proof of concept first,
  then grow the team.  You have to know how to solve the problem before
  you grow the team.

XIV. It's about working smart, not doing more work

  Rod is interested in history

    Higher up decisions are very important.  You can't succeeded with bad
    top down decisions.

  Using frameworks allow working smarter

  1. Big problems

    Too much code.  Too much maintenance

    Why?  Failure to use appropriate frameworks, insufficient refactoring.

XV. TD: overwork

  people work less effectively when they are tired and stressed.

  Cosmetic overwork is really dangerous.  Impress the client with activity.

XVI. Re-inventing the wheel

  No excuse to build an in house framework from scratch.

  Start from existing generic framework

  Spring

    Lots of extension points (he feels extension points are key for a
    successful framework).  

  People apply high bar for accepting third party frameworks, have total
  trust in their in-house framework.

XVII. Data access framework

  Need to use one.  Stock JDBC isn't enough.  Never use straight JDBC.

  Understandding how to judge OR mapping solution is appropriate.  

  Understand core O/R mapping concepts

XVIII. Testing

  Test first

  Integration testing

IXX. Poor productivity

  Lots of little hurdles

    Slow deploy-test cycles

    Slow build process

    Slow hardware

    Slow integration servers

  MAJOR productivity hits.  Increase the chance of failure

  Design build process and infrastructure to minimize these delays.

  Traditional J2EE development was laden with these little hurdles.

  

XX. Recommendations

  Always begin with proof of concept, or executable vertical slice.  All
  modern methodologies recommend this.

  Establish clear metrics.

    RUP (rational unified process) calls this the inception phase.

  Don't trust architecture-or technologies, until you've tried it with
  your needs.

  Automate everything

    Unit tests don't require container (due to dependency injection)

  Choose good frameworks, that allow customization

I'm at The ServerSide Java Symposium, blogging live.

Let me use this forum to list the people I'd like to meet here: Ben Galbraith, Howard Lewis Ship, Matt Raible, The Bile Blogger. If you see me, please say hi.

I just attended Dion Almaer and Ben Galbraith's talk on ajax. Here are my notes.

I The Myth:

  Not possible too create rich ui only inbrowser

II What is ajax

  A. History: HTML->JS->Applets->Flash (Back Button) and SVG (Not impl)

  B. JS Pain 1998
  
   debugging was nightmare

   xp pain

 C. Defining

    Asynchronous JavaScript and XmlHttpRequest

    Standards based presentation

    Use XML to manipulate data with XSLT

  D. Client model

     No more single request/response restrictions, more flexibility to
     go back to server at will.

  E. Can do it asynchronous, it's a big deal because it changes the
     request/response paradigm.  Gets rid of submit button

  F. A bit on how

     a. still have to do the browser detection thing, but can be abstracted.

     b. showed the code to do the request, handle the response, by
        installing a JS callback.  Get the response as XML, use dom to
        extract info, use dom to put it back into the form.

  G. History of the XmlHttpRequest, methods on it.

    open(), send(), can pass basic auth credentials. (What about certs?)

    JS has function pointers

  H. Ecmascript for XML (E4X)

     Build dom straight into Ecmascript
  
III Who's doing it

  A. Google: maps

    images are tiled.  Requested asynchronously, that's how panning
    works.  JS supports layering, with transparent images.  

     They use IFRAME, which allows history to work.  

  B. Google maps becomes a platform

   When you get into this world, you are building a platform
    
   If you are lucky, there will be a Google hacks on the way.

   Lots of cool hack out there already

  C. Google suggest

    aim: let you know what people are searching

  D. TadaList

    Built on Ruby on Rails

    Simple List component, keeps server side component updated.

IV General Framework

  A. General Solns

    CRUD on the DOM

    Ideal for portals

    Animations, feedback messages

      Feedback messages: just show a message and not re-display the
      whole page.

    Deleting from the Admin Panel

      A tree control, delete a node, don't re-render the tree: just nuke
      it from the DOM.

    Recalculate:

      Why not recalculate on the fly?

  B. SOAP access

     RESTful web services.

  C. Frameworks: Custom...

     Listed examples of common things you can specify as patterns of usage.  

  D. JSON: JavaScript Object Notation

     Lightweight format to get objects back that are not XML.  Built on
      Object, Array, String, Number, etc

  E. JSON RPC: essentially a Java ORB

  F. JavaScript Templates

     Manipulating the DOM is a pain.  Use templating.  Basically, allow
      parameterized DOM access.

  G. AOP with JavaScript?  Yes, you can.  

  H. How to fit with frameworks?

    Have component that integrates this functionality.

    You can register a component with tapestry that will receive all the
      requests dynamically.

   (I'll be talking with Ben immediately after this talk)

  I. JSUnit: how to do test first with JavaScript.

   Solenium

V RSS Reader Demo

  Show you can build an offline capable application with AJAX.

VI Conclusion, warnings

  A. Warnings

  Don't use for technoligies sake.

  Understand Usability testing

  Understand restrictions

  Still in creative mode

    Frameworks will be coming, take the work out of it

  B. JS Survival tips

    You'll miss the IDE

    Packaging as source only lets people see source code

    Debugging, tougher, firefox, mozilla has something

    Packaging libraries: be wary of namespace.  The packaging scheme is
      basic

  C. JS Limitations,

    Can't access resources on other sites: wrong, must sign code.

    Signed code can also read from and write to the local filesystem.

    You have to get permission in every function.

  D. ajaxian.com

     Don't build your own framework.  It's probably been done before.

I'm at The ServerSide Java Symposium, blogging live. I just attended Mark Hapner's keynote and here are my notes.

Mark started out listing some things that companies own, vs. what
communities own.  Companies own OS's, some protocols (AIM), but they
don't own the wire.  Communities own massively distributed services,
such as email, content, and also protocols.  Interestingly, he asserts
that Java is owned by the community.  The crowd grumbled a bit at this
assertion.  These two points of ownership were listed as a means to
support the assertion that developers want to own the whole stack:
protocol, framework, applications.

He introduces the concept of the services wire, stating that we must
never cede the services wire to a non-global protocol.

He spent some slides on defining what a services platform is, and
concluded that J2EE is getting closer to being that, but wasn't there
yet.  He used the analogy of the Unix Pipe as an easy way that programs
interoperate.  We need something similar for Web Services.

Service evolution is all about collaboration.  The essence of
collaboration is messaging, but messaging alone isn't enough.  You need
some message exchange patterns.  So, services will be built as
compositions of pipelines, a-la-Unix pipes.

The impl of MEP is XML.  (This places great importance on technologies
like fasst infoset).  Java is a great platform for XML.  Using XML here
allows each service node to use the technology appropriate to its need.
Of course, it also provides impl independence.  

Here Mark listed the core assertion of the talk, his vision for services:

  J2SE is the core
  JMX is the management piece
  JBI will be the collaboration piece
  J2EE will provide the services and the technologies

  This vision lead to Mark assert that the Java platform plays the main
  role in building out the web, and therefore will enable people to
  achieve their dream of community ownership of the entire stack.

Filter Blog

By date: