N. Alex Rupp's Blog

Tools Archives

TechEd 2004, Day 04

One of the major themes at TechEd this year was how to increase productivity. The marketing slogan was "Do More With Less". Early on, I mentioned how Microsoft's Visual Studio tools give them an edge on the Java community. This isn't because Java can't have tools that are just as good as Visual Studio, but it's because the collected principles that lead to the development of those tools aren't a conscious and explicit focus of our community (at least not from what I have seen).

The principles aren't rocket science either, and once you see them you'll know that most if not all of us are aware of them all at some level, but this is not the same as the explicit, direct focus I see coming from the Microsoft development community. I liken it to our focus on eXtreme Programming or Agile Development principles, of which the Microsoft development community is just becoming aware.

These principles, perhaps better thought of as best practices, revolve around constantly and intentionally raising the level of abstraction in building software solutions, using more patterns and more frameworks for increasingly specific problem domains, grouping software into product lines and using component assemblies and code generation. It isn't any one of these principles that we need to pay more attention to—we must practice them all at once, the way we practice agile development or extreme programming.

The singular end goal of these principles is to identify and develop Domain Specific Languages, high level abstract languages that help us illustrate and discover patterns in our software, in our business processes and in our development practices. Domain Specific Languages can help us write frameworks for dramatically improving our productivity when developing solutions for specific, narrowly scoped aspects of software development.

Domain Specific Languages contrast with UML in that they are highly tuned to a specific aspect of business or development, and they can more easily be used to configure underlying frameworks or generate code for specific families of software components. What I'm talking about here are tools and frameworks for writing software solutions—not just for writing software code. They needn't necessarily be graphic-based languages. For instance, Groovlets are a perfect example of a domain-specific language for abstracting and speeding up the development of Java Servlets.

But Domain Specific Languages should help reveal patterns in the creation of software components, and those patterns should be able to be summed up into even higher level Domain Specific Languages—perhaps a graphic or symbol based language, or perhaps not. The important part is that we continue to explicitly push for more abstraction in our tools, in how we represent the code, business concepts and development processes.

In the session I attended on Domain Specific Languages, quite a bit of time was spent contrasting them with the UML. DSLs can be customized for any problem domain, they can be developed by cooperative organizations or built by single companies and made popular through use before becoming officially standardized. DSLs, because they are more finely tuned to specific problem domains can more easily be used to generate software code, whereas trying to accomplish MDA with raw UML repeats the mistakes of CASE tools. This is not to say that the UML is worthless, though. It is great for quickly expressing basic development concepts and for documenting different areas of development.

No tools are perfect for everything, and DSLs not only acknowledge but actually embrace that fact. DSLs provide ways to express, model and develop very specific problem domains, because at the end of the day, improving business productivity is what computers are for. Can you imagine if a company tried to build a single tool that could be used for working on every aspect of an automobile engine? Or for building a house? There are millions of highly specialized tools for performing every type of job which can be done, and they are all very carefully tuned for their own specific problem domain. Software development tools are no different.

I thought the presentation on this topic was great, and I'll hopefully be able to more explicitly apply these principles as I work on development tools in the future.

TechEd 2004, Day 02

I don't know exactly what I was expecting from Steve Ballmer's keynote address this morning. I've never seen the man speak before, or heard his voice. In fact, I haven't even seen a photograph of him that wasn't a decade old. What I did not expect was for Mr. Ballmer to have somehow transformed into a spitting image of my former Governor, Jesse Ventura. They look alike. They speak alike. It threw me for a loop.

Mr. Ballmer has a very strong presence on stage, but it wasn't his presence that really drew my attention during his keynote. It was the contents of his message and, more importantly, the way in which he delivered it that most impressed me.

What I'm about to do might be a bit unfair, and I apologize in advance if I upset anyone, but the only other major keynote speaker from the IT industry that I've ever seen was Scott McNealy, who gave the final address at JavaOne last summer. The more time I spend here and the more I explore the differences between the Java and .NET communities, the more I wish I were going to San Francisco in June, so that I could make back-to-back comparisons while it's all still fresh in my mind. Last year Sun and Microsoft were still embroiled in a major lawsuit, and so of course Mr. Ballmer's speech this morning was more positive and constructive than Mr. McNealy's was last June.

But even so, Ballmer did not lash out against other technologies, or against Sun. He certainly didn't make the mocking of his company rival a central part of his keynote, as McNealy did last June. He kept an extremely positive focus, and stuck to community and technology-based topics throughout the entirety of his address. It was very relieving.

I'll get into the technical and business related contents of his speech in a moment, but first I want to make some important cultural and rhetorical critiques. Mr. Ballmer is a visionary, and he probably doesn't walk in the quite the same world as you or I do.

This became more obvious to me throughout the day. After spending some time in the trenches discussing ideas and technological considerations with different developers and vendors, I've come to the conclusion that there is still a great deal of bitterness toward Java developers among the .NET rank and file. What surprised me most was how the topic of Java, even among and between perfect strangers, always returned not to the technological flaws of our platform, but to the "jerk" attitudes of our developers.

