Panel members are:
 
Venkat Subramaniam – founder of Agile Developer
Keith Donald – one of the Spring junkies
Neal Ford – ThoughtWorks
Scott Davis – co-author of JBoss at work
Andy Glover – Vanward Technologies
Jared Richardson – author of “Ship It!”

 
Question on the Ruby phenomenon – the panel is a bit more sedate on this topic than I expected. No foaming at the mouth yet. Most of the panel members are fairly balanced, suggesting that Ruby is worth our attention to learn, but hasn’t wrested the crown from J2EE as the “it language”, as some people seem to believe lately.
Question on simplified web development, lowered development cycle time – lots of excitement over productivity on Ruby on Rails. Good mention of the Java alternative to RoR – Trails.
Question on goods and bads on Java 5 and Java 6 – one positive is JConsole with Java 5, and the level of instrumentation that comes with a standard JVM. Neal’s concerned about over-engineering in Java, including generics, the addition of Javascript into Java 6. He mentions Bruce Tate’s recent “Joe the Monkey” entry. Scott Davis jokes he won’t upgrade to the next version of Java until they deprecate something.
A decent discussion of agility in architecture. One interesting observation is that the lack of an analog for the DAO in MVC/web frameworks makes the choice of web framework a much bigger committment than a committment to a persistence solution.
Now we have some light references to test-driven development. It’s all fine and dandy, but I have yet to hear people provide a compelling approach to testing our sort of application. We have a heavily interactive web application that loads all of its pages based on user context, and has handshakes and signals to a back end server, sometimes out of sequence. We have pages and pages of Javascript includes. We have a matching engine that requires numerous active entries, and a non-deterministic outcome.

 
That’s about it. Interesting, but nothing unexpected.

 

Where am I blogging from? No Fluff Just Stuff’s Greater Atlanta Java Software Symposium.

I neglected to write about last night’s Agile Estimating and Planning session by Mike Cohn, who will be presenting most of the sessions I’m attending today. It was a good session – the main takeaway was that in planning projects, and particularly in estimating features for software, relative estimation is more accurate than absolute estimation. We’re better at realizing that one feature (or “user story”) is twice as difficult as something we’ve done previously. The idea is that then, once we’ve defined an abstract measure of work, we can gain a pretty good idea of the “velocity” or our team – the number of units of work we can accomplish during an iteration. Re-examining the plan versus results after each iteration helps us find a good equilibrium for our team.

This morning, my first session is Managing Agile Projects. It has a good bit of overlap with yesterday’s session, but addresses a broader array of topics. The prime concern is dispelling myths about agile project management – that agile projects are impossible to plan, that they don’t need to be managed because they are self-organizing, and that the project manager’s role is to buy pizza and get out of the way.

The first new tool to me is the “burndown chart”, which can be used for both releases and iterations within a release. In essence, the y axis is the amount of work remaining, the x axis represents the amount of time for the release or iteration. Each iteration or day, you update the work remaining, and connecting the line of work remaining over time gives you the ability to extrapolate and see how well you are tracking to the project schedule. It gives you a basis to begin investigating sources of slowdown or unexpected efficiency, adjust the release (either date or content) for the actual progress, and improve your estimation for next time.

On to the necessity of managing agile projects, we’re back to my problem of him talking about this stuff in terms of teams. He’s assessing the readiness of multiple teams for agile development. With just one team, we don’t have the luxury of evaluating team by team. We have the team we’ve built, and they’re very good at what they do.

The idea of a task board to “assign” tasks and track progress is fairly compelling. Some of this comes down to better planning of releases, and getting out from under the weight of bug fixes is key to accomplishing this. Also, a lot of these ideas seem predicated on the assumption that tasks to be accomplished are all new work, and thus features can be dropped and you can still deliver a release/iteration. In reality, many of our tasks are wholesale replacement of existing application components. Cutting features from a replcement for an existing component is not an option – a replacement MUST be feature equivalent. I suppose we could cut COMPLETION of the replacement from a given iteration and advance the completion to the next iteration, and cut the scope of the progress on replacement for that iteration. I’m not sure here, and will need to think about it further.

Many of these sessions are useful not only for the content, but also in getting me thinking about our development process and procedures, and how they can be improved. I don’t necessarily have good time to think about this stuff during the rush of a given week.

Where am I blogging from? No Fluff Just Stuff’s Greater Atlanta Java Software Symposium.

Kito Mann is here to talk about Portlets (though I normally relate him to JSF). The nice thing about portlets is that they make portals not just a capital-P Portal that the vendors all try and sell, they help commoditize the idea of a portal into a lower-case-p, somewhat portable aggregation of componentized applications. Back at S.P. Richards, we found single sign-on, minor user personalization, and content aggregation to be the most valuable aspects of a portal to our business, and created a “portal” with a few webapps and Tomcat’s single sign on valve. The other bits – multiple device support, portlets, and complex personalization, weren’t really necessary for the needs of the business. At the time, the open source portals didn’t seem mature, and the Portlet spec had just been approved.

