Irrespective of whether you use DOS prompt or cygwin, Windows limits the length of environment variables. Though there are various options to overcome this problem using Java 6 wildcard classpath, mapping the path to some drive etc, they all look like workarounds to me as problem can recur again anytime.

After some amount of research, I found appassembler plugin resolves this issue with booter-windows and booter-unix daemons. From the outset it looked like daemon does something else as the name is a bit misleading but in reality it’s a generic way to start your Java applications. The booter-unix/booter-windows platforms were introduced for the sole purpose of resolving the long classpath issue (see MAPPASM-43) in appassembler maven plugin. Here’s how it looks like in the pom you are working with:

<plugin>
    <groupId>org.codehaus.mojo</groupId>
    <artifactId>appassembler-maven-plugin</artifactId>
    <configuration>
        <repositoryLayout>flat</repositoryLayout>
        <installArtifacts>false</installArtifacts>
        <target>${project.build.directory}/appassembler</target>
        <defaultJvmSettings>
            <initialMemorySize>512M</initialMemorySize>
            <maxMemorySize>1024M</maxMemorySize>
            <extraArguments>
                <extraArgument>-DconfigFile=../../etc/config.properties</extraArgument>
                <extraArgument>-Dlog4j.configuration=../../etc/log4j.properties</extraArgument>
            </extraArguments>
        </defaultJvmSettings>
        <configurationDirectory>etc</configurationDirectory>
        <daemons>
            <daemon>
                <id>applicationName</id>
                <mainClass>com.xebia.appassebler.sample.Main</mainClass>
                <platforms>
                    <platform>booter-unix</platform>
                    <platform>booter-windows</platform>
                </platforms>
                <environmentSetupFileName>app-env</environmentSetupFileName>
            </daemon>
        </daemons>
    </configuration>
    <executions>
        <execution>
            < phase>package</phase>
            <goals>
                 <goal>generate-daemons</goal>
                 <goal>create-repository</goal>
            </goals>
        </execution>
    </executions>
</plugin>

If you look at the code carefully, you’ll find “app-env” as a parameter to “environmentSetupFileName” tag. It is quite useful in passing environment variables to the resultant script. Using app-env (for UNIX) and app-env.bat (for Windows) environment setup files, I could pass a modified $REPO environment variable so that the copied repository containing dependencies is shared between booter-unix and booter-windows folders as follows:

|-- booter-unix

|   |-- bin

|   |   |-- applicationName
|   |   `-- app-env

|   `-- etc

|       `-- applicationName.xml

|-- booter-windows

|   |-- bin

|   |   |-- app-env.bat

|   |   `-- applicationName.bat

|   `-- etc

|       `-- applicationName.xml

|-- etc

|   |-- config.properties

|   `-- log4j.properties

`-- repo

    |-- <dependency1>.jar

    |-- <dependency2>.jar

    |-- ...

To copy the environment files and result of appassembler:generate-daemons maven goal to the appropriate locations we can use “maven-assembly-plugin” as follows:

<plugin>
    <artifactId>maven-assembly-plugin</artifactId>
    <configuration>
        <descriptor>src/main/conf/descriptor.xml</descriptor>
    </configuration>
    <executions>
       <execution>
          <goals>
              <goal>single</goal>
          </goals>
          <phase>package</phase>
       </execution>
    </executions>
</plugin>

Here’s what src/main/conf/assembly.xml looks like:

