RSSMix.com Mix ID 115244

What is Scrum?

Recently, a friend of mine asked me "What is Scrum?"

I started thinking what is the best (and quickest) path to introduce a person to Scrum? So, I started my research for references; and here is a list of online resources that I feel can be used to get a quick familiarity with Scrum.

Enjoy!

Here are some more online resources:

The Agile Elevator Speech
Scrum in Five Minutes
An Introduction to Scrum
Scrum et al. - Ken Schwaber (who created Scrum) on Scrum at Google
And, of course, if you are (American) football fan, you can read my article that draws similarity between The Partiots - a Football team and some of the Scrum practices.

Product Backlog, Product Owner, and Business Value (BV)

As we all know very well, the Product Backlog (PB) is very critical artifact in Scrum and Agile. PB should be the central repository of all the work that needs to be completed in a Project. We capture all the work (as we know as of Today) in the form of Epics, Features, and Stories. The Product Owner (PO) would then be responsible for providing the priorities on them. The PO may also decide to use the Business Value (BV) to help him/her prioritize the Product Backlog.

While there is no explicit formula for Business Value, the Product Owner should be making implicit decisions based on his/her experiences. While assigning BV to Features and Epics, the Product Owner may consider some of the following criteria:

* What the team has accomplished so far?
* What the team can complete within the Release Cycle?
* Complexities
* Dependencies
* Impediments
* Market Size
* Market Timing
* Opportunity Cost

If you 'zoom' into these criteria and look at them closely, you will realize the first few criteria drive the Priority and Sequencing of the Feature and Epics. The last three, Market Size, Market Timing, and Opportunity Cost, are the ones that will drive the Business Value.

Harvard Business Publishing and Agile..

I recently read an article from Harvard Business Publishing on "Why Good Projects Fail". As we all know, the failure rate for projects is very high; more than half of the projects fail! This is especially troublesome in Traditional Project Management as you would not know if the project is failing until it is too late (remember, one big bang delivery!)

In this Harvard Business Publishing, the author suggests using rapid-results initiatives in order to minimize and mitigate the risks of failure. What he means by that is "to use small projects designed to quickly delivery mini-versions of the big project's end results". Do you 'smell' Sprints here!?

He goes on to list several defining characteristics of this rapid-results initiatives approach such as:

* Results oriented (As we know, with each sprint, our goal is to deliver value to the Product Owner.)
* Vertical (Refers to Cross functional team)
* Fast (Refers to Sprints and Releases)

There are many parallels in this article and what we do in Agile landscape. Check out the article here to find out more details.

Reading List..

I have been involved in transitioning two of the largest organizations (in the North America) to value driven project methodologies such as Agile, Scrum, and Lean. During these transitions, I have coached several teams, managers, and executives on Agile Practices and principles, and have often been asked for recommended reading list. I have accumulated a list of references that I often recommend my new teams read when starting their journey on Agile. Here is the list for your reference.

Books

Agile Project Management with Scrum (Schwaber)

User Stories Applied (Cohn)

Scrum and XP from the Trenches.pdf (Kniberg)

Scaling Software Agility (Leffingwell)

Agile Estimating and Planning (Cohn)

Implementing Lean Software Development: From Concept to Cash (Poppendieck)

Test Driven Development: By Example (Beck)

Agile Software Development with SCRUM (Schwaber)

Online References

Scrum Alliance

Being Agile is our favourite thing

Agile Manifesto

Agile Wikipedia

Mountain Goat Software

Jeff Sutherland NYC Spin

Scrum and XP from the Trenches

Agile Project Leadership

Agile Management

Ward Cunningham on the origin of the term Technical Debt

Agile Thoughts

Testers Shine on Agile Projects

Requirements Up Front

Agile Requirements

BSA Role

Its Not Just Standing Up

Big Macs vs. The Naked Chef

Agile Has Crossed the Chasm

Constructive Disruption and Compromised Agility

Kanban in a nutshell

Learn from the experts: Blogs, RSS Feeds

Schwaber on Scrum

Agile Advice

Agile Alliance

Agile Management Blog

Implementing Scrum

Pages tagged with 'agile' on del.icio.us

Stevey's Blog Rants: Good Agile, Bad Agile

agile at google

The Planning Onion: Five Levels of Agile Planning

Shameless post: link to my blog

Unlearn what you have learnt

Delivering the W, One Game at a Time

Field of View

a quick introduction: What is Scrum?

Star Wars and Agile..

In the Star Wars movie The Empire Strikes Back, Luke tries unsuccessfully to rescue his X-wing fighter from the swamp. After some time, he gives up. He tells Jedi Master Yoda that lifting the fighter is impossible with the force, the new approach Yoda is trying to teach him. Yoda has these words of wisdom for him:

"You must unlearn what you have learned."

Scrum is no different! Like the Jedi force, the Scrum framework is conceptually easy; it's putting Scrum into practice that is difficult. In order for a team to be successful, the team members must unlearn what they have learned so far in their careers.

Check out my recent article for more details on what habits must be broken to succeed in Agile Adoption.

Google CEO on pair programming..

Recently, I read an article on Business Week. In this article Google CEO Eric Schmidt describes the simple principles that helps the company drive innovation.

In this interview, he mentions that the best programming team is a "telephone call," which is two people, you and I, programming together. Sounds familiar! He is describing the pair programming.

He goes on to mention that the second-best programming team is, everybody fits into a single room. All other variants are bad. Do I hear co-location here?

There you have it! Even Google CEO is promoting pair programming and co-location.

Lessons from the battle front..

I recently presented at Annual Scrum gathering in Chicago, IL on April 14, 2008 on this topic. In this presentation we discussed opportunities and challenges of corporate roll out of Agile and Scrum. I am happy to inform that the presentation was a great success. There was lot of interaction from the participants during our presentation. This (participant interaction) is always a a good sign! I also got to meet well-known players in the Scrum landscape as well. All in all, it was very rewarding experience.

Click here to access our presentation material posted on Scrum Alliance website.

Please don't hesitate to contact me if I can be of any further help.
Thanks.

Field of View..

Field of View is defined as the angular extent of the observable world that isseen at any givenmoment.

As we all know, in Agile, planning is a continuous process. We do not believe in big planning upfront; rather planning is a continuous process and we do planning at different layers, at different stages in the life of a project. Mike Cohn refers to these multi-layer planning as Planning Onion.

At different layers of this Planning Onion, the project team focuses on varying level of details at different stages of project.

At the inner most layer, the daily planning, team focuses on the particular day (What am I planning to do today? Are there any impediments?). So, at the inner most layer, we can say that our field of view is just that particular day, we focus on one day and thats about it.

The next layer is Sprint planning, often refered to as Iteration planning. The team is now expanding the full of view and now focusing on one iteration. Team's field of view is expanding from one day to couple of weeks (depending upon the length of the iteration.)

So as we move from the inner most layer to outer layers, the field of view is expanding. As you get to the inner layer the details become more and more clear.

If I put a flashlight in front of this planning onion, you will see that the light is brightest near the flash light at the inner most layers, and as we go the outer most layer the light becomes more and more dim, the details become hazy. So, with this flash light, you would still be able to see (kind of) the road map if you were looking far ahead but at the same time it would not give you lot of details.

Migrating from Rails to Grails

I have been developing with Java for over 10 years and over the last couple of years got interested in Ruby and Rails. I have developed a few Rails applications mostly for personal use and use Ruby extensively on the job for utilities that I used write in Perl.

So I am a huge fan of Ruby and Rails, and then along came Grails. Grails is an implementation of Rails written in Groovy. Derived from Java syntax, Groovy is easy for Java developers to pick up. In addition, Grails uses familiar Java frameworks under the covers, most notably Spring and Hibernate. Recently SpringSource acquired G2one, the company behind Grails and some interesting work has been happening to integrate Grails and Spring integration. Reading the Grails documents and various posts, it was clear to me that Grails down-plays its Rails heritage. I expected some significant differences so I thought it would be interesting to port a Rails application to Grails.

I started with the Rails tutorial which guides you through a simple blog application. I used Mysql 5 for the database and got it up and running in no time. The application allows you to post blog entries and comments on the entries. Two tables are created, posts and comments. Of course there is a one-to-many relationship, so a post has many comments and a comment belongs to a post.

I basically wanted to retain the existing database tables and create the application with Grails. In the process, I discovered some of the key differences between these two frameworks.

The first step is to install Grails. It’s best to stick with the stable release. Being adventurous, I decided to check out the latest code from the svn trunk and build it myself. This is currently version 1.0.5. The latest stable version is 1.0.4. There is also a 1.1 beta release. Version 1.0.5, and 1.1 beta are buggy and caused some problems with object relational mapping. I eventually resigned myself to using 1.0.4, and everything worked as expected.

To create the blog application, type
grails create-app blog
This is analogous to the rails command. It creates the directory structure for your application and sets up a default configuration.

Next, configure the data source for Mysql. Edit grails-app/conf/Datasource.groovy, so that it looks something like this (changes are bolded):


dataSource
{
  pooled = true
  driverClassName = "com.mysql.jdbc.Driver"
  username = "root"
  password = "mysql"
  dialect = "org.hibernate.dialect.MySQL5Dialect"
}


hibernate {
  cache.use_second_level_cache=true
  cache.use_query_cache=true
  cache.provider_class=
'com.opensymphony.oscache.hibernate.OSCacheProvider'
}
// environment specific settings
environments {
    development {
      dataSource {
      //dbCreate = "create-drop"
        url = "jdbc:mysql://localhost/blog_development"
      }
    }
    test {
      dataSource {
        //dbCreate = "update"
        url = "jdbc:mysql://localhost/blog_test"
      }
    }
    production {
      dataSource {
      //dbCreate = "update"
      url = "jdbc:mysql://localhost/blog_production"
    }
  }
}

