The Binary Anti-Pattern

Publishing to Maven Central

2012-12-24T12:56:00.001-05:00

I just recently went through the exercise of publishing an artifact to Maven central and must say, once all is done, I feel pretty good about it. This is the first artifact that I have pushed to a central repository and I am hoping it will help others like me.

After a brief scan of the Maven Guide on publishing artifacts I learned that the only way to publish is to either use one of the approved repository hosting locations - such as Apache, Codehaus, … - or use the Sonatype OSS Repository. Since I assumed that publishing a small project such as mine to a giant like Apache would be unfeasible due to certain requirements for accepting projects - and if anyone knows otherwise I would love to hear it - I decided to use the Sonatype OSS Repository, which I have used extensively in the past - and even hosted on a previous company I worked for.

The Sonatype Documentation for the publishing process is comprehensive but cumbersome, I had to go through the process several times to get it to work appropriately, but I finally managed to successfully promote a release. In short the process is as follows:

Create an account on the Sonatype JIRA site and provide some basic information for your project. You will need to ensure your project is hosted on a public SCM such as GitHub. Once you create the ticket, you should get a response really quickly with information on your new repository. I filled a ticket on a Sunday and got a response on the next day in the morning. Take a look at the third section of the documentation to understand what data you will need to provide them.
Maven itself has certain requirements - understandably - that need to be fulfilled before you can push artifacts. These are most straight forward, there are a couple of paragraphs you must read to ensure your pom file has all the required elements. Additionally, you will need to sign your files with a public key, and I found the easiest way to accomplish this ( aka: automate ) was with the maven-gpg-plugin. Some observations on using the plugin:

Since I have multiple keys installed on my system I had to add a few configuration pointers to the plugin descriptions. You can take a look at my current pom file here.

Deploy a snapshot to Sonatype through "mvn clean deploy". You will need to provide your passphrase if you have configured maven to automatically sign your files. Make sure you also generate the javadocs and sources jar ( which can also be automated through the pom file ) since these are requirements for Maven Central. Lastly, be sure your version is qualified as snapshot or the submit will fail with a generic HTTP 401 errors. Don't worry, the release plugin will remove the qualifier before it publishes a staging or release version.
Once you have a snapshot published to Sonatype, you can not push a release staging version. This is accomplished through three commands:

mvn release:clean
mvn release:prepare
mvn release:perform

I had to go through the cycle "publish snapshot", "release" a few times before I got it working, but I believe the trick is to follow a few base rules:

Ensure that your code is committed to your SCM. The release process will fail otherwise.
Ensure your version contains the SNAPSHOT qualifier before trying to push a snapshot. Don't remove it, the release plugin will take care of that.
Ensure you have specified both your repository and snapshot repository on you pom file, and that you have added the login credentials to your maven settings.xml file ( usually under ~/.m2 ).

Now that you have your release staging artifact on the repository, the next step is to promote it. You will need to go to the Sonatype Nexus UI and under "Staging Repositories" (on the left) you will find the staging repository you want to promote. Once selected, you will need to hit the close button on the actions bar.
If all went well, the release button should now be enabled and you are ready to promote it.
The last step is to update the JIRA ticket to let Sonatype know that your first release is ready to be pushed.

The entire process is a bit convoluted and the error messages don't always help you pinpoint the cause of the issue, but I feel once I have been through this a few times it will become much easier to share some new cool open source artifacts with the community.

I hope this can provide some help to others who like me are getting ready to go through this process for the first time. Please do let me know if you found this helpful or if you run into any snags.

Fast REST APIs using RoR

2011-08-06T18:27:00.006-04:00

I have been working with SOA and Java for a few years now and on that environment, the so called enterprise applications environment, SOAP is king. There are various reasons why I believe SOAP/HTTP has its place and I will not get into this discussion on this post, but we must recognize that the simplicity and ease of use of REST services makes it unequivocally attractive for developing web based applications and high data volume API implementation.

It is no secret that I find Ruby a very elegant object oriented programming language, and that Rails is a very solid framework for building web applications using the MVC pattern while following Ruby’s DRY (don’t repeat yourself) principles. So it will be no surprise to anyone when I say that two weeks ago when I had to choose a language for building an API for a new prototype I have been working on my decision was easy, REST services using Ruby on Rails. In this article I will show you how to build a quick REST API for your web application.

We will start by creating our sample application for this article, which is made easy with the Rails script which should be available on your shell if Rails has been properly installed.

[rcracel@macmobile] rails > rails new blog-rest-api

This will cause the rails project to be created. You can look at the log messages produced from the script to see all the supporting files and configuration created in the process. Next we will see how we can use scaffolding to further help us creating the basic functionality for our new REST API. Rails scaffolding creates model, views and controllers for a new resource with a single command. Let’s create our coffee cataloging API.

