I first considered Showoff, a nice framework for building presentations in HTML (running on Ruby/Sinatra).  This tool is hot in the developer community right now.  Since it is a running application, it depends on deploying to hosting provider like Heroku.  It does have a nice simple markdown for capturing content and I would consider using it in the future.

HTML5 Slides is more of a demonstration on how you can use HTML5/CSS3‘s features to build web-based slide shows.  I considered this option as a way to learn more about HTML5.  The pages still need to hosted somewhere, and AWS S3 would be the perfect location.

Prezi.com is a service for building Flash-based presentations that break the convention of slides.  With Prezi.com, you can build dynamic visual presentations where the camera moves about on a page.  Public presentations are hosted for free, but you would have to pay for private presentations.  While Prezi does did offer a unique presentation style, I didn’t feel the platform (Flash-based) fit my needs.

In the end, I chose impress.js, as it seemed to be the best of all solutions.  Impress.js is essentially an HTML5 presentation framework that enables you to build Prezi.com like presentations. (thanks to Matt Makai for pointing this tool out)  You build your presentations in html (div = slide) and using tags and css, you can manipulate size, position, scale and even animation within your slide.  It is also the newest tool on the scene and seems promising.  By building my presentation in impress.js, I will be forced to beef up my front-end skills, which have been lacking as of late.

I also discovered that impress.js presentations can easily be hosted on GitHub using GitHub Pages.  Since my presentation is just a web page, all I have to do is push my changes to the gh-pages branch of my GitHub repository and wait for the site to be displayed.  GitHub will deploy the website using a url following this convention:

http://${username}.github.com/${repositoryname}

Github Pages works for private repositories as well, and all you need to do to enable it is create the gh-pages branch.  Having my presentation displayed directly from version control with a simple url makes the process simple to manage.  Updates to the latest version are a git add, commit, push away.

Since I am just starting down this road, I may have some further feedback on how these tools work out, but so far, the presentation is looking great!  If interested in any or all of these presentation technologies, here are some sample presentations:

• TDD your CLI by Dave Copeland (showoff)
• HTML5 Demo Slides at HTML5Rocks (HTML5 slides)
• Coca Cola Company (Prezi.com)
• 12412.org Presentation (impress.js)

1. On your Jenkins server, generate a new SSH key if you don’t already have one.  (Make sure you are logged in as the user that Jenkins runs as): ssh-keygen -t rsa
2. Log into your GitHub project and click the project’s admin button.
3. Click the Deploy Keys link and add a new key.
4. Copy the contents of the public key you just generated (id_rsa.pub) into the GitHub Deploy Keys field.

That’s it!  Now, using the Jenkins Git plugin, you can point your Jenkins Build Job at your GitHub repository and it should authenticate just fine.

This will only work for one repository.  GitHub requires that your Deploy Keys be unique among your repositories.  Ideally, you should be able to create multiple SSH keys on your Jenkins server, but I had trouble getting this to work.  What I ended up doing instead was adding the SSH public key to my GitHub user account.  This allows Jenkins build access to any of the private repositories I create.

I would ideally like to get the Jenkins GitHub plugin working, but after a 10 minute test, I stuck with my current setup so that I can move on to the next problem.

Six months ago, I started coaching a number of .NET development teams on Agile Engineering best practices.  This was an eye-opening experience for me and I learned a lot about .NET.  While there were some bright spots, namely C#, I was surprised how .NET seemed to be lacking in certain areas that were fairly mature in the Java community.  The most notable omision was the lack of a dependency management framework for .NET.

After my experiences with these teams, and discussing this problem with other .NET experts, I have come to realize that the standard practice is to check in .dlls to version control.  I was appalled.  When coaching teams on conduct unit testing, build automation, and continuous integration, I found the lack of a proper dependency management solution to be a huge problem.  Adding .dll’s to version control works ok for third-party libraries, but when I want to consume a “working” version of another team’s code as they change it, this becomes a burden that Maven solved gracefully.

I then discovered NuGet, and hope returned.  NuGet is a .NET open source project that’s sole purpose is dependency management in .NET.  Yes, just what the agile engineering coach ordered.  Right?  Wrong.  NuGet, while a promising project, is still young and lacks numerous dependency management features.  NuGet was originally designed as a Visual Studio extension for allowing developers to search for, download and add libraries to their solution.  Developers would then check in the .dlls to version control.  What!?  Isn’t this what we are trying to avoid?