Note that like Rails, Grails provides development, test, and production environments. This configuration provides access to the Mysql database I created with Rails. Note the dbCreate property is commented out. The default behavior for the development environment is to drop and re-create the tables every time you run Grails. In this case, I want to retain the schema and the existing data. Removing this property prevents Grails from destroying the database.

Next, you need to provide the declared driver class. This is the standard JDBC driver for Mysql in this case and is provided in mysql-connector-java-5.0.8-bin.jar, for example. Install this in the application lib directory.

Now, create the domain classes. These are somewhat analogous to the Rails model (ActiveRecord) classes. Grails provides Grails ORM (GORM) which uses Hibernate under the covers. GORM provides some nice features, and a nice DSL, but is somewhat incompatible with Rails in its “convention over configuration.” Key differences include:

No pluralization of table names
Automatic record versioning for optimistic locking
No timestamping records by default. Timestamping uses different field names by default
DB column names with underscores are converted to camelCase field names by default

So after some experimentation, the Rails compatible domain classes, providing the same features as in the Rails tutorial , are


class Post {
  String title
  String name
  String content
  Date lastUpdated
  Date dateCreated


  static constraints = {
    title(minSize:5, blank:false)
    name(blank:false)
  }
  static hasMany = [ comments : Comment]


  static mapping  = {
    version false
    table  'posts'
    columns {
      content type : 'text'
      lastUpdated column:'updated_at'
      dateCreated column:'created_at'
    }
  }
}


class Comment {
  String commenter
  String body
  Date lastUpdated
  Date dateCreated


  static mapping  = {
    version false
    table   'comments'


    columns {
      body type: 'text'
      lastUpdated column:'updated_at'
      dateCreated column:'created_at'
    }
  }


  static belongsTo = [post: Post]
}

Notice the boilerplate code required here. The timestamp fields are Grails defaults and will be automatically updated as appropriate. Unlike, Rails, they must be explicitly declared and mapped to the Rails conventional column names.

Versioning is turned off, as the tables do not include version columns. (I am a big fan of optimistic locking, but this is KISS). The constraints closure in the Post class demonstrates how field validation is done in Grails, similar to the Rails tutorial.

I struggled for a while attempting to refactor this code into a base class. I eventually gave up. GORM provides some conventions around mapping inherited domain classes. Also, I couldn’t figure out how to get the mapping closure to execute the base class mapping. It is likely due to my lack of Groovy and GORM expertise, so I suspect there is an easy way to do this.

From this point, it is fairly straight forward. Execute the commands:
grails generate-all post
grails generate-all comment

to generate the controller and view scaffolding code. Then
grails run-app
and you should be good to go.

As a final step, Grails scaffolding creates inputs for dateCreated and lastUpdated. This also behaves differently then Rails. So I went in and edited the view pages, e.g., grails-app/views/post/create.gsp and removed the date fields.

The blog application on Rails



The blog application on Grails



The Return of Domain Specific Languages

Domain Specific Languages (DSL) are among the hottest new trends in computer science.  A DSL is a programming language designed for a specific problem domain.  This topic is getting a lot of attention these days because a DSL can greatly simplify programming by providing semantics that more naturally express automated solutions for the associated domain. A DSL can be thought of as a domain-specific 4GL, much easier to program in than a general purpose programming language, or 3GL, such as Java, C++, etc.   But is this really a new idea?
In the late 1950s, when computing was in its infancy, DSLs were actually state of the art. In 1957, my father, the late William Joseph Turanski and his colleage, Anatol W. Holt, were employed at the Univac Applications Research Center of the Remington Rand Univac division of the Sperry Rand Corporation (now Unisys).  Their primary focus was the development of a Generalized Programming (GP) system (renamed FLEXIMATIC by the marketing dudes).  This was basically the first general high level language compiler.  Being a completely new field, computer scientists were still trying to devise basic “naming aids” such as symbolic addressing, mnemonic devices, and convenient notations, that could be efficiently parsed by a computer and correctly mapped to computer instructions.  However, compilers for specific types of computing problems were commonplace.
Holt describes the situation in General Purpose Programming Systems, a technical report he authored, dated October 30, 1957, based on a talk given before the ACM in Houston, in June 1957 (I own a hard copy).  In reference to GP, he states:
General Purpose Programming Systems by Anatol W. Holt October 30, 1957
“The system differs from other compilers,…, in that it aims to provide the programmer with a set of services equally applicable to the solution of any problem – services, in other words, which are claimed to be altogether “general purpose”.  Therefore the system contains no special design features which make it better adapted to one area of computation than another.”
One can infer from this, that designing a general purpose language was a very challenging proposition.  Similar to developing a general solution in mathematics or science, you first start with specific working examples and try to determine what they have in common to arrive at a generalization.  Such was the state of computing in 1950s.  There were specific language compilers developed for commercial use in various mathematics and business domains, but the general solution was still being worked out.   Holt describes the state of the art:
“In the development of most compiling systems, the designers begin with a special range of problems for which they intend their systems to be useful.  They invent special notations which they consider naturally adapted to the area of problems in question, and they construct a translating mechanism with just enough generality to cope with these notations.”
This is a pretty fair description of a modern DSL.  But of course this model didn’t scale very well.  As Holt observes,
“While…special notation for a given area of problems… may be very useful and important…, the ability to add arbitrary, new notation is even more important than any given set of special notations. … we cannot even hope…to subdivide the entire universe of problems into fixed areas, each with a well-adapted notation.  For example, if I have devised on notation satisfactory for business problems and another notation satisfactory for algebra,  I am still unable to write convenient coding for problems which…involve a lot of data handling and algebraic computation.”
William Turanski and Anatol Holt at the Univac 1, circa 1957

In the conclusion, Holt writes:
“In summary, …I claim that it is possible to construct a general purpose compiler…The theoretical foundations for such compiling systems are now being developed at Remington Rand.  Early examples, such as GP for UNIVAC 1, demonstrate the practical utility of a system designed from this point of view.”
The rest is history. Sadly my father died as a result of an automobile accident while en route to the Algol 60 conference in Paris.  Algol was of course a forerunner to modern languages such as C and Java.  I’m sure, if alive today, he would have appreciated that the wheel has once again come full circle.
       


Dependency Injection Explained in 2 Minutes
Bad - MyBar is tightly coupled to MyFoo
public class MyFoo{    public void someMethod() {         ...    }}public class MyBar {    private MyFoo foo = new MyFoo;}
Good - MyBar refers to the interface Foo; to change to a different implementation you only have to change where MyFoo is instantiated.
public interface Foo{    public void someMethod();}public class MyFoo implements Foo{    public void someMethod() {         ...    }}public class MyBar {    private Foo foo = new MyFoo();}
Better - MyBar refers to interface Foo and gets the implementation by calling a factory; the factory decides which implementation of Foo to return.
public interface Foo{    public void someMethod();}public class MyFoo implements Foo{    public void someMethod() {         ...    }}public class MyFooFactory {    public static Foo getInstance() {        return new MyFoo();    }}public class MyBar {    private Foo foo = FooFactory.getInstance();}
The getInstance() method can take, say, a Properties parameter so the client can supply attributes about what kind of Foo he wants.
Best - MyBar refers to interface Foo and has no direct involvement as to exactly which implementation of Foo is supplied; the instance is “injected” into MyBar; in this case, in the constructor.
public interface Foo{    public void someMethod();}public class MyFoo implements Foo{    public void someMethod() {         ...    }}public class MyBar {    private Foo foo;    public MyBar(Foo foo) {        this.foo = foo;    }}
I clearly have a bias, but the Spring Framework provides an excellent method for injecting dependencies.


MSI K9N2 SLI Platinum / AMD Phenom 9600 x4 0×0000007e Stop
More details to follow, but here are the cliff notes… 
After moving WinXP disk to this platform, received the dreaded 0×7e stop on boot; google pointed me to a problem with intelpmp.dll, but this wasn’t my (initial) problem; I couldn’t even boot from the XP install disk which is not tailored for Intel.
Turned out a mobo bios flash (3.3 -> 3.5) did the trick (also had to remove the intelpmp.dll because the install came from an Intel box).
Hope this helps someone.
Will fill in the details later.


The Customer Comes First (Back to the Future?)
It is nearly 30 years since I graduated as an industrial engineer; back then, as the “new kid on the block”, I was given the assignment of being the liason to the IT (then called Data Processing) department. Yes, I’m an old fart and, yes, we had punched cards back then.
I simply freaked when I found that even the simplest request (add a subtotal on a report, change a report sort etc) took 6 to 8 weeks to happen. So, I figured out on my own how to do ad-hoc reports; if folks in the IE dept. needed a new report, they had it on their desk in a couple of hours. I put a few noses out of joint but this was the start of my transition into IT.
Sure, more complex stuff takes a while but often something simple that can be implemented quickly can provide huge business impact.
Roll forward 30 years; after a short stint at that company and 25+ years in product development for one of the BUNCH, I have spent the last few years consulting in Java and related technologies.
My observation is that not a lot has changed; many IT departments are still considered to be laws unto themselves. With all our technology and cool stuff, we still need to understand that we are there to support the business. If one of our internal (or external) clients needs something that is easy to provide, just do it. It will pay off in spades; the next time something is hard to do, and will take time, they will understand; if it’s easy and you take care of it quickly, the kudos will flow. Often times, something that is easy to us seems hugely complex to clients (of course, the opposite is the case too but, again, if you help them out most of the time, they’ll believe you when you say something is hard to do).
This all might seem obvious, but I fear that too many lose sight. All I can say is that this philosophy has worked well for me over the years.
Moving forward…
Satisfying the customer gives one a good feeling, but that alone is not enough. What gets me out of bed in the morning is the sure fact that I know I’ll learn something more today.
As time goes by, I hope to use this blog to share some of the more interesting things that I learn.
Gary