<assembly>
    <id>bin</id>
    <formats>
        <format>tar.gz</format>
        <format>zip</format>
        <format>dir</format>
    </formats>
    <fileSets>
        <fileSet>
            <directory>target/appassembler/booter-unix</directory>
            <outputDirectory>/booter-unix</outputDirectory>
            <excludes>
                <exclude>*.bat</exclude>
                <exclude>*.cmd</exclude>
            </excludes>
            <lineEnding>unix</lineEnding>
            <fileMode>0744</fileMode>
        </fileSet>
        <fileSet>
            <directory>target/appassembler/booter-windows</directory>
            <outputDirectory>/booter-windows</outputDirectory>
        </fileSet>
        <fileSet>
            <directory>target/appassembler/repo</directory>
            <outputDirectory>/repo</outputDirectory>
        </fileSet>
        <fileSet>
            <directory>src/main/conf</directory>
            <includes>
                <include>app-env.bat</include>
            </includes>
            <outputDirectory>/booter-windows/bin</outputDirectory>
        </fileSet>
        <fileSet>
            <directory>src/main/conf</directory>
            <includes>
                <include>app-env</include>
            </includes>
            <outputDirectory>/booter-unix/bin</outputDirectory>
            <lineEnding>unix</lineEnding>
        </fileSet>
    </fileSets>
</assembly>

Now, if you run “mvn clean package”, it provides you the structure as mentioned in listing 2. You can execute the script from booter-windows/bin/applicationName.bat on Windows without worrying about long classpaths now.

As we created Kettle transformations and jobs, we were not very sure about its testability part. After some research we found that we can use BlackBoxTests class available in Kettle distribution for test purposes. The fundamentals of it are quite simple. You pass some inputs and define the expected file and in the output you get actual output file after executing Kettle transformation. BlackBoxTests asserts if expected file matches with actual file. So for instance if you have a Sample.ktr under test, BlackBoxTests will expect Sample.expected.<txt/xml/csv> as an expected file and Sample.actual.<txt/xml/csv> as actual file to make it work. It tests all available transformations under a folder and subfolders.

By definition Kettle uses kettle.properties (available under $HOME/.kettle folder) which creates complications from testing point of view. However you should be able to test a Kettle transformation in isolation. That’s why instead of using kettle.properties, we planned to use application specific property file to pass it to TransMeta class with available injectVariables() method. We were kind of successful but later found out that Kettle still uses kettle.properties even if we use a different property file.

After a lot of debugging we found out the culprit. BlackBoxTests uses EnvUtil.environmentInit() and does all the magic. It loads the kettle.properties by default and to our horror loads into java.lang.System.

We quickly got rid of using EnvUtil but found again that it’s not enough to pass the properties from outside. It works for the current transformation but somehow Kettle is not able to pass these properties to embedded sub-transformations. It worked earlier just because EnvUtil.environmentInit() loads properties into java.lang.System.

Overall, though we were finally able to do the testing with BlackBoxTests in isolation with some hacks, we concluded that the Kettle code is not designed to be testable and it can be termed as legacy code in Michael Feather’s language.

In the entire conference there was a lot of focus on Outside-In thinking instead of Inside-Out thinking. It’s no more sufficient just to think about customer satisfaction. It has more to do with customer delight and in true sense, participating towards customer success. So instead of thinking what you think will be good for a customer, it’s important to figure out what a customer actually need. So a thinking from an end-user perspective is very important for software development.

There was an interesting talk from Manoj Shrivastava in which along with stressing on the usability principle “Don’t make me think”, he stressed on the need of “Don’t make me state” being more explicit to software vendors. It’s about some basic fundamentals of software development which you as a customer wouldn’t like to state while defining requirements. For instance, as a vendor you definitely won’t say at the end of a project that you didn’t care about foreign key constraints as part of database design because design document was signed off and customer should have pointed it out earlier.

This highlighted two key facts. One – a lot of organizations still follow traditional methodologies for software development. As a result, there is no scope of early feedback and adapting to the changes. That’s one of the reasons why Agile has become and growing very fast as the mainstream software development methodology.

Second fact is even more serious. Simply, don’t make me state!!! From software development point of view, some of the things should be quite understood and shouldn’t required to be told.