[rcracel@macmobile] rails > rails generate scaffold CoffeeBean variety:string comment:string

Go ahead and open you controller to see how the scaffolding process created methods for performing CRUD operations against your coffee beans. At this point you should be able to fire up your rails server and test the newly created application code, but we won’t do that just yet. You should notice that the controller created knows how to handle requests for HTML and XML data, but since we are building a REST API for our web application, we probably should support JSON as well since most requests will likely be made using Javascript. To add support for JSON to our index method, we replace it with the following:

def index
  @coffee_beans = CoffeeBean.all
  respond_to do |format|
    format.html # index.html.erb
    format.xml  { render :xml => @coffee_beans }
    format.json { render :json => @coffee_beans }
  end
end

All we had to do is add the extra line for the json format to the method. Now lets go ahead and add that to all the methods on the controller to ensure they all support the JSON format on all of the different request types. Once all methods support the JSON data format, you can generate your database tables and start your server.

[rcracel@macmobile] blog-rest-api > rake db:migrate
[rcracel@macmobile] blog-rest-api > rails server

At this point, you have a fully functional REST API for storing and querying information about coffee beans, but at this point you still have no data. Lets add some data to our database first so we can make better use of the newly created API. If your server started successfully, you should be able to go to http://localhost:3000/coffee_beans/new and insert a new coffee bean definition. Also important to note is that the HTML format is assumed when no format has been specified, which is helpful in this case for adding data to our database using the HTML forms. You can find sample data for you application from Wikipedia, so lets insert a few records on our database in order for us to have some data for querying.

You will notice that once you insert your first record, you will be redirected to the coffee bean record you just created at http://localhost:3000/coffee_beans/1, where you will see a nicely formatted description of our coffee bean. This is ideal for humans, but not for automation where other applications may need to query data from our API. We can easily fix this by adding the appropriate format to our request - we currently support XML and JSON - by adding an extension to the request url. Try appending “.json” or “.xml” to the end of the URL to see what you get back. A javascript application, for instance, will likely opt to send and receive data using JSON instead, but if you try to get data from our API using JSON you will notice that the response will include our root object name in it, which increases the size of the response and the amount of code you need to write to iterate over it. Although having the root element may provide useful information regarding what kind of elements we are returning from user requests, in this case we know only coffee beans are to be returned.

We can tell Rails to not include the root element on the response by adding the following command to the application’s procedures:

ActiveRecord::Base.include_root_in_json = false

This can be accomplished by creating a new file inside ‘config/initializers’ containing the line above. You can give the file any name that you feel is sufficiently descriptive, but in my case I just named it ‘application.rb’. At this point you will need to stop your server (ctrl-c) and restart it for the new initializer to be loaded, and now when you refresh your page you should see that your root element name is no longer part of your response.

I hope this gave you an idea of how easy building REST API with Ruby on Rails may be. Be warned though, showing this to your [quasi-technical] may lead him to think that anyone can build any sort of application overnight using Ruby on Rails! Good coding!

