Blog

Dec 10 2005

Comments

Stop the Monkey Knife Fight!

Oh coding brethren, please stop the Monkey Knife Fight over Humane versus Minimalist Interfaces. I have a solution: let's write a minimalizer for Ruby, and a humanizer for Java. That way, we can all live in harmony, and program in the style of our choosing regardless of which language we use.

Ruby Minimalizer

Here's the Ruby minimalizer.

  def make_minimal(cls, *extraneous_methods)
    extraneous_methods.each {|m| cls.send :undef_method, m}
  end

You can pass parameters to selectively remove exactly the methods that bother you. Don't like those pesky first and last methods?

  make_minimal Array, :first, :last

Now they're gone.

Java Humanizer

On to the Java humanizer. Hmm, I'm having a little trouble finding the methods I need here. I'll just go read the Javadoc for the SDK real quick and see if I find what I need. Thank goodness the Java API is minimalist! I expect to be back in just a few minutes with the answer...

Dec 10 2005

Comments

How XML Killed Java (A Contrarian Perspective)

In the early 21st century, computer programmers often used statically typed languages, especially Java. While these languages were suitable for small-scale projects, they were not as well suited for enterprise class systems, where flexibility and adaptability were (and are) primary concerns.

Early attempts to help these languages communicate in distributed systems (CORBA, DCOM, etc.) were not wildly successful. Partially as a result, XML was developed as a connective tissue between systems. Where earlier approaches had failed, XML succeeded beyond expectations. XML became the standard communication language between systems. Surprisingly, XML also became a configuration language within individual systems. (It turned out that even very small applications needed more flexibility than Java alone provided. While programmers still said 'Java' what they really did was 'Java+XML').

But while XML was a great boon to Java in the short run, it was fatal in the long run. XML decoupled systems enough that enterprises could experiment with a variety of different approaches in different subsystems. Released from the monopoly effects of tightly coupled systems, niche programming languages had room to grow. And grow they did. Older languages such as Smalltalk and Lisp enjoyed a resurgence, along with their newer cousins Python and Ruby. The transition was slow at first, but its momentum was irresistible -- thanks to XML.

Dec 08 2005

Comments

The Spring Experience, Day 1

Wow, today was great. This morning, I got up late, at a bit of breakfast, then went in and gave the "ESBs with Spring and Mule" talk. I was really expecting this to be a niche talk, maybe 10-15 hardcore messaging people with a ton of JMS questions. But there were 50-60 folks in the audience, from all over the place, with tons of insightful questions (only a few of which threw me into panic "I don't even understand your question" mode). Hats off to the folks here at the show, that was a great talk to be the presenter for.

I followed it up with an intro to Spring MVC, which I also thought might be lightly attended. Again, I was wrong, and the folks that came were really into the topic and had lots of questions after the talk. I love that, because it means that a) people weren't sleeping, and b) the info was on target. People who aren't engaged don't ask questions.

I got the opportunity to sit on the "Expert Panel" after lunch with Rod Johnson, Rob Harrop, Juergen Hoeller, Colin Sampaleanu and Matt Raible. It was a pleasure to be in such august company, even if the microphone seemed glued to Rod's hand ;-). Somehow, the only time I felt like I had to jump in was when a question came up about what Spring and Rails can learn from each other.

In all, its been a great day so far, and the attendees seem to really be enjoying the show, which is, after all, what it's all about.

Dec 07 2005

Comments

Spring Experience, Day 0

I am in Bal Harbour, FL for the week at The Spring Experience. I'll be visible running some of the panel discussions, give me a holler if you want to talk about Spring Configuration DSLs.

Dec 07 2005

Comments

Build Your Own Spring Config DSL

Last week I posted a teaser for a Ruby-based DSL for Spring configuration. Like so many things, I doubt I will ever have time to carry this through so I am posting the code here. Please run with this if you are interested.

Here's the approach I used:

  • Create RubyBeanFactory as a subclass of XmlBeanFactory.
  • Execute the loaded resource, and treat the result as XML. I used Ruby but you could easily plug in some other language.
  • Create a helper (spring_config.rb) that defines a simple DSL instead of writing straight Ruby code.
  • .

If you plan to use this in production you will want to:

  • Refactor hard-coded stuff
  • Extend the DSL to handle more than just a subset of the Spring config vocabulary

Dec 02 2005

Comments

Building the Enterprise Hammer, Part 4

In Part 3, I argued that programming languages need to be flexible, and support powerful abstractions. But, there is a concern: Many developers and managers alike fear that more flexible, powerful languages are dangerous. They're right, but there is a solution: testing and transparency.

To continue with the Enterprise Hammer example: One approach to making the Enterprise Hammer safer is to limit its power and generality. If the hammers can only strike with a certain amount of force, then the hammer cannot accidentally break strong structures. Moreover, if the linkage between the hammers and the frame is deliberately complex, nobody will attach other implements that might damage something.