There was a very good presentation from David S. Frankel on the challenges involved in Model Driven Systems. Sometimes the cost involved in integrating various systems based for different financial networks can be too high (for instance one billion dollar if you think of changing small details in credit card transaction integration). He mentioned ISO 20022 as an emerging standard for financial messaging but at the same time highlighted its limitations as it solves some problems but creates even more. His focus of presentation was go to the next level and provide semantic interoperability in data integration path.

At the end of the day, there was a very good panel discussion on a very important topic – why we lack focus and drive on software product development and innovation in India. It was a great debate and here are some important points discussed.

• The entrepreneur culture: David S. Frankel asked a question – how easy it is to start and how easy it is fail as a business in India. For instance, it’s very easy to start a company in USA. The red tape and bureaucracy involved are very minimal. At the same time, it’s very easy to fail too. If you fail in one venture, you start another. Most of the successful entrepreneurs in the world did not taste success in their very first venture. They failed, learned from mistakes and started a new one again. The culture of easy to start and easy to fail creates a very healthy environment in setting up business ventures based on new ideas which is the basic premise of product development. At the same time in some countries, if you fail and go bankrupt, it may become very tough to start a new company again. In India, it’s very easy to start but not that easy to fail. Not because from legal point of view but from attached social stigma as Indian culture is a society based culture.
• Another point discussed was about the proximity of the market with India. Software market is still in western countries. Computer penetration in India is increasing but still hasn’t reached at that level. As market is in other countries, it’s difficult to think the need of new products from a thousands of miles distance. I personally feel it not a valid case as India is a very big market in itself. There can be many business ideas which suits to Indian consumer need.
• Some people attributed the culture of being followers instead of being leader in terms of innovation. Also it has a lot to do with the education system which hasn’t changed since colonial times and was created to produce clerks to aid British colonial system but definitely not creative thinkers. Current education system has a lot of focus on cramming books for getting good marks instead of focusing on new innovative ideas.

Personally I also feel, education and culture has a lot to do with it. At the same time, it’s also important to understand how easy or difficult it is to survive in India. India has absolutely no concept of social security. From the very beginning you strive for survival and in case you fail, you are on your own. Most of the people who are just living for survival don’t want to take chances and play safe. Entrepreneurship in product innovation is a risky game which makes it very difficult to fail in India. That’s one of the main reasons why people don’t try to experiment.

A session from Grady Booch was thought provoking in context of current grim economic environment. He gave several examples on how software world has transformed the world we know in recent years. In the face of economic scarcity, the tradition reaction is to retreat, shrink, slash, and/or panic. Very natural considering the tough situations it creates for corporates to survive. The thing about software, however, is that it is perhaps the most fungible and liquid of resources. The supply of software is limited only by human imagination and labor. Grady argued, software-intensive systems are an inescapable and necessary element in helping us operate, innovate, and even thrive in the face of lean economic times.

In all, it was a very informative conference and included participation from around 300-400 software professionals. However time and again, during discussions, I observed a fact that people from software services industry in India and also in other parts of world still follow traditional software development approaches. It creates a lot of issues in outsourcing world. You don’t show your kitchen anymore, how you build software and the progress on periodic basis. At the end of project, it leads to requirements not met, low quality product and not getting the required features in time. I think Agile Distributed Delivery Model brings a lot of proximity with customer with periodic delivery, always visible (open kitchen approach) quality dashboards and delivering prioritized business goals instead of delivering everything but half baked product.

It works very well when team is collocated as pair-switching, driver-navigator role change and design discussions in person is quite seamless in collocated environment.

What if you are the part of a distributed team? Developers still pair-up but not necessarily with team-member from distributed location. Though many teams have started implementing the concept of distributed pair-programming with the help of newly available communication tools (Skype for voice conversations and Skype Mikogo plugin for desktop sharing to name a few) quite successfully in which developers in distributed locations pair-up with each other .

While working in one such distributed project, we realized that knowledge areas were getting localized as distributed teams used to work on different stories. Standups by nature are brief and don’t give a lot exact implementation details. Planning-2 meetings help in defining low level design and steps but during implementation those steps are also bound to change sometimes. Because of above mentioned reasons, we felt the need of a forum for knowledge sharing between distributed teams.