Proxying Your Stubs Can Save Space and Time
Setting aside the discussion of stubs Vs. mocks in JUnit testing (that is covered more than adequately elsewhere), let’s say you’ve decided to use stubs, for whatever reason.
Please understand that the simple examples in this article may be more appropriately handled with mocks; they are for illustrative purposes only
Now, let’s say your class under test (CUT) uses a data access object (DAO) that has many methods, but it only needs one or two of those methods. The problem with a stubbed interface is you have to provide implementations of all the methods on the interface. Sure, modern IDEs such as eclipse can do the grunt work and generate all the method shells for you, with you being left to implement just the method(s) you need. However, especially with large stubbed interfaces, you can end up with a large amount of boilerplate code that can easily add up to 90%+ of the LoC in your test case.
This article discusses how to use dynamic proxies to eliminate this problem.
The technique allows you to create a class that implements just those methods you expect your CUT to use.
The examples below use JDK 1.4 syntax; at the end of the article, I provide the full project files in both JDK 5 and 1.4 versions, where the JDK 5 uses the strong typing provided by generics.
Onward…
First, declare the stub wrapper that creates the proxy; I prefer to make this a nested class within the test case so that I can invoke JUnit methods to make tests fail gracefully.
public class MyTest extends TestCase {//...    private static class StubWrapper implements InvocationHandler {        private Object wrappedStub;        private Class clazz;        public StubWrapper(Object wrappedStub) {            super();            this.wrappedStub = wrappedStub;            this.clazz = wrappedStub.getClass();        }        public Object invoke(Object proxy, Method method, Object[] args)                throws Throwable {            try {                return clazz.getMethod(method.getName(),                        method.getParameterTypes()).invoke(wrappedStub, args);            } catch (Throwable t) {                t.printStackTrace();                fail("Stub method invocation failed");                return null;            }        }        public static Object wrap(Class type, Object stub) {            return Proxy.newProxyInstance(StubWrapper.class                    .getClassLoader(), new Class[] { type }, new StubWrapper(                    stub));        }    }}
The static method at line 25 creates a new instance of our proxy; the caller passes the interface in the parameter type and an instance of the class that implements the desired method(s) in parameter stub; the method uses the JDK Proxy mechanism to create the proxied stub. Note that we pass in a new instance of the StubWrapper, which has a reference to user supplied implementation instance. 
The invoke method at line 13 is called when the CUT calls a method on the interface. This method is called by the proxy, passing in the proxy instance, the method that was invoked and a list of the arguments that were passed in. It simply delegates (via reflection) the method call to the wrapped stub, with an identical method name and parameter type list.
Note: if the method has not been implemented, we invoke the JUnit fail() method with an appropriate diagnostic.This is an added benefit of the technique. WIth the classic stub technique, if another developer adds a call to another method (in the CUT) there is nothing to force him or her to fill out the stub and the test may continue to pass even though no such implementation is provided. With this technique, the JUnit is sure to fail in such a circumstance.
Now we implement the stub itself…
public class MyTest extends TestCase {//...    private boolean daoCalled;//...    // no need to implement the interface; we get here via a proxy    private class StubDAO{        public Collection findSomeStuff() {            daoCalled = true;            MyVO vo = new MyVO();            vo.setSomeAttribute("someValue");            ArrayList l = new ArrayList();            l.add(vo);            return l;        }    }//...}
This is a simple test case that returns a list of value objects. Note that we set a boolean so we can assert later that the stub was called.

Instantiate the stub…
public class MyTest extends TestCase {    private MyDAO stubDAO = (MyDAO) StubWrapper.wrap(MyDAO.class, new StubDAO());//...}
See how we simply invoke the StubWrapper.wrap method to obtain our proxy that implements the MyDAO interface.
The cast to (MyDAO) is not needed in the JDK 5 version because the wrap method is strongly typed to return an instance of the class passed in as the type parameter.
Finally, we implement the test…
public class MyTest extends TestCase {    private MyDAO stubDAO = (MyDAO) StubWrapper.wrap(MyDAO.class, new StubDAO());    private boolean daoCalled;    public void testMyClassUnderTest() {        CUT cut = new CUT();        cut.setDao(stubDAO);        cut.doSomething();        assertTrue("Expected DAO call", daoCalled);    }//..}
We instantiate the CUT, inject the stub, call some method on the CUT (which calls the stub) and assert that the stub was called.
Putting it all together…
package net.gprussell.test;import java.lang.reflect.InvocationHandler;import java.lang.reflect.Method;import java.lang.reflect.Proxy;import java.util.ArrayList;import java.util.Collection;import junit.framework.TestCase;import net.gprussell.CUT;import net.gprussell.MyDAO;import net.gprussell.MyVO;public class MyTest extends TestCase {    private MyDAO stubDAO = (MyDAO) StubWrapper.wrap(MyDAO.class, new StubDAO());    private boolean daoCalled;    public void testMyClassUnderTest() {        CUT cut = new CUT();        cut.setDao(stubDAO);        cut.doSomething();        assertTrue("Expected DAO call", daoCalled);    }    // no need to implement the interface; we get here via a proxy    private class StubDAO{        public Collection findSomeStuff() {            daoCalled = true;            MyVO vo = new MyVO();            vo.setSomeAttribute("someValue");            ArrayList l = new ArrayList();            l.add(vo);            return l;        }    }    private static class StubWrapper implements InvocationHandler {        private Object wrappedStub;        private Class clazz;        public StubWrapper(Object wrappedStub) {            super();            this.wrappedStub = wrappedStub;            this.clazz = wrappedStub.getClass();        }        public Object invoke(Object proxy, Method method, Object[] args)                throws Throwable {            try {                return clazz.getMethod(method.getName(),                        method.getParameterTypes()).invoke(wrappedStub, args);            } catch (Throwable t) {                t.printStackTrace();                fail("Stub method invocation failed");                return null;            }        }        public static Object wrap(Class type, Object stub) {            return Proxy.newProxyInstance(StubWrapper.class                    .getClassLoader(), new Class[] { type }, new StubWrapper(                    stub));        }    }}

This zip file contains the JDK 5 version of the above code (eclipse project).
This zip file contains the JDK1.4 version of the code (eclipse project).

Gary
about


Enhanced Code Coverage for Finite State Machines
I was recently engaged to help debug and fix some code that was implemented as a Finite State Machine (FSM). There were no existing JUnit tests for the code, so I set about to write some. However, as one would expect with such an architecture, simple code coverage is not enough to verify that all the state transitions are exercised. Indeed, I had 100% code coverage with just a handful of tests, even though there were several hundred valid state transitions. (This was verified with the excellent EMMA based eclipse plugin - www.eclemma.org). 
For those unfamiliar with this tool, it lights up your code in green and red showing executed/unexecuted lines; it also has some excellent reporting facilities.
I used a technique similar to the following to verify that I had covered all the allowable transitions.
In a future article (if there is sufficient interest), I will show how I used Apache POI to drive the JUnit from an Excel spreadsheet so I could solicit help from the user community to create all the test cases and their expected results. Please add a comment (or email me) if you would like to see an article on spreadsheet driven testing.
Using these two techniques, I quickly identified a number of issues which were corrected, resulting in another happy customer.
The following is a drastic simplification but, hopefully, it illustrates the technique.
Given the following simple state machine implementation…
package net.gprussell;import java.util.HashMap;import java.util.Map;public class State {public static String STATE1 = "S1";public static String STATE2 = "S2";public static String STATE3 = "S3";public static String STATE4 = "S4";public static String TRANSITION1 = "T1";public static String TRANSITION2 = "T2";public static String TRANSITION3 = "T3";public static String TRANSITION4 = "T4";/* * Valid transitions *       S1 -> S2 *       S1 -> S3 *       S2 -> S3 *       S3 -> S4 */static Map<String , String> allowed;static {allowed = new HashMap<String , String>();allowed.put(STATE1 + TRANSITION1, STATE2);allowed.put(STATE1 + TRANSITION2, STATE3);allowed.put(STATE2 + TRANSITION3, STATE3);allowed.put(STATE3 + TRANSITION4, STATE4);}private String currentState;public State() {this.currentState = STATE1;}public State transition(String transition) {String newState = allowed.get(this.getCurrentState() + transition);if (newState == null)throw new RuntimeException("Invalid transition from " +this.getCurrentState() + " with transition " + transition);this.setCurrentState(newState);return this;}public String getCurrentState() {return currentState;}public void setCurrentState(String currentState) {this.currentState = currentState;}}
It can be shown that the following test case executes 100% of the code.
package net.gprussell;import junit.framework.TestCase;public class NotGoodEnoughTest extends TestCase {public void testGoodTransition() {State state = new State();assertEquals(State.STATE2, state.transition(State.TRANSITION1).getCurrentState());}public void testBadTransition() {State state = new State();try {state.transition(State.TRANSITION4).getCurrentState();fail("Expected exception");} catch (RuntimeException e) {assertTrue(e.getMessage().startsWith("Invalid transition"));}}}
Here is the EMMA report for this test. 
However, we clearly have not exercised all the allowed state transitions.
The following test case ensures that all transitions are executed.
package net.gprussell;import java.util.HashSet;import java.util.Set;import junit.framework.TestCase;public class FullCoverage extends TestCase {private static Set<String> coverage;protected void setUp() throws Exception {if (coverage == null) {coverage = new HashSet<String>();for (String s : State.allowed.keySet())coverage.add(s);}}private State testing(State state, String trans, String newState) {coverage.remove(state.getCurrentState() + trans);state = state.transition(trans);assertEquals(newState, state.getCurrentState());return state;}public void testGoodPath1() {State state = new State();state = testing(state, State.TRANSITION1, State.STATE2);state = testing(state, State.TRANSITION3, State.STATE3);state = testing(state, State.TRANSITION4, State.STATE4);}public void testGoodPath2() {State state = new State();state = testing(state, State.TRANSITION2, State.STATE3);state = testing(state, State.TRANSITION4, State.STATE4);}public void testBadTransition() {State state = new State();try {state.transition(State.TRANSITION4).getCurrentState();fail("Expected exception");} catch (RuntimeException e) {assertTrue(e.getMessage().startsWith("Invalid transition"));}}// final test - ensure we covered all transitionspublic void testCoverage() {if (coverage.size() > 0) {for (String s : coverage) {System.out.println(s);}}assertEquals("Not all transitions covered", 0, coverage.size());}}
First, before we execute any tests, we add all the allowable state transitions to a set. As each test is executed, it is removed from the set. At the end, we verify that the set is empty, ensuring that all allowable transitions have been exercised.
Simple, but effective.
Conclusion
It is important to realize that simple code coverage verification is not sufficient in many cases. While it is good to strive for 100% coverage, sometimes even that is not enough and we need to go a step further.
Gary
about


Hotfix Out For SharePoint 2010 On Windows 2008 Server R2



Ringin' In The New Year, MVP Style



SharePoint 2010 Links Dropping, But...*UPDATE*



SharePoint Geeks Descend On Las Vegas!



SharePoint 2010 and PowerPoint Themes



Speaking at SharePoint Saturday - Philly!



SPC09 Day 1 Highlights



SharePoint Server 2010 Beta Server Farm Installation: Go!



SharePoint Saturday - Philly Was a Huge Success!



SPC09 Day 2 Highlights



Underdocumented SQL Server mail parameter
Due to popular demand, Microsoft added the @query_result_no_padding to the sp_send_dbmail stored procedure.

Sadly, you wont find this in the online help. It was added as part of a Service Pack.

Use this parameter to trim excess spaces from the query results attached to the email. Otherwise, the column output pads out to the length of the char OR varchar field.

For example:
declare @t TABLE (field varchar(10))

insert into @t
select 'hello'

When sent with @query_result_no_padding = 1
the result is:


field
-----
hello


otherwise


field
----------
hello



Test Window
<root>
 <users>
  <user>Joe</user> 
  <user>Willie</user>
 </users> 
</root>





Results Here



Selecting XPath Nodes
To select a range of nodes based on their position, use the really cool position() function.

Using the code example below, this syntax will get the first two nodes:

var nodeList = xmlDoc.selectNodes("/root/items/item[position()<3]");


XPath Basics
When querying an XML Document with XPath syntax, there are two things you need to identify; the node(s) you want to return and the criteria that determines which nodes qualify.

In this XML document:

<root>
   <items>
      <item>One</items>
      <item>Two</items>
      <item>Three</items>
   </items>
</root>


To get the item nodes using MSXML
var nodeList = xmlDoc.selectNodes("/root/items/item");

To apply selection conditions, add brackets:
var nodeList = xmlDoc.selectNodes("/root/items/item[.='One']");

The "." in the brackets means "this node". So in plain English you're saying, "Give me all the item nodes where the value is "One".

You can also select nodes based on the values of child or parent nodes.

Let's make the simple example above a little more complicated:


<root>
   <items>
      <item>One</item>
         <type>Odd Number</type>
      <item>Two</item>
         <type>Even Number</type>         
      <item>Three</item>
         <type>Odd Number</type>
   </items>
</root>


To get all the nodes which have a type value of "Odd Number" you would use this syntax:

var nodeList = xmlDoc.selectNodes("/root/items/item[./type='Odd Number']");

Notice here that the select path still goes to the item level. However, the query references the type node. The XPath path symbols are nearly identical to directory structure navigation syntax. 

/ = levels
. = current node
.. = parent node
./ = child of the current node


Decode HTML Strings in SQL Server
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO

-- EXEC UrlDecode '%c3%a1'
-- EXEC UrlDecode '\\Tul1ciprmw1\RichMediaAssets\Open\Telemundo\Al Rojo Vivo con Mar%c3%ada Celeste\_derived_jpg_q90_172x128_m1\3ARValx05Mar%c3%ada Celeste Arrar%c3%a1s.jpg'
-- EXEC UrlDecode '%4D'

ALTER PROCEDURE UrlDecode 
 -- Add the parameters for the stored procedure here
 @URL varchar(2000)
AS
BEGIN
 -- SET NOCOUNT ON added to prevent extra result sets from
 -- interfering with SELECT statements.
 SET NOCOUNT ON;

 DECLARE @Position INT,
  @Base CHAR(16),
  @High TINYINT,
  @Low TINYINT,
  @NewHigh INT,
  @Pattern CHAR(21)

 SELECT @Base = '0123456789abcdef',
  @Pattern = '%[%][0-9a-f][0-9a-f]%',
  @Position = PATINDEX(@Pattern, @URL)

 SELECT @High = CHARINDEX(SUBSTRING(@URL, @Position + 1, 1), @Base) -1,
   @Low = CHARINDEX(SUBSTRING(@URL, @Position + 2, 1), @Base) -1

 WHILE @Position > 0
 BEGIN  

   IF (@High & 15) = 12 -- xC0 
   BEGIN  
    SELECT @NewHigh = @Low * POWER(2, 6) --Shift Low 6 bits
    
    SELECT @High = CHARINDEX(SUBSTRING(@URL, @Position + 4, 1), @Base) -1
    SELECT @Low = CHARINDEX(SUBSTRING(@URL, @Position + 5, 1), @Base) -1

    SELECT @URL = STUFF(@URL, @Position, 6, CHAR(@NewHigh | (16 * @High) | @Low))

    SELECT @High = 0, @Low = 0, @NewHigh = 0  

   END
   ELSE
   BEGIN 
    SELECT @URL = STUFF(@URL, @Position, 3, CHAR(16 * @High | @Low))

   END      
   
   SELECT @Position = PATINDEX(@Pattern, @URL)
   IF @Position > 0
   BEGIN
    SELECT @High = CHARINDEX(SUBSTRING(@URL, @Position + 1, 1), @Base) -1,
      @Low = CHARINDEX(SUBSTRING(@URL, @Position + 2, 1), @Base) -1
   END
 END

 SELECT @URL

END
GO


ActionScript for .NET Programmers
NOTE: These notes are based on my development efforts with Flash. If there are any incorrect statements, please let me know in the comments. Thank you.

DEBUGGER

The debugger is not tightly integrated into the IDE. It is a separate tool that you must invoke by selecting Control > Debug.

Once invoked, the project is in a paused state. Select Continue to debug.

Breakpoints are only allowed in the Actions window of the .fla file. You cannot set breakpoints in classes you've created.

The trace() method will become your best friend as the watches do not evaluate complex values like object.items[i]. Also, there is no Immediate window for interacting with the code.

CLASSES

ActionScript 2.0 supports classes in the traditional sense as objects with private and public members, inheritance and defined members. Earlier versions of ActionScript also support malleable objects similar to those defined in JavaScript. Those objects can have properties and methods stuck onto them at run time.

MovieClips are the base object similar to WinForms. Flash supports a form-based model of programming using components derived from MovieClips. This component of this type: mx.screens.Form.

Think of a form as a one frame movie clip.

Note that the forms appear to be inaccessible from code stored in class modules (.as) files. I have found that passing in the form reference to a private member gets the trick done.

PROGRAMMING MODEL

All server interactions are handled asynchronously using callbacks similar to Delegates.

XML

The XML object in ActionScript 2.0 is far less rich than the XMLDOM COM object or the  .NET XmlDocument objects.

There is no select nodes or XPATH support for the nodes. Rather, every element, including a node's text is considered a node.

Iteration is done through arrays generated by the childNodes property.

If a node is XML, its nodeType property is 1, and the available propery is nodeName. If the nodeType property is 3, then it is a text node and the nodeValue property is used. Note that the nodeValue is not available to nodes of type XML.


Querying Table Definitions
A query to return metadata about a table. This is useful for dynamic query building like in a SqlAdapter, for example.



SELECT C.COLUMN_NAME,
       C.DATA_TYPE,
       C.CHARACTER_MAXIMUM_LENGTH,
       CASE WHEN PK.CONSTRAINT_NAME IS NULL THEN 0 ELSE 1 END IS_KEY,
       CASE WHEN IC.object_id IS NULL THEN 0 ELSE 1 END IS_IDENTITY
FROM INFORMATION_SCHEMA.COLUMNS C
       LEFT OUTER JOIN
INFORMATION_SCHEMA.KEY_COLUMN_USAGE PK ON C.TABLE_NAME = PK.TABLE_NAME
                                      AND C.COLUMN_NAME = PK.COLUMN_NAME
       INNER JOIN
sys.tables T ON C.TABLE_NAME = T.name
            AND T.[type] = 'U'
       LEFT OUTER JOIN
sys.identity_columns IC ON T.object_id = IC.object_id
                       AND IC.[name] = C.COLUMN_NAME
WHERE C.TABLE_NAME = @TableName


Using CTE (Common Table Expression)
To create a collection of rows without querying a table or a repeating series of INSERT statements.

declare @seed int
select @seed = 8;

WITH RecurseTable(Id)
AS
(
    SELECT @seed

    UNION ALL

    SELECT R.Id -1
    FROM RecurseTable R
    WHERE R.Id > 1
)

select * 
from RecurseTable


Efficiently Rounding a SQL Server datetime
Truncates hours, minutes and seconds without messy string manipulation:

CAST(FLOOR(CAST(GETDATE() AS DECIMAL(8,2))) AS datetime)



Revisiting Requirements Management
The number one job of the Architect in an IT project is to manage requirements. The Architect is in the only position within the enterprise to look deep enough into the business and deep enough into the technology to understand the translation of the requirements between the two. It is the Architect who is on the front-lines of business-IT alignment, and people should look no further when IT seems "out of touch" with the business.
A requirement, in its simplest form is the codification of a business need. In this regard, requirements should trace naturally to the goals of a business and the metrics that the business uses to track their performance against those goals. Business goals and performance metrics should trace directly to the business plan - which is the embodiment of the business strategy.

Requirements management, the domain of an Architect, is about managing the full life-cycle of a requirement; ensuring that the business value (goals & metrics) traced to that requirement is both:
effectively captured during requirements analysis and
efficiently delivered by the technology traced to that requirement.
In this way, all technology and associated investment should trace naturally to business value.

Therefore, the first half of an effective requirements analysis process is for the Architect to ensure that this traceability to the business plan is well-defined, and that the business context associated with the requirement is clear to IT. Architects are on the front-line of IT strategy and planning, and it is their responsibility to challenge and guide their business counterparts in applying the same rigor to the business strategy and planning process as they apply to the technology strategy and planning process.

The second half of the requirements analysis process is for the Architect to ensure that the traceability to the technology plan is well defined, and that the IT context associated with the requirement is clear to the business. The IT context associated with a requirement can be broken down into three main areas:
the expected impact of the requirement on the enterprise architecture,
the planning input for the project required to deliver it, and
the expected impact on IT operations to support it once it has been delivered.
The impact of a requirement (or set of requirements) on the enterprise architecture should be captured across three main enterprise technology views: the software architecture, the server(or hardware) architecture, and the network architecture.In order to properly trace a requirement from business to one of these technology views, the original requirement needs to be "refined". The process of requirements refinement is a meticulous one, that requires all of the skill of an experienced Architect. Refining requirements involves deriving new, more detailed requirements from the base requirement that are specific to the technology view being considered. This process should not add or remove from the scope of the original requirement nor otherwise alter the original requirement. The motivations, assumptions, and constraints considered while deriving a software, hardware, or network requirement from a business requirement should be well-documented by the Architect. This documentation serves as a feedback mechanism from the Architects to their business counterparts on their interpretation of the original requirement. Requirements refinement and associated documentation serves as the basis for involving the business in technology decisions by providing transparency to the IT strategy and planning process.

Planning input should include the basis of estimate that drives the variable costs, any required fixed costs, and any notable risks associated with delivering therequirement (or set of requirements). The first half of the basis of estimate should be a quantifiable metric (other than hours) that drives effort. Some examples of quantifiable metrics include the number of expected users, a number of screens to be developed, or the number of entities in the data model. The second half of the basis of estimate should bean estimate of hours, by resource type, associated with delivering the requirement across that metric. For example, it may be estimated that it will take 6 hours of a DBA, 1 hour of a business analyst, and 1 hour of a project manager to implement the necessary physical database objects associated with a single entity. This information can then be easily used to generate the necessary staffing plan for a project to deliver the set of requirements being planned, which would smooth the consolidated effort estimate for each resource type across a set of requirements over the full timeline of the project being planned to deliver those requirements and associate a cost per hour for that resource type to determine the cost for that effort within the scope of that project. Fixed costs from subcontractors or vendors that will be providing specific services and / or products needed in the delivery of a requirement should also be included in the planning input for each requirement. Finally, any risks known at the time of planning associated with delivering the requirement should be well-documented. Included in the risk documentation should be a probability that the risk will be realized and its potential impact on project cost, time, and / or quality.

Lastly in the IT requirements analysis process should be the development or modification of a concept of operations for the requirement (or set of requirements) to be delivered. This concept of operations should include any on-going monitoring, management, or administrative activities required to operate the new software, hardware, and or network components delivered while fulfilling the requirement. Like project planning input, the concept of operations would document the basis of estimate for any ongoing variable costs, any regular fixed costs and their timing interval, and any risks associated with operations in support of the components being delivered to meet this requirement (or set of requirements).

Once proper analysis has been done for a requirement, an Architect's job is not over. It is the responsibility of the Architect to monitor the delivery and ongoing operations of each requirement for variances to plan. Variances in cost and time (efficiency) during delivery or operations, including the realization of risk, should be analyzed by the Architect to determine if they are one-time or systemic in nature. Systemic variances in IT efficiency discovered over time should be re-factored back into the requirements analysis output with proper change management controls in place to notify interested business and IT stakeholders. Finally, it is the Architect's responsibility to periodically review the business goals and performance metrics that each requirement is tied to to ensure that expected business value has been delivered by IT. Variances in delivering expected business value (effectiveness) should also be analyzed by the Architect to determine if they are one-time or systemic in nature. Systemic variances in IT effectiveness discovered over time should be re-factored back into the IT strategy and planning process with proper change management controls in place to notify interested business and IT stakeholders.

Architecture today often has the misconception by business and IT stakeholders as being a project-based activity. However; true requirements management, which is at the heart of all modern architecture, involves the regular monitoring and course-correcting (governance) of the business-IT alignment. Requirements management defines architecture as an on-going relationship activity between business and IT; one that should not be confined to the delivery of specific IT projects.



ReFactoring Enterprise Architecture
I was listening to David Linthicum's podcast from last week (http://akamai.infoworld.com/weblog/realworldsoa/archives/IFW_SOA_05-12-08.mp3) and got to thinking more about the problem of Re-Factoring Enterprise Architecture. Re-Factoring your Enterprise Architecture is a variant on the Enterprise Modernization angle we have been pursuing within the technology industry for legacy platform customers. The reason Enterprise Modernization is not enough in my mind is that it is only really targeted at customers (like the government) who are still on homogeneous (albeit legacy) platforms and due to personnel training and retention issues want to stay that way [homogenous]. Most commercial customers likely have a highly heterogenous environment or want one to better keep up with the heightened competition within their industry.

Most commercial enterprises would agree that their Enterprise Architecture has organically grown over the years in a similar way to how the Amish sew together a patch-work quilt. This is the problem of "shopping for your EA solution".

On the left-side of the "shopping for an EA" continuum, you have customers that consider themselves early adopters and are willing to try new things to "get an edge" on their competition. [insert your favorite market guru here] tells these customers that they should have a portal, and that Plumtree is one of the best point-solutions out there so they buy that. [insert your favorite market guru here] tells them they should have a framework, and that SilverStream is one of the best point-solutions out there so they buy that. [insert your favorite market guru here] tells them they need an ESB solution, and that Cape Clear is the one of the best point-solutions out there so they buy that. And so on. These folks may be fast out of the gate, but lose momentum over time, due to inefficiences caused by lack of integration along the way and the rapid turnover of products (and vendors) caused by the fickleness of the commodity software industry.

On the right-side of the "shopping for an EA" contiuum, you have customers that consider themselves more conservative and place a high value on staying with a single vendor. These folks are still "shopping for an EA", except that they wait to be told what to buy and when to buy it by IBM or Microsoft. These folks are always dealing with repressed feelings of frustration and doubt caused by their inability to keep up with software market innovation because their chosen vendor isn't getting them there fast enough.

In my opinion, customers at either end of this continuum can be refactored toward a planned Enterprise Architecture, highly customized to their specific needs, that can deal with change in a "systemic" or "repeatable" fashion through the combination of:
the strategic use of Open Source software to get at the core problems within the IT portfolio by either better glueing the pieces together or more rapidly extending the functionality of the monolith (with either approach based on open standards) - making the IT-side of these commercial customers more agile while also providing a forward-looking context for better supporting their engrained spending habits, and
the tactical use of Governance solutions to give the business-side of these commercial customers visibility into the measureable (metrics-driven) progress they are making towards the goals that define their reasons for investing in IT to begin with.
To summarize, I like the "ReFactoring your Enterprise Architecture" angle because it deals with the heterogeneity (or lack thereof) that likely exists in most commercial enterprises while still sending the "we aren't here to change you ... just make you better" message that Enterprise Modernization sends.



Agile SOA - Part III
This is the third and final blog in this series. In Part I, I opened with the thought that the real challenge of SOA is changing the way you look at the IT investment of your business to be more from the perspective of software architecture. In Part II, I discussed that the best approach to software architecture is Agile due to the evolutionary nature of software. In this final installment I'd like to close with how an Agile approach to software architecture - based on thinking of SOA in terms of composite design patterns implemented as part of your application architecture through the use of embedded frameworks will help you better realize the benefit of through an Agile approach.

In the quest for enterprise architecture discipline, many of us are re-creating our futures out of our past by modeling it through a static, black-box approach. If your business' enterprise architecture can only be described in a power-point slide deck, using boxes and connecting lines - then you haven't taken the time to truly understand the collective learning from the previous generation of hardware-centric architects - and are doomed to make the same mistakes they made. SOA makes behavior a first-class design concern, and pushes static representations of architecture to a "behind-the-scenes" supportive role.

A business' enterprise architecture is a living organism, much like the business it supports, and at it's core should be a software architecture - modeled through a dynamic, white-box approach. We should be striving to describe this software architecture through a means closer to a linear, episodic series of video clips. Each episode should demonstrate an encapsulated portion of the system in a white-box manner - demonstrating the scripted pattern in which these components interact (think of a football play being viewed from an overhead camera with primary and optional flows for the different players on the field). Episodes should be linked together in a linear-fashion through the use of rule-based pathing (think of a football game as a composition of individual plays - where the individual plays are woven together with an over-arching strategy that capitalizes on both an individual team's strengths and an opposing team's weaknesses). It is in this way that a business strategy can best be decomposed into a set of composite processes that capitalize on the competitive advantage of a business within an industry full of competitors.

Many of you who are reading this may think that I am just another advocate of a Business Process Management (BPM) middleware-centric approach to SOA. In fact, I am not. Using my analogies above, I believe the Process Manager pattern is a good fit for demonstrating the scripted interaction oflocal components. I emphasize the word local here because I do not believe Process Manager is a good architectural pattern for interactions of distributed components. Hohpe and Woolf describe the Process Manager pattern as follows in their Enterprise Integration Patterns book: "Using a Process Manager results in a so-called hub and spokepattern of message flow." Similar to database architecture, the hub and spoke architecture of a traditional process manager will not scale well horizontally. Horizontal scalability is key to distributed computing, especially within today's cloud hardware architectures.

If you still think that the Process Manager pattern is best for managing the scripted behavior of local components, then you have to take a long, hard look at the BPM middleware at the core of most commercial-off-the-shelf (COTS) vendor SOA suites. BPM middleware today is built around the Web Services Business Process Execution Language (WS-BPEL) standard - which describes a standard way in which many, distributed Web Services can be orchestrated within the context of a single business process. If the Process Manager pattern should not be used for distributed components, then the link between Web Services and today's BPM middleware should come in to question. If the Web Services standard is removed from BPM middleware, then the whole WS-BPEL standard fails as a foundation for implementing the Process Manager pattern, and COTS BPM products in-turn fail as a foundational component of your SOA infrastructure.

As an alternative to BPM middleware, I prefer a lightweight solution, such as the one described in the following InfoQ article by my colleague and friend, Oleg Zhurakousky: Workflow Orchestration Using Spring AOP and AspectJ. This article demonstrates how to build and orchestrate highly configurable and extensible, yet light-weight embedded process flows within your software architecture using Aspect Oriented Programming (AOP) techniques. Oleg's use of Spring AOP, a proxy-based AOP mechanism, to address functional concerns such as instrumenting a process with activities while using Aspect, a byte-code weaving AOP mechanism, to address non-functional concerns such as activity navigation and transition is, in my opinion, the perfect way to implement thescripted interaction oflocalbusiness logiccomponents within the Process Manager pattern.

So if the Process Manager pattern is not the right foundational pattern for your distributed SOA, then what is? I believe the right foundational pattern for your SOA is the Staged Event Driven Architecture (SEDA) patternfirst published by Matt Welsh, et. al., from the Computer Science Division of the University of California, Berkeley in 2001.In SEDA, applications consist of a network of event-driven stages connected by explicit queues. Using my previous football analogy, think of the network as the whole football game, composing a number of event-driven stages which represent the individual play. The network architecture underlying SEDA is intrinsically better at supporting the horizontal scalability demanded by distributed SOA computing.

Within the context of SEDA, a stage is a self-contained application component consisting of an event handler, an incoming event queue, and a thread pool. As described above, that self-contained application component could itself be a compositescripted interaction oflocalapplication components.The introduction of a queue between stages decouples the execution of application components by introducing an explicit control boundary - which allows for their distribution. The SEDA model constrains the execution of a thread to a given stage, as a thread may only pass data across the control boundary by enqueuing an event. Introducing a queue between two modules of an application provides isolation, modularity, and independent load management. Because stages interact through an event-dispatch protocol instead of a traditional API, it is straightforward to interpose proxy stages between components for rules-based pathing, performance profiling, and/or testing & debugging.

One of the best implementations of the SEDA pattern is Spring Integration, described in the following InfoQ article by Joshua Long: Getting Started with Spring Integration. In an answer to the "Why Spring Integration?" question, Joshua says it best with the following quote: "Because Spring Integration is so lightweight (you deploy the Spring Integration server with your application; you don't deploy your application to Spring Integration) and so focused on the development life cycle (XML schemas to facilitate configuration, POJO-friendly APIs, and strong integration with the Spring Framework and JEE), you'll find Spring Integration a better fit than a lot of other ESBs." Spring Integration supports a pluggable transport layer, where a lightweight, highly scalable Message Broker, such as Apache ActiveMQ, can provide support for the network architecture that allows for the horizontal scalability of the Spring Integration solution.

So why all of these tools from SpringSource (Spring Framework, Spring AOP, AspectJ, Spring Integration, and ActiveMQ)? Traditional Enterprise Integration products promote a proprietary development and deployment model that requires a steep, costly organizational learning curve to successfully adopt. In addition, the more successful you are at adopting these development tools and deployment models - the more locked in to those proprietary products you become. The SpringSourcemantra is Eliminating Enterprise Java Complexity. Using their standard Java development tools and deployment models, SOA can be incrementally adopted in a lower risk, more agile way - led by the Java developers and systems analysts you already have using the tools they already know (and love).The end-result of this incremental adoption is simply a re-factored version of your current Java and .NET business applications. Finally, the Spring Framework, which serves as the foundation for all of these tools, ensures both the tight integration and full portability you've come to expect from any SpringSource solution.

As I stated in the very beginningof this series, SOA is an architectural pattern - not an expensive suite of software products. A pattern, by definition, is the encapsulation of a complex, dynamic system into a reusable component. Patterns are meant to describe, through a white-box approach, best practice ways for you to build YOUR solution - they are not meant to be solutions in of themselves. Patterns therefore lend themselves to be best implemented by lightweight, embeddable frameworks thatserve tosupportyour solution,notheavy, commercial-off-the shelf products thataim tocontrolit. The integrated Spring components, backed by the unwavering commitment to simplicity of the SpringSource company, provides you with the Agile SOA solution you need to support the evolutionary nature of your business.



Agile SOA - Part I
Service Oriented Architecture is not an expensive suite of software products as the large software vendors would like to sell you. SOA is an architectural pattern. A pattern is a well-described, proven way of doing something that has evolved out of multiple attempts (successes and failures) across an entire community of professionals. SOA is a best-practice way of constructing an enterprise software architecture to better suit the evolving needs of your business.

The real challenge of adopting SOA is to change the way you and your organization think about enterprise architecture, not to change your information technology infrastructure yet again to continue the cold war-like arm's race against your competitors the software vendors have sold you on (at a great profit to them, I might add).

Why is SOA such a challenge? Simple, because it puts the focus of enterprise architecture on software architecture, not hardware and network architecture. The IT industry is in the midst of handoff between its first generation of infrastructure architects and a new generation of software architects. Businesses, who have come to rely heavily on their architects, are struggling to understand a new sofware-centric view of their technology portfolio. The old days were (somewhat) easy, let the IT guys handle the infrastructure, and we'll handle the business. Investments in technology were relatively simple and straightforward to both understand and manage - and the results were tangible assets that had an expected life and could be depreciated with comfortable precision.

The first generation of architects are extremely good at what they were asked to do - connect hardware through ever-growing and ever-speedier networks. Software, at least the software they intended to run the mission-critical elements of the business on, was considered to be a commodity - just like the hardware and network components they were used to implementing. Their view of software from an enterprise perspective was through the hardware nodes that the software was to be deployed on (this box is for General Ledger, that box is for Accounts Payables, this box is for email, that box is for our website, and so on ...). Rack it, stack it, connect it up, and turn it on.

The new generation of architects don't think of software only in terms of how it is deployed. Disrupting forces like the Internet, Mobile Computing, Virtualization, and Cloud Computing are making physical hardware and networks a ubiquitos (and somewhat abstract) concept. With the changes brought about by these forces, it is not likely that the IT group of the future will even continue to manage physical technology assets within business-owned data centers anymore.

So if IT departments are no longer managing hardware and networks for the business, what will that leave them with? Will IT cease to exist as a business-critical function within the enterprise? The answer, of course, is no (or else I'd be learning a new trade instead of blogging about this one). The answer is that IT departments will "move up the food-chain" within the business - becoming newly responsible for managing and securing its intellectual property (IP).

IP is the beating heart of today's business. It is composed of the knowledge and the processes that form the foundation of a business and give it its unique competitive differentiation within the marketplace. Knowledge and processes are modeled as software, not hardware - and those models can no longer be confined to the physical boundaries of hardware and networks. Look no further than Amazon, Google and other major internet-based companies that have survived the dot.com bubble to form the new guard of today's business for proof of this paradigm shift is real.

So how does this all tie back to SOA? SOA is simply a better way of managing the knowledge and processes that form the IP of your business. SOA is a better way because it is a software architecture that, like the knowledge and processes it manages, is not confined to the physical boundaries of hardware and networks.

So, if I shouldn't approach SOA the way I've approached technology investments in the past, by going out and buying some components from a vendor, connecting them up, and turning them on; how should I approach it? This will be the subject of my next blog - Part II in this series.


Agile SOA - Part II
After establishing the forces behind the paradigm shift of Service Oriented Architecture (SOA) in Part I of this series, I'd like to talk about how we should now be approaching enterprise architecture from the perspective of software architecture in this article. SOA is an architectural pattern for how to build software that better supports the evolutionary characteristics of your business. The emphasis within this discussion will be around the term "evolutionary", and how agile methods best support the evolutionary development of software.
We'll first start by contrasting the "evolutionary" aspect of modern software architecture against the "predictable" aspect of modern hardware architecture. Moore's law best describes the predictability of modern hardware architecture: that almost every aspect of digital electronic devices (processing speed, memory capacity, etc.) are all improving exponentially, doubling approximately every two years. The trend was first observed by Intel co-founder Gordon E. Moore in a 1965 paper, has continued for almost a half of a century, and is not expected to stop anytime soon.

Modern software architecture has no such predictability. It is best described by the theory of evolution, well-known within the domain of biology. The primary reason for this is that software is used to model the knowledge and processes that form the foundation of a business. This intellectual property (IP) that gives a business its competitive differentiation comes from the coordinated effort of its people. In biology, evolution is change in the inherited traits of a population of organisms from one generation to the next. Evolution occurs naturally within any biological population, so it is natural to expect that that the knowledge and processes guarded by a group of people will evolve as well, and therefore that the software that models that IP must have the chief characteristic of "evolvability" in its design.

Whether you fall on the side of Evolution or Creation as it applies to the origins of humanity, no one can deny the fact that software is created. One could argue if all software was indeed created by an "intelligent designer", but that is the subject of another blog. Designing software to best support its own evolution is by far the hardest thing a software architect must attempt to do. While evolution is a relatively simple thing to comprehend, it is not even remotely simple to design for.

Service Oriented Architecture is the next step along the path our industry has taken since its inception to achieve "evolvability" in software design. At first we categorized and organized data "in-situ" with structured programming, then we began to add behavior and encapsulate both data and its behavior as objects with object-oriented design, and now we are making behavior a first-class design concern with SOA - pushing data to more of a "behind-the-scenes" supportive role. This is because the knowledge that forms the competitive advantage of a business is derived from the interpretation of data created and managed through the processes with which the business provides value to its customers. Data is only a means to an end, it is in the successful interpretation of data that a business lives or dies. That successful interpretation is inexorably linked to the evolving environment in which the business is competing. Safely and securely nurturing and advancing the IP of a business is indeed akin to "survival of the fittest" within the free market economy.

So why is Agile the best method to use when approaching the evolutionary characteristic that is the chief concern of SOA? Simple, because while those of us who architect software may be intelligent - we are not omniscient, and cannot predict the ways in which our software and its use within the business context will evolve over time. Whenever I discuss Agile, I like to go back to the 4 basic values that were recognized by Kent Beck in "Extreme Programming Explained: Embrace Change", Addison-Wesley, 1999. These values are Communication, Simplicity, Feedback, and Courage.

Communication."The first value is communication. Problems with projects can invariably be traced back to somebody not talking to somebody else about something important."

An Agile approach to SOA is all about establishing, and continually improving, the communication between business and IT. Architecture is the way in which those of us involved with software design communicate to our business counterparts. This communication is meant to be "reflective", in that it should reflect the values, priorities, and requirements initially shared with us by the business. Perhaps the biggest way in which SOA improves the "reflective" property of IT to business communication around software design is that it de-couples the two concepts of business and application services. Business services are discovered in a top-down fashion from the activities that make up a business process. A business service delegates the automated work related to the activity it is modeling to application services. Application services are discovered in a bottom-up fashion from the existing systems and data that support the business. It is in the mapping of business services to application services that our business counter-parts can truly understand the value provided by their application portfolio, and that we in IT can rationalize the continuing investment from the business for maintaining it.

Simplicity. "The second value is simplicity. The [Agilepractitioner] continually asks the question: What is the simplest thing that could possibly work?"

An Agile approach to SOA is all about deriving simplicity from the seemingly complex. Legacy application services are complex, mainly because those who designed them just didn't expect the internals of these applications ever to see the light of day in the business world. Legacy Enterprise Resource Planning (ERP) applications were a commodity and so long as they functioned properly as a whole within acceptable service levels, it didn't really matter how they were designed internally. However, in SOA, these legacy application monoliths must be broken down into the specific services they provide in order toeffectively trace those application services to the business activities they support.

Simplicity in SOA comes down to reducing the "surface area" of the software we are integrating into our business. Legacy monolithic applications just have too much surface area to consider when attempting to integrate them within an evolving business process. The ERP days were also all about implementing these legacy monoliths "vanilla", with as few customizations as possible - because customizations were hard and cost money. This led to the business being forced to conduct their processes the way the software dictated they be conducted. This rigidity, introduced by IT, led to many businesses falling behind in their ability to compete by successfully adapting to their continually evolving industries. This has left a very bad taste in their mouths about IT (not to mention the debacle of Y2K that yielded absolutely no business value).

With SOA, it is an absolute imperative that we find the simplest way to keep our respective businesses competitive. SOA promotes simplicity in its design through modularity and flexibility. By flexibly composing more complex business services from simple, modular application service building blocks - we are better preparing that software to evolve along with the business processes it supports. Kent Beck says it best: "[Agile software development] is making a bet. It is betting that it is better to do a simple thing today and pay a little more tomorrow to change it if it needs it, than to do a more complicated thing today that may never be used anyway." Time is the enemy of complexity - only the simplest of solutions will endure.

Feedback. "The third value [of Agile] is feedback. Concrete feedback about the current state of the system is absolutely priceless. Optimism is an occupational hazard of [software architecture]. Feedback is the treatment."

An Agile approach to SOA is all about promoting feedback at both design-time and run-time, creating a continual feedback loop between the changes in the processes that support the business and the responsiveness of IT to those changes. At design-time it does this by improving the testability of software while at run-time it does this by allowing real business results to be tracked and monitored in real time.

In software, increased modularity leads to increased testability. Testability of software deals with the ability of software to hide errors from detection during testing. More complex software is more difficult to test because its complexity acts as a sort of camouflagefor latent bugs, allowing them to survive longer without detection. Many studies have shown that the longer it takes to detect a bug, the more costly it is to correct that bug. Simple, modular software architecture allows for more effective testing of smaller, and therefore more manageable, chunks of an application. Since this testing can be focused on the module and performed independently of the rest of the application, it is far less likely to conceal bugs further into the software lifecycle.

SOA also promotes feedback at run-time by linking the work performed by application services to tangible business results. Business services represent activities that add value for the customer within the context of a business process. Run-time monitoring of these business services provides real-time feedback on how well the business is running. If a business service is not running within established service levels, it is also easy to "click into" a particular business service and see if the reliability, availability, scalability or performance of the supportive application services are the source of the problem. Finally, the real-time metrics collected by monitoring a business process can be used to simulate business process performance under load to better understand the impact of changes to that business process while those changes are still under test.

Courage. "Within the context of the first three values - communication, simplicity, and feedback - it's time to go like hell. If you aren't going at absolutely your top speed, somebody else will be, and they will eat your lunch."

An Agile approach to SOA is all about finding the courage to be wrong sometimes, while minimizing the impact of being wrong and optimizing the time to correct those mistakes as they are discovered. Due to the predictable nature of hardware architecture, it wasn't generally acceptable for the first generation of enterprise architects to be wrong. The new generation of architects must be capable of making educated decisions in the trade-off between "perfect" and "fast". If software is going to successfully evolve at the speed of business, we software architects must learn how to facilitate, not impede, that evolutionary progress. We must trust that if we follow the other tenants of the agile approach, that our mistakes will be fewer, of smaller scope, and much easier to detect and correct. The business does not really care if you can unequivocally point the finger at a software vendor as the source of a problem - they only care how long it will take you to diagnose and correct that problem. If you are able to keep pace with the business, then small, quickly recoverable problems with the software will be tolerated by the business. It is only when you cannot keep pace with the business that the business begins to expect the impossible. Your customer's expectations for the software you deliver are directly proportional to the time it takes for you to deliver it -- the longer it takes for you to deliver software to your customer, the higher your customer's expectations for that software will be.SOA gives you the modular and flexible design you need to embrace business change while an Agile approach gives you the most rapid approach to keep pace with that business change.

So if I've convinced you that an Agile approach to SOA is the right approach, you may come to see the monolithic SOA Suites the large vendors sell as overly-complex and the cumbersome development methods and processes they dictate to you as overly-slow. This will be the subject of my next blog - part III in this series.



Hand to Hand Malware Combat
Mon, 02 Nov 2009 15:28:40 -0500
Does anybody else like to battle viruses and malware by hand? I use the free AVG Anti Virus and highly recommend it. But my kids play a lot of flash games that invariably come from sites designed to infect with the latest malware.The free AutoRuns utility from Sys Internals (now Microsoft) is my chief weapon [...]


Software History Books
Mon, 02 Nov 2009 14:50:00 -0500
It’s valuable for programmers to know the history of computer programming. One reason is to observe how ordinary people accomplished extraordinary things…creating software that’s part of our everyday existence. Another is to gain insight into how software development got to its current state and where the future lies. I find the stories of Internet start-ups, success or [...]


The CIO is accountable for SOA
Fri, 30 Oct 2009 12:46:07 -0400
Interesting question posed in the ebizq.net forum:In SOA Governance, Who Has the Authority?In my opinion, the short answer is the CIO is accountable for (service-oriented) architecture. The long answer involves first addressing 2 key buzzwords associated with the question: SOA and governance. I leverage MITs IT Governance model when defining SOA governance: SOA governance involves [...]


Software Configuration Management Part II  Branching strategies
Thu, 29 Oct 2009 14:30:57 -0400
BRANCHING STRATEGIESA sophisticated branching strategy can yield significant improvementsThe function of a branching strategy has several functional goals : Create better software (fewer bugs); deliver software faster; allow for flexible (agile?) deployments, where an intelligent choice can be made as to which features are released, giving you the ability to do time-based releases with a [...]


Corporate IT Forecast: 100% cloudy with a chance of meaty cost savings
Tue, 13 Oct 2009 09:16:41 -0400
As the adage goes, history is bound to repeat itself. In his book, The Big Switch, Nicholas Carr presents an insightful summary of the evolution of the power-generation industry and draws discerning parallels with that of the information technology industry. First, he summarizes how the industrial power-generation business transitioned from the brawn of men and [...]


The Adventures of a Not So Lucky Enterprise Cloud Pioneer
Fri, 02 Oct 2009 12:50:35 -0400
Why cant every CIO be as lucky as Jim Barton? The mythical man, with not one iota of technology expertise, is thrown into a seemingly inescapable trap of leading fictional IVK Corporation through data security breaches, web site denial-of-attacks and other corporate information technology maladies. Yet, somehow he manages to escape them all with only [...]


Integration Architecture Considerations: REST vs. SOAP
Thu, 10 Sep 2009 12:51:15 -0400
Introduction of latest integartion archtecture trend called Service Oriented Architecture, or SOA for shot, has stirred up quite a debate on what types of service architectures are best suited for enterprise wide adoption. Should the services be based on:REST or SOAP ? Before casting the final vote, one must understand these types of services and [...]


Application Portfolio Rationalization  Prioritize dont Architect!
Tue, 25 Aug 2009 10:51:07 -0400
A common misconception is that application rationalization and optimization will somehow unlock the mysteries of your future IT architecture. Many believe that by analyzing the patterns in your technical architecture, assessing your teams skill-sets, and reading the tea leaves of future technology trends you can boldly stand up and say we will be an SOA [...]


Startup Interest Group
Fri, 21 Aug 2009 11:38:56 -0400
I’ve been attending a technology startup interest group, the Philly Startup Hackathons, for about two years now. I’ve met lots of interesting people, notably Gabriel Weinberg, the organizer. Gabriel’s always got too many interesting projects underway! One of his latest is an internet search engine called DuckDuckGo. He’s also well-connected in the area, and is [...]


Blog Comments
Tue, 18 Aug 2009 09:38:02 -0400
Comment Spam, Serial Posts, Long GapsWow, 95% of the comments posted to the blog articles here are spam. Through the spam, I’ve learned a lot about Pfizer’s flagship product…or is that flagstaff product? The comment spammers go to varying amusing lengths to make their posts look like legitimate comments, but they’re effortless to spot, so [...]


Introducing The Collaboration Center of Excellence
Mon, 17 Aug 2009 13:34:05 -0400
Collaboration can be framed in terms of how it impacts People, Business Processes and Organizational Knowledge. Processes address the methods, applications and rules which define and govern how work gets done. For example, order fulfillment, new account development, employee on boarding, web site publishing, product development, etc. Knowledge and knowledge management refers to the development [...]


Best Practices in The Real World: Square Peg/Round Hole?
Mon, 10 Aug 2009 09:45:24 -0400
In any collaborative platform implementation, SharePoint notwithstanding, there are different approaches to do different things. How does one install the tool within the current Enterprises environment? How does one configure the tool to meet the business need? Questions like these can be answered in many different ways. It is from these different approaches that Best [...]


Web Architect?  Is there such a beast?
Tue, 26 May 2009 14:49:49 -0400
Of course, there is no industry standard definition of a web architect.Below is how I view the role.A Web Architect is a specific type of application architect*. A web architect is expert re: web-specific scenarios and technologies applying best practices, patterns, and reference architectures around delivering web-native experiences in one or more of 3 types [...]


Twitter to blog script
Sun, 24 May 2009 13:37:58 -0400
Based on an example provided with the Twitter library for Python I cobbled together the following script to add my latest tweets to this site. It’s called from a cron job that I run on an occasional basis. My script linkifies hashtags and @username tokens in tweets so that you can see search results or [...]


Keeping files in sync with Dropbox
Sat, 23 May 2009 18:25:49 -0400
When you use more than one computer on a daily basis, keeping files in sync between them is a constant problem. I’m familiar with tools like Subversion and Mercurial that make it relatively easy to keep code in sync between machines, but these require explicit actions that I often want to control. When it comes [...]


Ideal Transform Rule
Mon, 11 May 2009 16:19:31 -0400
Always work from ideal input.Developers familiar with the power of pipeline operations central to the UNIX operating system know how simple, modular tools can be chained together to accomplish a wide variety of complex tasks. The small-scope and single-purposed blocks of code that make up a pipeline maximize the ability to maintain the code. Even if [...]


Technology or marketing tool?
Thu, 07 May 2009 18:53:55 -0400
On April 22ndNationwide Insurance released an “Accident Toolkit”on the iPhone Storedesigned to “guide you through the steps to take after an accident.” The services the app provides include:Calls emergency servicesHelps you collect and exchange accident infoStores your insurance and vehicle info for easy lookupLocates Nationwide agents near youTakes and stores accident photosConverts your iPhone into [...]


What is the Meaning of Life?
Mon, 04 May 2009 12:18:08 -0400
I thought it best to comeright out of the gate and try to tackle the big questions first.Get this one correctand future posts about thetechnology challenges faced by the insurance industry shouldseem trivial.Truthfully,my goalin writing this blog is notthatambitious, butthere are a lot of “big questions”for IT professionals serving the insurance industry to contemplate, such [...]


Unit Tests for FinQ
Thu, 26 Mar 2009 00:08:31 -0400
I’ve setup the FinQ library solution to support the unit testing framework NUnit. Here are a few of the guidelines I’ve used for setting up the project. Tests belong in a separate assembly.Place tests in the BaseName.UnitTests namespace.Break up tests into multiple classes and files by subject area.Tests should stand-alone and be single-purposed.Name tests clearly.Maximize [...]


FinQ Stats
Fri, 13 Mar 2009 00:00:57 -0400
I took too many statistics courses in college, or perhaps they took me. Hopefully I escaped with enough stats to implement the basics: mean, variance, and standard deviation for the FinQ library. LINQ stops with average, but standard deviation is etched into my mind as being genuinely useful…so I’ll go the extra few lines of [...]


Get fast computers for your developers
Sun, 08 Mar 2009 14:42:52 -0400
I’ve just been through an office move at a client site and packing it up got me thinking about the choices that companies make for their staff when it comes to computer hardware. Most users can benefit in some way from having faster computers, with bigger screens, and better input peripherals. Corporations have a tendency [...]


Reduce Redux
Wed, 25 Feb 2009 15:29:47 -0500
Reduce is a powerful function pattern. In fact, it can be used as the base implementation for both Filter and Map. That’s what we’ll do to take our functional library to the next level of functional goodness. We initially had Reduce take a list of many values and produce a single value, an aggregate, but [...]


Lambda Functions
Wed, 25 Feb 2009 15:20:47 -0500
What about those predicate, conversion, and aggregation functions? Does this style of programming with higher order functions mean you have to write a bunch of tiny functions to pass around? Nope! We can use C# lambda functions. A lambda function is a function defined on-the-fly at the call site without a lot of declaration and [...]


FinQ Reduce
Wed, 25 Feb 2009 15:02:04 -0500
The Reduce function uses an initial value and an aggregation function to build a result value from a sequence. Taking the sum of a set of numbers is a reduction, a reduction by addition.public static R Reduce<T, R>(this IEnumerable<t> list, R init, Agg<T, R> agg){    R result = init;    [...]


Software Configuration Management, part I
Fri, 20 Feb 2009 10:20:45 -0500
OverviewSoftware Configuration Management (SCM) is the art of both controlling and tracking changes in a software project. If software engineering is fundamentally concerned with producing quality software in a known and repeatable fashion, then SCM is the fundamental tool that drives the operation of software engineering.Why is Software Configuration Management important?The formal goal of a [...]


Essential Utility: htop
Sun, 08 Feb 2009 22:46:46 -0500
I’ve been rebuilding my Dell PowerEdge 830 server after a meltdown last week. This time I decided to go with Ubuntu Server 8.10 as the base operating system with Windows running under VMware Server 2.0.Since this is a pretty small server, I’m always checking up on resource usage and top is a useful tool for [...]


Weekly Links #2
Mon, 26 Jan 2009 23:18:12 -0500
Microsoft InfoMesa Project Whiteboard for your dataFabric – like Capistrano but written in PythonA Visual Introduction to Screenretlang – Google CodeTim Sneath : The Bumper List of Windows 7 Secretsupdate-engine – Google Code


PowerShell and svnadmin dump/load
Mon, 26 Jan 2009 23:10:31 -0500
Recently I was migrating several Subversion repositories from a Windows server over to a Solaris one and ran into a rather frustrating issue. Actually it’s quite an interesting problem, but was frustrating due to the size of the repositories involved, and my fear that repositories were borked.It all started with my decision to fire up [...]


First impressions of Windows 7 Beta 1
Sun, 11 Jan 2009 15:52:33 -0500
After a very quick install on a Dell XPS M1710 laptop, and a few hours of messing around, I have come to the conclusion that this is going to be the best release of Windows yet. At the same time, it’s not very exciting for the alpha geek in me. Perhaps it is good to [...]


Weekly Links #1
Sun, 11 Jan 2009 14:36:35 -0500
I manage my bookmarks using a Delicious Bookmarklet, and I’ll post some of the best on my blog each week.Hiring for an Agile Team: Possible Questions FontExplorer X – The new professional font management software TextMate Blog  Working With History in Bash Using MVC to Unit Test WPF Applications Mole v4.2 For Visual Studio [...]


Return of the blog
Sat, 03 Jan 2009 14:49:22 -0500
Maybe this year will be the one where I get back on the path to regular blogging. Between 2002 and 2004 I was a fairly frequent blogger and then things got substantially busier when I moved to the US. The obligatory first post these days seems to be some background information on the blogger, but [...]


SOA Performance Metrics
Fri, 26 Sep 2008 10:14:05 -0400
SOA performance measurement is important for two main reasons — requirements compliance and system planning.  The first reason, requirements compliance is obvious, where you must prove that your system meets the overall performance requirements of whatever process you are running.  The second reason, system planning, is necessary to get to a fully deployed [...]


SOA performance part I : managed environments and garbage collection overhead
Tue, 05 Aug 2008 13:40:40 -0400
Automatic garbage collection is simultaneously the best and worst part of implementing programs in managed code.  On the positive side, garbage collecting makes the writing of the program easier by freeing you from the need to explicitly manage memory and it thus makes the runtime more stable as it prevents most memory leaks (Self-referential [...]


Fixed Cost Software Development : Good for whom exactly?
Tue, 15 Jul 2008 14:25:53 -0400
So I was reading the latest issue of Dr Dobb’s and got to the piece by Scott Ambler called “Is Fixed-Price Software Development Unethical?.”  Mr. Ambler, as you may know, is the Agile Methodology guy at ddj.  It is really a fascinating article, and something that I have been on about for some [...]