On Avalon and a desire for competition

A note of caution to the reader: this posting may appear to be chock full of code names like in a corny spy thriller.

The next version of Windows, code-named "Longhorn" has three main sub-systems: presentation (code-named "Avalon"), data (code-named "WinFS"), and communication (code-named "Indigo"). Avalon consists of a new collection of classes added to the .NET framework in addition to a spanking new markup language [again code-named] "XAML" or Extensible Application Markup Language. The way I see it, XAML is meant to accelerate the demise of HTML by a few dozen years. It is similar in concept to the Extensible User Interface Language (XUL) from the Netscape/Mozilla camp. [I will not get into who copied whom. That argument is a never-ending waste of time and bandwidth and is best relegated to whine fests at Slashdot].

A typical application written to Avalon will end up using both program code as well as markup code. Everything you can do in markup you can also do in program code. But not vice versa. So let's look at a snippet of XAML markup:


<Button Background="Silver" FontSize="10pt">
Demo
</Button>


This represents a Button element with a couple attributes. XAML tags are tied to the Avalon class library in that each tag such as 'Button' is actually a class and the attributes specified are actually properties of that class. For that matter any class with a public no-arg constructor and public accessor/mutator (getter/setter) methods [ or 'Bean' as we Java developers refer to them] qualifies as a tag in XAML. So the above code snippet can be redefined in C# as:


Button button = new Button();
button.Background = Brushes.Silver;
button.FontSize = new FontSize(10, FontSizeType.Point);
button.Content = "Demo";


Simple eh? Microsoft in a master stroke has reduced Windows UI programming to this kind of idiocy. But wait, Visual Studio .NET will auto-generate markup with a few mouse-clicks and keystrokes. That's just perfect for all us poor sods who were frequently dropped on their heads by their parents. Java Swing developers will catch on fast to the panels, layouts and event handling model in Avalon.

No, I am not jumping onto the .NET bandwagon, now that I have drooled all over this page. So what is the point I am trying to make here? It is this: where's the competition? The mantra of simplicity is a great way to evangelize a development platform. Innovations like Avalon -- that provide simple solutions to tackle hitherto complex (not to mention cumbersome) problems -- democratize the developer community. My friend Miral Shah always said "Visual Basic is for housewives". Well, I don't know about that, but I certainly believe XAML is. [I am not being pejorative here]

Unless the Java and GNOME communities get in gear and do something about desktop solutions using Java, XUL, GTK+, Qt or Mono [take your pick], there will be no fitting answer to the elements of Longhorn. Mono is an open-source .NET clone being developed by Novell (Ximian). They are now trying to implement the Windows.Forms namespace into the Linux platform. I think it is a worthwhile idea but a sad waste of time. Microsoft controls the .NET platform and whatever these guys at Mono do, they will always be playing catch-up with Microsoft. Plus Microsoft has the ability to wire .NET to Windows and by extension 90% of computer users out there. The .NET technology is optimized for Windows and vice versa. Try beating that 900 pound gorilla with your fly swatter! Instead of making Linux more like Windows, they should be focussing on capitalizing on Linux's unique plus-points i.e. the initiative and innovation it has fostered in the fledgling open-source community. This cries for something more fitting than a lame platform port of your competitor's software. There are existing projects out there, that in a correct combination, can provide credible alternatives. Some events need to happen in order to build a semblance of competition:

• GNOME must support Java via the GCJ open source virtual machine and even Sun or IBM's VMs. The GNU Classpath project must reach currency with the Java language specs [it is only a matter of time now].



