import javax.crypto.SecretKeyFactory
import javax.crypto.spec.PBEKeySpec
import java.security.SecureRandom

def salt = salt()
def hash = hash('password', salt)

println hash

private salt() {
    final Random r = new SecureRandom();
    byte[] salt = new byte[500];
    r.nextBytes(salt);
    return salt
}

private String hash(String password, byte[] salt) {
    char[] passwordChars = password.toCharArray();

    def iterations = 5000
    def keyLength = 192
    PBEKeySpec spec = new PBEKeySpec(
            passwordChars,
            salt,
            iterations,
            keyLength
    );
    SecretKeyFactory key = SecretKeyFactory.getInstance("PBKDF2WithHmacSHA1");
    byte[] hashedPassword = key.generateSecret(spec).getEncoded();
    return String.format("%x", new BigInteger(hashedPassword));
}

Null pointers are the bane of software developers. The nefarious NullPointerException or NoReferenceException is know to all java or C# developers. At worst, they are a minor inconvenience. At worst, they can cost companies a lot of money. So when I heard about a new feature in Java 8 that was supposed to help mitigate these bugs, I was excited.

Imagine a world where we didn't have to check for "null".

— Robert G Greathouse (@greathr_) April 2, 2014

The feature is called “Optional”. There are a lot of existing examples in other languages of how nulls can be easily handled. Indeed, the documentation even cites some of the examples.