This safety comes at an extremely high price. The problem with reduced power becomes obvious as soon as you need more power. The problem with reduced generality is more subtle, and therefore even more damaging. When solutions cannot be generalized, work must instead be duplicated. Poor generalization is the leading cause of "code bloat". And the damage from code bloat is not linear. Poor generalization makes software geometrically more expensive to build and maintain (think "spaghetti code"). Even worse, tools that inhibit generalization inhibit genius--those cross-disciplinary leaps of imagination that move the industry forward.

The "safe language" argument appeals to fear, while the "flexible language" argument appeals to a sense of opportunity and adventure. Both are powerful motivations, so for a long time this argument has been a stalemate. Happily, that period is coming to an end. Two new factors have come into play: automated testing and transparency. Over the next five years they will turn the balance totally in the favor of more flexible languages.

Automated testing turns software on itself. By using code to evaluate that other code functions correctly, we can reach a much higher level of assurance than was ever achieved by the stopgap measure of weakening our tools. Instead of building small, soft hammers, and placing them in a low-powered frame, we build exactly the parts we need. We then test each of the parts individually (unit testing), test aggregates of parts working together (functional testing), and test the entire system (acceptance testing). If we decide to modify the frame, engine, or hammers, we can quickly re-execute our tests and verify that the entire system still works as before.

Transparency comes from open source. Other things being equal, developers who depend on open source will outperform developers who do not. To return to the Enterprise Hammer: Imagine now that frame and engine are covered with an opaque outer shell, to prevent hammer developers from seeing (or tinkering with) the internals of the Enterprise Hammer. This is the closed source world. If the frame and engine are performing perfectly, then the people building and using hammers may not care much. But when problems or questions arise, the shell needs to be removed. There are, of course, halfway measures such as documentation and technical support. But those are never as good as the code itself.

Are testing and transparency recent discoveries? No. What is new is their widespread adoption and acceptance by developers. Something else is new too: developers today understand the basics of OO. When James Gosling designed Java, it gave developers plenty of new stuff to think about. Most developers were new to OO, and had yet to learn inheritance, polymorphism, etc. Developers now understand OO, and understand automated testing. In other words, developers are ready to learn something new, and they have a great safety net (testing) to use along the way.

For evidence that testing and transparency foster good code, take a look at Spring. Spring has succeeded wildly with only a fraction of the investment (time and $) that has gone into closed-source J2EE stacks. But doesn't Spring's success argue in favor of Java, not more flexible languages? Stay tuned for the next installment.

Dec 02 2005

Comments

Simple DSL for Configuring Spring Beans

I have this working (in skeleton form). Anybody interested?

  bean :id=>:one, :class=>:NamedBean do
    set :name, "first"
  end

  bean :id=>:nv, :class=>:NameValueBean do 
    set :name, "nv"
    set :value, :one, :local
  end

  bean :id=>"sb-with-string", :class=>:ScoreBean do
    constructor 15
  end

Nov 25 2005

Comments

Building the Enterprise Hammer, Part 3

In this installment we are going to dig further into Idea #3 from Building the Enterprise Hammer:

The transition from EJBs to POJOs is only a halfway point. We now need to leave Plain Old Static languages (POSs) behind.

Developers have already rejected "special hammers" (past versions of EJB), in favor of plain old hammers. This is a great step towards more flexible applications. However, they still typically mount their hammers in some kind of frame (e.g. Spring). What happens when this frame is not perfectly adapted for the task at hand, or when the task at hand changes?

Let's say, for example, that we wanted to repurpose our Enterprise Hammer as an Enterprise Window Washer, by installing different attachments. We believe that this should work because:

  • Windows are regularly spaced on the side of the building.
  • Window spacing has a known relationship to the spacing of nails hammered by the Enterprise Hammer.

This is an example of refactoring to generality: finding similarities so that you can cheaply provide a new function (washing windows) through the same mechanism that provided the original function (driving nails).

Java makes this kind of generalization difficult. Java encourages up-front rigor about the type of an object. If you decide later than the "Hammer" type can be generalized to "Widget", you may have to touch hundreds or thousands of lines of code to enact that change. Duck-typed languages, such as Ruby and Python, encourage less assumptions. And, the assumptions are easier to change later. This is one place where the 10x hype is real.. Duck-typed languages can be an order of magnitude more productive, in both developer time and lines of code, when designing for (or refactoring to) generality.

There's another issue here, as well. Our Enterprise Window Washer may require changes to the frame itself, since windows are spaced differently than nails, and washing requires a different motion than hammering. But, we didn't build the frame. What are our options? Many languages provide a simple solution through open classes. With open classes, our own application code can make spot modifications to the frame to suit our specific needs. Conversely, Java discourages this flexibility in two ways:

  • deliberately, by closing classes
  • inadvertently, through its complex deployment model

As a result, Java developers may learn to not even see opportunities for reuse. Elegant solutions are not only not chosen, they are not even considered.

But More Flexible Languages are Dangerous!

Yes. There are many good reasons that Java became dominant, instead of e.g. Smalltalk. Understand those reasons, and you'll also know why it's time for a change. Stay tuned for the next installment.

Nov 23 2005

Comments

Building the Enterprise Hammer (Part 2)