I'll be the first to admit, my flaws are boundless. I've written and said some things in the past, particularly about Marc Fleury and about the Redmond giant, that were deliberately inflammatory and sensational to no constructive end. I know it's a bad habit to get into as a writer, and especially as a critic whose job is to interpret and not to cast judgement. This editorial style certainly doesn't make me a better person, so I've been trying to grow out of that practice. It certainly helps to have people I admire, like Richard Monson-Haefel, acting in an extremely courteous manner toward someone he's slighted. For that, Richard, I'm very grateful.

It's easy to demonize your opponent when they only exist on your computer screen, but it's another matter altogether when they're standing right in front of you. And the whole "tribe mentality" plays into it as well, as it does in software projects, as it did last June when Scott McNealy made his keynote and burned Microsoft. It isn't difficult to see how the rank and file Java developers might amplify this half-playful distain into raw contempt for the .NET crowd. But the "US versus THEM" Napoleon-complex mentality is a luxury we can no longer afford as a developer community. As an American citizen, I can definitely say that political events of the last year have given me pause to reconsider how I conduct myself in public, and especially how I regard and treat my competitors in the public arena. I don't hate these people—I have a tremendous amount of respect for them, even if I disagree with them on technical details.

Which brings me to the next part of my blog for the day. For the last year I've been flirting with the dream of bringing affordable J2EE technology to small and medium sized businesses, and of someday making it possible for small companies to buy affordable, enterprise quality software. That, more than anything, is the reason that I use, study and develop Open Source software. Sometimes I get frustrated by the high cost of deploying enterprise-strength web applications. I'm probably just trying to crack an egg with an axe, but it's the principle of the damn thing that I just can't shake. I'm a small player but I like to think big, and I admire other people with the same penchant. I'd like to be able to deliver big, even to small clients who share my unfortunate addiction to thinking big. What really bugs me is when people I know make tongue-in-cheek comments about how companies who can't afford to pay hundreds of thousands of dollars for J2EE's stability and features don't deserve it. I refuse to accept that only Fortune 500 companies deserve rock-solid code. This totally ignores the market potential and the importance of small and medium sized businesses, and doesn't do much for the reputation of the Java guy.

Today, I saw more evidence of that truth than I was prepared for. Microsoft's development tools are easy to use, easy to learn, and affordable. That is why .NET is so appealing to small and medium sized companies. According to Ballmer, over 50% of IT developers in the country use .NET. These people don't write code--they have forms and wizards for developing just about anything you can think of. When they do write code, they have development tools that actually force them to write unit and performance tests. And from what I can tell, they have tools for writing those as well.

The tools they've got coming out this year will probe their software for security vulnerabilities, and color highlight the areas of their code which they have not adequately tested, forcing them to correct the error before they check the code into the repository. Tools, to amplify their productivity. Tools, to tell you while you're developing if you'll have fatal errors at runtime, thereby easing the testing and QA process. Tools for performance testing components in ASP.NET web applications, to push multiple simultaneous threads through your software, to bootstrap an ASP runtime environment and use it behind the scenes to simulate a live runtime environment. JUnit won't even add a Multithreaded Test Runner to their core API. Tools to design web UIs, built directly into their ASP.NET IDE. More tools than you can shake a stick at.

In the United States, only the pharmaceutical company Pfizer spends more money on R&D than Microsoft does. They've embraced Agile development techniques in Redmond and before long the rank and file will catch on as wel—they will have no other choice. The tools are there to make Test Driven Development ubiquitous throughout the .NET industry. In the realm of tools and ease of use, Microsoft and the ecosystem of small vendors surrounding them have got us outgunned and outclassed.

All of this was running through my mind before Mr. Ballmer even finished his keynote.

BUT—we in the Java community don't claim to be the most approachable or user-friendly development platform in the world. Usability has never been the greatest strength of the Java platform, and I know we're making strides to overcome our deficiency in that area. As I attended various sessions on .NET technologies, especially one about developing web applications with ASP.NET, it became fairly clear to me that we still have a tremendous and important role to play in the future of enterprise computing, of persistent transactional object frameworks, of distributed component frameworks, of ultra robust application servers. We've got a good handful of J2EE app servers on the market already, and more are one the way from JBoss, Jonas and Geronimo. The licensing costs will fall by necessity, freeing up more spending for support and better feature offerings.

Microsoft does not seem to have an answer to EJB, or at least the developers I've spoken with don't spend much time considering distributed component architectures. They're still coaching developers to hand-write their SQL code—the very thing that drove me from ASP technologies back in 2000. "Sometimes it's better for performance to customize the SQL", a gentleman explained to me this afternoon. Agreed, but where is the option to have a persistence engine do the heavy lifting for me? I can always subclass a BMP object to do custom transaction stuff. When the customer decides to change to a different database on a different operating system (yes, it actually does happen) and they've got to rewire their library of data access objects, it will certainly help that the SQL queries are encapsulated into objects and not scattered throughout the application, but it won't save them if they've got 6,000 unique data objects in their system. I'm not saying this to be cruel, or to spit on ASP.NET technologies. It's just my perception. ASP.NET might not be the best tool for that job. Or maybe it is. If so, is it worth the risk of lock-in? If it's not worth the risk of lock-in, does that mean that Microsoft and its employees are all terrible and evil? Of course not. It probably just means we need a two-tiered market, and that things are the way they are for a very good reason.

