Passion Driven Development

Although I had not patience to learn .NET C# using the textbook, I have created my first application in C# using Spring.NET. Isn't this cool? :-)

using System;
using System.Collections.Generic;
using System.Text;
using System.Xml;
using Spring.Core;
using Spring.Context;

namespace VerySimpleProject
{
    class Application
    {
        
        public static void Main(string[] args) 
        {
            VerySimpleMethod();
        }

        /**
         * This is a very simple method.
         **/ 
        private static void VerySimpleMethod()
        {
            IApplicationContext ApplicationContext = new  XmlApplicationContext("application-context.xml");
            SimpleObject SimpleObject = (SimpleObject) ApplicationContext.GetObject("myObject");
            SimpleObject.DoSomethingSimple();
            System.Console.ReadLine();
        }
    }
}

There have been a while since I have stopped writing code for this project, a web framework named 'wedge', built on Spring.

I realized that although the ideas behind it was good, the implementation suffered a lot. It was pretty close to a first finalized version with not much features but working. I my opinion it was fast enough too. Don't know about scalability.

Being my first framework developed to such a far stage, I got overwhelmed by the complexity. Now I know that building a framework for general use is hard and it takes a lot effort and a good approach and, more than all, time.

My approach now is to start building a real world application from which to extract the framework. The framework will evolve in parallel with the application and features added to it will be added as needed and in the form that is needed. Thus, I hope to have several versions of the new framework working as fast as possible. As it will grow, I hope that I will also get some feedback from the community. I really missed that in the first version. Maybe I haven't commercialized it enough and maybe is better like that. I am sure that I wouldn't have been able to bare all the pressure from the possible users.

As my designer skills will grow, I am sure that I'll be able to produce something that is better and useful.

Now, here is some of my ideas for the new version of the framework:

• Use dom4j as parser for templates. It is fast and already used by Hibernate and, as Hibernate/EJB3 will be a close friend of wedge, there will not be a undesired dependency. An alternative would be to use the parser provided by the JDK.
• Integrate with Dojo for client functionality and Ajax features.
• Use Groovy for runtime compilation of generated classes (if there will be still a need for this). Groovy may also be useful for enabling dynamic reloading of classes and templates.
• Use of Spring 2.0 custom scopes for pages and components.
• Enable Wedge to work in an OSGi environment and integrate with Spring-OSGi support.
• Wedge should be aware of the fact that Hibernate is in town and provide support for it.
• Integration with Spring Acegi. Wedge artifacts will be associated with access levels and Wedge itself will take care of the problem.
• Provide support for searching. An real time indexing of the pages with lucene.
  
• Atom and RSS support.
• Other things that will grow from my application that I am planning to build. :-)
  

I used to be a physicist and I used to love being that! It was interesting, dealing with high level perspectives on the physical universe, abstract and elegant theories about quantum systems. All these are past.

Now I am a software developer that found that there is a domain for which is worth paying at least as much passion energy as he payed for physics. His passion is continuously sustained by those persons in the software community that share his ideas and vision or event the joy of creating beautiful and good software.

That's fine about being an architect!

I also believe that there is a wall between the passioned and the others. Some may call it ignorance, others may call it something else. But what exactly is making this wall to be a wall?

Imagine that you could have the power to simply stand in front of this wall and not only see beyond it but also hold your hand trough it just like it wasn't there!

It this would happen in the real life one would not consider that the wall is special but the person that does this has the capacity to pass through it.

You can not make a wall to understand to step aside. You got to become that soft(like soft in software) to be able to see beyond and step through it.

That's hard about being an architect!

When starting developing something new it's very important to think and to work in such a way that you get fast results and feedback from what are doing. Write the most simple piece of code that works and get you some results.

Imagine that you need to write the grammar for some proprietary language and for this you start to learn the great tool ANTLR. So, how to proceed? You should spend some time learning how to write a grammar and then write fully the grammar for your language such that you will have something to test real code? I suppose not!

Coding to much before you get something working is bad and it happened to me many times.
And since I am a lazy programmer, as every programmer should be, reading all kind of things about extreme programming and agile methodologies I have started to apply some of them in my daily work. And I must say that it improved my efficiency and my code quality.

Thus, a very good way to start something new is to create that minimum base for starting coding. In the case of writing a grammar this would mean to write those few lines of XML in a ANT project that help you generate the parser from your grammar. These may look something like this:

<path id="antlr.classpath">
<fileset dir="lib">
<include name="antlr*.jar">
</include>
</fileset>

<target name="gen.parser">
<property name="output.dir" value="/src/com/mycomp/myapp/parser">
<echo message="Generating parser and lexer to ${output.dir}">
<antlr target="grammar.g" outputdirectory="${output.dir}">
<classpath refid="antlr.classpath">
</classpath>
</antlr>

