Agile Open Space

I enjoyed facilitating an Open Space meeting for agileLUNCHBOX today.  This was the first such meeting for that organization.  We had around 20 participants and did 2 rounds of discussions, in 3 circles.  We had a variety of topics posted and some great discussions.  I took a few photos of the event, which you can see below; including one that shows the topics that we discussed.  Click on an image to see a larger version.

Before kicking off the discussions I gave a brief overview of Open Space Technology.  Here is the short slide deck I went through.

At the end we had a brief retrospective and it was the general consensus that we should do another Open Space meeting at agileLUNCHBOX in the near future.  We are also going to look into having an Open Space evening at COHAA, where we have more time to work with.

Web Service Testing Talk

Today I gave a talk on Testing Web Services at the monthly QSI Tech Lunch.  I basically went through various products and frameworks that I have used when testing Web Services, talked about what kind of testing each one is suited for, and provided some general tips on Web Service testing.  I have uploaded the slides from the presentation to Slideshare and the code and test-scripts are available on GitHub.  I will be repeating this talk (likely with slight modifications) at the 2013 Columbus Code Camp, next month.

7 Reasons to Become a Software Development Consultant

I have been a software development consultant for a few years now.  I sometimes get asked by friends and colleagues why I prefer being a consultant rather than becoming a full-time employee (FTE) at one of the many companies I have done contract work for.  Here are some of the reasons why I think consulting is the way to go.

1. It forces you to stay on top of your game and as a result you end up becoming a very well rounded developer  
• You can't get away with just learning the technology stack of a single company and eventually becoming stagnant.  You need to stay marketable, follow trends and learn the latest and greatest.
• When working for a consulting company you are encouraged to attend conferences, do public speaking, etc. to enhance your career.     
2. You get exposed to many different technologies and have an opportunity to learn a lot
• I have never been hired onto a client assignment knowing every single technology listed on the job posting.  There are always some things I don't know beforehand, and as a result of the assignment will get to learn those.
3. You end up doing a lot more new development (green-field projects) than you would ever do as an FTE
• Consultants are rarely brought in for maintenance work, carrying the on-call phone, or doing production support; things that most developers are not too found of.
4. You get to shop around and see how multiple companies do their software development
• Eventually you become really good at picking up good habits from your clients, stuff you see that works, and assisting other clients in doing the same.  That makes you really valuable and your work rewarding (what you do matters).
5. You typically don't do a lot of overtime, but when you do, it is paid
• Clients are much more likely to ask their FTEs to do overtime than a consultant that they have to pay extra for.  Contracts are typically written with a 40 hour workweek in mind.  Any change in that requires paperwork and additional expense to the client (throwing off their budget), so most clients tend to avoid that.
6. You get to work with and learn from really great people  
• Consulting companies thrive on having the best and brightest minds and they ensure their employees do a lot of knowledge sharing.  QSI, the company I consult for is excellent at doing this.
• Most clients you end up working for have some really good people as well (architects, tech leads, etc.), that you get to learn from.
7. You are not stuck in the same old job
• After few years in the same place many developers get bored and start wondering if the grass is greener somewhere else.  Being a consultant means you will have a frequent change of scenery, so you rarely have time to get bored.  If you like your client and do a good job, you can likely get renewed with them as long as you care to (for years).  If you are ready for something else, then complete your assignment and work with your consulting company to get a placement somewhere else.  It may take some time to get it worked out (you want to make sure you end things on a good note with the client), but it is a lot easier than having to quit your job and find a new company to work for.

Lastly, it is just a lot of fun!

Visually Import SSL Certificates to Java Keystores

Working with SSL certs in Java, in particular those self-signed ones frequently found in dev & QA environments, usually means dealing with the command line keytool that comes with Java.  Either to add a certificate to a keystore (JKS file) or to add a new certificate authority to your truststore (cacerts file).  If you are tired of reading the keytool help or googling what the exact import command looks like (and have forgotten it in the year or so since you last had to deal with it), I recommend the GUI tool Portecle.  It makes it very easy to view the contents of a keystore/truststore file and to import new certificates, and it allows you to download public certificates right from within the tool.

To add a public key certificate to a keystore, open up the JKS file in Portecle, select Examine SSL/TLS Connection and type in the hostname and port number of the https site you would like add certificate from.  Then hit the PEM encoding button and save the certificate to a file.   Next click the Import Trusted Certificate button and select the file you exported and hit save.  That's it!

To add a trust for a new certificate authority in your truststore you open up your cacerts file (password most likely 'changeit') and add the CA certificate file via the Import Trusted Certificate button.  You will need to locate the CA certificate file on your app server and convert it to PEM format if it is not already in that format.  For example in WebLogic the CA file is located in the [WebLogic Home]/server/lib directory (CertGenCA.der by default).  In IIS you can export the CA file to PEM format through the IIS Management Console.  After importing the CA file to your cacerts file your JVM should trust certificates issued by that CA.