We started having distributed knowledge sharing sessions using Skype voice-communication and Mikogo desktop sharing tool and they were quite effective. Even though it may be difficult to grasp entire flow in one session, it still provided a good view on implementation issues which helps in implementing future stories or fixing any maintenance issue quickly,

During those discussions we also used to get design feedback within the team which were helpful in identifying any design flaws, points of improvements, refactoring areas etc.

Earlier, most of the times, entire distributed software project used to be executed completely at offshore because of time-zone differences and communication issues. Now because of communication revolution, you see a new trend where software companies like to extend their teams (augmented Agile teams) with different vendors. Recently while working in such a project from a distributed location, we realized the need of local retrospective.

As part of retrospective (Scrum practice), at the end of a sprint (iteration), entire team sit together and discusses the good points and points of improvement. At the end of it, entire team converges to vote on the most important “points of improvements” which could be implemented in the next sprint.

During one of such retrospectives we realized that sometimes, some points of improvements are local in nature. For instance, team in US may feel strongly about some issues for which Indian team may not feel with the same intensity and vice-versa.

It leads to situations where issues are lost somewhere because of lack of consensus between distributed teams. Sometimes there can be cases in which because of some political and management reasons, the local (vendor) team may not want to discuss some local issues with other part (customer) of team.

In such cases, there used to be some informal discussions on problems within the team but most of the times without any solutions (action points) and action owners. Also those discussions used to be one-on-one discussions but not with entire local team. Not taken seriously, it created even bigger problems for the team in long run.

Finally we realized that we need a formal forum in which entire team sits together, discusses local points of improvements, identify action items and action-owner. Also it’s important to identify somebody on alternate basis to track the actions taken.

As part of the Agile philosophy of keeping information radiator always visible, these retrospective action items should also be visible on Scrum board.

We realized that having local retrospective helped the team a lot as we could focus on many local points of improvements like “how to gain domain knowledge quickly, how to improve on pair switching etc” which otherwise wouldn’t have been possible and could have lost somewhere.

Another side of the coin is – in the competitive age of software products with two many choices and with a lot of time-crunch, end-user might be a bit lazy in downloading and installing just to be able to look at the features of the application. On the other hand browser based applications are quick to experiment with. In terms of features and power, browser based application may be a subset of desktop application but still provides majority of features for most of the quick users.

We had a similar situation in our project where we had to refactor an existing AIR application to provide support for both browser and AIR versions. To accomplish this task, we found a good article which provided us a basic architectural approach to do it.

We started with refactoring existing AIR project (ProjectAIR) into two more projects, SharedProject and ProjectWeb (web project). SharedProject contained the common shared code between ProjectAIR and ProjectWeb.

Adobe AIR based applications use windows, file-system, SQL operations etc which needed to be replaced with their counterparts in web version. We abstracted out these functionalities using ActionScript (AS3) interfaces. In other words wherever AS3 code had to be implemented in different ways for AIR and Web version, we identified common abstraction in form of AS3 interfaces and provided AIR (in ProjectAIR) and Web (in ProjectWeb) based implementations.

We used Spring ActionScript, an ActionScript dependency injection framework, to inject appropriate AS3 interface implementations based on applications we are using (different applicationContext.xml for ProjectAIR and ProjectWeb).

As AIR version is able to work on files (say images), we had to provide a similar functionality in web version also. It was just not possible in Flash 9 as it is a violation of sandbox security. Recently Flash 10 introduced a new feature of read/write files in flash player without any need to send anything back to the server. We used recently introduced Flex 3.2 SDK to access these features. Instead of storing data in file-system (possible in AIR), we used SharedObject (Flex cookie) to store the user-information on desktop.

