Be In A Position Of Strength When Changes Occur (By Maintaining Code In A Ready-To-Ship State).
Rarely does anything in life work according to plan and software projects are no exception. Simply put, changes are bound to happen and how you deal with them will determine how successful the project is. Most of these changes will be involuntary and unexpected and the programmers and testers are usually at the receiving end. With deadlines whizzing past you the pressure mounts and the vicious cycle continues. This is where a solid foundation is useful as explained here. If you have a solid foundation, then it becomes less of a burden to maintain code in a ready-to-ship state at all times. Without that you may not have the ability to respond to changes in a timely manner. Lets look at a few scenarios.

• Sudden requests for demos or alpha/beta builds by influential customers. If you have a continuous build system and you keep your builds reasonably green, then you could literally provide the last successful build. If not you would need to drop everything you are doing and try to figure out a way to get a stable build. If you have many test failures, you will probably need to fix them first as well.
• A team member resigns, or falls ill. Unless the project culture had insisted in tested, reviewed and documented code right from the get go, the person who have to take over will need to spend a significant amount of time in getting it going.
• And our favourite, the customer and/or marketing folks change their mind for the umpteenth time. Again if you have ready-to-ship code backed by an armada of tests (unit, integration, performance, interoprability ..etc) then you are in much better position to make the required changes with confidence. The tests will provide you instant feedback about the impact. The most important thing is to be able to give an accurate picture of the impact of such a change. If you have evidence to backup your claims then managers, marketing folks and the customer are more likely to listen to you

Have A Well Defined Process To Manage Change (No, I am not talking about the process that your organization already has)
Most organizations have a formal process for handling RFE’s and bug fixes etc. (There are also organizations that are completely at sea when it comes to this). Irrespective of whether there is such a process or not at the organizational level, the engineering team should have it’s own. Some points to consider from an engineering perspective (as alluded to in my previous post).

• If your organization doesn’t have a proper process already in place or does not follow the process, then the first thing to do is to work on getting that done. It’s sad to see that some organizations doesn’t have such a process, while others did have a process but was frequently ignored for short term convenience. The consequences were disastrous, especially for the poor engineering team, and not to mention that the ability to respond effectively decreases dramatically over time. How such a process should look like and what’s involved is a separate discussion that I hope to tackle later on.
• Branching policies for handling releases, hotfixes (these are notorious for making your life dreadful). In my humble experience, having this discussion right at the beginning (and on an ongoing basis) vs later in the project cycle (especially when everybody is under the gun) is whole lot more productive.
• Handling RFE’s/critical bug fixes for existing releases. - same as above. Do it when your head is relatively free.
• Figuring out how to evaluate change requests & who is responsible for what area to make that call While the team leader/manager is ultimately responsible for making a call, they are always not in a good position to make a good decision without input from others. Therefore it want hurt to have folks informally appointed (known within and outside the team) as subject experts in certain areas. Radical changes to the code base, taking on new functionality that directly/indirectly affects a particular area should not be decided without the input from these area experts. All though Apache Qpid is an open source project, most committers will discuss with the area expert (on the dev-list/JIRA) if the commit falls outside the committers core area of expertise. Not only it’s courteous and reduces friction/disagreements it also ensures things are done correct the first time which minimizes the impact it has on schedule etc..

Deal With RFE’s/Requirement Changes Methodically (instead of being emotional and kicking up a storm).
No matter how swamped your team is and/or how ridiculous the request/requirement is, emotional outbursts or rejecting them with “not enough time” ..etc is not going to help.
It’s in your best interest (and the interest of the customer) to listen, understand, analyse the impact and then compile your response backed with evidence.

• If you make an effort to listen & understand the change request,
  • You may find the real underlying requirement is something else. Which maybe easier to implement after all.
  • Provide an acceptable alternative
  • Provide an acceptable workaround until you fix it properly in the next release.
• If you provide a proper response backed by evidence
  • First of all people are likely to listen to you as you are presenting facts backed by evidence and not mere conjeture .
  • It helps people to understand the impact and the consequences (Ex half the functionality will not work and would need n extra days).
  • Even if your opinion is ignored and the change is forced upon, atleast for your own/teams benefit you know how much of an impact you have to deal with.

Your Credibility Is Important.
This could go a long way in ensuring your opinion is heard, hence being able to negotiate changes successfully!

• If you have provided sound judgement in the past, the managers are likely to listen to your opinion.
• If you have built credibility with the customers, then they are likely to listen to your opinion, accept your workaround or alternative solution.

Ability To Improvise
Sometimes it takes a bit of improvisation to deal with the changes and still beat the clock. Instead of complaining and whining about the changes, use them as an opportunity to show your worth.
And here are some stories..

