Currently I am working on a tool called Verde, this is an automated characterization testing tool targeted for all Java legacy applications out in the wild.
One of the key feature of this tool is it can generate characterization tests with mocks meaning if we want we can generate Junit test cases by mocking database access or network access. Yeah it is cool.

As part of our integration test suite of Verde we have few end-to-end tests that generate test cases with mocks from sample application and run them to verify that everything is working, as they should be.

Recently one of our developer noticed that generated tests are no longer generating correct mock expectations. This must be because of some changes we made in our code but the crazy part is our integration tests never failed. In spite of wrong expectations our tests are still running fine because without mocks our generated tests are hitting the actual network resource and asserting the result received over the network. So from outside everything looked fine and worked fine too. Now this is an interesting problem, we cannot disable network connection because some tests are expected to use external resources. What do we do?

SecurityManager is for reuse.

Without going into details of how Security Manager works in Java, java.security.SecurityManager defines quite a few check methods for various operations like file read/write, print job, network access etc. The behavior of these check methods is very simple, if allowed nothing happens but when denied these methods are suppose to throw SecurityException.
So to tackle this problem we created a custom security manager to block network access. First we overridden all the check methods with do nothing implementation. This means that you are allowing all the access or granting all the permissions. Then we did something like following.

…

@Override
public void checkConnect(String host, int port) {
throw new SecurityException(”Not allowed to access network connection, make sure all the dependencies are mocked out”);
}

@Override
public void checkConnect(String host, int port, Object context) {
throw new SecurityException(”Not allowed to access network connection, make sure all the dependencies are mocked out”);
}

…

We are throwing SecurityException from couple of check methods related to network access. What it means is now when test will try to access network it will get security exception, and the test will fail. That’s it. Maybe oneday you might find this trick useful.

Oh don’t forget to specify your custom security manager using –Djava.security.manager when running the tests.

Things are really going crazy in programming language world these days, especially for JVM. Yesterday I noticed the new loke programming language from Ola bini and today I found clojure.
loke is a prototype based object oriented programming language. I personally think prototype based languages are much more fun to play with compare to class based object oriented languages, the reason I love JavaScript so much. Not the new JavaScript 2 though.

On the other hand we have clojure which is a functional programming language with lisp dialect. I haven’t looked into it yet but I will definitely play with it very soon. Infact there is already a beta book available for it.

I am not sure what tomorrow has in store for me?

IT Organizations around the country are facing a common problem: “How can we handle the pressing burden of maintaining our legacy Java applications while we also push forward with new software initiatives?”  This is a difficult question.  The perspectives on this are diverse.

Some have tried a balancing act of keeping the most difficult or brittle applications in-house while exploring the use of offshore development for new applications.  This approach leads to disgruntled developers and skeptical business leaders.  Some have found that the overall costs of ownership actually increases with the complexity of communicating requirements and maintaining the resulting code.

Some have tried to keep all development in house:  Maintenance and New Development.  This works, but it is expensive and forces the business to accept a very small number of new applications each year.  Although used by most, this approach is not working well as most organization allocate 75% of the budget to just keep existing applications running.

What if there was a way to reduce the costs of maintenance while increasing the confidence in the integrity and longevity of applications over time?  We think we have the answer.

There are a few driving business issues that prevent the maintenance of critical applications from ever “leaving” the close supervision of a few key IT people:The business/IT leaders don’t trust others to maintain the integrity of the application.

. The code lacks proper tests - code coverage is very low
. The code is very brittle
. All the business expertise is wrapped into the minds of a few IT people
. Applications considered too risky to outsource
. Government or Trade restrictions
. Response times by distant offshore companies can be very poor
. Localized support options do not exist - until now

In response to these issues, Pillar is offering the following services:

Localized Development Centers to provide support of complex .NET and J2EE applications
Verde Characterization Testing can guarantee the integrity of an application over time.  This is the key.  Business Leaders want to know that their key applications continue to work even if less experienced resources are maintaining the code.
Guaranteed response times as needed
Outsource Insurance Plan - we can enable your application with the appropriate check  points to allow for outsourcing as needed.

The benefits of leveraging the Pillar Development Centers are numerous:

Each application is wrapped with Verde Characterization Tests that are used as an audit tool.  Each week, the tests are run to demonstrate the ongoing integrity of an application.  No other outsource solutions are offering this service.
The overall Total Costs of Ownership is reduced as Pillar leverages a model that allows entry level developers to pair with experts.
Language and distance issues are resolved as development centers are strategically located within easy reach of the customers.
Business leaders trust the support of applications as they review the Verde Characterization Tests Results each week.
The most valuable resources are allocated to focus on building new applications.