One of the major issue comes when you have to reuse View (MXML). For some views where it was just not possible, we created different views (one each for web and AIR version). However for majority we could refactor and reuse them. We refactored the Views and taken out any AIR specific functionality. They became base version of view which could either be directly used in web version or needed to be extended for both web and AIR versions. We created a nomenclature something like AIR and Web (e.g. InvoiceViewAIR.mxml and InvoiceViewWeb.mxml which extend from InvoiceView.mxml). For instance InvoiceViewAIR.mxml (extends from InvoiceView.mxml) could be something like this.

Using above mentioned techniques, we finally were able to run the application in both AIR and web-browser and it was a wonderful moment for us.

One of the things which is common amongst all browsers is – popup should open from a user action like button-click, link click etc. Popup-blockers almost always block windows opened without user-actions which looks fine to me as otherwise spammers could open dozens of windows without asking you. However this posed a bit of problem in Flex for me. I wanted to open a window after invoking some backend services. As responses (results from web-services) coming from Flex events are always asynchronous, it was just not possible to open the window after having some backend interaction. I had to change some of my design.

Another problem was different browsers behaviors. In some browsers Flex based ExternalInterface.call() method works and on some navigationToURL(). While solving this problem, I came across with a good link which solves most of the window.open() issues on different browsers.

Safari poses yet another challenge when it comes to using window.focus() function. In many of the situations you’d like to open one single named window (important from usability perspective). While using the same window for a new URL, you may want to put focus on exiting window using window.focus() function. Safari doesn’t support window.focus() function. I tried to find a suitable alternative but nothing worked except close and open the window again as follows:

var newwindow = '';
function popitup(url) {
    if (!newwindow.closed && newwindow.location) {
        newwindow.close();
        newwindow=window.open(url,'name'+Math.random(),'height=600,width=800');
    }
    else {
        newwindow=window.open(url,'name','height=600,width=800');
        if (!newwindow.opener) newwindow.opener = self;
    }
    return false;
}

Please note I used a new window name every time I close a window. Again in Safari one cannot reopen the same named window after closing it.

I also used following references which were helpful for me.

• Javascript – Cross window scripting
• about window.open() in safari

Part 1:
Automated code reviews with Checkstyle, Part 1

Part 2:
Automated code reviews with Checkstyle, Part 2

This article series attempts to bridge the gap of code review with applying automated Checkstyle checks in a complete and proactive way. First goal is to make the task of custom Checkstyle rules creation so simple so that any enterprise IT team could create new custom rules suiting to their project (IT standards) needs.

Second goal is to apply these rules in PROCTIVE fashion. Instead of waiting the build to fail or waiting for rule violation reports and working on them in a reactive way, the idea is to apply these checks proactively with Checkstyle Eclipse plugin or applying them at SVN level itself. Irrespective of which IDE you are using, if your code contains some of the high severity violations, you will not be able to commit the code in SVN. You will see the same kind errors and location on SVN console as you see with Eclipse plugin. This is achieved using SVN pre-commit hooks.

1. Support for generating getters-setters automatically.
2. Support of templates for creating constants.
3. Organize imports. If some type has not been included already, organize-import should do that.
4. Better refactoring support. Right now refactoring is just limited to renaming and you start missing real sense of refactoring in terms of creating new methods etc.
5. Sometimes you may want to create your own templates for creating ASDoc instead of doing it from the scratch all the time
6. Formatting ActionScript/Flex files

I did some research on internet and found some options to resolve these problems.

Eclipse Monkey

Eclipse Monkey currently is a part of Eclipse Dash project. It is proposed to be split from Dash to make it full-fledged project in itself. It’s a very powerful tool. Instead of extending Eclipse platform through creating plugins, you can extend Eclipse functionality through some scripting. Eclipse Monkey uses the Mozilla Rhino Javascript interpreter at its core. You guessed it right, scripting couldn’t have been easier for Eclipse than the way it does with Monkey using Javascript.