What Alternatives to Null Are There?
Languages such as Groovy have a safe navigation operator represented by “?.” to safely navigate through potential null references. (Note that it is soon to be included in C#, too, and it was proposed for Java SE 7 but didn’t make it into that release.) It works as follows:

String version = computer?.getSoundcard()?.getUSB()?.getVersion();

In this case, the variable version will be assigned to null if computer is null, or getSoundcard() returns null, or getUSB() returns null. You don’t need to write complex nested conditions to check for null.

In addition, Groovy also includes the Elvis operator “?:” (if you look at it sideways, you’ll recognize Elvis’ famous hair), which can be used for simple cases when a default value is needed. In the following, if the expression that uses the safe navigation operator returns null, the default value “UNKNOWN” is returned; otherwise, the available version tag is returned.

String version = computer?.getSoundcard()?.getUSB()?.getVersion() ?: “UNKNOWN”;

[snip]

OK, we diverged a bit and all this sounds fairly abstract. You might now wonder, “so, what about Java SE 8?”

After reading that section, I was momentarily excited. The “?” and “?:” operators in groovy are godsends. But, my enthusiasm was quickly halted. To use this new feature, variables have to be wrapped in Optional objects. For instance:

public Optional<Book> findBook(String isbn) {
   Book b = //look up book in some repository that may return "null" for not found
   return Optional.ofNullable(b);
}

So what does the equivalent Elvis operator “?:” look like in Java 8?

String name = computer.flatMap(Computer::getSoundcard)
                          .flatMap(Soundcard::getUSB)
                          .map(USB::getVersion)
                          .orElse("UNKNOWN");

What happened here? How can you tease me with the easy to use syntax and then throw this up? What the heck is flatMap and map? All I’m trying to do is get the version of the usb connected to the soundcard on my computer.

I can see where there are other use cases for Optional as I read through the rest of the documentation page. But I have to wonder if those other features could have somehow been tacked onto the language in a different manner. I fully admit that I am not a language creator, nor have any experience in it. But in APIs that I write, I try to hide away the ugly and leave a nice, easy-to-use front end. The above does not appear to hide the ugly.

To be fair, I have not had any practical experience with the new features in Java 8. So it is possible I do not fully understand how this particular feature will fit in with the new additions. I will keep an open mind and attempt to use the Optional feature when it makes sense. I tend to write mostly in groovy thesedays, so I will happily keep using the “?” an “?:” operators.

Thanks for reading my rant.

How does one build confidence? Through experience. Experience is not something that you have when you are born (obviously). It it gathered over time. Often through repeating the same thing. Drills are one way to gather experience. Drills build muscle memory. When I was training for my pilot certificate, I had lessons that only practiced take-off and landings. These lessons were three to four times a week and included up to 10 landings per session. My instructor kept hammering the fundamentals until they became second nature.

The best way to gather experience in software development is to write software. Often times, though, simply writing software on-the-job only gets you experience using the tools, languages, and ideologies that your company has approved. If you are still writing software the same way you were a one, two, five years ago, it might be time to expand your toolbox.

A common suggestion is to commit to open source projects. I personally have no experience with that due to a lack of ambition of my part. It feels like it would require a lot of prerequisites. I would have to find a project needing help, read through the developer guidelines, find an issue that I can fix, submit a pull-request, and so forth. To me personally, that seems like a lot of work. If I am coding for fun, it should be fun.

Therefore, I suggest writing software that scratches your own itch. If there is a problem that you wish a computer could solve for you, try writing it yourself. I have written 20+ software projects for my personal use. Most of them have been thrown away after a while, but what I learned while writing them has stayed with me. I have found that writing a “real” product while learning a new language or framework is ideal. Having a real product with real features keeps me interested in continuing development. I get bored writing a TODO app simply to learn a new language.

Once you have a good baseline confidence in yourself, you should not be afraid of attempting anything. This transcends software development. Every aspect of life is better when you are confident in yourself.

The title of this post came from the Star Wars: The Clone Wars Season 1 Episode 5 moral

This post contains a simple example of using Groovy Categories to help manage the resource management of database connections. There are a lot more robust solutions (ie: GORM), but sometimes you only need a quick implementation.

To accomplish our goal, we will be using a static closure defined below. The OpenDatabase class is merely a container for the closure. I think the final implementation of the code reads nicely because of the name.
OpenDatabase.groovy

import groovy.sql.Sql

class OpenDatabase {
    def static with = { DbConnection conn, Closure closure ->
        Sql sql
        try {
            sql = conn.getConnection()

            if (closure) {
                closure(sql)
            }
        }
        finally {
            sql.close()
        }
    }
}

The DbConnection class is a simple interface for creating the groovy.sql.Sql object.

DbConnection.groovy

import groovy.sql.Sql;

public interface DbConnection {
	Sql getConnection();
}

Below is the sample usage of these two classes.

OpenDatabase.with(dbConnector) { sql ->
         sql.execute("insert into BLAH...")
}

The database connection will be closed after closure exits. Simple, easy resource handling. The groovy way.

A lot of projects have a “utilities” package or namespace. These packages contain tweaks and helper functions to aid with the rough edges of the language. Prior to Java 8, how many java projects have special classes to handle date/time manipulations? These packages provide some insight on the level of knowledge the original developers had of the language. It is often enjoyable to see how others have solved similar problems. Sometimes they solve it in a similar way I have seen. However, often times it is solved in a completely different manner. Seeing those differences helps me grow and evolve.

Digging Deeper
After getting the initial peek, I look at the dependencies. What external frameworks are being utilized? This gives me a some landmarks to visit. I research any dependency that I do not immediately recognize to determine the approximate age and level of support.

Audibles
A common sore spot in application development is accessing databases. In my experience, database access has been the largest performance bottleneck in most applications. In addition, incorrect handling of connections can cause memory leaks and bring an application down. I look to ensure proper connection handling as well as review the usage of ORM or other database mapping frameworks.

If the application is a web application, I will look at the general configuration. Whether that is the web.xml in Java or the global.asax in dotNET. I am looking for the general entry point for most requests. I follow up with reviewing how the chosen web framework has been implemented. Are the defacto standards followed?

Conclusion
I tend to learn something new regardless of the age of the software, the original developer’s experience, or the chosen language. Often I will see a language feature that I never knew existed or a method on a class that I have never seen. I enjoy reading code almost as much as I enjoy writing it.

* The original developers may have only been novices in the chosen language. They could very well have had many years of software development.

Project releases are often big-bang, all-or-nothing style of releases. Projects can often take months or even years to release. The software tasks are typically tracked with gantt charts and is often managed in a waterfall-style. The schedule is typically considered the most important component in this model. In addition, projects typically require vast amounts of documents prior to the first line of code being written. These documents include requirements, high-level design, detailed design, use cases, test scripts, and countless others. Project releases are often used by “enterprises” to release software.

Most of the projects I have worked on have failed. Those projects that were successful typically failed within a year. When a project completes, the organization will move their human resources to a new project leaving noone to maintain the software. Software is rarely done. Projects seem to encourage software developers to take shortcuts to make the due date.

Product releases on the other hand, typically do not have a finite end date. Software is released in feature and bug fix increments. A software roadmap help guide the development effort. These roadmaps provide a general idea of when features will be implemented. Since there is no end date, the software developers can evolve the codebase. This helps create a clean, maintainable source tree. Developers typically take more pride in their work. They know that the shortcuts they take today will affect them in the near future. The most important component is this model is working software.

In my experience, software managed in the project model feel heavy and slow. Whereas, the product model seems a lot lighter and quicker. I prefer to work on products and not projects. What type of release model do you prefer?

Youthful software developers tend to dislike legacy code. I was once one of those developers. I thought I could easily rewrite a section, feature, or even a whole program in less time than it would take to make minor changes to it. I finally learned my lesson after many, many, m-a-n-y failures (and one success*).

Now, instead of using the term “legacy”, I try to substitute with “existing”. I don’t shy away from existing code. I embrace the fact that the code has many battle scars. Those scars are years of bugs that have presumably been killed. The intrinsic evolution of features and nuances that make the product what it is today. I no longer have a craving to slash and burn code to simply start with a greenfield.

I prefer working on an existing codebase. I love fixing issues that the client has had for many years. I enjoy incrementally making software better one refactor at a time. It is also a lot quicker to see the software I’m writing get in the hands of end-users and make a real impact.

I would like to tell all of the developers that think they are stuck on a legacy project:

Contrary to the term, things aren’t always greener on a greenfield project.

We should all simply enjoy the code we get to write. I know I love writing every line that I can. If you focus on keeping things clean and concise, your legacy will be appreciated by those who follow.

* I actually did rewrite an entire program in one day. However, I was scared out of my mind when the Vice President of Information Technology actually called me on my brazen promise. I ended up working late into the night. I learned a valuable lesson about having a big mouth. That was also the last time I made any more “bold rewrite” statements.

I recently quit my day job to work full-time as an independent contractor. One of the hurdles of going alone is purchasing insurance for a business. I am required to carry Commercial Liability insurance and Professional Liability insurance including Errors and Omissions (often abbreviated as “E&O”).

I started with the insurance company that I use for my home and auto. The application was long and confusing. After I submitted it, I had to wait 6 business days to hear the bad news. They were unable to cover me. I must have answered some of the questions incorrectly. I recently moved and have not found a local agent. Therefore, it was difficult to ask my agent questions regarding the application. I am mostly to blame for that.

I now had 2 weeks to scramble and find insurance prior to the start date of my new contract. I immediately setup meetings with two local agents. I feared that the underwriting process would take too long and I would not be insured by the start date.

I learned about techinsurance.com from a fellow contractor less than one week prior to my start date. I had not heard back from either of the two local agents so I was really stressed and worried.

I filled out the techinsurance.com online application form that night. It was straightforward and easy to understand. Their website says that they are often able to give real-time quotes. However, they were not able to for me. The following morning, I received an email with quotes from several reputable insurance companies. I was also assigned a licensed agent to work with me through the process.

The quotes given to me from techinsurance.com were effective immediately. No more waiting 6-8 business days for underwriting. I was relieved to know that I would have insurance for my first day. Not only that, the quotes were good rates. The E&O insurance is half what a fellow contractor is paying. However, one of the local agents had a lower quote on the Commercial Liability. I mix and matched the plans and came out with a great annual premium for all of the insurance required.

I am very impressed with techinsurance.com. The assigned agent, the quick quote process, and the easy purchase experience is what made it great. I would highly recommend them to any professional that needs commercial and professional liability insurance.

Let’s be honest. Software developers typically make a pretty decent living. Three years ago, my wife quit her day job to stay home with our kids. I have made enough to provide for my family with my sole income. I feel like I have been compensated well enough. So what is the purpose of this post?

I would love to remove the taboo that exists around salary discussions. Who benefits from keeping salary information scarce? The employers. I have seen some contracts and NDAs that explicitly disallow employees from discussing current salaries and bill rates. If developers do not talk to one another, the employer has a lot more leeway to steamroll naive or timid developers (like myself).

I would love for every developer to have the confidence to know what their skills are worth while negotiating a salary increase. There are websites like http://www.glassdoor.com/Salaries/index.htm that attempt to provide a range. However, these are often off or give a wide range of salaries.

So what are some options for determining how much you are worth as a developer?
As previously mentioned, you could try using online salary range calculators. You could job hop and find what other companies are paying. Or you could simply ask your fellow developers.

For me, I am no longer going to be timid when it comes to compensation discussions. I will have asked my fellow developers, I will have done my research, and I will come prepared to any future negotiations. I hope you are open to the discussions.

I have only been pair programming for a little over a year. Prior to that, the majority of my career has been spent alone in a cube or office.

In 2001 when I started in my first job, we did something like pair programming. Obviously, it was not called that at the time. It also did not look like today’s pair programming. It consisted of me sitting next to a more senior developer while s/he wrote code. I would help dictate requirements and help transpose. It was still two eyes on one screen. This style of work helped me get learn the system, but it didn’t really help me learn to program.

Fast-forward to today. I am in a position that pairs 100% of the time. We switch pairs after every 2 week iteration. One developer usually takes the keyboard in the morning, and the other takes over in the afternoon. We sit at large tables with a single monitor between us. We each have our own laptops and simply switch the video cable for the monitor. This allows us to setup our own computer to suit our unique needs (ie: plugins, keybindings, etc). It also allows us the ability to turn away and check emails or text messages on occasion.

After working in this environment, I have seen how well it works to get new hires integrated with the software. I have seen how it helps fresh graduates start learning the “right way”^[1]. I think about all of the missed opportunities from my past career with regret.

In addition to the two benefits described above, it is also beneficial on new features or working around critical components. Two sets of eyes are better than one.

However, pair programming is not a silver bullet. I feel it does not work for every company or situation. Production support is one such situation. Often times tracking down bugs is a hunting mission. Lots of different paths have to be explored to find the bug. Pairing will only get in the way here.

Simple feature enhancements usually do not require a pair. These features are fairly simple and straight-forward. They do not touch critical components. Pairing on these types of features is a waste of time.

In conclusion, I am not advocating NOT pair programming. I advocate to use it in the correct situations and not just simply applied as a constant practice. I highly recommend doing pull requests prior to integrating any code into the main branch. This will allow a second set of eyes to review code. I also highly recommend writing tests. In my opinion, these add up to more quality than 100% pair programming.

^[1] Obviously, there is no one “right way” for everything. But there is usually a lot of predisposed teaching that needs to be undone to most fresh graduates.