In this segment we are going to dig further into Idea #1 from Building the Enterprise Hammer:

The three things that distinguish real enterprise development are flexibility, adaptability, and maintainability -- not scalability!

The Enterprise Hammer is not Flexible

In the first segment, we introduced the "Enterprise Hammer", which attached a number of hammers onto a frame so that entire sides of buildings could be nailed together quickly. In practice, this Enterprise hammer has a lot of problems:

  • Other building shapes will not work.
  • Other building materials will not work.
  • It is difficult to adjust the Enterprise Hammer to deal with local variations: terrain, zoning, architectural considerations, etc.

This starts to look like a straw man argument. Couldn't we just make a more flexible, adjustable frame for the Enterprise Hammer, and solve these problems? Yes, we could, but...

The Enterprise Hammer is Deliberately Inflexible!

In the Java world, we have been obsessively focused on scalability. I.e., how big can we make the Enterprise Hammer? Flexibility gets less attention. In fact, the J2EE stack and the Java language itself are deliberately designed to limit flexibility. To continue the analogy: engineers are allowed only to build and attach hammers. They are not allowed to adjust the frame of the Enterprise Hammer, or attach other devices to the frame. What the consequences of this approach?

  • If the frame is flexible enough to match your building, you will do well.
  • If the frame does not match, you may be worse off than if you had no frame at all.
  • If the frame is inflexible, you will see builders abandon the frame and build their own.

The success of Spring, Hibernate, etc. are pretty good evidence that more flexibility is needed.

Are You Saying that Flexibility and Scalability are Opposites?

Absolutely not! In fact, they go hand-in-hand.

Enterprises need flexible software systems that model their world in rich detail. While some processes are wholly standardized, there will always be important exceptions. Enterprises also need to deal with disparate internal systems, outside partners, mergers, and evolving laws and regulations. Size brings issues not only of magnitude, but also of variety.

One reason enterprises need flexibility is in order to scale! Consider a seemingly unrelated question: world hunger. Tragically, people go hungry every day, despite global food production capabilities that are sufficient. The problem is not production, but allocation. Similarly, software scalability problems tend to come not from insufficient processor power or disk space, but from difficulty in allocating that power to the right tasks at the right times. More flexible systems make it easier to reallocate resources and tasks, solving real scalability issues when and where they occur.

So How do I Get More Flexible?

Stay tuned for the third installment.

Nov 22 2005

Comments

Building the Enterprise Hammer

We do a bad job of building Enterprise software, primarily because we don't even know what "Enterprise" means. Today we will lay out six facets of Enterprise development. In subsequent posts we will evaluate each facet in more detail, working toward a shared notion of "Enterprise" that just might make projects more successful.

The Enterprise Hammer, Today

Hammering a few nails is a personal project. Hammering thousands of nails on the side of a building is an Enterprise challenge. Here's one solution, in six parts:

  1. Up-front design: Carefully map the position of the nails that need to be hammered.
  2. Enterprise Specification: Build a frame that matches the design
  3. Components: Attach special hammer adapters to the frame, at each point that a nail needs to be hammered.
  4. Engine: Attach the frame to an engine that can drive all the special hammers at once.
  5. Scalability: The engine handles a big task (hammering all the nails on one side of large building) very quickly.
  6. Build to Standards:You can improve quality of service by attaching a different engine. Or, you can build a different kind of building by using a different frame.

The Trouble with Components

The Enterprise Hammer I just described is J2EE:

  • Hammer = Java code
  • Special Hammer Adapters = EJB
  • Engine = J2EE Container
  • Frame = J2EE Specification

By now, the Java community has realized that this is a poor way to build software. They have focused their ire on item 3 (component models, especially EJB). I will reiterate the primary arguments against EJB very briefly here:

  • The special hammer adapters are more expensive to build and maintain than plain old hammers, and offer no compensating benefit.
  • The special hammer adapters are difficult to test, undermining reliability. Entire (sometimes interesting) technologies have sprung up to deal with this. I guess that's a form of peace dividend.
  • Terrible performance is easily achieved.

Rather than put up with this nonsense, developers who want to get work done have built their owncontainers around Plain Old Java Objects (POJOs).

But All the Other Facets are Broken, Too!

Java developers have rejected EJB in favor of more pragmatic approaches such as Spring and Hibernate. But it is time to take the next step, and realize that the other five facets above are equally problematic, and need to be reconsidered. POJOs are not a sufficient solution to the component problem, either. So let's start over, and replace all six facets of the Enterprise Hammer with the following ideas for Enterprise development:

  • The three things that distinguish real enterprise development are flexibility, adaptability, and maintainability -- not scalability!
  • Standards should evolve from working code. The role of standards bodies is to filter the best and simplest.
  • The transition from EJBs to POJOs is only a halfway point. We now need to leave Plain Old Static languages (POSs) behind.
  • Engines should be testable and open source.
  • Specifications should be flexible, and encourage developers to focus on key concerns.
  • The goal of up-front design should be maximum flexibility, not complete solution of the problem.

Subsequent posts will take up each of these ideas in turn.

Popular Tags