I find the current state of IT very interesting.  I must first confess that I have perspective.  My perspective covers over 30 years of IT development.  I welcome the challenge of an argument, but my perspective is simply this:   The Approach to Software Development Must Change!

When I first started my coding career (late 70’s), relational databases were beginning to emerge as a growing trend.  VSAM and flat files would soon be eliminated - any day now.  Cobol would soon be replaced by emerging 4GL languages and life would be good as applications would fall into production with ease.  The days of debugging Cobol would soon come to an end.  Tongue in cheek for sure, but we believed it at the time.

Fast forward to 1983.  Recession hits the nation.  IT would begin to explore ways to reduce the costs related to IT development.  The beginning of Offshore development took place.  All of our problems would now be solved with cheaper labor.

IT Management was convinced that the Water Fall Approach to software development was the answer.  They were equally convinced that the real issues were simply related to the expensive staff of American programmers - the evil developers would have to pay a price or else!  The battle for cost savings had begun.

Fast forward to 1995.  A few of the faithful IT thought leaders were convinced that the real savings opportunities could be secured by fixing the root problem - Change the Approach! They believed that a new EXTREME approach to writing software was the answer.  Ron Jeffries and others would begin to define a new approach to capturing requirements and writing software.  The birth of agile (XP) had taken place.  I was a witness to this, but not smart enough to realize what was happening.

The first Agile project failed - mostly due to political reasons.

The Agile Movement was motivated by this failure and refused to stand down from the challenge.  The Agile Manifesto was signed - no turning back.

Years of fighting between bean counters and enlightened developers have ensued.  Some have awakened to the truth: The traditional water fall approach to software development does not work.  Even in the midst of these hard times, there are many advocates of simply sending requirements to distant shores and hoping for costs savings.  Good luck with that.

Enough already!

The truth is out.  Agile wins.  Always has and always will.

Pillar has led a march against the established traditions for years.  Over the past 10 years we have waged the war to find the perfect approach to software development.  We have failed on occasion, but we have shouted victory with passion as well.  Speed-to-Value (S2V) is the result of a lot of blood, sweet, and tears.  But it has been worth it!

Those who cling to the past, have dug a hole of despair as they cling to the empty hope of costs savings by lowering labor costs.  This trend has led to the the demise of numerous organizations.  The american auto sector may never recover because of the short sighted approach of the leaders involved.

In the face of despair, we stand with the emerging Agile Community and offer hope.  We have discovered a better way.  We have challenged each other and we have improved on the process.  We are bridging the gap between the business community and the IT community.

Change is hard, but it is possible.  As small as we are, Pillar is making a difference in the world. We are no longer supporting failed strategies of the past.  We now choose to wave our hands in the air and offer hope to others on this journey.

Let’s make a difference today.

Gary Gentry
Founder/CEO

www.pillartechnology.com

Last weekend in the “Simple Design and Testing Conference” we had a discussion on “What makes Design Simple” and this is a summary of the discussion we had along with my thoughts.

Well before we go further with in our way of defining simple/complicated design we have to step back and first answer why do we design?

We design to be productive and I don’t do it if it is below the DesignPayoffLine. Now if you read What is software design which I highly recommend you will learn that we design all the time, when customer approves a story he/she makes a design decision (this is interesting, some times we evolve to complicated design when stories are not broken properly), when we write tests (we do test driven development) and programming is also a design activity. So I guess we are always designing with or without knowing it.