A question to ask shortly… Many Java APIs are fairly useless without the vendor-extensions. How much of the common portlet functionality depends on vendor-specific configuration?

Generally, portals are bite-sized applications that can be embedded in a portal view alongside other portlets. Google has an example of a non-hideous portal.
The “Top Stories”, “Weather”, and “Quote of the Day” would be portlets in Java land.

The rest of the session has been a fairly mundane tour through the Portlet API itself. Mostly stuff you could pick up from a magazine article. The actual demo of the portal using Liferay is fairly interesting. It looks like Liferay has come a long way in the past year or two, in terms of look and usability. Getting it working was also a beast at the time, and it didn’t respect J2EE security, but if I need a portal, I’d have to at least give Liferay a second look, based on what I’m seeing.

Where am I blogging from? No Fluff Just Stuff’s Greater Atlanta Java Software Symposium.

Maybe this session sounds like old hat, but I’m looking for more ammo to add to the list of reasons we should jump to Java 5 from either 1.3 or 1.4, and sooner rather than later. Already on the list is that we’d like to get to Tomcat 5, and introduce Hibernate. In introducing Hibernate, I’d prefer to go straight to H3 with annotations rather than do a double effort of implementing Hibernate with typical mappings or XDoclet, and then moving to annotations. Venkat Subramaniam is presenting.

I’m going to go about this session a bit different and actually post the entry now, and update it as the session progresses.