• SWT (IBM's open source Standard Windowing Toolkit) is a platform-specific runtime that exposes widgets like text boxes, panels, and other familiar GUI controls to Java developers, but uses JNI to make native code calls to create and interact with those controls. SWT applications work across platforms (currently support exists for Windows, Windows CE, Linux, AIX, Solaris among others). IBM or the open source community can combine XUL and SWT to create an alternative to Avalon.



• Alternatively, extensions to the Swing API can be added to provide support for markup-based UI development. For all that people say about Sun, I trust it if anyone to pull something like this off, if they only stopped treating Swing like an abandoned child. Nothing significant has gone into that API in the past 3-4 years while Sun has been touting XML here there and elsewhere.

It is time we had effective XML-based form and UI definition languages backed by powerful managed runtime environments. Welcome, Avalon! And hooray for choice!

Email this | Bookmark this

The need for people-centric software processes

Having a software development process or methodology -- although not completely adhering to it -- is better than not having one at all. Traditional software development methodologies spend a lot of time and energy in resisting change. The guys who thought up agile methods like eXtreme Programming, Crystal, Scrum etc. figured that out. These process thrive on change and are hence adaptive, in contrast to the traditional predictive model. There is one other big big [Yes, I did say that twice for emphasis] difference though. Agile methods are people-oriented rather than process-oriented. They look at the process as existing to support the development team rather than the other way around.

But enforcing this "people come first" philosophy is much harder than it seems. It goes against the grain of conventional management theory. But not everything that is appropriate to the manufacturing industry is completely applicable to the software world. In order that a process gain acceptance from the development team, it must aim to empower its target community. Anything different will be resisted. It is important therefore that software processes be flexible enough that developers see real value before they jump headlong into accepting it. Even as XP is an adaptive process, it requires a lot of discipline to execute; most developers -- including me -- would resist some of its tenets and would rather prefer something like Crystal which aims at being less disciplined.

Martin Fowler provides this topic a great treatment here. He suggests

...the developers must be able to make all technical decisions. XP gets to the heart of this where in its planning process it states that only developers may make estimates on how much time it will take to do some work.

Such technical leadership is a big shift for many people in management positions. Such an approach requires a sharing of responsibility where developers and management have an equal place in the leadership of the project. Notice that I say equal. Management still plays a role, but recognizes the expertise of developers.

An important reason for this is the rate of change of technology in our industry. After a few years technical knowledge becomes obsolete. This half life of technical skills is without parallel in any other industry. Even technical people have to recognize that entering management means their technical skills will wither rapidly. Ex-developers need to recognize that their technical skills will rapidly disappear and they need to trust and rely on current developers.

And then there's Alistair Cockburn's analysis which categorically rejects the view that people are easily replaceable "parts" in a software process. That article can be found here.

In the end, agile processes attempt to fill in the gaps left over by the Rational Unified Process. And do a good job with it. Their version of technical leadership is a marked shift for most managers [Jad Bitar that does not include you!] who'd rather stick to the familiar confines of traditional models. If you have ever-changing requirements [who doesn't?] and a motivated development team who like to get involved in the decision-making process, then I highly recommend taking the adaptive process route.

Email this | Bookmark this

More J2SE 1.5 buzz

