For a while now I have been using a tool that I created called the Jazz Support Handler. I originally created it as part of a thought experiment of how to bring some of the Jazz.net experience into the Rational Team Concert client. The tool automates searching Jazz.net and Google when an error occurs inside of eclipse. This saves me a lot of copy/pasting and additional browser windows. With the upcoming release of CLM 4.0.3 and the move to Eclipse 4.2.2, I thought I would update the dependencies and make it available to the public.
Now this tool will only catch errors passed to the ErrorSupportProvider from the Eclipse Workbench API. it only works while the eclipse workbench is still active. Lastly this is a non-supported tool. Although I do work for IBM this is not supported by IBM nor myself. That being said I do encourage you to comment on this post with any trouble you may have.
The latest bits are designed to work with the Rational Team Concert 4.0.3 Eclipse client (3.6.2 or 4.2.2 Eclipse clients). If you have RTC 4.0.3 installed in another Eclipse client than it needs to be Eclipse versions 3.6.2 or later. Eclipse also supports numerous operating systems but I have only tested it under Windows XP, Linux (Ubuntu, RHEL 6.2, and Fedora), and Apple OSX.
From the Work with drop down select “All Available Sites”
Select Jazz Support Handler and its child feature.
Accept the license.
After the install has completed there will be a new “Jazz Support Handler Category” in your Eclipse Preferences dialog. This new preferences area is where the Jazz Support Handler can be configured and tested.
There are three basic settings available to the user.
Enabling the Jazz Support Error Handler or using the default ErrorSupportProvider.Eclipse only allows for one error handler to be enabled at a time.
Which data sources do you want to display? Google? Jazz.net? both? neither?
What do you want the tool to ignore? I am always amazed how much search engines can know about their users. I normally add filter words for my projects which prevent project specific errors from being googled.
Finally there is a test button. This is very useful for testing filters and also allows you to see the dialog without the need for an workbench error.
Every iteration my team explores ways of reducing time required for QA/Testing. We are a small team and do not have dedicated resources for Quality Assurance. That being said, what we can do is reduce the amount of defects found during that time. The best way to do that is to follow a Test Driven Development (TDD) methodology where you write your test from requirements before writing application code.
Now of course you cannot test everything but you can test close to one hundred percent of requirement and code coverage. Now Test Driven Development usually is done with Unit Test but it can be done with Functional Verification Test (FVT) and Performance Verification Test (PVT) as well. However FVT and PVT require a level of requirement elaboration/documentation that is not always available. That being said Automated Unit Test done right will reduce a large amount of possible defects.
How to perform Test Driven Development?
Now I alread described Test Driven Development (TDD) above but I thought I would go a bit deeper first before jumping into implementation across languages. TDD is more than writing a test before code. Rather it is a repetitive iterative process of adding changes in bite sized pieces.
I recommend the following path:
Start by writing a test for the smallest requirement, defect, or change request that has little to no dependencies. The smaller the change the less understanding you will need of the larger picture.
Run the test you just wrote. If it succeeds then the existing code supports it and you should move on to the next smallest requirement.
Write just enough code to make all of the test pass. If you have a dependency on another component that has yet to be defined or written then create an interface and mock it (I talk more about this later).
Refactor your code to make it cleaner and smaller while rerunning all the test to ensure you don’t break any functionality. This also removes any dead code from retired functional requirements.
The component is a simple application to read an email from a string and look up the title in an external directory (i.e. LDAP). Now the external directory doesn’t exist so I use a Mock object to test the components.
Unit Testing Perl
Unit testing in Perl has been around for a long time. However I often describe Perl code as being pre or post 2008. That is when Adam Kennedy gave a talk about managing a massive amount of perl code and why testable code is important.
My favorite quote from the talk is “Our ability to create software is limited, primarily, by our ability to test software.” I also love the references to the city of London’s 19th century sewers. I recommend every Perl programmer watch this presentation. You can look at any Perl code and tell if the developer used principals from this talk.
Now perl is a very dynamic language where you may only be able to identify dead code during runtime. I typically use Devel::Cover to identify dead code.
On one hand you get the benefit of an interface but the failure to implement a function is only known during runtime which is bad. As always I am open to suggestions and feedback.
Unit Testing in Java
JUnit is possibly the most popular Unit Testing frameworks. It is also included within Eclipse by default and there are tools provided to make Test Driven Development a first class citizen. There are numerous tutorials available on the topic.
Test Driven Development is a very powerful tool. Looking at code writen using this method there is an obvious difference. Code is less buggy and easier to manage. You have confidence your code is sound without having to implement the entire application. I also want to mention Jurgen Appelo excellent article on implementing a requirement across multiple iterations TDD style.
Now I purposely left some topics out for future blog post. For instance as I mentioned earlier it is possible to use Functional Verification Test (FVT), Business Verification Test (BVT). Performance Verification Test (PVT) as part of Test Driven Development. You can do more than simple Unit Test but there are more than a few gotchas.
One of the great things about Rational Team Concert is it brings an awareness to a Development team. Now outside of the CLM Dashboards and the thick clients that awareness continues in the forms of email and news feeds. Now everyone knows email but when left unchecked your Inbox can become unmanageable.
My personal preference is to use the news feed capability of Rational Team Concert. Not only does it provide notifications out of my inbox but it allows me to have greater control over what I want to see. I can take any work item query and turn it into a feed.
Sandro Mancuso recently published a video on “Testing and Refactoring Legacy Code.” One of the key benefits for writing test for legacy code is it allows you to understand the existing code while reducing risk in changing it.
It is a great video but a bit long so here are some of his suggestions.
Do not change production code unless it is covered by a test.
Start testing from shortest to deepest branch. The Shortest branch will require less understanding of the code base.
Start refactoring from deepest to shortest branch.
Do not execute another class from the unit test. The test should only care about the class it is testing. Otherwise you may be testing components (database, external systems, etc…) that you don’t want to test right now. Refactor the Singleton, Static call, or object to a protected method (Seam) and overwrite it.
Feature envy is when one class/method has functionality that probably belongs in another class.
Guard clause is a parameter check and should be moved earlier.
Bring declaration of variables and the code that uses the variable closer together.
My team is currently in the process of documenting a project we inherited. The project was a skunkworks effort and documentation wasn’t as important as proving that it works. The developer who wrote it is no longer on the project and isn’t the most pleasant person to interact worth so we are on our own. The interesting thing about this exercise is we are realizing how much lack of documentation cost a project.
The number one reason for documentation is so another developer can step in and keep the project running if you are hit by a bus, falling piano, or UFO. The big motivator for us is code refactoring and removing dead code becomes very hard without proper documentation.
I was watching a presentation by Jack Diederich on code reduction and one of the reasons he often hears against removing dead code is “It might be used…somewhere.”
As he points out when using a dynamic language it can be very hard to identify if code is called or not. He recommends adding a comment to indicate where code is called from. Using code coverage tools does help identify dead code but you need to have a full understanding of the use-cases or else you may accidentally remove code that addresses an edge case.
Documenting legacy components can be seen as an expensive part of a project but will ultimately reduce technical debt and save time later on.
When I first started developing web sites choosing a color was easy. There were not that many to choose from. Of course HTML at that time supported 16 million colors but any competent web developer would limit it to web safe colors. I remember working for a small startup and had to tell the head of marketing that the logo and branding colors were not web safe. The Visibone color guide came in very handy back then.
Today picking a color scheme for a web site is not as easy because you have significantly more colors to choose from. Now I should mention that not all colors appear the same on each monitor and people see shades of color differently. Radiolab did a great podcast on how we see and experience Colors.
When I am developing sites for work it is easy because their are color guidelines I need to be in sync with. So here is my advice for picking colors for a personal site.
Start with one color
Most WordPress themes ask you to choose a plethora of colors (background, foreground, text color, title color, link color, etc…). You want to start with one color and select other colors that complement. The next question comes down to how to pick one color. Now people spend a lot of time and money to come up with a single color. There is a whole psychology behind picking colors.
Possibly one of the simplest way to pick a color is to start with an image that represents you. I am an avid Scuba diver so I started with an underwater photo I took of a shipwreck.
Now I am not a fan of background images. Frankly they can be extremely hard to do right and can add a good amount of size to a page. So I take the image and use a service like http://www.pictaculous.com/ to find out what colors I should consider.
Of the three colors selected I chose #001C4A.
Try out different schemes
I found my notes on color from Art class in College. There are plenty of different methods on choosing complementary colors which do not always translate well for websites. Even the tried and true 30/30/60 can look odd. Frankly you end up back where we started with color doesn’t always look the same and the color of the content (pictures, embedded players, etc…) can make that color look different.
What I like to do is just try different palettes that contain my color from popular color palettes sites like Kular, ColourLovers, ColoRatate, or Color Explorer. It is very simillar to the process of picking up swatches at Home Depot and attaching them to the wall to see if they work.
Over the years I have started many project and handed them off to others both successfully and unsuccessfully. Now as developers we develop and document our code/project as though we are going to get hit by a bus, meteor, or falling piano the next day. Then we are shocked when another person looks at our code/documentation and can’t successfully pick up where you left off. This weekend I performed a retrospective on my projects over the years and made a list of the following best practices.
Don’t expect the person owning your code to be like you.
I once had a developer tell me that his documentation is only meant to be a memory reference for him. This is obviously a bad practice however in many respects we document less for things we think is obvious. For instance I may write java code that will be handed off to another Java developer. Now I am a Test Driven Developer and utilize the JUnit library to verify all of my code. Now just because the developer accepting my code knows Java does not mean that he/she knows JUnit. So I may have each test case very well documented but that doesn’t mean the new developer knows how to run them.
I recently watched an interview with Alton Brown about writing a recipe. He recommended against documenting everything. He tried to document how to make a soufflé for aliens and gave up after 20 pages. There needs to be context or shared experience for this to be feasible. He takes an interesting approach by applying cartography techniques to recipe writing.
Give the person a top 10 list
Just because the person will receiving responsibility for your project doesn’t mean they can absorb 8 months of knowledge in a week. Provide them a Top 10 list to keep the lights running for the project. It is also important to footnote this list with what is not included and would require deep knowledge. I once had a developer maintain a project with only that list only to have the project explode 5 months down the line. There needs to be an understanding that the list will not solve everything.
Give the person a fool proof work environment
Everyone’s development environment is different and a huge amount of time can be wasted trying to get your project working in their environment.
Get more than simple sign off
Most project management documentation emphasize the importance of obtaining sign-off from the other person before the hand off is complete. In my experience developers sign off on accepting projects like people accept iTunes EULAs. There needs to be more involved in accepting a sign off.
One technique I have done over the past few years is to give the new developer homework. If the developer can make an enhancement or fix a core defect then they know the code well enough. Performing a code review of their change doesn’t hurt either.
Go on vacation
There should be a sense of urgency to encourage the developer to take ownership. They do not need to be that self reliant if you are always reachable. I like to set a deadline where I will not be available. Now I should mention that you shouldn’t hand off a project and then go immediately on vacation.