UPDATE: Added source code for this example to GitHub (https://github.com/rcracel/CoffeeBeans)

First iPad App: update

2011-01-19T21:30:00.000-05:00

So far, I was able to produce and deploy to my iPad a prototype of what the blogging application is to become. With very limited functionality, I can now login to my blogger account (and persist my credentials), retrieve my list of blogs, retrieve the list of posts for that blog, and retrieve the actual article. I will post screen shots soon. Not much, but still I am pretty impressed with how much I've accomplished in a few nights, considering that two weeks ago I knew nothing about objective-c.

The tale of retain, release and autorelease

2011-01-19T21:24:00.002-05:00

After dwelling with objective-c for a couple of days now, I think I finally understand the basic rules of engagement when it comes to memory management. And to my surprise, the basic rules are rather simple. Look at the following three lines of code:

NSString* string_one   = [[NSString alloc] init];
NSString* string_two   = [NSString stringWithString: @"Some String];
NSString* string_three = [myObject name];

On the first line, you are using the alloc selector to allocate memory for a new string. The string returned by the alloc selector has a retain count of 1, therefore you must release (or autorelease) this object to avoid memory leaks.

The string on the second line is created using the factory selector stringWithString. The returned string is already autoreleased, therefore you do not have to release this object. You do, however, must retain it if you intend to keep it around past the end of your block of code (selector) and eventually release it at some point (possibly on the dealloc selector of your class).

The third string is being returned by a custom object. According to the rules of engagement, the block that created this string (the selector) should have returned an autoreleased string, much the same way stringWithString on the previous example does. Therefore you should follow the same rules as you would for the previous line.

This also bring up the question of what you should do on your own selectors when you need to return objects. To avoid memory leaks, you should always return autoreleased object from your own selectors, as it is the responsibility of the invoker to retain the object if needed.

To better illustrate all three cases above, take a look at the following snippet:

-(void)didReceiveEvent:(NSString*)objectName {
    name_one = [[self createRandomName] retain];
    name_two = [objectName retain];

    NSString result = [[NSString alloc] initWithString:@"3rd string"];
    return [result autorelease];
}
-(NSString*)createRandomName {
    NSString* randomName = [[NSString alloc] initWithString:@"rndm"];
    return [randomName autorelease];
}
-(void)dealloc {
    [name_one release];
    [name_two release];
}

One small detail in here is that due to memory-constraints on smaller devices, Apple discourages the use of autorelease on its mobile devices (IPhone, IPad, ...) in blocks of code and methods. Autorelease will cause the memory allocated for a given object to be retained for a "undetermined" amount of time and, specially during memory intensive operations, can cause the device to run out of memory. Therefore, although valid code, the following should be avoided:

-(void)someMethod {
    for ( int index = 0 ; index < [array count] ; index++ ) {
        NSString* message = [[NSString alloc] initWithFormat:@"This object was found: %@", [array objectAtIndex:index]];
        NSLog( message );
        [message autorelease]; // should release instead, as array could be very large
    }
}

Hope this helps others understand reference counting under objective-c a little better.

Now my little disclaimer: the code above is not guaranteed to compile, nor should it be used for any purposes other than illustrating the concepts covered on this article. Use it at your own risk. :)

First iPad App: Shooting for the stars

2011-01-18T08:45:00.001-05:00

After reading about a book and a half in objective-c, I decided to take on the task of writing a full iPad application to test my newly acquired skill. I wanted to write something that would use some of the relevant technologies that are widely used in the industry, but focusing on some of the items new developers have difficulty with... well, why not write a app that would allow me to monitor and post articles to this blog?

From my research, these are some of the items I would have to get proficient with to be able to write a fully functional application to interact with the Blogger API:

HTTP Requests (both GET and POST) in asynchronous mode
XML Parsing
Mixing up different types of view controllers (plain, navigation, ...)
Persistent storage for user options (username, password, ...)
Memory Management (although not really a technology per se, this probably tops the list of items people have difficulty with when learning a non-garbage collected language

I will also need to come up with a cool name and a nice looking UI, but first lets get it to work. As I progress with the development of this app, I will post articles on how I tackled some of those items, which will hopefully help people who are new to objective-c, such as myself.

I know that I have a big challenge ahead of me, specially after looking over the Google Blogger API and noticing that some of the features I would like to implement appear to be missing. At first glance there appears to be no way to get a user's profile, or a list of blogs a certain user is currently following (certainly a desirable feature in such an application), therefore I will need to look into alternate ways of accomplishing this (while trying to avoid screen scrapping at all costs). Although typically I would start by downloading the libraries provided by Google for accessing the Blogger API, for this app I have decided to take on the task of writing my own library for dealing with Blogger API data (Google API data).

Now let's get to work....

Learning Objective-C

2011-01-15T12:50:00.000-05:00

Although I still do not consider myself a Fan-Boy (perhaps this is just me being in denial) I am now a proud owner of a brand new IPad, and as any curious engineer I decided it was just natural that I would now learn to write applications for it. Perhaps because this is something that could help on the other project I am working on, perhaps because I need something new to tickle my brain, perhaps because I am really becoming a Fan-Boy? Nahh.

My obvious approach to this was finding a couple of good books that I could read on my commute to and from work, daily, to maximize my time and capacity of absorption (and make those 45 minutes I spend on the train each way a bit more productive). I found a couple of e-books (so I could download them on my IPad of course) and made the move to start the process of learning it. I just finished reading Cocoa and Objective-C: Up and Running and am almost halfway through Learning iPhone Programming: From Xcode to App Store, which I am hoping will provide me the basic knowledge I need to start writing applications for Apple's mobile devices.

I will keep posting my experiences in here as I find more time to explore it, and perhaps a few good examples of some of the chalenges I have encountered during my endeavors, but so far, besides some stumbles with the reference counting approach to memory management, I must say that its a very refreshing and dynamic language, and I am very excited with the possibilities and opportunities that will come from becoming proficient in it.

Starting a new project: Programming Languages

2011-01-15T12:28:00.000-05:00

A couple of months ago shortly after starting plans to work on a new application, I was faced with a very difficult decision to make: which tools and technologies we should use? The programming language landscape now days is almost as large as the number of cab drivers on the streets of New York... so which languages and platforms do we use to maximize our productivity (while working full time jobs) and still have the confidence we are building a solid application that will scale appropriately when (hopefully) our user base reaches the thousands, and even the millions?

Some of the obvious languages that first came to me were Java [the language, not the framework] (the language I am the most familiar with), PHP (I have done some PHP development in the past), Perl (known for being very fast), and Ruby (well, Twitter uses it right?). I will share the criteria I used to make this determination with you, and hopefully you can share your own experiences with me:

- Performance is critical, as this will be a web application with potentially millions of users.
- Fluid programming; I didn't want to have to spend hours trying to get around restrictions build around the language because of academic reasons (read Java).
- Community; I needed a language with a good community support so that I could get help and ask questions from a helpful crowd (I will perhaps elaborate more on this rant in a future post); This would also be a good indicator of how easy it would be to hire additional help if necessary.
- Platform and Frameworks: Efficiency in the implementation process is key, therefore the more tools and libraries available, the less time I need to spend writing boiler plate code.
- Easy to get it up and running.
- Hosting prices and options.
- Must be fun; Hey, I will likely spend nights and weekend working on this, so this is the least I can ask for from a programming language isn't it?

I ended up choosing Ruby (on Rails) for this new project, and picked up the following two books from the bookstore, which really helped me understand not only the language but the culture around it (and I do feel that understanding the culture of a programming language is key to becoming a proficient developer):

Beginning Rails 3 (Expert's Voice in Web Development)
Beginning Ruby: From Novice to Professional

Some of the reasons I eliminated the other languages:

- Java is a very bureaucratic language; after programming Ruby for a couple of months now I understand what the fuss is all about around adding closures to the Java language. Performance would also rank high on my list of concerns with using Java for such an application;

- PHP is fast, but I didn't find as good information (and feed back) about its many MVC frameworks, and I didn't want to end up writing the boiler plate code for a home grown framework to support some of the core feature I will need to implements;

- Perl is very fast.. but boy do I dislike it... and I assume this is personal, I just don't like the semantics of the language and all of the ghost variables that you need to know to be able to be an efficient programmer.

In summary, Ruby provided many of the features that I both needed and was used to (Object Oriented, MVC) and allowed me to get up to speed on both the language and frameworks around it.

A Follow-up on Data-Only Wireless Plans

2010-09-19T00:39:00.000-04:00

While spending a few hours at the mall today looking for a gift for a birthday party tomorrow I ran into a new store which caught my attention. The store was called Clear and their business is wireless data. That is when I decided to take a few minutes to walk in the store and have an interesting conversation with the only person on duty during that time.

During my time in the store I learned that the store is a front for Clearwire Corp (NASDAQ:CLWR), which I found out were the first and currently only providers of 4G data in the country. However, they are not your regular cell phone provider, they focus on the data segment only. As a matter of fact, Sprint Nextel, one of the major cell phone carriers in the US, uses Clearwire’s networks for providing 4G data to their clients.

The interesting important fact in here is that this is a data only wireless carrier, priced aggressively, with some major names amongst their investors (aside from Sprint Nextel, you will find that Intel, Time Warner and Comcast are amongst their shareholders). With plans starting at $25 a month and no service contract required, it may become a serious player in the wireless carrier sphere. We just need for more smart phones with WiMax support to be infused into the market and we may be able to finally say goodbye to the outrageous fees changed by the current carriers.

For those of you interested, some of the phones that currently carry WiMax chips are the Samsung Epic 4G, the HTC Evo and the HTC Supersonic.

Can cell phone carriers stop progress?

2010-09-17T23:32:00.000-04:00

Voice over IP has become the de facto telephony standard for all sizes of business, and already gaining traction with residential customers. In addition to using service provides such as Comcast and Verizon for dedicated VoIP lines in you home, we can also benefit from widely available free services, such as Skype and Google Voice, amongst others. Traditional telephony will eventually be replaced by dedicated data lines that will handle all of our communication needs, including voice and video. When will cell phone providers recognize that voice channels are a thing of the past and start offering reasonable data-only plans? With the growth of adoption of smart phones amongst US customers (25% of subscribers, according to Nielsen) we will soon have no need for standard voice plans. It would certainly be nice to no longer have to pay all those extra fees for minutes and text messages when all of this could be handled for a single fee over a data channel. Maybe that is why carriers are so hesitant to sell data only plans.

Cloud Computing: Virtual Desktops

2010-09-17T22:33:00.001-04:00

The concept of virtual desktops is not new, however just recently advancements in Internet technologies and the recent rise of popularity of cloud computing are expanding the use cases for the virtual desktop technologies. Aside from the regular office environment where having user desktops stored on the server can save the company money with decreased requirement for hardware and IT resources, there are several additional scenarios where I think this technology will eventual change the landscape of certain industries while increasing productivity and decreasing operational costs.

For instance, anyone who ever worked with 3D rendering or video editing, having powerful desktops capable to render complex animations is crucial, and often times delegated to a more powerful server for rendering of the final product. With virtual desktops able to deliver distributed processing on demand, companies may be able to save money not only on hardware but also IT infrastructure by no longer having to maintain local servers and paying only for the used CPU cycles.

Many companies have been involved in developing the future landscape of what we call the Internet. One such company that has been investing on development of cloud computing technologies including virtual desktops is Citrix Systems (NASDAQ:CTXS), which you may recognize as the providers of GoTo Meeting, currently competing with heavyweight VMWare on the virtualization domain.

The Myth of Platform Independence

2010-09-10T00:03:00.000-04:00

The idea of being able to write applications that run on any platform is very attractive both for developers and the people making the business decisions. Platform independence is a selling factor, that is coined to conceive the idea that once you write the code for your product, you can deploy it on any machine running any operating system. Well, wouldn’t that be nice?

The reality is that platform independence is utopia. A Shangri-la of software development. Platform independence is impossible to achieve. It is essential to understand that one will always need an interpreter to convert your code to a dialect (machine code) that can be understood by the underlying platform, and this interpreter, by definition, cannot be platform independent, thus making the entire process dependent on the platform you want to target, or at least a range of platforms, as is the case with the Java language (and all languages running on the Java platform).

Following up on the example of Java (as both the platform and the language), source code is compiled to Java bytecode, which is the intermediate language understood by the Java Virtual Machine (JVM). The JVM is then responsible for executing the instructions described by the intermediate code generated by the Java compiler. In theory, this intermediate code should be runnable on any platform, but in reality you need a JVM written for the specific platform your are targeting. Although you can find implementations of the JVM for the most popular platforms (Windows, OS/X, Linux, Solaris) as well as some other more specific platforms (such as consumer eletronics), this is a far cry from being able to claim that it can be run on any platform, after all, I haven’t seen a JVM for Comodore VIC-20 yet.

Many of the languages we have grown accustomed to call platform independent should instead be endorsed as cross-platform, since they can be execute on multiple platforms (but not any). And this is really sufficient for almost, if not all, our needs as software developers and system engineers. Since we typically know before hand the platforms we want to target, we should be able to make an informed decision to which language better suits our needs.

Unit Testing: Friend or Foe?

2010-09-09T00:33:00.000-04:00

It is not uncommon to find developers who despise the task of writing unit tests. Often discarded as a lesser task, or a waste of productive time, unit testing is rarely a priority in a developer’s mind. But is there a benefit associated to the time spent writing unit tests? Having working on projects falling on both extremes of the spectrum of unit test coverage I believe that unit testing is an underrated practice. The opposers of unit testing often claim that the added benefits are negligible, and testing is to be left to testers. I believe that these claims indicate a misunderstanding as to the purposes of unit testing. A few important facts about unit testing:

Unit tests do not eliminate the need for ad-hoc testing;
Unit tests do not eliminate the need for formal testing;
Unit tests are nowhere near 100% effective;

Well, since unit testing does not preclude us from having to perform additional testing, why would you want to waste spend time writing excruciating testing code? I will highlight what, in my opinion, are the main drivers for implementing this type of testing:

Allows me to avoid the build-deploy-test-fix-repeat iteration often required when implementing complex methods and algorithms. Specially with larger applications, it takes a lot less time to write a unit test that covers a set of anticipated scenarios than having to fix and redeploy the application a couple of times. Once the testing framework is configured, writing new tests really does not take much effort. Also keep in mind that it is easier to debug code through unit tests than on the server.

Assurance that modifying a seemly innocent piece of code will not cause havoc on seemly unrelated modules. This is specially true when dealing with larger applications where different developers (or teams) work on different parts of the code (or modules). You can use unit testing to guarantee that contracts are not being broken and other modules are not being affected by your code changes (regression testing).

Makes it easier to identify which parts of the code haven’t been tested. I accomplish this by running unit test coverage analysis tools. This can be done by running these tools on your build scripts or via plug-ins on your favorite IDE. Identifying deficiencies on your testing coverage may aid you in identifying what parts of your application will need more comprehensive ad-hoc testing.

It is likely to reduce the amount of bugs reported by your testers. This translates into less time will be spent fixing bugs and more time spent on adding new features.

Please be mindful that by no means I am advocating that projects should be anywhere near 100% test coverage. Firstly, most likely this is an unattainable goal for most projects unless they are willing to tailor their codes for this specific goal (and believe me that it takes a considerate amount of tailoring). Secondly, the amount of effort required for this would not be at par with the benefits. You will need to exercise some self diligence here to determine how much is enough for your needs.

Still with me? Great to know that I have captured your attention this long. Let me now take a step back and warn you of some of some pitfalls drawbacks associated with unit testing:

Once you get going, it can be addictive. It can be overdone. And it can be a black hole that sucks an immeasurable amount of time and effort from your developers. Be specially attentive to that one developer in your team that is fixated with statistics and metrics, as he is the most likely one to get sucked in the race for 100% coverage.

It can also create a false sense of security. As mentioned before in this same post, unit testing does eliminate the need for ad-hoc and formal testing. Do not get over confident looking at your coverage report with all of those full green bars and think your work is complete.

Finally, developer frustration will likely be the top drawback associated with implementing unit testing. One way to motivate developers with unit testing is with a friendly competition with running scores for the developer with the least amount of bugs reported by the testing team. This will surely incite your developers to write more tests to make sure their code works.

Unit testing can be exceptionally helpful with software products. But as most things in life, is a practice that works better in moderation.

Review: Issue Tracking Tools

2010-09-08T00:02:00.000-04:00

Although I do believe that all projects implement some form of issue tracking (even when they don’t realize), I have always been a strong promoter of formal issue tracking and believe it improves the overall performance of a software development team by providing a organized way to store and monitor bugs and tasks, and increasing management oversight.

Let me first start by defining what I consider a formal issue tracking process and then I will move on to explore its benefits. A formal issue tracking process entails the following a few basic rules:

All data must be available from a single source or repository. It is important that all members of you team have access to the repository where your issues as stored. These issues should be used when determining the daily tasks that will be handled by the team (think Scrum).

The repository must allow users to incorporate their own ideas and comments, as well as log progress. All authorized users should be able to add comments to existing issues. Ideally, this repository will also track changes to the issue and notify stakeholders. All data added to issues are important for historical purposes (i.e. being able to back track why certain decisions were made)

The issue creation process should not be onerous to the reporter (issue creator). Authorized reporters should be able to create and add issues to the repository. Making this process laborious (i.e. having to ask a manager for permission/authorization) will result in issues not being logged.

The process used must allow for a certain level of security to protect privacy and accuracy of data. The data stored in these repositories have to be safe from accidental removal, preferably with some sort of version control to allow tracking of changes. Additionally, certain issues may contain important proprietary or company IP that may not be appropriate for viewing by all team members.

The two most basic forms of issue tracking that exist are email and white boarding. Although some teams are successful with implementing these two methods of issue tracking, they do not fit my definition of ‘formal issue tracking’. The first one, email, does not implement rule #1, as it is not available from a single source, making it very difficult for managers to monitor the status of these issues (you can’t always rely on developers to cc the right people). The former, white boarding, fails rule #4, as all it takes for you to loose all of your data is a new cleaning person with a knack for making sure your offices are spotless clean... including all the gibberish scribbles on your white board. Come teams also use spread sheets or word documents as their repository, but these aren’t ideal either.

This leaves us with a wide variety of free and commercial tools. Honestly, there are too many to list, but I will mention a few that I have had a personal experience with. A more comprehensive list can be found on Wikipedia. The most recent issue tracking tools I have used or evaluated are: Bugzilla, JIRA, Trac, Squish, Eventum. Before I let you in on which one I prefer, I will give you a short review of each. Please bear in mind that some of my experiences with these tools involved older versions, as these were performed over the last four years.

The first tool, Bugzilla, is focused on bug tracking and therefore lacks a few very important features that can greatly facilitate monitoring and reporting on tasks and bugs. It is written in Perl and supports MySQL, PostgreSQL and Oracle as the database back-end. Configuration wasn’t straight forward and frustrating to understand at time. The user interface lacked some of the Web 2.0 glamour we have become accustomed to. Bugzilla is free and open source.

Attlasian’s JIRA is a well rounded issue tracker and performs well on all areas a issue tracker is expected to excel. It can be used for both issue/bug tracking and tasks, supports multiple projects, comprehensive security and authorization mechanism, extensible through Plug-ins, and great reporting facilities. Jira is written in Java and supports SQL Server, MySQL, PostgreSQL, Oracle, and the default HSQLDB database back-end. It has a rich user interface with all the bells and whistles one can expect. Configuration can be overwhelming, as every aspect of the tool is configurable, and upgrading can be a daunting task since you may need to update your database schemas. Jira is a commercial product, albeit open source projects can be granted free licenses.

If you do a search on issue trackers, you will see that Trac is a favorite of many. My personal experience with this tool wasn’t that favorable. I had a very difficult time getting it installed on one of our CentOS servers at the time and never managed to get it up and running. This may have been due to my lack of experience with Python, but I still think the installation process could have been made accessible to everyone. Trac supports SQLite, PostgreSQL and MySQL as its datastore. Trac is free and open source.

Squish is a hosted issue tracker solution developed by a company I used to work for. Although I worked on a different project, we did use Squish as our issue tracking platform. Its interface is simple and intuitive, although not as flashy as some of the other tools we are used to. Pricing can be prohibitive, specially for small companies, where one will certainly have to be mindful when creating new issues (pricing model is based on number of issues).

The last one, Eventum, was one of the tools I was really excited about when I first found it at MySQLs website. It runs on PHP and MySQL and at first glance it has a clean and straight forward interface. I did say ‘first glance’ didn’t I? As soon as you start drilling down into its issues and FAQs you start to notice all the extraneous information on some of the screens that do nothing but distract you from the actual data you are trying to track. However, it is not difficult to get used to it once you learn where the pertinent information is located on every page and start filtering out the clutter, and for the price, free, it is certainly a good option if you are feeling adventurous.

When making your decision for which issue tracking tool you will implement for your company or project, be conscious that whatever tool you pick will likely be the one you will have to stick with for the duration of your project (migration between these tools, when possible, tend to be labor intensive). If you can afford it, JIRA is an excellent tool for the money, and they often have incentives for small companies, educational institutions, and open source projects. Chances are at least some of your developers already have experience with JIRA as it is used by a broad number of open source projects. If pricing is a driver for your decision, both Trac and Eventum can be good alternatives once you get used to them.

Do you have an issue tracked you prefer over the alternatives above? Drop me an email with a link and brief description and I will happy to evaluate it and add to my blog.

Internet: Improving Your Public Profile

2010-09-06T20:55:00.000-04:00

There is a general understanding that there is no privacy when it come to the Internet. Even our personal email and other private information (i.e. social networking) is vulnerable. But at the same time we need to realize that the increasing amount of information we voluntarily publish about ourselves on the Internet, both private or public, can be harmful to our offline persona. It has become common knowledge that many companies already use candidate’s online profiles to screen candidates and monitor current employees, and why shouldn’t they? Employee behaviour can cost companies both money and reputation. I can think of at least three recent incidents where employee behaviour had serious adverse impact on their employers public image: Domino Pizza, British Airways, Obama Campaing. As a consequence, employers are increasingly relying on tools such as Tenero's Social Sentry for real time monitoring of employees online activities.

Although this practice is raising concerns from various groups, no new regulation has been introduced in the US to deal with these concerns. Outside the US, Germany has recently started working on a draft for a law that intends to make it illegal for prospective employers to use private information from candidate’s online profiles for screening, but how effective are such regulations? If you take into consideration that information, once published on the Internet (and indexed), is virtually impossible to remove without the help of professional service, then you will realize that many of us already have damaging information available somewhere on the large landscape of the World Wide Web.

The question that begs to be asked is whether it is ethic for current or future employers to be searching for information that is perhaps not private, but certainly personal. Well, if you acknowledge that the Internet is quickly becoming the center of mass media, then you can compare posting personal information on [insert your favorite social networking tool here] at a similar capacity to publishing it on a major newspaper. We must understand that the accessibility of the Internet as a medium is not to be abused, and everything you produce should be scrutinized before it is published for posterity.

Although there is risk associated with the increased exposure to your personal (and sometimes private) Internet profile, not all is evil. If you have a knack for it, the Web can be a great PR tool to promote your skills and experience for prospect employers. Taylor your public Internet image to represent your strenghts and ambitions without misrepresenting yourself to get the most value of this great medium.

Mastering Your Craft: The 10,000 Hour Rule

2010-09-04T01:18:00.001-04:00

Ever wondered what it takes to become a master at a specific craft? According to this article (pdf), all it takes it practice and diligence, at least 10,000 hours of it. The article explores how it is not by natural talent, but rather with dedication, deliberate practice and deliberate thinking that masters are created. But the article also touches on the fact that in order to achieve excellence you need to be constantly pushing your limits in order to extending the range of your skills.

Firsts

2010-09-02T22:15:00.000-04:00

The Comodore VIC-20 was the first computer we ever owned at my house. I still remember playing playing Blue Miners on the VIC-20 back when I was just a child, being mesmerized by all the fun packed in that game playing on a black and white TV.

The first experience with a programming language was native Basic on a NE-Z800, with a memory expansion module and a faulty cassette tape player for loading and saving applications that would often corrupt our cassette tapes. I remember spending hours at a time writing simple Basic programs and playing with existing source code just to learn how to program.

Eclipse Plugin: m2eclipse

2010-09-02T16:02:00.002-04:00

m2eclipse is a free plug-in for Maven integration with the Eclipse IDE. It eases the process of creating Maven projects by delivering an intuitive set of dialogs that can be used to choose all steps of the project creation process including a very useful archetype browser. I usually have trouble with building more complex projects inside eclipse and rely on my mvn (command line) tool for the build process, but still use the plug-in to create all my maven projects.

Apache Maven: A Brief Introduction

2010-09-02T15:48:00.002-04:00

MApache Maven is becoming a industry standard build and dependency management tool for the Java platform. It allows you to create custom build processes that are smart enough to deal with even the most complex collection of dependencies for your project. There are a few new concepts that developers need to understand in order to be able to take advantage of the full potential of this great tool.

Every Maven project contains a pom file (pom.xml) that can be found on the root of your project’s directory. This file will contain various pieces of information, but we will start by focusing on the most important ones: your project’s identifying information, information about its dependencies (and how to resolve conflicts between them), and information its build requirements and instructions.

Project Identification: Maven identifies projects according to three elements. These elements are the artifact id, the group id and version. The artifact id is your project’s name, group id is used to resolve projects that may have colliding artifact ids (think about namespaces in xml) and version allows you to identify the release of the project.

Project Dependencies: Maven allows you to specify dependencies and version resolution instructions for these dependencies. Project dependencies are automatically resolved from the local or remote Maven repository. These dependencies are typically jar files you need to include in your application, and must exist in either your local repository or on one of the many public repositories available on the Internet. Some companies have proxy repositories available on their local network to facilitate (speed) the retrieval of dependencies, but this is a topic we will cover on a different post.

Build Instructions: Maven allows projects to specify their own build instructions, but save developers from the sometimes cumbersome task of specifying all aspects of their build process. This means that you can have as much or as little control over the build process as you’d like. In general, the least information you need to specify, the more portable you build process will be. The build configuration can be done by either specifying a packaging format or specifying a build plug-in (plug-ins are a powerful feature of Maven, but we will leave these to a later time).

Now that you understand the basic concepts of Maven, stay tuned for an upcoming tutorial on how to build your first Maven project from scratch. But you can start by going to the Maven Website and downloading the command line tool. Don't forget to follow the instruction on how to setup your environment variables.

Can the Android Beat the IPhone?

2010-09-02T10:25:00.002-04:00

There is no denying that the IPhone was potentially the most revolutionary consumer device we have seen over the last decade and, when it comes to features and interface, Apple has had no real competition on the smart phone market since the first gen IPhone debut back in January 2007. For the first time we could enjoy the full power of the Internet on the palm of our hands (well, almost, as the lack of support for Flash and Java has always been a strong point for criticism on this platform). But the smart phone landscaping is starting to change and now Apple has some real competition and appears to be now loosing ground on the smart phone market.
The IPhone still remains the most desirable amongst smart phone consumers, but Google’s device is gaining traction, with some impressive numbers for new phones acquisitions over the last 6 months.

According to Nielsen, the Cupertino company still holds strong with 28% market share on the smart phone market, right behind RIM’s Blackberry, in a slow decline over the last year, but if Google’s platform keeps growing at the current rate we may see the Android topping both IPhone and the Blackberry in subscribers over the next two years. Apple’s loyalty numbers are not to be neglected, and Google will certainly have a hard time prying some of those devices from the fierce hands of some of the loyal IPhone customers.

Learn to Appreciate Your QA Team

2010-09-02T08:14:00.003-04:00

Over my career I have heard all sorts of snarly comments about our QA professionals from the development team, and all sort of excuses from management on why we shouldn’t spend the money to hire [more] testers. I came across this article that I believe hits the nail on the head regarding some of the top excuses people use for not having a QA team as part of their software development process.
In additional to the points raised by the article, it is also relevant to note that a good QA team should help you test not only the quality of your product, but also your compliance with requirements. Delivering a product that is buggy or doesn’t comply with all requirements can be very expensive as it may cause your users desert or even result in legal or financial penalties from your customer.

Eclipse Plugin: Coverage

2010-09-01T22:32:00.000-04:00

Coverage is a great free plugin that allows you to do unit test coverage straight from eclipse. In addition to displaying detailed results on your test coverage, it also highlights your Java code to indicate coverage (full, partial, none) of blocks of code by unit tests.
I have not found a way to exclude the test source directory from the reports yet, the data generated is granular enough that you can just focus on the percentages for your main source directories.

Google vs. Oracle

2010-09-01T22:20:00.000-04:00

Only hours after Oracle’s filing of a lawsuit against Google on patent and copyright infringement over the Java platform, the search giant announced it will no longer be attending Sun’s [Oracle’s] JavaOne conference, claiming that Oracle’s lawsuit is an attack on open source software.
Google technologies Tim Bray, co-inventor of XML and a former employee of a Sun Microsystems, has posted an article on his personal blog indicating that the actual reason for Google’s boycott on JavaOne is actually Oracle’s lack of developer focus.
This may impact this year’s attendance on JavaOne, but its unlikely that it will soften Oracle’s stand on the lawsuit, which appears to be one that is less about patents and more about power and money. Regardless of the real reason behind it, this appears to be a good indicator that Google intends to fight this lawsuit to the end, no matter the cost.