Eclipse Monkey can be used to create getters and setters in ActionScript in automated fashion. You may want to take a look on a ~eokyere blog to see how Monkey is used to create getters and setters. As I searched some more available Monkey scripting resources, I found more examples and one of them satisfied my problem no 2 also.

If you have already downloaded and executed Monkey scripts on your Eclipse platform, you may have realized how powerful this Scripting tool is for Eclipse. You can create a lot of scripting based tools to enhance productivity without creating specialized plugin.

FDT ActionScript Editor

For rest of the problems mentioned above, I tried many options but somehow they didn’t provide desired outcome. However one ActionScript based editor FDT comes very close. It supports most of features mentioned in the list and is certainly a better choice from ActionScript editor point of view. However it’s not free and sometimes I wonder why somebody will invest yet another €599 to buy this tool if he already has Flex Builder. Flex Builder is a defacto tool for Flex based development whereas FDT mainly focuses on ActionScript based programming. FDT doesn’t support MXML yet.

No wonder that we come to conclude that Flex Builder has a lot to catch up in terms of enhancing its tooling for Flex developers. However the tools I just mentioned come a bit close in providing the required support.

Because of all those reasons, some frameworks have been created in Flex world to provide MVC pattern implementation. One such frameworks is Cairngorm which is an architectural framework to provide the separation between different MVC layers using some of the very well known design patterns from JEE world. So it may sound quite familiar to you if I talk about Front Controller, Business Delegate, Service Locator, GOF Command Pattern and Value Object patterns. Flex world still calls Data Transfer Object (DTO) pattern as Value Object because of some reasons. Along with all mentioned patterns it uses one more design pattern which is specific to Flex world and is called Model Locator design pattern. This pattern is based on singleton pattern though.

Now while I talk about these design patterns, you may wonder that some of these patterns reduces testability a lot because of their singleton nature. Service Locator tries to get the dependencies instead of being injected. To resolve all these problems, you may wonder that there has to be a Spring like dependency injection framework in Flex world too. You are absolutely right. There is one and is called prana framework. Now if you use prana on top of Cairngorm framework, you automatically remove the need of creating Controller classes, Service Locator, singleton nature of Model Locator etc. Also automatically it enhances the testability of the applications and encourages programming to interfaces.

However while using prana you may come across with a problem. You define the actual implementation of the interface in applicationContext.xml but mxml compiler does not include these dependencies while creating resultant SWF file because it doesn’t see these dependencies in the actual code. It may result in a lot of runtime errors. To resolve these problems, generally implementations are included in the main MXML file just for compilation sake which you already know is error prone. I should call it as the limitation of Flex framework as currently it’s not able to resolve the dependencies with prana based applicatonContext.xml files. To resolve this, some people create tools to generate the Factory classes from applicationComtext.xml to get actual implementation.

The prana framework is in 0.6 release right now and as you expect it yet again, it requires a similar IDE as you have for Spring (SpringIDE). Even after removing all above problems in Cairngorm with the help of “prana”, Cairngorm still has some other problems which then are removed using cairngorm UM extensions.

For unit testing purposes, we have FlexUnit framework but it doesn’t meet some of the requirements of unit testing like testing asynchronous code and other similar problems. To resolve them currently people use fluint framework which is a unit-test as well as integration test framework. Similar to Selenium web application testing framework Flex world currently has FlexMonkey to test Flex UI.

Flex build is mostly done on ANT which provides a low level build abstraction compared to Maven 2. Flex world currently lacks good Maven plugins. On similar note, FlexBuilder (an Eclipse based Flex IDE) needs many improvements in IDE in the areas of code refactoring (refactoring support for ActionScript classes other than renaming) and other very usual Eclipse based code generation.

As you already can see that Flex world is going through with a lot of architectural frameworks changes currently. Most of the time, they are Flex specific implementations of already proven existing JEE architectural frameworks/design patterns. In coming time, Flex world is expected to have more matured frameworks which will make the life of a developer easier and software more maintainable.