This will help you to generate rapidly the parser as you make changes to your grammar.
Then you just copy and paste a template from ANTLR grammar, one which you can find here.
Then insert a simple rule like this:

simpleRule: "Hello world!";

and you are ready to generate and use your parser. In a test first methodology, you should have write a test for the parser before generating it. But, as it's totally new stuff you're dealing here let just write the test now. A test method for your parser would look like this:

MyLexer lexer = new MyLexer(new StringReader("Hello world!"));
MyParser parser = new MyParser(lexer);
try {
parser.simpleRule();
} catch (Exception ex) {
fail(ex.getMessage());
}

Further, the development will go on just like this: change or write a new test then modify the grammar, regenerate the parser and finally run the test to see if your parser does the job you need to.

It's a good thing to have tests for each grammar rule and for as many as possible situations. This way you'll be sure that the grammar is still working in all of the aspects after you change it.

Last evening I have played a little bit with Groovy and with it's excellent support for builders.
There are some articles on this subject referenced from the Groovy site. You may want check them out as they are a very good introduction into this subject. The Ant project builder is the builder that actually made me enthusiastic about Groovy builders.

I am particularly interested on this subject because I intend to rewrite some of the Wedge framework on the Groovy language. As Spring 2.0 offers great support for dynamic languages, the integration between Wedge and Groovy will be quite natural. However, this integration will be transparent for the users code.

Currently, Wedge uses Java code to generate Java code that will be dynamically compiled using embedded Eclipse JDT compiler. This allows that framework to reload page templates and classes as they change on disk. However, all this process is tedious and Java verbosity made the code cluttered and hard to maintain and improve. That is way I thought that writing this part in a more flexible language will be a major improvement.


So I have created a simple CodeBuilder that extends the builder support provided by Groovy and with this builder one could write something like:


def writer = new StringWriter();
def cb = new CodeBuilder(writer);

cb.def(name:"variable", 0);
cb.while("variable < 10"){
cb.println("variable");
cb.inc("variable");
}


and this will end up in a code like this:


def variable = 0
while(variable < 10) {
println(variable);
variable++;
}


This is a very elegant and more powerful way of generating code than the initial Java approach by using anonymous classes (too ugly to be reproduced here! :-)).

I imagine that a builder for Spring configuration could be done by using the markup builder in Groovy just like an Ant project builder. This could look like this:


def spring = new SpringBuilder(writer);

spring.beans(){
import(resource:"context.xml");
bean(name:"myBean", class:BeanClass.class) {
property(name:"someProp", ref:"otherBean");
}
}


I think that this may be a less verbose way to build Spring configurations than the XML or programmatic way and much more "in a single place" than the incoming annotation based style which will be available in Spring 2.1.

I have decided to watch closely the development of the new version of Tapestry.
It seams that Howard decided to completely rewrite Tapestry. He also decided not to build it on the Hivemind IoC container but rather build a new one, Tapestry IoC, in order to achieve

"greater simplicity, greater power, and an avoidance of XML".

Spring framework with its close to final 2.0 release already achieved greater flexibility, configuration simplicity and a lot of new features. As with the 2.1 release, Spring will provide easier XML free configuration through Java 5 annotations. Still, Howard has some objections on Spring, and considers it as being not suitable for it Tapestry 5 release. Here are his arguments:

• Spring does not have the concept of a namespace. The names of beans are simple and unqualified, which could lead to naming conflicts.
• Spring beans can be wired together by name (or id), but it is not possible to introduce additional naming abstractions. Tapestry 4's "infrastructure:" abstraction was the key to allowing easy spot overrides of internal Tapestry services without having to duplicate the large web of interrelated services (nearly 200 in Tapestry 4.0).
• Spring doesn't have a concept of visibility, whereby some service implementations are internal to a module (Spring doesn't have modules), which makes it easier to create service facades.
• Although Spring allows beans to be intercepted, it does so in the form of a new bean, leaving the un-intercepted bean visible (and subject to misuse). HiveMind and Tapestry IoC "wrap" the service inside interceptors, preventing unintercepted access to the core service implementation.
• Spring's XML configuration files are quite verbose, often more so than equivalent HiveMind XML files. This has improved with Spring 2.0.
• Spring has a simple map/list/value configuration scheme, but it is not distributed; it is part of a single bean definition. HiveMind and Tapestry 5 IoC allow service configuration to be assembled from multiple modules. This is very important for seamless extensibility of the framework.

I think it will be a good discussion subject on Spring developer list to see if this are real issues of the Spring framework or are simple misunderstandings.

However, I believe that Wedge should definitely be written by following the same IoC perspective although there will be a small number of services declared by wedge. Besides that, I am in a sort of rewriting wedge stage too because I found it hard to maintain a framework that uses java code generation from java it self. I believe that Groovy will help me a lot on this subject! Will see it very soon!

There's beginning for every thing. :-)