In reading the forums (here, here, here, and here), it appears that users where complaining that NuGet wasn’t doing enough dependency management.  In fact the project organizers were hesitant to add Maven-style dependency management.  ”We need NuGet to support continuous integration!”, the community cried.  Well thankfully, NuGet is an open source project and the features for restoring dependencies has been added to the 1.6 release.  With this release, you Nuget can be setup to restore packages that haven’t been checked in, as well as support for “beta” releases.  For me, this change is still half cocked and fails to establish the benefits that Maven provided years ago.

NuGet is a promising young project and I hope that it will continue to grow and do well.  The .NET community desperately needs it to grow up fast and support more features.  In the spirit of open source development, I have done my part to support the project by submitting a bug report.  I wish the Nuget team, as well as the rest of the .NET community the best of luck.

To make this change, open up the $TEAMCITY_HOME/buildAgent/conf/buildAgent.properties file and update the following value:

serverUrl=http:\://localhost\:8080

In this case, the agent is running on the same server as the master server.  Once you restart the build agent, the master server recognizes the agent as back online.  Hope this helps.

Prior to discussing unit test methods, I want to mention that the naming conventions for unit test classes are fairly well solidified.  I will assume that everybody will using the following naming convention for their unit test classes:

[NameOfClassUnderTest]Test

Some conventions specify that the ‘Test’ postfix be ‘Tests’.  I personally don’t care about the difference between the two, so long as your team uses one or the other and not both.

JUnit

JUnit is one of the first unit testing frameworks and one could argue is responsible for the explosion of unit testing over the past ten years.  In previous versions of JUnit, it was necessary that the name of the unit test method be prefixed with test.  This was how the JUnit runner identified unit test methods.  So a unit test method name might look like this:

public void testAddingTwoNumbers();

This framework limitation unit test method name was overcome in JUnit 4.  In JUnit 4, it is possible to use Java 5′s annotations to tag a method as a test method.

@Test public void addingTwoNumbers();

Most modern test frameworks no longer force developers to prefix the test method name with the word test.  I prefer to avoid frameworks that impose this convention, but there are exceptions.

The Art of Unit Testing

Roy Osherove wrote a great book on unit testing called the Art of Unit Testing.  While this book was focused on .NET testing approaches, there is a lot of good recommendations there applicable to all developers, and I would recommend it.

In this book (as well as his blog), Roy recommends a unit test method naming convention that uses the following pattern:

[MethodName_StateUnderTest_ExpectedBehavior]

While I appreciate how comprehensive this standard is, I don’t personally subscribe to this approach.  I find that this approach doesn’t put enough emphasis on the overall behavior of the class under test, but rather inputs and outputs of methods on the class.  When applying TDD, I find that I think more about behavior than I do inputs/outputs.

Introducing BDD

Dan North introduced Behavior Driven Development, or BDD in 2006 with an article in Better Software magazine (which you can read here).  In this article, Dan discusses the series of revelations he had regarding unit test naming conventions before he came across BDD’s Given When Then convention.  I am not going to go over BDD here, but I definitely recommend reading this article.

While I personally love BDD and feel it is extremely valuable in defining human readable tests, I feel it aligns much better with acceptance testing than unit testing.  What peaked my interest in this article was some of the intermediate steps Dan made on his way to BDD, namely “test method names should be sentences”.  He references a friend’s open source project agiledox that turned a unit test class into a document describing what the class does.  For instance, given this unit test class:

 public class CalculatorTest {
     @Test public void addsTwoNumbers () {...}
     @Test public void subtractNumberFromAnother () {...}
     @Test public void multipliesTwoNumbers () {...}
     @Test public void dividesTwoNumbers () {...}
 }

Agiledox would produce documentation for the class that would look like this:

Calculator

- adds two numbers

- subtracts number from another

- multiplies two numbers

- divides two numbers

This was an aha moment for me.  While I have never used agiledox, I found this convention and approach to be extremely simple and easy.  The unit test names now provide a description of the behavior of the class under test.  When I write unit test methods, I imagine these agiledox style sentences being laid out, as a sanity check.

Focus on Behavior

For me, the best unit test name should be focused on a particular behavior of the class under test.  How you word the test name is up to you, so long as you focus on behavior.  You should make sure to include exception cases in this definition of the behavior as well.

Another nice side effect of this focus on behavior is it makes it easier to assess whether or not the class under test is violating the Single Responsibility Principle (SRP).  By quickly looking through the feature list, provided by unit test names, you can determine whether or not the class is doing too much and should be broken up into collaborating objects.

Side Note: Method Names in Groovy

Since Groovy allows method names to be strings, this allows you to write a unit test method that looks like this:

class CalculatorTest {
   @Test void "adds two numbers"() {...}
   @Test void "subtracts a number from another"() {...}
   @Test void "multiplies two numbers"() {...}
   @Test void "divides two numbers"() {...}
}