• Once we had to deal with a customer who asked for frequent GUI changes on an application that ran in an embedded device. Suffice to say it was a real pain. At the time one of my colleagues was toying with the idea of expressing the screens in XML. We promptly adopted it and taught the customer how to customize the screens to their hearts content. My colleague eventually went on to lead the team.
• We needed an automated build system to run our test suites in different OS’s and aggregate results. As the project progressed the permutations grew. We looked around and didn’t find anything that fit our needs. Then a colleague of ours used our own product to create a distributed automated-build-system.
• While working on an application that ran on an embedded device (same as item 1), the QA team had a tough time testing due to the restricted nature of the embedded device. The long test cycle ate into our dev cycle and impacted our turnaround time. I finally wrote a simulation program during my free time that simplified a lot of the testing. I scored some brownie points there, which came handy during the next performance review

In summary, a software engineering team can do a lot to mitigate the risks posed by changes that happen throughout the project. How well you negotiate those changes will have a huge impact on the final outcome.

It amazes me to see how little attention is paid to this simple truth when a software project is undertaken. There is a reason why it’s said “you reap what you sow”. More often than not the success of a software project (for that matter many things in life) depends on how well you have laid the foundation. But It seems far too many think that software projects are immune from simple realities in life. You don’t need to have elaborate plans or lengthy kick off meetings, but reasonable time and effort needs to be spent on getting the basics right. While none of us have the power to foresee every obstacle that might crop up during the project, there are many aspects that are within our control. And more often than not, these aspects are not given their due recognition, hence taken for granted !

The Way We Set It Up Is How It Ends Up.
What can be managed should be managed right from the start by following the proper process. We all know we need to test, use coding standards, provide documentation, do code reviews, follow process..etc, but how often do we think about these aspects right at the beginning of the project? These are things that we can control to a reasonable extent, but if not paid enough attention could spiral out of control and eat up enough cycles to cause major disruptions in your project later on.

• How many projects use a continuous build system right from the start? In the first couple of days or so you may not even have enough tests to run, but ensuring that at any given moment the code is compilable and tests are passing will set the tone for the project right at the beginning.
• We all think we could write documentation when we have enough functionality, but we soon find out that we have quite a bit to write with not enough time. Ditto for code review & coding standards.
• Same goes for writing tests too! By the time we decide to write the tests in earnest, we have done quite a bit of coding. All that time saved by not writing tests and a lot more is now wasted doing damage control.
• Using a bug tracking system right from the get go is better than using sticky notes:)
• How often do we slap in a quick ant file/make file ..etc to get it going soon, thinking we can improve it later as the projects gets more complex. Anybody who had gone through the pain of tinkering with the build system when the project is in full swing knows what I am talking about. Spending some time upfront designing a more robust build system would save you loads of time and frustration down the line.
• During the initial setup period, how often do teams discuss about the internal release process, branching policies, how to handle hotfixes, bug fixes for existing releases etc. If these points are discussed in earnest right at the start, then perhaps you could put in place structure that would accommodate them more easily vs having to bend over backwards at a latter stage of a project when we really need to do it.

Simply put, following proper process right at the start will determine how successfully your project ends.

This Applies Even When Your Are Doing A Proof-Of-Concept (And here’s why)
I have seen many proof-of-concepts being done without using any version control, without adhering to coding standards, using a bug tracking system or writing any sort of tests. The justification being it’s only a proof-of-concept, and we could do it properly when we get to the real thing. But how many times have we seen the proof-of-concept being used almost as it is as the initial code when the real project starts?

Now all of a sudden you have a lump of code, that is not reviewed, documented, tested or version controlled properly. Since no bug tracking was used, all the time spent in testing the POC is now wasted. While nobody cares about the POC being stable and forgive you readily when the system crashes several times during the demo, the same allowance is not given when you deliver the real system. But scarily enough the same unstable code is now being used as the base for the real system. Now is the time you lament about not following proper procedures during the POC development.

Ideally a POC should be what it is - a POC and nothing more. The real system should be started from scratch. But the problem is, we don’t live in an ideal world!
So if your organization has a history of turning POCs into real systems in double time, then follow process right from the start to avoid a stroke or a heart attack.

The Only Thing That Does Not Change, Is Change Itself. So Plan For It At The Beginning!
Changes are going to happen! Either the customer or the marketing dept or both will change their mind. These changes will happen for a variety of reasons and more often than not they will need to be accommodated. We cannot have an architecture that will withstand all the numerous RFE’s. We cannot plan for everything. But we could still have a plan for dealing with these changes! Having one right at the beginning will save you a load of trouble. You may need this kind of planing at different levels.