Javaworld has a 3-part article on the new features in Java 1.5 (aka Tiger). The blurb describes it as the "most significant revision" to the language since its original inception. [That's absolute rubbish, if you ask me.] IMHO, J2SE 1.2 was far bigger. It showed the language mature and stabilize and hold its own. The features in 1.5 are at best can-haves not must-haves. Some of the features like support for enums should have been there in the first place. To be fair, I like the Autoboxing and Unboxing and Generics features, and plan to use these two with studious zeal.

With these new features, the language adds some veneer to the woodwork. The Java language (with the JSDK) couldn't have asked for a better evolution cycle. Like in a typical neighborhood swimming pool, there are different sides to the language. There's the shallow end for newbie developers (1.0 was largely just that), then the medium and deep ends for more adept programmers. There's also the diving section to whet the appetites of the code-gurus out there. The evolution of the language has been marked at various points by excitement and innovations in a whole plethora of areas: open source projects, patterns, anti-patterns, development methodologies and testing processes. Swing however stands out as a stinky sock. I don't know anybody -- user or developer -- who's a great fan of the Java UI. Sun needs to throw it away and go with SWT. And it needs to do more with the VM. I've talked about it here. More on that later.

You can read the Javaworld article here.

Email this | Bookmark this

In search of a project documentation framework

I am evaluating a few project documentation frameworks to find the one right solution that will make the rest of this Release period more productive. There are a lot of user guides, tutorials and other documentation to be written and a powerful, user-friendly framework is essential before we move forward.

My research -- rather brief -- has led me to some good candidates: Forrest, Toot-o-matic and Maven. Each of these has it's own niche. So a straight comparison has no merit. Maven is richer and more appropriate from the project management perspective while Toot-o-matic churns out tutorials [a la developerWorks] rather well. Of these Forrest has impressed me the most. [Ladies and Gentlemen, it really is all that and a bag of chips!] Not because of what it can do, but because of what it takes to make it do what it can do.

Technical Writers are very rarely that -- technical. Forrest's simple site configuration and page content DTD make it quite handy indeed. It comes with a basic validation mechanism that can help trap newbie errors quickly. The rendering mechanism uses Cocoon and generates both HTML and PDF documentation. There is a lightweight server that will run your site, once rendered, so you can quickly check how it all falls into place. It took me all of a 1/2 hour to learn and implement a basic prototype [I translated an 8-page product release notes into its new avataar].

I will look at Maven and Toot-o-matic more closely in future posts.

Email this | Bookmark this

Because the truth affects us all

"I read it on the Internet, so it must be true ... right?". Heh-heh-heh. Wired News had an interesting story a week or so ago. Now here's why there will never be a shortage of idiots to go around. Yet another case of someone who read The Onion and took it for real news. Now if only there were laugh tracks on web pages like in the sit-coms, we wouldn't be having such a great time poking fun at poor sods, eh?

Okay, I know this has nothing to do with software, but I found this pretty amusing. It's been a slow Friday, so I guess I get a hall pass.

Email this | Bookmark this

Smashing baby!

"Imagine the day computers fix their own problems before you even know it." No, this isn't a line from one of Ray Kurzweil's masterpieces. I have been doing some reading lately on the state of Autonomic Computing and I like what I see. I suspect big corporate behemoths [we won't name names here to protect the guilty] are looking at this arena for the next technological bloodbath. I first heard of the SMASH (simple, many and self-healing) concept when Deep Blue kicked Kasparov's ass. Not a lot of information on the progress made since has been released widely into the public domain. But I for one will be following this trend.

I came across this item on the feature list for J2SE 1.5 (Tiger):

Java Heap Self Tuning

The option to request that the JVM self tune the size of the Java heap has been improved to consider both application performance and application footprint. You can specify performance goals for applications and the JVM will tune the size of the Java heap to meet those performance goals with the smallest application footprint consistent with those goals.

No more details. Nothing else! Now let's not kid ourselves by comparing this with Autonomic Computing, but surely if Solaris has had self-tuning capabilities for years now, is it such a big deal to get the Java Virtual Machine (JVM) to do it too? How many people seriously feel that the default heap size of 64MB is adequate for most computing? Well, Joe Public Developer doesn't go set the heap size unless forced to [ most times not even]. Why not follow the BEA Weblogic JRockit lead in implementing the ability for the virtual machine to expand or contract the Java heap during runtime. This would mean that users would no longer be required to fully understand the memory needs of their application system. Instead, they can trust the JVM's memory system to adjust the heap size based on application needs. Here's an excellent article by Eva Andreasson.

In addition to providing memory usage performance equal to manually tuned systems, a self-tuning mechanism can also dynamically detect changes in the application environment, and then take corrective measure. Didn't Einstein say "Everything should be as simple as possible and no more"? Well, this is simple. And it's about time!

Email this | Bookmark this

How not to cache a page

The reason I am smiling right now is I got around this one. Otherwise there was a whole lot of hair left to tear out. My problem was simple: why does this doggone page remain accessible even after I log out? I was quite sure that the security-constraint for my web resources was properly configured (it showed me the login page when I first tried to access secure resources, afterall). A few trace statements later it dawned on me. It was all Intenet Explorer's doing! The gods at Microsoft weren't smiling at me today and that was why this infernal contraption was acting out.

So the problem boiled down to this: my LogoutAction [yes I am using Struts, that pile of stinking dogturd] was handling the session invalidation and cookie resets properly. I had followed the rules as I knew them, which meant including meta tags to my HTML head:

<META HTTP-EQUIV="Expires" CONTENT="-1">
<META HTTP-EQUIV="Cache-Control" CONTENT="no-cache">
<META HTTP-EQUIV="Pragma" CONTENT="no-cache">

And for added safety, setting the same attributes on the response object. And yet I could access a page that shouldn't be accessible to unauthenticated users. This meant that IE was plainly ignoring my meta directives. Or this may be a bug. One Google search later, I had the solution. It was goofy yet brilliant.

It seems "The Pragma statement up above sometimes fails in IE because of the way IE caches files. There is a 64K buffer that must be filled before a page is cached in IE. The problem is that the vast majority of the pages using the Pragma statement put it between the HEAD tags.
The HEAD loads and the Pragma comes into play. The browser gets the go ahead to not cache the page, however there is not yet a page to not cache. How's that for backwards logic? Since the page hasn't filled the 64K buffer, there's no page so the Pragma is ignored. Thus...the page is cached.

The solution is to play to the buffer. If you're really serious about the Pragma working, place another set of HEAD tags at the bottom of the document, before the end HTML tag and re-enter the Pragma."

So my layout page now ends like this:

</body>
<head>
<META HTTP-EQUIV="Expires" CONTENT="-1">
<META HTTP-EQUIV="Cache-Control" CONTENT="no-cache">
<META HTTP-EQUIV="Pragma" CONTENT="no-cache">
</head>
</html>

So, who gets flogged for this?

Email this | Bookmark this

Checked Exceptions

I don't know about you, but I often have a terrible time dealing with APIs that enforce checked exceptions. They are a good feature to have but their rampant misuse just defeats the whole beautiful idea. My understanding of exceptions is that they allow programmers to write less error checking code because this code could be delayed until a more appropriate point in the program. When done badly it is like trading today's problems for tomorrow's. For people that think all compile-time checks are better than any runtime checks [yes I happen to know such people], static type checking in their exception handling seems like manna from heaven.

Merely by virtue of its ability to channel errors up the call stack, one can justify the need for an exception handling mechanism. But programmers litter their code with try-catch clauses just because they have to and also to cover their asses -- not because they want to. Then there's those people who suffix every method signature with

throws Exception

These guys need to be rounded up and publicly flogged. This is just unforgivable!

Most code I have reviewed doesn't have any impressive exception handling. Rather the focus is on protecting against that exception (like de-allocating memory, closing open connections etc. as the case may be). If your chief way out in case of an exception condition is to log a message or popup a dialog for the user, then it makes sense to have a centralized exception handler that acts as a bucket for all such critters.

Bill Venners and Bruce Eckel [two smart dudes] interviewed Anders Hejlsberg, the C# big honcho, about checked exceptions and the versionability and scalability issues that come with it. It is an interesting read. But here's a hilarious -- and smart -- critique of that interview by James Ross that made me fall out of my chair laughing. It was only my earphone cord, plugged to the laptop, that prevented my head hitting the floor.

This issue's being talked about a good deal of late. There's some great ideas thrown around. More soon.

Email this | Bookmark this

Spring is here

There are as many web frameworks out there as web applications -- well almost. Most reinvent the wheel everyday. So when I read Rod Johnson said "Spring does not reinvent the wheel", I sat up and read further. In his excellent introduction to the new Spring Framework, the author of "Expert One-on-One J2EE Design and Development", lucidly lays down the features of a framework that makes the management of business objects its central focus. It comes out as a framework of mini-frameworks, each relying on Inversion of Control.

I like the myriad goodies it provides for the business layer:

• a robust implementation of business objects and a way to wire them together;


• wrappers for data access that take the pain out of JDBC [as the bard said, "Parting is such sweet sorrow!"] or plug O/R solutions like Hibernate and JDO right in;
• a generic transaction management that isn't tied to any specific environment [I close my eyes and imagine thousands of developers who write JTA code giving thumbs ups on this one]

Besides Spring aims to provide J2EE services to Plain Old Java Objects (POJOs) using the much-touted AOP approach. [We will look at Aspect Oriented Programming in a future weblog]. Before you jump and say "But JBoss already does that", let me remind you that Spring provides this feature across application servers, thus avoiding vendor lock-in. There is also a powerful MVC web framework, quite like Struts with none of the Struts flaws. There is a clean division between the Model, the View and the Controller and the use of IoC prevades into this area as well tying it with other parts of the framework. Yes, I have really taken a liking to Spring. There's a lot of activity on its website [http://www.springframework.org]. Definitely worth a good look.

Email this | Bookmark this

Why are we here?

I say this aloud very often: "Even a trained monkey can write code" and have drafted many an email with this theme in the sub-text. It is usually directed to the higher-ups, trying to convince them that the development team needs more than just regular code-cutters. I know a lot of people share my sentiment and can't for the life of them figure out why others just don't get it. I have other rants too. Some of them unprintable. So it was only when I realized how stupidly simple it is to create a blog such as this -- no doubt made for chimps like me -- that I figured I had at last got a vehicle to air my rantings. If I thought anybody would bother reading this, then I'd be diagnosed with a clinical form of delusion. For some time now, I have wanted to jot down ideas about software architecture, design, coding and testing; ideas that I stumble upon or bookmark or conceive or promote. This web log will help organize those random ideas somewhat.

There will always be questions that raise issues [thank you Kafka!]; questions that will raise further questions when first answers are given to them; questions that could seldom be answered simply by Yes or No; hypothetical questions that present suppositions -- the implications or consequences of which are to be examined; questions that are complex and have many related parts, to be taken up in an orderly manner.

Yes, inconvenient questions must be asked. Uncomfortable situations must be created. Ideas need to be thrown around. Beautiful code needs to be written. That's why we are here.

- Ashish 'nerddawg' Shetty -

Email this | Bookmark this