This allows you to write true sentences without the need for a tool like agiledox to break up the camel case. Another compelling reason to use Groovy for unit testing Java.

I have also found some interesting resources on Grails best practices that I would like to share.

• Grails Podcast – episode 127
• Grails Package Naming (dangertree techblog)
• Grails Best Practice discussion on StackOverflow.com
• Martin Fowler on Anemic Domain Model – not directly about Grails, but food for thought when talking about Domain object design

Where the article raised questions for me was when James started talking about GitFlow and Vincent Driessen’s Git Branching Model.  If you haven’t read this article, I recommend you stop and go read it now.

Vincent’s approach to using Git takes full advantage of a major feature provided in DVCS, cheap local branching.  As an advocate of continuous integration however, I have always recommended that one should avoid the approach of excessive branching.  One of the principle practices of continuous integration is:

Everyone commits to the mainline everyday

Martin Fowler goes on to say,

“In practice it’s often useful if developers commit more frequently than that. The more frequently you commit, the less places you have to look for conflict errors, and the more rapidly you fix conflicts.”

So taking this a basic rule of thumb, does Vincent’s branching model conflict with continuous integration?  The short answer is no, so long as the developers are only branching locally and are pushing their changes to origin (the centralized git repository) daily.

In Vincent’s approach however, he says

“But besides the centralized push-pull relationships, each developer may also pull changes from other peers to form sub teams. For example, this might be useful to work together with two or more developers on a big new feature, before pushing the work in progress to origin prematurely.”

This is an approach to feature branching Martin Fowler calls Promiscuous Integration.  Martin Fowler attempts to assess whether the concept of promiscuous integration is a good idea or not.  I recommend you read the article yourself, but he ends up saying he thinks it’s not the best idea (but doesn’t outright say don’t do it).  He recommends using Feature Toggles or Branch by Abstraction as approaches to avoiding Feature Branches in long running development cycles.  This same advice is reinforced in the book Continuous Delivery by Jez Humble and Dave Farley.  I highly recommend this book!

So, what does one do with this information?  Is use of GitFlow or promiscuous integration a bad idea?  I think that it can work very well for some teams and could be very dangerous in others.  In general, I like it when the VCS stays out of the way and the team gets in the habit of pushing changes and looking to the CI server validation that everything is ok.  Introducing promiscuous integration could interrupt this cycle and allow code changes to circumvention the mainline longer than they should.  This branching scheme feels complex, even with the addition of GitFlow.

I plan on trying GitFlow and further investigating it’s merits, hopefully writting a more in depth analysis of how it works.  I think that it is an interesting idea (worth blogging about) and has a lot of potential.  I would love to hear what you think about GitFlow, promiscuous integration, feature branching and how they are good or bad, so please comment below!

Unit Tests:

• Focused on defining (not testing) the behavior of a particular class, and that class only.
• Fast (less than 0.1 second per test)
• No external implementation dependencies (filesystem, database, web services, etc.).  All dependencies are faked for the test context.
• Can easily be parallelized, since each test is atomic

Integration Tests:

• Focused on verifying the integration of one or more components together.
• May have external dependencies. (in fact, it is likely testing the integration with this dependency)
• A test that takes longer than a unit Test should (longer than 0.1 seconds per test)

Both unit and integration are focused on the internal quality of the application, whereas acceptance tests focus on the external, or business quality of the application.

Code Coverage
I feel very strongly that developers should focus on achieving >80%  code coverage by unit tests only.  Unit tests should target happy case logic as well as exception logic.  With integration tests, it is not necessarily to target a high code coverage.  Integration test coverage needs to cover integration points.  For instance, write integration tests to ensure your Hibernate database mappings are wired correctly.  Exceptions that could result from a integration failure should be defined behavior in the unit test, and expressed easily through fakes.

Summary

Your team should have a testing strategy that focuses on using both unit and integration tests, as both have a different focus and goal.  If you have additional criteria to add to this discussion, please feel free to share it.

The presentation serves as an introduction to the concept and practices of Continuous Delivery.  The presentation cover the concept and need for continuous delivery, and then talks about the core practices necesarry for continuous delivery, such as:

• Agile
• Configuration Management
• Continuous Integration
• Testing
• Build Pipelines

I intended to cover both the core practices as well as tools, but I ran out of time.  In the future, I will likely break this presentation up into two halves that cover an introduction, and then a specific roadmap with tools and techniques.

I have included a link to the slide deck I used for the presentation.  Check it out and add comments.    I hope that you enjoy it!

Article: http://www.sdtimes.com/content/article.aspx?ArticleID=35628&page=1