• Most organizations have a process for dealing with changes and RFE’s. But you may need to have a project specific criteria as well. What might work for one project may not work for another, so the corporate guidelines may be inadequate in covering all scenarios. Working that out right at the beginning and getting approval from all concerned parties may reduce a load of pain at the end.
• While you cannot architect for every conceivable change, we could still try to identify areas in the system that can potentially change. Not only this is useful in scheduling, it is also important in the architecture stage as you could try to isolate change as much as you can. Even though you have no control or visibility into how a particular feature might eventually pan out, you still maybe able to isolate it enough to minimize the impact the changes could cause in your system.Identifying areas that could change at the beginning and setting up your architecture in such a way will ensure how well you deal with inevitable changes.
• Similarly testing strategies should also be planned with changes in mind. Having this discussion right at the beginning rather than later will no doubt contribute positively towards the success of the project

Related to this topic is discussions about resourcing, requirements planning etc. These aspects are critical in properly setting up a project. However the above piece is written more from a software engineers perspective. In some ways the software engineer has very little influence (ex resourcing, requirements planning..) in determining the way a project is setup and in other ways quite a bit is within their sphere of control (ex. the aspects mentioned above). The idea is to maximize what you could manage/control and plan for what you cannot.

Apache Qpid (http://qpid.apache.org) is a cross platform enterprise
messaging solution which implements the Advanced Message Queueing
Protocol (http://www.amqp.org). It provides brokers written in C++ and
Java and clients for C++, Java (including a JMS implementation), .Net,
Python, and Ruby.

This release contains many bug fixes and stability improvements over
previous release and we recommend that all users upgrade.

New in this release is another .Net WCF implementation which uses the
C++ client library as its transport rather than the native C# client.
This version has improved protocol version interoperability with Java
broker support for the 0-10 and 0-9-1 AMQP protocol versions.

Apache Qpid 0.6 can be downloaded from here:

http://www.apache.org/dist/qpid/0.6

A complete list of the reported features/bugs addressed in this release
can be found here:

https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310520&styleName=Html&version=12313728

• SSL
• SASL security layer

This articles focuses on how to secure your connections between the C++ broker (on Linux) and the JMS and C++ clients with SSL.
I plan to write an entry explaining how to use the SASL security layer in the future.

Disclaimer : The SSL tools/techniques used below for creating certificates are for illustration/testing purposes only. For production you need to use certificates from a competent third-party CA or use Professional grade CA software.

1.0 Installing SSL Support

1.1 Installing SSL Support For C++ Broker & Client
The C++ Broker/Client uses Mozilla’s Network Security Services Library (SSL) for SSL support.

1.1.1 Installing From RPMs
For Broker support

yum install qpidd-ssl

For Client

yum install qpidc

1.1.2 Building From Source

• Download a released source tarball from here
• Make sure you have the following dependencies installed
  • nss
  • nspr
• Follow the build instructions given in the INSTALL file located in the source directory

1.2 Installing Java Client
Download the Java client from here.

2.0 Creating the SSL Certificates For Testing
Lets create the required certificates for testing our SSL setup. For this purpose we are using the Mozilla certutil tool.
For more details please read [1].

2.1 Setting Up The CA
We need to setup the CA and the self signed root CA certificate.

• Create a new certificate database in the CA_db directory.

               >mkdir CA_db
               >certutil -N -d CA_db
               

• Create the self-signed Root CA certificate, specifying the subject name for the certificate.

               >certutil -S -d CA_db -n "MyRootCA" -s "CN=MyRootCA,O=ACME,ST=Ontario,C=CA" -t "CT,," -x -2
              

  • It will prompt you for a password. Enter the password you specified when creating the root CA database.
  • Type “y” for “Is this a CA certificate [y/N]?”
  • Press enter for “Enter the path length constraint, enter to skip [<0 for unlimited path]: >”
  • Type “n” for “Is this a critical extension [y/N]?”
• Extract the CA certificate from the CA’s certificate database to a file.

             >certutil -L -d CA_db -n "MyRootCA" -a -o CA_db/rootca.crt
            

2.2 Creating The Certificates For The Server (Qpid Broker)

• Create a certificate database for the Qpid Broker.

                >mkdir server_db
                >certutil -N -d server_db
               

• Import the CA certificate into the broker’s certificate database, and mark it trusted for issuing certificates for SSL client and server authentication.

              >certutil -A -d server_db -n "MyRootCA" -t "TC,," -a -i CA_db/rootca.crt
              

• Create the server certificate request, specifying the subject name for the server certificate. We make the common name (CN) be identical to the hostname of the server. Note that this step generates the server’s private key, so it must be done in the server’s database directory.

               >certutil -R -d server_db -s "CN=localhost.localdomain,O=ACME,ST=Ontario,C=CA" -a -o server_db/server.req
               

• This step simulates the CA signing and issuing a new server certificate based on the server’s certificate request. The new cert is signed with the CA’s private key, so this operation uses the CA’s databases. This step leaves the server’s new certificate in a file.

              >certutil -C -d CA_db -c "MyRootCA" -a -i server_db/server.req -o server_db/server.crt -2 -6
              

  • Select “0 - Server Auth” at the prompt
  • Press 9 at the prompt
  • Type “n” for “Is this a critical extension [y/N]?”
  • Type “n” for “Is this a CA certificate [y/N]?”
  • Enter “-1″ for “Enter the path length constraint, enter to skip [<0 for unlimited path]: >”
  • Type “n” for “Is this a critical extension [y/N]?”
  • When prompted password, enter the password you specified when creating the root CA database.
• Import (Add) the new server certificate to the broker’s certificate database in the server_db directory with the appropriate nickname. Notice that no trust is explicitly needed for this certificate.

             >certutil -A -d server_db -n localhost.localdomain -a -i server_db/server.crt -t ",,"
             

2.3 Creating The Certificates For The C++ Client

• Create a new certificate database in the client_db directory.

                >mkdir client_db
                >certutil -N -d client_db
          

• Import the CA certificate into the client’s certificate database, and mark it trusted for issuing certificates for SSL client and server authentication.

                >certutil -A -d client_db -n "MyRootCA" -t "TC,," -a -i CA_db/rootca.crt
               

• Create the client certificate request, specifying the subject name for the certificate.

                >certutil -R -d client_db -s "CN=CppClient,O=ACME,ST=Ontario,C=CA" -a -o client_db/client.req
                

• This step simulates the CA signing and issuing a new client certificate based on the client’s certificate request. The new cert is signed with the CA’s private key, so this operation uses the CA’s databases. This step leaves the client’s new certificate in a file.

               >certutil -C -d CA_db -c "MyRootCA" -a -i client_db/client.req -o client_db/client.crt -2 -6
               

  • Select “1 - Client Auth” at the prompt
  • Press 9 at the prompt
  • Type “n” for “Is this a critical extension [y/N]?”
  • Type “n” for “Is this a CA certificate [y/N]?”
  • Enter “-1″ for “Enter the path length constraint, enter to skip [<0 for unlimited path]: >”
  • Type “n” for “Is this a critical extension [y/N]?”
  • When prompted password, enter the password you specified when creating the root CA database.
• Add the new client certificate to the client’s certificate database in the client_db directory with the appropriate nickname. Notice that no trust is required for this certificate.

               >certutil -A -d client_db -n "CppClient" -a -i client_db/client.crt -t ",,"
               

2.4 Creating The Certificates For The JMS Client

• Import the CA certificate in to the trust store.

               keytool -import -v -keystore trust-store.jks -storepass password -alias RootCA -file CA_db/rootca.crt
               

• Import the CA certificate in to the key store. (need for client authentication)

               keytool -import -v -keystore key-store.jks -storepass password -alias RootCA -file CA_db/rootca.crt
               

• Generate keys for the client certificate.

               keytool -genkey -alias java-client -keyalg RSA -sigalg MD5withRSA -validity 356 -keystore key-store.jks -storepass password
               

  Answer the questions accordingly and press enter when prompted for the password to select the same password as the key-store.

• Create a certificate request.

               keytool -certreq -alias java-client -sigalg MD5withRSA -keystore key-store.jks -storepass password -v -file java-client.req
               

  Answer the questions accordingly and press enter when prompted for the password to select the same password as the key-store.

• Create a certificate request.

               keytool -certreq -alias java-client -sigalg MD5withRSA -keystore key-store.jks -storepass password -v -file java-client.req
               

  Answer the questions accordingly and press enter when prompted for the password to select the same password as the key-store.

• Sign the certificate request using CA certificate.

               certutil -C -d CA_db -c "MyRootCA" -a -i java-client.req -o java-client.crt  -2 -6
               

  • Select “1 - Client Auth” at the prompt
  • Press 9 at the prompt
  • Type “n” for “Is this a critical extension [y/N]?”
  • Type “n” for “Is this a CA certificate [y/N]?”
  • Enter “-1″ for “Enter the path length constraint, enter to skip [<0 for unlimited path]: >”
  • Type “n” for “Is this a critical extension [y/N]?”
  • When prompted password, enter the password you specified when creating the root CA database.
• Import the certificate into the key store.

               keytool -import -v -alias java-client -keystore key-store.jks -storepass password -file java-client.crt
               

3.0 Configuring The C++ Broker To Use SSL

• The $CERT_LOC denotes the directory where we created the CA_db, server_db, client_db, trust-store.jks and key-store.jks
• The broker-pfile needs to contain the password you entered while creating the server_db
• If you want to use client authentication, add –ssl-require-client-authentication to the broker options

If starting the broker from an installation.

/usr/sbin/qpidd --ssl-cert-db $CERT_LOC/server_db/ \
                       --ssl-cert-password-file $CERT_LOC/broker-pfile \
                       --ssl-cert-name localhost.localdomain \
                       --ssl-port 5674

If starting the broker from a source build

./src/qpidd --load-module ./src/.libs/ssl.so
                 --ssl-cert-db $CERT_LOC/server_db/ \
                 --ssl-cert-password-file $CERT_LOC/broker-pfile \
                 --ssl-cert-name localhost.localdomain \
                 --ssl-port 5674

4.0 Configuring The C++ Client To Use SSL
The following steps needs to be followed to enable SSL on the C++ client side.
The client side options are specified using environment variables.

1. Load the SslConnector.so
   If running from source

                          export QPID_LOAD_MODULE=./src/.libs/sslconnector.so
                 

2. To open an SSL enabled connection, set the protocol to ssl in the ConnectionSettings passed to Connection::open():

                   #include 
                   #include 
                   #include 
   
                   using namespace qpid::client;
   
                   int main(int , char** ) {
   
                   ConnectionSettings connectionSettings;
                   connectionSettings.host = “localhost”;
                   connectionSettings.port = 5674;
                   connectionSettings.protocol=”ssl”;
   
                   Connection connection;
                   try {
                        connection.open(connectionSettings);
                   ……
               

3. If client authentication is used, then we need to specify the clients certificate.

                    export QPID_SSL_CERT_DB=$CERT_LOC/client_db/
                    export QPID_SSL_CERT_NAME=CppClient
                    export QPID_SSL_CERT_PASSWORD_FILE=$CERT_LOC/cpfile
                

4.0 Configuring The JMS Client To Use SSL
The following steps needs to be followed to enable SSL on the JMS client side.

1. You need to specify the ssl option and the correct port in the Connection URL

                    amqp://guest:guest@test/?brokerlist='tcp://localhost:5674?ssl='true''
                 

2. Specify the trust store which contains the CA certificate

                   -Djavax.net.ssl.trustStore=$CERT_LOC/trust-store.jks \
                   -Djavax.net.ssl.trustStorePassword=password \
               

3. If client authentication is used, you need to specify the trust store and the key store which contains the client’s certificate

                   -Djavax.net.ssl.keyStore=$CERT_LOC/key-store.jks \
                   -Djavax.net.ssl.keyStorePassword=password \
                   -Djavax.net.ssl.trustStore=$CERT_LOC/trust-store.jks \
                   -Djavax.net.ssl.trustStorePassword=password \
               

4. In case you run into issues adding “-Djavax.net.debug=ssl” will enable logging in the Java SSL code

If you have any questions please feel free to contact us at users@qpid.apache.org.

This book is part of a new series started by O`reilly where the chapters (or entries) are chosen from a series of contributions (short essays) made by many individuals. The contributions are collected via a wiki and goes through an editing process via a designated editor. Once submissions are edited and agreed upon by the editor and the contributor they get added to a separate section from where the final contributions are chosen. This type of book offers the reader an opportunity to see multiple and varied perspectives of many individuals about the subject as opposed to a single authors perspective. The format of the book also allows for easy reading and the short concise entries are easy to digest. AFAIK there are two other books in the series, 97 Things Every Software Architect Should Know and 97 Things Every Project Manager Should Know.

My contributions were motivated by the daily challenges I faced as a programmer. Refactoring and testing are topics that are relevant to any programmer.
Before You Refactor and Test While You Sleep (and over Weekends) are based on my humble experience working in the industry for over 10 years. I hope it helps another programmer to avoid the pain I had to go through by learning things the hard way. Kevlin Henny was the editor for this book and it was a pleasure to have had the opportunity to work with him. Sometimes it’s amazing to note how a little bit of editing could make a world of difference. During the process I learnt a few things about writing from Kevlin for which I am very grateful for.

And here is the cover page with my mug shot

2009 have been a very busy and an eventful year. My wife graduated and thus ended our 2 year stay at the university residences at UTM. All though a small townhouse (albeit with 4 bedrooms - no idea how they fit them all in that tiny space) it was nestled in a lovely location. There was greenery all around and our townhouse backed into a wooded lot where there was deer with plenty of raccoons and the occasional rabbit. The campus had clearly paid a lot of attention to maintaining a healthy balance with nature, so there was plenty of tress around the area. I am not really a shutter bug, but we did take a few pictures here and there. Sadly I can’t seem to find them, so I’m linking with a few photos (pic1, pic2, pic3) I found on the net taken by one QueenCindy. My kid loved this place as there was plenty of room to run around and play.

After my wife graduated we had to moved into another place and after a very exhaustive search we found our selves back in the northern edge of Brampton,ON. House hunting was no fun and we spent countless hours running around looking for a place that fits our whims and fancies and also within our budget. Once we found the house it was a mad rush to find a mortgage at a suitable rate as we had only a few days. At the time the rates were very attractive, but the lending institutions were very thorough with so many requirements for various kinds of documents. I just about managed to get all the paper work done in time, but not without a last minute scare where for reason only known to them the bank refused to work with my lawyer. So I found another one at the eleventh hour that had a good working relationship with the bank which ensured we closed on time. All this happened while my wife was doing her final exams and I had to work on site with a customer that had a fairly aggressive schedule. My interactions with customers were mostly via email or phone calls, so being onsite was a new experience, all though I have to admit it was fairly stressful as well. I have blogged on my experience about it here. By the time the gig came to an end, I had lost quite a few hair.

The university gave us a one month grace period as there was nobody waiting to lease our townhouse. It allowed us some flexibility in the closing schedule. We have moved 5 times during the last 6 years, where one move was from Ottawa to Brampton (in Greater Toronto Area) !!!. So the very thought of moving again itself was a dreadful experience. I managed the last 5 moves on my own by renting a UHaul trunk. It wasn’t fun and I had enough, so this time I hired a mover. It took us quite a bit of time to get everything unpacked and settled in.

I started playing cricket in earnest during the last season (2009) for the Toronto and District Cricket League. It was an up and down season ending with me breaking my finger pretty badly during the last match of the regular season. The finger was dislocated and had a volar plate chip fracture. My finger is still in a pretty bad shape with a real possibility of it not attaining at least a 70% of what it used to be. One highlight of the season was facing Navin Stewart from Trinidad (who came to Canada to play club cricket during his off season). He plays for Trinidad and Tobago and featured in the Stanford Super Series and the esteemed Champions League in India. The bastard bowled two bouncers the second of which hit my glove, ricocheted off my helmet before being caught at the slips. He had decent pace and it was difficult to pick the red ball against the fading light. I hope I had better luck this coming season, but not sure if I am able to play at all due to the finger injury.

With all the madness happening around I had managed to post a grand total of 3 blog entries for 2009. I am certainly hoping to improve on that in the coming year. Again I wish everybody the very best for 2010 !!!

From the read me the following features are available,
1. WCF service model programming using one way contracts
2. WCF channel model programming using IInputChannel and IOutputChannel based factories
3. Programmatic access to AMQP message properties on WCF messages
4. AMQP version 0-10 (as provided by the Qpid C++ native client library)
5. Shared connections for multiple channels based on binding parameters
6. WCF to WCF applications (using SOAP message encoders)
7. WCF to non-WCF applications (using raw content encoders)
8. Rudimentary AMQP type support for headers (Int and String)
9. Channel functional tests using NUnit
10. Programming samples

There are several opportunities for folks to collaborate in this area. Cliff Jansen who worked with Qpid on the code drop identified the following areas as potential areas for contributions.

From qpid/wcf/ReadMe.txt:

2. Planned features (not yet available)
=======================================

1. Full AMQP type support, including maps and arrays
2. System.Transactions integration (local and distributed with dynamic escalation)
3. Prefetch window for inbound messages
4. Shared sessions
5. Connection failover with AMQP broker clusters
6. Temporary queues
7. Broker management
8. System logging and tracing
9. CMake build system support
10. Transport and message based security

One item that I would like to add to the above list is documentation for the WCF client and it’s examples.

If you are interested in contributing please join us by sending an email to dev-subscribe@qpid.apache.org
You are most welcomed to contribute by way of code, testing, providing feedback or documentation.

In any case it is important that software engineers develop necessary skills to handle such situations effectively. Some of these skills will help when communicating within your organization and some for life in general.
Following are some tips that may help you to make your engagement a productive and a pleasant one.

1. . Pay attention to the subtleties when communicating over email.
   It is often easy for people to misunderstand you when communicating over email as opposed to phone or in person. The tone could be easily misunderstood as being aggressive or rude as the person reading is unable to gauge your emotions or see your body language. This is especially important if you haven’t met them in person or spoken to them over the phone. Generally once a person can put a face to a name it becomes a bit more easy.

   I have had several instances where this has happened and I now pay close attention to any email I send out to ensure that I communicate exactly what I intended.

   Also it is important to state the obvious at least for completeness sake. What is obvious to you may not be to others. This especially important when using emails as there is no opportunity for instant feedback/questions. Otherwise it will result in lengthy email threads.




2. Respect the people you are dealing with and try to build good working relationships
   Telling a customer to RTFM is probably not a good idea. Even if you are frustrated due to repeated questions that you have answered a 100 times to several people during the last few days, it is best to answer it one more time. Even when you have no choice but to tell them to RTFM, do so in a respectful manner which doesn’t make people feel bad. Nobody in this world wants to be belittled or disrespected. When egos are hurt it creates a very unpleasant work environment.

   In fact good healthy relationship can go a long way in making sure the project runs smoothly and successfully.




3. Your code vs my code - avoid the customary finger pointing
   Most people are very passionate about the code they write. And often when there is a problem we tend to take a defensive stand. Anybody who has seen a conversation between a programmer and QA engineer would know what I am talking about.
   But when you are dealing with a customer, you need to be extra careful about how you look at a problem. Even if the issue is not in your product you need to control your urge to point it in the same emphatic way you do so with your QA folks. You need to be more diplomatic in how you point out the bug on their side and try to avoid using words like “your code” or “our code”.




4. We can’t reproduce in our lab environment is not a good answer.
   Certain problems may not be possible to reproduce (in the exact form), outside the customers environment as it is difficult to replicate the exact environment due to differences in hardware and not having access to their application binaries due to security, legal and other issues. . But it is important to identify the issues at a more deeper level. Perhaps if you understand the root cause, you maybe able to simulate the issue in a different way.
   Take the time to understand the issue and try to talk to all people involved to get a complete and accurate picture. From experience I have seen that sometimes you want get all relevant information the first time you talk to people. People often forget unless you ask probing questions. Most times the first reactions from people capture the symptoms rather than the root cause. So a careful analysis maybe need to nail the real issue.




5. Encourage the use of proper support procedures right from the beginning. Never take short cuts.
   I have been burned several times by not following this. When an issue happens it is important that you encourage your customers to follow the correct procedure. For example the use of a bug tracking tool instead of a series of adhoc emails. It is often tempting to ask customers to email log files, or if you are on site to walk over to their desk and try to investigate.
   But if you encourage the use of a bug reporting tool it will have several benefits. It will force the person reporting the issue to think through in a methodical way and capture all the right information while it is still fresh in their mind. For example most bug reporting tools have fields to capture version information, a problem description, a component, steps to reproduce (if any), expected and observed result and provisions to attach log files ..etc. Once information is captured in a central location it is easy to share that information with your engineering team rather than digging through a series of adhoc emails.




6. Proactively educate the people you work with
   By experience I have found it is helpful to have a meeting as soon as possible with all involved parties and educate them on the following. Some of these may have already being communicated to them. But most may have forgotten or in some cases not being given to them at all.
   • Provide links to documentation, training slides ..etc
   • Educate them on the proper procedure to follow when reporting issues (can’t stress this enough)
   • Based on the most frequent questions, try to provide an faq that is tailored to their environment
   • Once you identify the full system setup provide a basic trouble shooting guide for them to isolate if the issue is related to your organizations product or not. This I found reduced a lot of pain and non issues being reported.
   • Provide useful links to other skills involved in the project. For example I sometimes encountered folks who work mostly in a windows environment, but now dragged into a product being deployed in a unix environment. So links on basic unix skills would make it easy on everybody in such a situation.




7. Don’t babysit the people you work with
   Initially you may get into the habit of spoon feeding information and babysitting them. This may seem like an easy option rather than trying to get them involved in the process. But it is in everybody’s best interest to get the customer to gain as much confidence in getting to know how to install, debug and use your product. This will reduce a load of pain later on in the process. Also try to,
   • Avoid getting sucked into debugging the customers code.
   • Avoid the temptation to debug or fix an issue on your own. Try as much as possible to get them involved in the process.
   • Document trouble shooting attempts and consolidate them into a trouble shooting guide. Most products have official trouble shooting guides, but a supplementary trouble shooting guide tailored to their environment and using terminology familiar to them will make them more comfortable.




8. It is helpful if you have multiple programming language skills
   Since you write code, the customer will expect you to answer questions at the code level. Sometimes you may have to review code segments and provide an opinion. However if your product is providing clients in different languages, these questions may be in a language that is outside of your core competencies. Therefore it is important that you have a at least some knowledge using those languages.
   In general the ability to write code in several languages is always an added bonus as you will be a valuable asset to the company.




9. Know thy unix tools
   Also if you are in the unix world it is nice to have some skills in basic unix tools like top, vmstat, pmap, netstat, sar, lsof ..etc and text processing languages like perl, awk, sed etc. These tools can help you diagnose issues and obtain important information about the env. The text processing tools will be invaluable when you need to make sense out of massive log files or other text processing tasks. These skills will make you more productive by allowing you to extract information quickly and efficiently than just using grep or crunching numbers using a spreadsheet.




10. Keep your conversations professional and never take things personal
    You always need to remember that you are representing your company/product and the team you work with. Therefore the people you work with at a customer’s site may directly vent their frustration at you. This may manifest in the form of rude comments, lack of cooperation and in rare situations a bit of yelling (Fortunately I’ve only seen only one such incident that happened a few years back) . Never take them personally or get into any sort of argument. It is best not to take anything personal or get emotionally involved. When the stakes are high and push comes to shove, humans will react and we need to understand that and continue to behave professionally. Sometimes all they expect is for you to keep quiet, listen to them and empathize with their situation. And something simple as “I hear your point/understand your frustration. We are doing all we can to help” is all it takes.

    However if you are finding it difficult to cope, it is best to bring it to your managers attention and discuss possible measures to address the situation. It’s a bad idea to just keep quiet and bottle them inside, as you run the risk of an emotional outburst. Let your manager help you by dealing with the management on the customers side. All though the customer is the king, it is not acceptable for anybody to be treated badly.

Apache Qpid (http://qpid.apache.org) is a cross platform enterprise messaging solution which implements the Advanced Message Queueing Protocol (http://www.amqp.org).
It provides brokers written in Java and C++ and clients in C++, Java (including a JMS implementation), .Net, Python, and Ruby.

New features included in this release are:

• .NET, WCF and excel support for AMQP 0-10
• SSL added for C++ broker and all clients
• Windows port for C++ client & broker
• C++ Broker
  • ACL
  • Active-Active clustering
  • Federation, push bridges & dynamic routes
  • RDMA for C++ broker & C++ client (70-80us, yes us max latency on a well setup machines)
  • Support for message TTL
  • Queue options
    • added RING/ STRICT ring
    • LVQ
  • Exchange options
    • LVE
    • message sequencing
  • XQuery based XML Exchange now as plugin
• Performance work
• Management for AMQP 0-10
  • QMF C updates (console)
    • Python
    • C++
  • QMF Agent
    • C++
  • QMan JMX bridge for QMF
  • Alerts/ logger for QMF events
• JMSXUserId
• Java broker
  • Message Priority
  • bug fixes
  • some prep work for AMQP 0-10

It is available to download from:
http://www.apache.org/dist/qpid/M4/

Complete release notes are available here:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310520&styleName=Html&version=12313279

Spin bowling is more art than science. The principles of spin bowling are very simple. One could learn to bowl spin by learning these principles, but mastering them is an art. A closer look at spinners who were successful at their trade, shows that each made an art out of these principles. They had something unusual to offer that set them apart from the rest of the pack.

Looking at some of the greatest spinners, for example Bhagwat Chandrasekhar had an unusually whippy action due to a withered arm which was a result of childhood polio. It is said that he delivered googlies, topspinners and leg breaks at near medium pace and eventually producing an unplayable delivery. Abdul Qadir had a fancy run up, the temperament of a fast bowler and good variety to back it up. His googly was probably the best. Muttiah Muralitharan was a vicious spinner of the ball on any type of surface. Saqlain Mushtaq was probably the first to use the “doosra” effectively. Shane Warne undoubtedly the best leg spinner we have seen so far, has quite a bit of variation. Then finally you have Ajantha Mendis who uses variation as his main weapon. All these folks mixed their unique talent (and their deformity in the case of Mural and Bhagawat) with these principles to create an art form that is almost magical. (For the die hard fans, the above is not an exhaustive list of great spinners. So if your favorite is not listed there please do not think I have thought less about your favorite spinner).

As a bowler you need to consistently beat a variety of batsmen to become a successful bowler. Sure you may get a few freebies when the batsmen eventually makes a mistake (every human is going to make a mistake at some point) or due to pressure at the other end. But if you need to improve your wickets column and become a champion spinner, then you have to ensure that the batsmen makes those mistakes while you are bowling.

There are several ways to beat a batsmen and more often than not a combination of those techniques is what buys you a wicket. Most of these techniques are intertwined. One technique is to try and out think a batsmen. For example Shane Warne always tried to anticipate a batsman’s move and bowled accordingly. Creating doubts in a batsman’s mind is another way. Ajantha Mendis is a master at this as he bowls very accurately with subtle changes in the direction where the ball spins. Bhagwat Chandrasekhar didn’t even know what would happens when he bowled and never planned his deliveries. When a batsman is not picking up the variations he begins to doubt and his confidence suffers, effectively stifling the scoring and increasing the chances of making a mistake. Deceiving a batsmen is another way. You could deceive a batsmen through changes in the amount of spin imparted, pace, line, length , flight or direction of spin by cleverly disguising your variations off the hand. For example a spinner could bowl a quick top spinner, a cleverly disguised googly or an arm ball. The batsmen depending on his ability and concentration level may not pick the subtle change in your action, the pace or the direction it takes off the pitch, Yet another way is to setup and lead a batsmen into a trap. For example a leg spinner or an off spinner could use their stock ball on a given line and length and then stealthily produce a googly or a doosra on the same line and length inviting the batsmen to make a mistake. Or the trap could come in the way of a cleverly placed field setting.

If we look closely most of the great spinners, have devised their own way of executing those techniques. The rest are ordinary bowlers who approach spin bowling mechanically as a science and most with a bit of coaching can get there. But the legendary spinners used what ever skill they had to transform spin bowling into an art of it’s own. Great spinners are not made, they are born.