It always seems to return to two crucial factors: the tradeoff between flexibility and performance, and the tradeoff between vendor lock-in and the inefficiency of committee-governed standards bodies. Is that what this whole long fight has really been about?

Enterprise scale technology is not always necessary. But when it is necessary, when a distributed component architecture is necessary, when you need a Component Transaction Monitor and common server-side component model, does .NET measure up? And if so, is it worth the risk of getting locked in? This is what I still don't know. Critics of Microsoft's MTS technology always return to the issue of vendor lock-in, of the open-ness of EJB as a server-side component model, of the ability of different vendors to implement the technology and compete with each other for performance, features, pricing, etc. If the Sun and Java community weren't as dedicated to sharing the wealth of ideas, of supporting non-profit organizations who want to compete in their CTM market, projects like Geronimo couldn't even exist.

I think that, out of respect for my boundless ignorance, I'll defer any further exposition on this topic until after I've spoken with some more .NET evangelists, specifically the ones who would know about .NET's distributed component architecture capabilities. Also, out of respect for the customers and managers who ultimately must make this decision, I'll just keep looking for the common ground, the higher patterns and the difficult questions, and leave the decision to the people who ought to be making it. Finally, out of respect to the engineers and developers on both sides of the fence, I'm going to try really hard for the remainder of the week to represent the "Java guy" as a fellow developer and not as an outspoken, embittered ideologue.

I will write about this rockin' hotel room, when I get a chance. Hope everyone's having fun out there ;)

Open Source UI framework comparable to Lazlo

Now, before I go on, I want to address a very strong prejudice that I've noticed in my dealings with Open Source developers. It's the old familiar sentiment that if it isn't built in Java, it ain't worth using.

That might be true for a lot of people, and I have a lot of respect for that sentiment--it's an important one for our community. We're doing more than writing software in a certain language here. What we're doing is contributing to the development of a J2EE development platform. We're building tools for each other to use. If you've got the right tools, all the jobs in the world open up for you. For instance. There are precious minerals deep in the earth waiting to be harvested. These minerals are incredibly valuable and useful in industry. But if you're up on the surface walking around with only a stone axe and a loincloth you'll never be able to do that job. Another irony about tools is that sometimes you have to acquire and master the tools before you can even learn that a job exists. The creative reapplication of tools toward new industrial pursuits is what opens up entire new markets.

Another example. When I was seven years old, nobody in the world could make a living as a multimedia internet programmer. There were no Flash designers, because there was no Flash. When I was 21, that had all changed. I knew a lot of people who were making big dollars just to play around with Flash. One of the reasons for this, perhaps the biggest reason, is that by the time I was 21, the tools had improved.

That said, let's try to keep our input streams open to the possibility that Flash is still a very useful and cool piece of software (especially for those who know how to use it), and not relegate it to the status of "web designer's toy". I'll be the first to admit that the potentials of Flash have been largely squandered on sick cartoons and the infamous "Flashturbation" sites that every budding C-Corp and their brother launched in 1999 (you know--the ones with the contrived techno scores, who desperately wanted to be 2advanced?)

Well, for a while I made a living chasing that ghost, then gave it up for a while, returned to school, read some John Milton, some Thomas Paine and some Robert LeFevre, and now I'm back at it, looking for ways to develop new and better tools. This time, however, to retain my sanity, I'm doing it without a host company (for-profit or otherwise). And this time it has proven to be a lot more fun.

So here are some of my ideas. I want to build a manageable, rules-based J2EE development framework that enables the liquid UI capabilities of Flash on the presentation side. I want this thing to stream dyanically generated XML content to the client-side application and to completely automate the persistance layer. On the client side, I want to build an abstract UI engine in which users can plug in Swiff graphics libraries. Ideally, the UI engine would be able to digest swiff files and use them to skin the entire application.

If this software is built correctly, it should allow Flash developers to design skins which overlay UI components. They wouldn't have to deal with data maintenence at all--just building innovative graphics libraries. The app should easily plug into J2EE persistence. A lot of the contrived Flash apps of the 90s were IMNSHO a result of the nigh impossibility of reaching the persistence layer without having to fork over 35,000 USD for Generator.

The tools were the problem then, and the tools are the problem now. FlashMX costs a pretty nickel, and there seems to be a shortage of Open Source Java middleware developers in the world who know Flash like the back of their hand and have experience developing abstract application frameworks. To prove that point, I'm sounding out. If there are any more of you guys out there, for God's sake, drop me a line. We'll throw a party and write some new Flash tools, or maybe Macromedia will shoot us with the money gun and comp us FlashMX development suites in return for the fruits of our Open Source loins. In the meantime, 'll fork over the 75 bucks to launch a little non-profit company so we can get started right away.

Barring that, I'd settle for SVG, but I'm not convinced yet that it's worth its spurs.

This work is licensed under a Creative Commons License.