• Autoboxing – the nice syntax cleanup that turns a bunch of casting from primitives to objects (int to Integer and back). I know that it’s just Java doing all the casting behind the scenes, but I like the way it takes some of the ugly and tedious code out of Java source. The gotcha I wasn’t aware of is that if you write “int myInt = myArray[0];” on an Integer[], and the element in the array has a null value, you get a NullPointerException. Ouch.
• Happier for loops – for(int i=0; i
• enums – nice to finally see a sane way of expressing enums in the Java language. Once again, it’s little more than magic hand-waving behind the scenes, but it’s a real improvement to readability, and short-circuits the constants-as-static-final-variables-in-an-interface anti-pattern, with type-safety as a bonus. Some folks have a real beef with Java shoe-horning these features into the language, I give them a ton of credit for accomplishing their magic in the compiler rather than mangling the runtime with all of these features. I also haven’t seen this magic of adding a method to an enum – very interesting. EnumSet and EnumMap are also news to me.
• varargs – I hadn’t even heard of this until today. More nifty syntax sugar that allows you to supply a variable number of arguments to a method, with type safety. Declare your method public static void doStuff(String…), and you can call it with doStuff(“one”), doStuff(“one”, “2”, “three”) – Java will, behind the scenes, make your method accept a Sttring[], and bundle up your method call parameters into a String[]. Very cool.
• Annotations – one of my favorite new features in Java 5, based on the headache it relieves in creating Hibernate mappings. Defining an interface is quite wacky, but I think far more people will be using annotations than defining them.
• Static Import – Venkat isn’t a fan of this feature, and neither am I. Static import lets you import all of another class’ static methods and call them without even naming the class they belong to. The methods are called just as if they were defined inside the class. This looks like it has major confusion potential, with a minimal value-add.

Mike Cohn’s 12 things you MUST do in transitioning to agile:

1. Pick the right project – find the project with the proper intersection of duration (2-4 months), size (1-5 teams), with a business sponsor, and importance (high – keeps you on task).
2. Pick the right iteration length – XP now says 1 week, Scrum says 30 days – just pick what works and be consistent.
   • Will you allow change during an iteration? (Refinement of requirements is not change)
   • He recommends no – pick an iteration length equal to how long the organization can go without changing its mind.
3. Get everyone on board – make sure all key players surrounding the project buy into Agile
   • Objection – it only works with talented people. No, but you need at least one developer who can fluidly move between different development techniques. (But you pretty much need someone like this for any project to succeed)
   • Objection – it only works on trivial projects. This is disproven by the number and breadth of complex projects that use agile (Yahoo, Joint Strike Fighter).
   • Objection – it’s not appropriate for all projects. This may or may not be true, but just use common sense, use it when it makes sense
4. Have a “customer” – an actual customer or product owner, and keep them consistently involved.
5. Start with a beachhead team – for larger organizations, start with a smaller, focused group and help them fight through the infrastructure and process issues until they’re succeeding. Ensure that this team is fully cross-functional.
6. Deliver – makes sense. Don’t allow the team to miss any deadline, large or small. Missing a small deadline trains the team to miss parge ones.
   • Stress quality, not speed. You want code you’re PROUD of, that you would hang on your mom’s refrigerator.
7. Automate – automate unit tests, acceptance tests, regression tests, builds, deployment
   • Test automation tools – JUnit, FIT, FitNesse, HttpUnit, HTMLUnit, Canoo WebTest
   • Continuous integration – Automated nightly build at least, if not continuous – Cruise Control, AntHill
8. Follow a guide – you need someone who’s been there before, either an employee or an outside mentor or coach.
9. Track and communicate progress – many approaches, from a task board to formal reports
10. Meet Daily – use a daily standup meeting to coordinate, communicate, and make committments to one another
11. Reflect – at the end of an iteration, reflect and discuss what we’d like to start doing, stop doing, and continue doing
12. Don’t try it all at once – start with the practices that seem most valuable, prioritize the ones you want to adopt later in a backlog.

His preferred order of implementing things – Requirements as user stories (light requirements), estimate and create a release plan, nightly or continuous build with tests.

I enjoyed the talk, though much of it seemed focused on how to sway the momentum of a large organization toward agile. He called a company a “small shop” when it had 100 developers. Our entire company is around 50 people, including operations, support, sales, etc. So our challenge is more about the proces to adopt rather than the politics of adopting it. Some later sessions may help shed some light on this decision.

Where am I blogging from? No Fluff Just Stuff’s Greater Atlanta Java Software Symposium. I was using the [GAJSS] heading before, but thought NFJS Atlanta might be more clear, and better signal the relevance of the entires to the Atlanta community better.

Neal Ford is keynoting on using dynamic languages to build domain-specific languages. It’s a stark contrast to Dave Thomas’ keynote from 2 years ago. Dave was very philosophical on the ways we think about doing development. Neal is right down there in the code – source is getting more screen time than powerpoint at this point. He contends that Java is already commonly using domain specific languages in the form of XML configuration files for our frameworks. [As an aside, the wireless access here in the main session room/dining room is actually reliable. JRoller still continues its attempts to eat my drafts as I save them.] Thus far, I honestly think he (along with half the developer community) has gone a bit far off the deep end in terms of the pain of developing in Java. Perhaps I’m numb from being knee deep in Java for more than 5 years, but the repeated dismissive references to “curly brace languages” are a bit overstated, I think.

He’s mentioning Language Workbenches, but at this point it looks like the current set of language workbenches are all proprietary, vendor-based offerings. In my opinion, until there are multiple, freely available language workbenches, perhaps an Eclipse variant or plugin to handle it, this technology will face serious challenges to wide adoption.

So the general idea is that you use this language workbench thing to create a meta-language, that defines a language that is very similar to the problem domain. The problem I see with this is that each individual problem at each individual company is defined with its own domain specific language. One of the reasons community acceptance is such an important selection criteria in choosing which Java framework to use for a particular problem type is the knowledge that the more known the framework, the easier it will be to hire someone who immediately understands at least that framework, even if they don’t understand the company’s software yet. For lower level concerns, I can almost understand a use for this – in replacing the Java frameworks. At a higher level, in terms of a business’ actual problems, such as CRM, manufacturing, etc, I see a potential problem where you now end up hiring developers who understand neither your language nor your problem domain.

This is my gut-shot reaction. I’m going to have to chew on it a bit more and reach more long-term conclusions. Time to head home, starting back at 9 AM tomorrow.

Where am I blogging from? No Fluff Just Stuff’s Greater Atlanta Java Software Symposium.

More Stuart Halloway, now talking about Java Security (slides here. [Incidentally, Roller definitely needs a draft autosave feature. On a spotty network, this is KILLING me that any given draft save can kill my entry. Resorting to a copy of my entry before saving a draft is a cheap workaround.]

We start off with a look at the typical java platform security stuff, the java.policy file and such. I’ve never had much use for this in my work, so the move along to JAAS is a welcome one.
A good explanation is that a Subject in JAAS is a container, and a Principal is a set of roles, identities, and whatever else associated with that Subject. This is helpful for me, since I’ve always found those words unintuitive and confusing. The Principal class is nothing short of useless. The fact that Java continues to pump out specifications that are so dependent on vendor extensions to do anything useful is insulting and counter-productive to everyone but the vendors who depend on it as an obstruction to portability. [Just survived ANOTHER JRoller choke thanks to cut and paste.]

He also points out a nice permissions sniffer for making the trial-and-error process of figuring out which permissions your authenticated user (Subject) is requesting that it doesn’t have, and adding them to java.policy.

It’s been interesting, but perhaps hits java at a lower level of abstraction than I’m used to. I do mostly web apps, so my perspective is largely on the level of users and roles that are exposed in a webapp, and the permissions that are exposed in that relationship. The closest I get to worrying about JAAS implementation details is selecting which login module I want the app server to use. I don’t deal in permissions very often. This beef is probably more about my selection of this session than Stuart’s presentation of it.