Being an agile developer, we don’t focus ourselves on BUFD (Big Up Front Design) but rather we believe in evolutionary design, a design that grows as your system grows and there are benefits of doing that which I will not discuss here (read http://martinfowler.com/articles/designDead.html). One of the key aspects of the evolutionary design is to do the “simplest thing that could possibly work” nothing less, nothing more. There are couple of things that needs to be noted here, “simplest” and “possibly”. Simplest or simplicity is your shortest path to the solution i.e. getting your idea from your head to screen as quickly as possible. And why it is possibly? Because we are not sure whether it will work and that’s why we write test to make sure that our idea works.

But the interesting part is we all start simple (I am totally ignoring the fact that there are teams that start with 200 page design document from day one) and it gets complicated over time because it starts doing more work. But if we could restrict ourselves to keep it simple for tomorrows need tomorrow then I guess we can preserve simplicity and this is where refactoring step fits in. Refactoring is our way to simplify things when it gets complicated. Einstein once said, “As simple as possible, but no simpler.” And I think that makes sense here.

Wait a minute we haven’t defined simple design yet? I don’t think I can define simple in two lines but lets ask the question differently, “How will we know that our application design is simple?”

Software with simple design will enable team members to quickly respond to change. And as your design deteriorates, so does your ability to respond to change. This is really critical for agile projects (again ignoring rest 70% of teams who don’t believe in agile, they really don’t care) because we embrace change and customer satisfaction is important to us. Kent beck calls it “reversibility” property of software. If we can change our decisions quickly it is not a big deal to get them right in the first place and that means less planning upfront (we are wrong most of the times anyways). There are some really good second order benefits to simple design, we get our work done sooner and it is easier to communicate our work with others (I am not sure about you but I still work as part of a team, collective ownership rings any bells?). Above of all it is less stressful to work with simple design.

So how can we keep our design simple?  Testability

I absolutely agree with James Bach on ” there are no best practices” but rather appropriate practices and I think the appropriate practice  to keep your design simple is continue to write tests.

Testability is a characteristic of software application that provides ability to developers to write tests for their software application. In the world of TDD, we derive our design from tests and having that ability is very important. In fact if it is hard to write test, developers will stop writing tests especially new agile developers. It is very easy to get into “code and fix” mode under agile radar. If you are the only manager reading this article please pay attention to your developers when they say it is hard to test, this could be good indication that application design is deteriorating.

While discussing “What makes design simple” in the conference, Brain Marick raised one interesting point, we should strive for habitability, “The characteristic of source code that enable developers feel like home and place their hands on any item without having to think deeply about where it is”( read http://www.wirfs-brock.com/PDFs/DoesBeautifulCodeImply.pdf). We do spend good portion of our time everyday inside the code we are working on and habitability makes working easy. I guess more appropriate answer to the question “How will we know that our application design is simple?” would be habitability. If it is easy to work with your design, it is simple.

If you are still with me then probably some of these makes sense but if you were looking for top 10 practices for simple design sorry to disappoint. The take way point is  “Design for today, not for tomorrow”

Pillar is bringing a new suite of tools to the market. Verde is the name that we have chosen to leverage the fact that we are attempting to provide greenfield test coverage in situations where there are no other signs of life.  Verde is a tool that allows existing legacy Java Code to be wrapped with JUnit Tests.  These tests are well structured and maintainable.  They are created dynamically at run time with real data.  Verde is a game changing tool.  While we are not advertising or publishing the power of the tool, we are actively using the tool for a few select clients.  If you have questions, feel free to contact the author for more information.

due date of the project and reality is nothing goes as you plan in this world.

Groovy Script

Groovy Scripts are different from Groovy classes, in Groovy Scripts you can directly write code without declaring methods or classes (just like your bash or perl scripts). We can use Groovy Scripts from Groovy classes, Java classes or using “java” to run them.

From Java Classes

[sourcecode langauge=”java”]

ScriptEngineManager manager = new ScriptEngineManager();
ScriptEngine engine = manager.getEngineByName(”groovy”);
System.out.println(”Calling script from Java”);
try
{
engine.eval(new FileReader(”MyGroovyScript.groovy”));
}
catch(ScriptException ex)
{
System.out.println(ex);
}

[/sourcecode]

Note: Make sure your groovy-engine.jar file is in your classpath

From Other Groovy Scripts

[sourcecode langauge=”groovy”]

def shell = new GroovyShell()
shell.evaluate(new File(’MyGroovyScript.groovy’))

[/sourcecode]

From Command line

We can compile our Groovy Scripts using groovyc compiler and when you do that it will create a single “.class” file based on name of the script with auto generated main(String[] args) method. Once you have a main method we can clearly run using java command, no tricks there. The auto generated main method creates an instance of the class which extends groovy.lang.Script and invokes run method on it

From Groovy Classes

[sourcecode language=”groovy”]

def runSomeScript() {

…

run(MyGroovyScript)

…

}

[/sourcecode]

What the heck is this? Are we missing something?

No we are not. In Groovy (like Ruby) class names are constant and in Groovy this constant points to java.lang.Class class of the class created by the groovyc compiler. So now if I have a method like following I would be able to run the script

[sourcecode langauge=”groovy”]

def run(Class scriptClass) {//You don’t have to specify type, I did for clarity

Script script = InvokerHelper.createScript(scriptClass, new Binding()) //Binding is a way to share variables and context info with Script

script.run()

}

[/sourcecode]

Lately I am having stupid merging issues with .classpath (eclipse) file because of subversion. Anyways that’s not what I want to discuss here. In Mac dot files are hidden and you cannot view them in finder by default and my windows friends find that bit annoying while pairing. So I looked up and found that we could use “defaults” command from terminal to change some of these behavior. For example if you want to view hidden files in finder, the following command will enable it

defaults write com.apple.Finder.AppleShowAllFiles YES

To make the above command work you have to restart your finder from your dock though.

Not only that , you have other hidden features that you could enable, especially I liked the one where you could drag widgets from dash board to your desktop.

Even better you have TinkerTool  which allows you to play with these hidden defaults from a nice gui…Sweet.