Purple Plutonium

Background Logging With Disruptor

2011-10-24T09:26:00.001-04:00

I spent a couple of minutes over the weekend watching the presentation: Understanding the Disruptor, a Beginner's Guide to Hardcore Concurrency to try and better understand the technology. It is a good talk but you need to have the slides in front of you to really follow along. The current project I am working on does not have the throughput requirements that the LMAX projects do but I was pleased to find a blog post describing a scenario that we do use on our current project: background logging. We have multiple servers spitting out log messages to a central logging service which allows us to trace a work request as it comes into the system and bounces between servers for processing. We didn't want have main processing held up waiting for log messages to get posted so we decided to go with a background logger based on blocking queues. Curious to see what the solution looks like using Disruptor, I decided to code up the examples and do a little benchmarking. If you are interested, you can grab the code from bitbucket. What I found interesting was that the Exchanger based solution works only when there is one producer and one consumer, which I don't think is practical. The Disruptor and Blocking Queue solutions deal with the multiple producer scenarios, which is what we have in our system. The simple benchmark I've written indicate that the Disruptor and Blocking Queue exhibit similar processing times, which was surprising to me. Based on what I've learned from the presentation, I would've expected more overhead from the plain Java solution. I'm guessing somebody who really understood the inner workings of Disruptor could show me where I'm doing something silly in the code, artificially holding back the framework and skewing the results. What I did find interesting was that the Disruptor framework wasn't that hard to get implemented. It is a single JAR file and couple API calls and you are off to the races. I'm not working on a SEDA-based solution but the next time I am, I'll definitely look more closely at using Disruptor as the queuing solution.

Quick Book Review: SQL Antipatterns: Avoiding the Pitfalls of Database Programming

2011-09-04T09:45:00.002-04:00

SQL Antipatterns: Avoiding the Pitfalls of Database Programming by Bill Karwin

I'm a software developer who gets paid mostly for working on the back end portion of solutions and I've worked in both small and large companies. I am not an SQL guru and I am more than happy to let somebody else review and fine tune any SQL that the solution uses. If I'm lucky, I'll be working in an organization large enough to have full-time SQL experts who can help me out. More times than not, however, the development team has to craft the SQL ourselves. As of late, I've been letting Hibernate do most of the heavy lifting for me, trusting that it will generate reasonable SQL and keep me out of hot water. I fully understand that, like most tools, Hibernate is only as useful as the developer's understanding of it which is why I try and read up on the ins and outs of Hibernate as much as I can. To that end, I figured I'd pick up a copy of SQL Antipatterns: Avoiding the Pitfalls of Database Programming to help me understand if I was asking Hibernate to do something silly and I'm really glad that I did.

Some of the anti-patterns I've seen before, like not using using constraints or using a column to mean multiple things, but there are many I haven't seen before but should now be able to spot. I enjoyed the discussions around security and can appreciate that storing passwords in the database is a bad idea (I've seen that more than once) and have a better understanding on how to protect against SQL injection attacks. The section on application development was a pleasant surprise to me because it talks about testing and possible migration strategies. I also enjoyed the comparison of the Active Record pattern versus the Repository pattern as it convinced me that the decision to use Repository on my current project was a reasonable one.

All in all, I loved the book and recommend that anybody who has to deal with a relational store pick up a copy and give it a read. It isn't a very long book and you get the sense that the advice given came from some hard learned lessons on the job.

View all my reviews

Quick Book Review: Driving Technical Change

2011-08-26T09:45:00.001-04:00

Driving Technical Change by Terrence Ryan
My rating: 3 of 5 stars

Ever come across a shiny new technique or tool but couldn't get it adopted by your organization? I know I have. This book contains some ideas on how you might get people to give your idea a try. The information contained in the book isn't likely to be used daily like some other books but when you really want to try something new and have run into a road block, the book has some interesting ideas. The essence of the book is to try and identify the different archetypes of skeptics and use specific approaches to persuade them to your way of thinking. Some archetypes include The Burned and The Ignorant. Be warned, however, the techniques described aren't going to work overnight and you will have to apply them over time. He doesn't spend much time on it but it is assumed you have done a bit of thinking to ensure that the shiny new tool makes sense for the business. As I said before, you aren't likely to use this book daily but when you really want to install a new tool or technique, this book has some good ideas to try.

View all my reviews

Quick Book Review: Designed for Use: Create Usable Interfaces for Applications and the Web

2011-08-23T12:50:00.003-04:00

Designed for Use: Create Usable Interfaces for Applications and the Web by Lukas Mathis
My rating: 3 of 5 stars

I spend most of my programming time working on the back end of systems but have been called on to contribute to user interface portions of solutions. I'll admit that UX is not a passion of mine but I thought it would be wise to better understand the thinking that goes into creating a usable interface, so I picked up a copy of the book. At the very least, it would allow me to better contribute in meetings when I get asked my opinion on which option I think is best.

Much like the rest of the software engineering world, there is no "one way to rule them all". You have to understand what is out there, try something and test, test, test. The book is split into techniques and ideas where techniques are concrete steps you can use to create a usable interface, such as paper prototyping. Ideas, on the other hand, are more abstract and general covering topics such as how to write usable text or animations. Being a UX newbie, most of the ideas in the book were new to me and I found them to be very interesting. I especially liked the notion of capturing your user's context prior to exiting an application in an attempt to determine if they succeeded in their task or gave up frustrated. Tracking what features your users actually use was also interesting probably because I've been in many discussions over adding complexity to a feature that nobody uses. Maybe there are ways to prove or disprove that assertion? Apparently, much of UX is testing your design and getting useful feedback and there are discussions on various ways to do that.

Overall, I found the book to be useful as it gave me broad coverage in the topic and pointed me to resources in case I wanted more depth.

View all my reviews

Quick Book Review: The Agile Samurai: How Agile Masters Deliver Great Software

2011-08-19T09:09:00.000-04:00

The Agile Samurai: How Agile Masters Deliver Great Software by Jonathan Rasmusson
My rating: 4 of 5 stars

I enjoyed this book and found that it had useful information. I am not Scrum certified and haven't picked up an XP book in years and enjoyed reading about the current state of the Agile world. The book feels authentic because the author lets you know throughout the book that the goal is to write great software that is useful to your customers and there is no one way to do that -- you have to be open to ideas and give them a whirl on your project. I'll have to revisit the chapter on estimation because that is the part of the job I typically struggle with. The notion of an Inception Deck is one I had not heard of before and found it very compelling. I'll have to try it myself to see if it works for us but it looks like it could be very useful and a tad bit scary -- you have to ask some tough questions when creating the deck. In short, I think the Pragmatic Programmer guys have produced another DRM-free, interesting and useful book. Two thumbs up.

View all my reviews

Quick Book Review: Dependency Injection

2011-08-15T15:55:00.001-04:00

Dependency Injection by Dhanji Prasanna
My rating: 3 of 5 stars

I've have been a user of the Spring framework for years now and like to think I know a thing or two about DI so I was a dubious about the book, but I checked my ego at the door and purchased the book anyway. I'm glad that I did. For one thing, being a Spring fan it was nice to see some examples of Guice, another popular DI framework. The author helped clarify the nuances of scoping and provided some interesting ideas on how to apply custom scopes. The book also reminds us how important it is to remember about thread safety when creating DI managed services. If you are new to the DI world then you should pick up this book. If you are a DI veteran, then some of the material will be familiar to you but I am confident that there are some nuggets in there worth the purchase price. If I could give it a 3 1/2 stars I would.

View all my reviews

Transparent Language: We're Hiring

2011-08-08T08:32:00.002-04:00

My current employer is hiring and seeing that these are tough times for some, I figured I would spread the word. All currently available positions can be found at the Transparent Language careers page, but below are a few highlights:

Front End Flex Developer
Front End Developer and Designer
Senior Software Engineer
Technical Support Project Manager

Quick Book Review: Specification by Example: How Successful Teams Deliver the Right Software

2011-08-05T08:56:00.000-04:00

Specification by Example: How Successful Teams Deliver the Right Software by Gojko Adzic

My rating: 3 of 5 stars

I'm currently trying to better understand the BDD mind set and how it might improve things on my current project so I was really excited when Specification by Example showed up in my Kindle. I was looking forward to finding a whole check list of dos and don'ts to help accelerate me to BDD nirvana. Instead, I learned that implementation of SBE is very contextual -- one size does not fit all. Different teams use different techniques. The author interviewed several teams using SBE and discovered what worked and what didn't work for them. Some teams started fresh on greenfield projects while others added SBE to existing brownfield projects. Some common themes emerge, such as don't specify at the GUI level and implement your living documentation system as soon as possible, but to really dig out the nuggets I would suggest the following. Read the book once cover to cover to get a grasp of what the teams went through. After that, scan the book again looking for the pearls of wisdom that each team offers and create your own list of dos and don'ts. From that you, should be able to get some ideas on what might apply to your current project. I enjoyed the book and feel that it offers valuable insights but readers need to be aware that some work on their part will be required in order to get the full benefit of the book. Potential readers might want to visit the book's web site for a taste of what is inside.

View all my reviews

Quick Book Review: Zero Day

2011-07-28T14:23:00.004-04:00

Zero Day by Mark Russinovich
My rating: 4 of 5 stars

Good book if you enjoy cyber terrorism and plausible scenarios. Probably not enough explosions to make into a Michael Bay movie but fun none the less. I hear rumors about a sequel and will read that the instant it comes out. Two thumbs up.

View all my reviews

Quick Book Review: Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions

2011-07-27T10:30:00.000-04:00

Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions by Gregor Hohpe
My rating: 4 of 5 stars

I wasn't really expecting to enjoy this book as much as I did but it is packed full of really useful information. I've worked on a few systems that used enterprise-level messaging and I thought I had a good handle on the space but I picked up the book anyway just to deepen my knowledge. I am really glad that I did. It is very apparent that the authors have been involved in a variety of integrations and have managed to convert their experience into patterns. The book does a good job of balancing the explanation of the patterns and their combination into solutions. Given that there are numerous patterns to sift through, you will likely have to review the list when crafting a new solution to just to re-familiarize yourself with the possibilities. The book can't tell you what solutions are right for your situation but it does a great job of making you think of the various aspects that need to be considered, such as configuration and control, security, logging and testing. The examples bounce between Java and C# but they should be readable by most developers. I highly recommend to anybody who is involved in any integration solutions.

View all my reviews

Quick Book Review: Free: The Future of a Radical Pric

2011-07-26T08:52:00.000-04:00

Free: The Future of a Radical Price by Chris Anderson
My rating: 4 of 5 stars

Even after a second reading, I still find valuable insights into how people view free, what the expectations are and how free can be used in a business environment. Although I don't recommend it, you can skip to the back and look at the list of ways free can be employed. The chapters before the list contain the interesting nuggets and should be read. I enjoyed the book and it caused me to think about free in the context of software and how to monetize it via free. The freemium model is the one I see the most but other interesting ones also exist.

View all my reviews

Quick Book Review: Building and Testing with Gradle

2011-07-25T09:46:00.002-04:00

Building and Testing with Gradle by Matthew McCullough
My rating: 3 of 5 stars

A short read but answers many of the questions a Gradle newbie would ask. Much of the material was already familiar to me but I had to invest weeks to gain that knowledge. If you are starting a Gradle project this book should be sitting next to you. One piece of advice, looking at the Gradle source will save you a bunch of time and give you new ideas on how to solve problems.

View all my reviews

Quick Book Review: The Cloud at Your Service

2011-07-22T09:44:00.002-04:00

The Cloud at Your Service by Jothy Rosenberg
My rating: 4 of 5 stars

I was a bit skeptical when I flipped through the book but I'm glad I decided to pick up a copy. Although I try and keep up with current technology, I'm not currently on a team that is knee deep in cloud technology and was a little surprised about how much I wasn't aware. The book does a good job of presenting the primary arguments for the cloud and the types of scenarios where it can be useful but accounting for the fact that the technology is rapidly evolving. I enjoyed the discussion of security because I just assumed that an in-house IT solution is more secure than a cloud one. I've since changed my mind. I also enjoyed the treatment of database sharding, which is a technique I've never personally had to employ, and was unaware of the issues that have to be thought through prior to use. If you aren't already in the cloud but want to be prepared for when your boss says it is time I recommend reading this book today.

View all my reviews

Continuous Delivery: Part 14

2011-07-07T09:54:00.000-04:00

Last time, we talked a bit about whether or not our pipeline should support branches or not. Today I would like to ask another question: are debug builds necessary? Back in my C++ days, we would typically build two flavors of the software: one intended for production and one for development. The production one was built with all optimization flags turned on and debugging symbols removed. The development version was almost the opposite with the key being that debugging symbols were enabled. In order to have a reasonable hope of tracking down a bug, you really wanted access to a debug version of the build. The reason I bring up the topic is that one of the primary principles of the continuous delivery movement is to build your artifacts once and then test the crap out of them before deploying into production. Does a CD pipeline need to support debug builds?

In the Java world, compiling without the debug flag isn't the end of the world. Stack traces will contain useful information but you won't be able to look at local variables in your debugger. One feature that is often put into a debug build are assertions which, in Java, are enabled/disabled at runtime, not compile time so a debug version isn't necessary. Finally, logging messages are controlled at runtime as well. Again, no debug version is necessary. So, for my project, it looks like a debug version is not necessary but I see how it might be useful in other languages. How might we do that?

When we do our builds, not only do we create the primary artifact, such as a WAR file, we also create secondary artifacts. Such artifacts include production source code , test binaries, test source and documentation. Perhaps we could also create a debug version of the build and treat it as a secondary artifact? Picture this, QA is running their manual tests and finds something wrong. The bug report contains the candidate release version allowing the developer to pull down the debug artifact along with the accompanying source. In theory, this should allow the developer to deploy a version very similar to the one tested by QA. Perhaps this is good enough to track down the defect without having the developer try and recreate the release on his own? The price of such a solution is increased build time and storage space used by the artifact repository. Sounds like something worth exploring. Until next time.

Have I Found My Application Logging Solution?

2011-07-01T09:31:00.000-04:00

I've been programming for many years with the last decade working mostly with Java code. One of the problems I've struggled with over the years centers around logging. I have yet to work on a system where the logging didn't negatively impact the system in one way or another. Typically, too much logging is used and you end up with "scroll blindness", missing the critical message, or it impacts the performance of the application. I really like Michael Nygard's view on logging which he presented in his book Release It!: Design and Deploy Production-Ready Software. Among other things, Nygard recommends using error codes to drive log messages. He reminds us that the folks in operations trying to keep the system healthy will read the logs more than the developers so their's should be the perspective we take when crafting logging solutions. I've been using his technique on recent systems and have liked the results -- slf4j rocks!. Today I read a read a great article that takes Nygard's advice to the next level.

The article is filled with good observations and recommendations but the part I'm really enamored with is the author's idea of using a plainly human-unfriendly log format so that the information can quickly be sent to a central log repository and analysis service. The idea is to reduce the stress of log processing on the applications and off-load that to some other node. Here is an example of the log message:

1300604499194,4,192168001002,20600,1001,2,500000

To make sense of that you need to look an example logging API that is used to generate that message:

public class LogClientFacade {

      public void log(int logLevel, int instanceId, int subsystemId, int componentId, int errorCode);

      public void logWithContext(int logLevel, int instanceId, int subsystemId, int componentId, int errorCode, Object[] contextInfo);

      public void logWithEx(int logLevel, int instanceId, int subsystemId, int componentId, int errorCode, Throwable ex);

...

}

I'm a huge Spring fan and use it to inject loggers into objects that indicate their desire to access one. I can see enhancing the bean post-processor to automagically determine the application's instance, sub-system and component, saving some boiler plate code. I look forward to thinking about this to see if it might make sense on future projects. Until next time.

How Can I Show Nice Code Snippets in Blogger?

2011-06-29T09:29:00.000-04:00

Typically, when I blog I write about programming which means that I often show code snippets, as done in a previous post. Although I like Blogger's convenience, I wish that it pretty printed my snippets. Finally, I got off my butt and did some searching and came across two techniques. The first, uses this recipe and allows you to stay within Blogger when crafting a snippet. Here is an example of that:

sourceCompatibility = 1.5
version = '1.0'
jar {
    manifest {
        attributes 'Implementation-Title': 'Gradle Quickstart', 'Implementation-Version': version
    }
}

A second option, which requires no Blogger template configuration, is to use gist. Here is an example of that:

Which do you think looks better? The two solutions are reasonably easy to implement and offer a better result than stock Blogger. Until next time.

Are TDD and Polyglot Programming a Poor Combination?

2011-06-25T10:29:00.000-04:00

Last time, we dug up some old tools that can help us to auto-detect our JUnit tests. As I was writing up my thoughts for that post, my mind wandered a bit over to something I had been wanting to try and how it might impact testing.

Test Driven Design (TDD) in increasingly becoming more accepted each day. Part of TDD is to develop a code-test-code-test rhythm. To this point, I've always written my tests in the same language that the implementation used -- typically Java. On today's JVM, there are a vast array of different languages to chose from so does it make sense to use a different language to test than the one being used for production? Neal Ford, in his book The Productive Programmer, has an example of a test written in two ways: once using Java and once in Groovy. The Groovy one is more concise because it can skip over the reflection APIs used in the test. Groovy can look similar to Java code if you want but it can also look different. After you drop the typing, semi-colons and add in iteration constructs and closures, you are looking at a different beastie -- which leads me to my question. Is there a cognitive penalty for constantly switching between programming languages?

When TDD is flowing, you are constantly switching between the production abstraction and the tests that poke at it. The focus is on how to verify the abstraction, not what language feature should be use to do that. Groovy can look like Java so maybe the penalty isn't that great but what about jRuby? Scala? The syntax and language libraries aren't my only concern. What about the notion that TDD can help define better APIs because your tests are the first users of those APIs? Are the APIs going to look differently depending on what testing language I select? This viewpoint suggests that TDD doesn't guide you to a better design but, instead, to a less coupled and more testable one but that is a debate for another day.

If anybody has any real-world experience with polyglot testing I would love to hear from you. I'm thinking about applying it on a new project and hope to avoid any known issues. Until next time.

Still More JUnit Auto-detection Solutions

2011-06-23T08:58:00.000-04:00

In a previous post, I talked about a solution for automatically detecting JUnit tests and obviating the need for maintaining suite files. As I walked into work this morning, I spotted a copy of JUnit Recipes on my bookshelf. The book is from 2004 and I haven't cracked it open for quite some time but I decided to see if a recipe for my problem existed. Sure enough, Recipe 4.5 titled Scan the file system for tests slapped me in the face and describes two solutions that might be useful to me. Granted, JUnit 4 was not released until 2006 so it is possible that these solutions may no longer apply but I'll pass them on just in case. One option is to use Mike Bowler's GSBase library which contains the RecursiveTestSuite object. Unfortunately, the project didn't load for me and may no longer exist. Another option is to use Vladimir Bossicard's JUnit-addons DirectorySuiteBuilder object. This site, thankfully, loaded but does not appear to have been updated recently. The documentation says that the file system is scanned for tests candidates and that you provide a custom filter based on the class name and class meta-data. I bet I could write a simple filter that could look for the new Category annotation. The DirectorySuiteBuilder does deviate from what I want in one respect: it scans the file system and not the classpath. Using a solution that searches the classpath has the potential for being more portable. For example, I'm looking into how difficult it might be to embed some of our application's tests into the application itself. Not having to deal with differing file system layouts would make it a bit easier. If I ever get around to trying out DirectorySuiteBuilder, I'll let you know. Next time, I hope, we'll get back to some more build pipe lining.

Continuous Delivery: Part 13

2011-06-20T09:49:00.001-04:00

Last time I promised to expand a bit on our Gradle file's ability to assemble Java code but I'd like to break that promise because something relevant to our pipeline just came across my desk: source code branching. My investigations into a pipeline implementation assumed a main line build and nothing else. Does the pipeline need to support branches or is building the trunk good enough? Thinking back over the projects I've been involved in, I can remember both good and bad when it comes to branching the code.

The good, and I'm being kind when I say good, involved branching code after a release into the wild. The release branch was fairly stable and was only touched in order to fix bugs. What got interesting is when we were asked to port a fix in the trunk to the release branch. Typically, the code differed enough that you had to use diff tools and merge the changes in by hand -- a scary proposition to say the least.

The bad happened when some disruptive feature was being created which typically took many weeks to develop. If we were really lucky, we could have two feature branches going on at the same time. If the feature developers were disciplined enough to merge from the trunk everyday, things worked out reasonably well. Even if they did, it was not uncommon for files to get moved around or otherwise refactored making it more difficult for the feature branch to stay in sync with the mainline. Merging back into the trunk was always an adventure. How does this relate to a CD pipeline?

If the goal of a pipeline is always to deploy, does that apply to a feature branch? In my experience, feature branches spend much of their time "broken" and don't fit the mold of something to be continuously deployed. Release branches, however, may work. I can see how bug fixes should seamlessly progress through the system. So how do we, in the context of a pipeline, give the business the ability to introduce new features and still keep the deployment train rolling? One idea is to use Feature Toggles.

The essence of Feature Toggles is to add the ability to enable/disable features so that development and testing can continue on the trunk. There are build-time and run-time strategies that can be used, including configuration files, program parameters and annotations. So, as far as the pipeline is concerned, we will focus on supporting release branches but not feature branches. Using feature toggles appears to be better aligned with the continuous delivery mantra. Hopefully, next time we'll dig a bit more into our Gradle file and learn how to create more of the artifacts that will be consumed by step two of the piepline.

Another JUnit Test Auto-detection Solution

2011-06-18T03:00:00.000-04:00

Last time, I wrote about a solution that I came across that will allow me to auto-detect tests, eliminating the need to maintain JUnit suite files. I was pleased to see a DM from and old colleague pointing me to a library he had written to solve that problem. I haven't had a chance to try out Dale's solution but having worked with him for a few years I have no doubt that the solution is solid and does what is advertised. I am really interested in perusing the source to see if I can glean its secret recipe for success. I'll probably write about what I find out but my plan for next time is to continue down the pipeline road.

I will drop TestNG for JUnit

2011-06-17T03:00:00.000-04:00

Last time I was pondering whether or not to reexamine my preference of TestNG over JUnit. I had mentioned that I was not willing to give up TestNG's ability to group tests as well as its auto-detection capabilities. I did some poking around the web and was pleased to find that some smart folks have already solved the problem. JUnit 4.8.2 now supports the notion of a Category which is a mechanism to logically group your tests. This is similar to TestNG's group feature. The auto-detection of tests, however, is not built in.

In order to solve that problem, you need to include a nifty library named ClasspathSuite. It purpose in life is to scan your classpath for JUnit tests. Awesome. Some nice person posted a recipe for mixing auto-detection with Categories which I shamelessly ripped off. I've posted my learning test code on bitbucket in case anybody is interested. It is close enough to what I get from TestNG that I'm willing to switch over to JUnit and see how that works out for me.

I already see one thing I'll miss from TestNG which is the ability to identify all public methods in a class as tests with a single annotation. In JUnit, you have to annotate each method but this is minor complaint. Hopefully, moving back to JUnit will make integration with other tools less painful than it has been when I was using TestNG. We shall see. Next time, we'll get back to discussing the continuous delivery pipeline.

Should I drop TestNG for JUnit?

2011-06-16T03:00:00.000-04:00

I thought I would take a break from our discussion on implementing a continuous delivery pipeline and revisit a decision I've made a while back. First, some context.

Yesterday, I was chatting with a good friend of mine who had mentioned that he was having trouble getting his Scala tests to run the way he wanted with TestNG. I suggested that he try his test under JUnit and his response was "I don't like JUnit". It was then that I remembered that years ago he and I had arrived at the same conclusion: TestNG was the best framework for how we tested. Over time, JUnit has improved itself and both frameworks have borrowed ideas from each other giving developers a difficult choice of which tool to use. My favorite features of TestNG are its ability to assign a test to multiple groups, eg unit, integration, smoke. It also has the ability to scan your classpath for tests, freeing you from having to manually maintain an ever growing collection of tests to run. You can also combine the two notions so that you can easily tell your build system to run all the smoke tests in one target and all the unit tests in another target. Once I was reminded that my decision to use TestNG was based on data that is years old I started to wonder if maybe it is time to revisit that decision?

I went to the JUnit website and started reading the release notes. Lo and behold I find a new feature called Categories which, on the surface, appear to be similar to TestNG's groups. One less feature in TestNG's favor. I continued to search for discussions on how to make JUnit auto-locate tests and came across one on stackoverflow that seemed to indicate that it is not a built in feature but can be coerced into doing it. I'm seriously consider trying out JUnit again but it has to be able to support my two favorite TestNG features. Why bother, you ask? Primarily it is because JUnit appears to be the most popular choice for unit testing in Java. For example, I've been using Spring Roo to help me bootstrap a Spring MVC project and it has the ability to generate the skeletons for the tests. Guess what framework it supports? You guessed it, JUnit. JUnit has improved greatly since its 3.0 days and has a sizeable ecosystem surrounding it so I'll probably give it another chance. If I can't get where I want to go using off-the-shelf components I may experiment with writing my own test runner -- maybe. Next time we'll go back to our journey towards pipeline nirvana.

Continuous Delivery: Part 12

2011-06-14T06:00:00.000-04:00

Last time, we decided how we would structure the build files and I promised to finally start writing them. Let's get started.

The stage one build is responsible for compiling the production and test source as well as running the unit tests and some light-weight inspections. The team recognizes that Java is a very capable but aging language and wishes to be bit more polyglot in their development. Our past strategy for introducing something new into our tool box is to deploy it into test. If the experiment fails, we won't impact the production system. In our case, we are looking to simplify our test code and are willing to try some of languages available on the JVM, such a Groovy and jRuby. Let's see if Gradle can help us do that.

Gradle tries to simplify the developer's life by providing commonly required behavior in the form of plug-ins. If your project adheres to the plug-in's conventions, then your build file can be very small. Our primary requirement is to compile and package Java files and that can be done with a single line: apply plugin: 'java'. If you've done this correctly, you should be able issue the command gradle tasks and see some build related tasks appear in the list, such as classes. Any .java files in src/main/java and src/test/java get compiled. Most projects have dependencies on libraries and gradle needs to know what they are. There are a variety of ways to express the dependencies and here is an example of what I've done:

dependencies {
   compile module('aspectj:com.springsource.org.aspectj.weaver:1.6.8.RELEASE')
   compile module('slf4j:slf4j-api:1.6.1')
}

Including the Java plug-in and specifying the dependencies should be enough to let Gradle build your Java source files. The documentation for the Java plug-in is good and you should use it to help guide your build file. Like Maven, Gradle's Java plug-in supports different classpaths based on context. For example, the above snippet shows two libraries being added to the compile configration. The testCompile configuration is the classpath used when compiling and running the tests. The runtime and providedCompile are examples of other configurations.

I'm out of time today but next time we'll continue to build out our stage one build file.

Continuous Delivery: Part 11

2011-06-13T06:00:00.000-04:00

Last time, we pondered how the Gradle build files should be organized. It seems reasonable that each stage should have its own build file. We also considered playing some games with Subversion to avoid having stage two check out source files that it won't be building. After thinking about it some more, it seems clearer to have the two build files appear in its natural form and not do anything tricky with the VCS. Although this may fall into the category of YAGNI, I'm not sure that the DVCS systems we are likely to move to in the future, such as Mercurial and Git, can support the virtual layout mechanism we were thinking about employing. Second, if a developer wanted to test out stage two on her box, she would have to keep two working areas, one for each stage, which seems like a hassle. Finally, the plan is to store library dependencies in a repository and not as part of the source tree which should help to keep its size reasonable.

In summary, we will have two build files, build.gradle and stage-two.gradle, living at the root of the source tree with common logic stored in shared.gradle. The stage one build will use build.gradle and the stage two build will invoke stage-two.gradle. The clarity of keeping the various build files together in an understandable manner outways any potential performance benefits of not downloading files that won't be built. Next time, I promise, we'll start crafting the build files.

Continuous Delivery: Part 10

2011-06-10T06:00:00.000-04:00

Last time we talked a little bit about how the source files are laid out and promised to start writing some Gradle code. I may have been a bit premature.

One thing we need to consider is Gradle in the context of the CD pipeline. Stage One is going to be the stage that does all the compilation and assembly of the code, along with some light testing. Stage Two is going to perform all the automated tests and deep inspection of the artifacts. To avoid leakage of stage one build constructs into stage two, I'm thinking we need to create two build files: one for each stage. Gradle allows the specification of a build file via the --build-file option so that should be doable. Using a script based plug-in, we should be able to share common Gradle code between the two files. If we imagine the build running in a CI environment, we have to ask this question: should the stage two build be part of the stage one source tree or independent? Asked another way, should stage two endure the overhead of checking out the entire project despite the fact it is not going to do any building? In our small example project, the overhead is not significant. In a larger project, however, it may be a factor. I guess it boils down to a few issues:

how can the two Gradle build files share common code if they reside in different areas of VCS?
do the files need to live in different area of VCS or can we play Subversion tricks and just grab what we need?
is how stage two gets its artifacts from stage one a factor in the decision?
is separating things too hard to do at this point and should be tabled to a later date?

Interesting questions but I'm out of time for today so we'll have to ponder them next time.

Continuous Delivery: Part 09

2011-06-09T09:00:00.000-04:00

Last time we talked a bit about how you might want to load up the Gradle source into your IDE whenever you start doing Gradle work because it'll save you plenty of time. Today, we'll talk about the directory structure and the project we'll be creating to test out the CD pipeline.

First off, I'm a big fan of the Spring framework and have created a simple template project that I use to bootstrap new projects. I also use it to see how things change between Spring releases. This is the project we'll be using to test out our pipeline. It is a simple web application that exposes a basic RESTful service that is tested using Spring's RestTemplate. The application also uses Spring Social to make a quick Twitter call to get a list of an account's followers. Nothing fancy but it does mimic what you might find in a typical application.

The layout of the project attempts to follow the Maven conventions. Although I don't use Maven on my personal projects, I really like what they have done with dependency management and encouraging standard project layouts. Our project follows their conventions and looks something like this:

src/main/java
src/main/groovy
src/main/resources
src/test/java
src/test/groovy
src/test/resources
buildSrc/src/main/groovy
buildSrc/src/main/java

The files under src/main contain the production code and the files under src/test contain the test code. Files under buildSrc are the custom Gradle plug-ins we'll write. The project is implemented in Java but we added Groovy directories so that we could test out how polyglot programming might work under Gradle, especially in the context of testing.

In our shop, we've settled on the following definitions for tests:

unit - testing of a single object isolated from its dependencies, driven by TestNG and Mockito
component - testing of a set of cooperating objects but does not require the entire application to be up and running, driven by a combination of TestNG and Spring's testing objects
system - testing of the fully assembled system running in a production like environment, driven by a variety of tools including TestNG and SoapUI.
UAT - testing of what the application does from the perspective of the user. This is a new area for us and we hope to use Cucumber to drive the UATs but that may just be a disaster in waiting.

All our tests live in the src/test directory and use annotations to group our tests. For example, we use TestNG's group notion to tag tests as either unit, component or system. Cucumber has a similar feature in its framework which should allow us to group those as needed.

That's it for today but now you have a better understanding of how the code is organized and how we are thinking about attacking tests. Next time, we'll actually write some Gradle code and get this bad boy building.

Continuous Delivery: Part 08

2011-06-08T09:00:00.000-04:00

Last time, we decided to go with a single project layout. It doesn't allow for much reuse but it is the simplest to implement. Today we'll talk about implementing the build in Gradle.

Tip: load up the Gradle source into your favorite IDE before you do any Gradle work. You'll be glad you did. The documentation is generally pretty useful but if you really want to know what is going on or want to do something out of the ordinary, looking at the code will make it easier.

Tip: write a plug-in. Taking the time to write a simple plug-in will help you to better understand how Gradle is put together and gives you another option for packaging your logic. Plug-ins take a few forms. One, is a simple file inclusion where you are importing a Gradle file and looks like this: apply from: 'shared.gradle'. Another form manifests as Groovy and Java files. The simplest version of this type live in your project's buildSrc/src/main/groovy or buildSrc/src/main/java. Understanding how plug-ins work makes it easier to figure out where to look when reverse engineering existing Gradle logic.

I'm out of time for today so next time we'll discuss the directory structure of the project.

Continuous Delivery: Part 07

2011-06-07T09:00:00.000-04:00

Last time we mulled over the selection of a build tool and arrived at Gradle. Now we have to decide how to layout the project files. There are two options: one is to have a single project that contains the code for the entire system from presentation to persistence -- soup to nuts. The other option is to create smaller interdependent projects that comprise the solution. To help us decide, we need to quickly examine the tensions between the three major parties that care about the project layout.

The first party is the developer. Ideally, she just wants to issue a single check out command, point her IDE at the source and get to work. In our shop, Eclipse-based IDEs are the norm, such as SpringSource Tool Suite and Adobe Flash Builder, and we need to account for its layout preferences. In Eclipse parlance, individual Projects are collected together into a Workspace. If we opt to have a single uber-project, we would have a single Workspace that contains a single Project. If we opt to use a multi-project layout, the Workspace would contain multiple Projects and the Projects would refer to each other so as to share the various symbols each produces. Our shop currently uses Subversion as its VCS which supports the notion of Externals which can be used to present a virtual layout different from the physical one. We can use that mechanism or a custom script to solve our "single checkout" requirement.

If we switch perspectives to that of the CI server we'll see that the single project model is easier to implement. Most of the documentation talks about building a project or showing the test results for a project. Most don't even acknowledge that is even possible to create a chain of interdependent builds. Let's says that we have a Client project that depends on APIs produced by the Server project. The CI build sequence is to build Server first, export its artifacts to Client and build that. The complexity comes from the export step. The CI's reporting preference is also a factor. Most CI servers can show test results and other reports for a project. I have yet to see one that can aggregate the results for a set of projects into a single view. It is easier for people to assess the health of a build if they see the results of the whole and don't have to visit each project's build page to see how the tests are doing.

Finally, we need to look at things from the Gradle's perspective. We must assume that Gradle will be official build tool. The IDE's build is for convenience only and the developer is expected to execute the Gradle build prior to check in. Gradle can easily handle single and multi-project layouts so, at first glance, our decision doesn't really matter. If we combine the CI viewpoint with that of the developer, we see that there is certain amount of tension. Assume that we have taken advantage of Subversion Externals and have created an Eclipse-friendly multi-project layout. If we also assume that the CI server does not use the virtual layout but instead checks out just the individual projects we can see that Gradle must support two views of the build landscape. One view is the layout as seen on the developer's desktop where sibling projects can be accessed by using relative paths. The layout on the CI server is isolated and has to obtain dependencies a different way. Gradle must operate in both environments and needs to accommodate both views. Gradle uses Groovy to express build logic so we should be able to put in the needed infrastructure to support both but it is likely to be complicated to implement. For example, how can Gradle know, when running in a CI environment, how to obtain artifacts generated in previously built projects? What is a good way to remain DRY and share common build logic when building a single project in a CI environment? Is it possible to aggregate reports of the individual projects into a single view?

Once you think about, the seemly simple decision of whether to have a single uber-project or not is a bit more complex than originally thought. Individual projects do appear to offer greater reuse between different solutions because you can share artifacts via an artifact repository but with greater development cost. A single project is simpler to implement but doesn't support reuse like the individual project solution. Given that we are trying to keep implementation time down for this project and that we are more interested in how the CD pipeline works, I'll opt for single project model. If we find value in CD, then I'm sure we'll revisit the single- vs. multi-project layout decision.

I've rambled on enough for today but at least we've selected a project layout style. Next time, we begin crafting our Gradle build and I'll share a few tips that I've learned.

Continuous Delivery: Part 06

2011-06-06T09:30:00.000-04:00

Last time we listed some of the potential tools that we might use in our CD solution and came to realize that there are numerous moving parts. Today we'll focus on one aspect: the build tool.

The candidates are Ant, Maven and Gradle. The team is already comfortable with Ant but it really isn't anyone's favorite tool. Yes, it has many of the pieces needed to build a Java project and is also being used to build our ActionScript projects. Yes, it is integrated with most IDEs and yes, there are custom Ant tasks to bind it to various tools. Ant, however, is a blank slate and doesn't make it easy to create a working build and applying conditional logic can be a pain.

"Apache Maven is a software project management and comprehension tool" which sounds ambitious. My favorite feature is its ability to manage library dependencies and I also like how it encourages a standard directory structure. On the negative, Maven can be a bitch if something doesn't work right. For example, I worked on a project were the automated tests were getting run twice and it turned out to be a "known problem". If you don't do things the Maven way, you will be in constant debug mode, despite what the documentation says. I admit, it has been a while since I've been involved with a Maven build and haven't looked at Maven 3 but I doubt things have changed that much.

Gradle is an interesting approach in that it combines a DSL expressed in the Groovy language with Apache Ivy producing a powerful build environment. As an added benefit, it has Ant support so that, in theory, anything you do can do in Ant can be done in Gradle. I've been annoyed enough with Ant and Maven that I once wrote a build system that was 80% Ant and 20% Groovy and managed to create a reasonably powerful build system that had reasonable defaults, freeing the developer from having to specify most things. Gradle stole a page from the Maven playbook and supports common tasks via plug-ins. Gradle also has support for multi-project builds.

Gradle sounds good but what are the risks? First, at the time of this writing, it still in release candidate status so 1.0 hasn't shipped. Second, none of the team has any real experience with it. Third, only IntelliJ appears to have baked-in support for it. Eclipse might, but I haven't waded through the zillions of plug-ins that could be installed. Since we are talking about implementing CD on a low-risk pilot project, picking Gradle doesn't sound like something anybody could get fired over and Plan B would simply be to re-write the build in terms of Ant.

Now that we've selected Gradle as the build tool we now have to decide what to do with it? Do we create a single monster project or use a set of cooperating individual projects? That will be the discussion for next time.

Continuous Delivery: Part 05

2011-06-05T09:00:00.000-04:00

Last time, we talked a bit about the vision for a CD pipeline. This time we'll toss around some candidate technologies.

The first thing we'll need is a CI server. Being an Atlassian shop, Bamboo seems like a reasonable choice. The folks over at ThoughtWorks have their GO solution which has the added benefit of being designed by the author of the CD book. Jenkins, a fork of Hudson, seems like an popular free solution.

Another piece we'll need is a build tool. The usual suspects are Ant and Maven but Gradle looks really interesting. Complementing the build tools are artifact repositories, which boil down to Nexus and Artifactory, and the version control system. For us, our current choice is Subversion but I can see Mecurial and Git on the horizon.

After the code is compiled and assembled, it needs to be tested. Two popular testing frameworks are JUnit and TestNG. For UAT, Cucumber appears to have the potential for being very useful for UATs and I can't forget about SoapUI for testing RESTful APIs. We also need to see how much of the code has been tested so we'll need run a coverage tool, such a Cobertura, EMMA or Clover.

Once the code is tested, it needs to be inspected for various quality and standards violations. FindBugs can help find common bug patterns in the code. Checkstyle and PMD can look for coding violations and bad practices while CPD can help keep the code DRY. Sonar, thankfully, can run all of these tools for you and perform trending analysis.

In the grab bag category, we'll take a peek at SchemaSpy, Doxygen and UmlGraph for generating documentation and Liquibase and dbdeploy to assist with rollback of deployments.

Holy smokes, that is a lot of stuff to look at and is going to take a bit of time to wade through. Next time, we talk about what we want to use for building the code.

Continuous Delivery: Part 04

2011-06-04T09:00:00.000-04:00

Last time we talked about some of the parameters surrounding the project so this time I figured I would talk a little bit about the pipeline we want to set up. After a few discussions with the team, we came up with a four stage pipeline, with two being automated and two being manual:

stage one - compile, package, unit tests, documentation and basic inspection
stage two - automated tests (unit, component, system and user acceptance), deeper code inspection, publication to repository
stage three - manual testing (functional, longevity, performance)
stage four - deployment to production

In stage one, we are trying to quickly verify that no egregious errors have been introduced, including compilation errors, too little unit test coverage or ridicuously long and/or complex routines. We want stage one to run as quickly as reasonable because the developer's are supposed to run the stage on their desktops prior to check in and they are also supposed to wait until the stage completes on the CI server before moving on to their next task.

In stage two, we are taking the artifacts generated in stage one and applying deeper inspections as well as running all of the automated tests. As we will see in future discussions, implementing stage two can be challenging, for various reasons.

In stage three, the changes have passed all automated testing and are ready for manul testing. The goal is to have a tool in place that notifies the test team that a test candidate is available and provides push-button deployment to the desired test environment. Typically this will mean functional testing but, on occassion, we'll need to run non-functional tests, such as longevity tests. Ideally, the tool used to notify the test team of candidates should also remind them when some of the non-functional tests need to be run.

Finally, in stage four our push-button deploy tool should notify the operations folks that a release candidate is available for deployment. This stage must include a rollback strategy in case something goes wrong. Ideally, some form of smoke test should be available to ensure the sanity of the installation.

Our pipeline should be triggered after a commit to the version control system (VCS) is done. The idea is to better isolate who caused a breaking change. The Blame Game is fun to watch once in a while but can become tedious on a regular basis.

Now that we have an idea of what we want to happen in each stage, we can sift through some candidate technologies and see what shakes out. We'll do that next time.

Continuous Delivery: Part 03

2011-06-03T09:00:00.000-04:00

Last time, we discussed how the CD project got kicked off and promised to review some of the project's parameters.

We're not a huge company with near limitless resources and have made some investments in software and infrastructure. The CD solution should leverage those investments when reasonable, keeping the dollar cost down. We use several portions of the Atlassian stack so it makes sense to look at their CI server to see if it can meet our needs. We are not afraid to use open-source software which opens up a whole lot of doors. I prefer to select open source technologies that are mature enough to have some sort of commercial entity backing them, just in case we need some support. The Spring framework and SpringSource are a good example of what I mean.

Another restriction is that the solution can not take months to create. There are too many projects that need attention and too few of us to do the work to spend on something that could potentially improve things. To me, this meant either finding a reasonably priced off-the-shelf solution or integrating various OSS parts together. In any case, writing new software to make this happen or spending too much time working around defects in nascent technologies is out of the question. This had to be done in a few weeks, not months.

Finally, the solution has to work with Java based projects with ActionScript compatibility a "nice to have". Java has been around for years with a mature ecosystem so compatibility with JVM-based languages shouldn't be a problem. It will be interesting to see what tools are available on the ActionScript side.

In summary, don't spend too much time or money crafting the CD solution and make it work with Java and ActionScript. Next time, we'll discuss candidate technologies and maybe even pick one or two of them.

Continuous Delivery: Part 02

2011-06-02T09:00:00.000-04:00

Last time, we kicked off the discussion about my particular continuous delivery solution. This time I thought I would give a bit of context to the project.

Like most software companies, mine is constantly looking to improve the software development process. My manager was a developer in a previous life and understands how automation can ease certain pain points and kicked off a pilot project to see if continuous delivery is suitable for our development shop. I have always been interested in improving the development process and have tried to stay current with the continuous integration landscape. Unfortunately, my past shops have stopped at "continuous compilation" and weren't all that interested in automated testing, inspections or deployments. Luckily, I attended an NFJS conference and one of the speakers encouraged people to grab a copy of Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation to see if some of its recommended practices would be relevant to our current situations. I had heard of continuous integration, read some books on the topic and implemented a few "continuous compilation" servers at a few jobs but CD was new to me.

I threw a copy on my Kindle and liked what I read. The advice seemed sound and didn't reek of the all too frequent "do it this way and all will be well" seen in some software literature. Some of the techniques described in the book were already underway in our shop so trying to build out a CD pipeline seemed like a good fit.

Of course, no field is totally green and there are certain restrictions that have to be respected. We'll discuss those restrictions next time.

Continuous Delivery: Part 01

2011-06-01T09:12:00.000-04:00

I've been involved in an effort to implement a continuous delivery system and have come to appreciate how difficult the solution can be. Throughout this process I've come to rely heavily on the communities surrounding the various tools we are using in our implementation and have decided that I should give back by documenting what I've learned. If I can save somebody an hour or two of hair pulling by pointing out a dead end path or sharing a tip, then I'll be happy.

I'll be putting up short posts on a regular basis and will be discussing tools such as Gradle, Groovy, Jenkins, Bamboo, Sonar, TestNG, Cucumber and maybe even a little ActionScript. I warn you, however, that the solution is not yet complete and I really can't say exactly how this journey will end but it might be fun to stick around and see how it all turns out.

Next time, I'll be discussing the context of the solution including the requirements, restrictions and the team that will be initially using the system.

Why doesn't my Traeger heat up past 350 degrees?

2011-05-29T18:09:00.000-04:00

I'm starting my second full season of grilling with my Traeger and I've run into an interesting problem: it won't heat up past 350 degrees. This isn't a problem when I'm cooking ribs or some other "low and slow" meat but it is an issue when I'm trying to cook burgers or steak. When I initially purchase the unit I remember it topping out right around 500 degrees. When I replaced the stock thermostat with a digital one, the maximum temperature dropped to around 450, which was fine.

Fast forward to this spring, I cleaned out the grill as it had spent the winter snuggled under its cover. When I fired it up to verify everything was ok, the thermometer wouldn't get passed 320. Thinking that it might be an issue with the digital thermostat, I swapped it out for the stock one. No joy -- the Traeger still wouldn't climb much higher. I used a kitchen digital thermometer to verify that the thermometer built into the grill wasn't somehow broken -- it wasn't. I had read on the internet that sometimes the fuel can become damp with moisture and affect the heat output. I swapped out the pellets for a different batch but it made no difference. I even bought some non-Traeger brand pellets to see if that was the issue but no luck. I cleaned everything out once again and tested to see how hot the grill could get with no grate, drip shield or anything that covers the fire box. That configuration allowed me to hit 500 degrees with no problem. Adding back the drip shield, however, decreased the grill's output back down the the 350 range. I'm hoping that somebody might give me a tip or two on how to solve this problem. I'll contact the folks at Traeger to see what they can do to help me. I haven't dealt with their customer support before but I'm hoping they'll be able to help me out.

Update: I was a bit on the bored side this Sunday afternoon so I asked Traeger for assistance in three ways: Twitter, Facebook and their website. Five minutes after filling out the support form on the website, I got an e-mail listing 7 things I can try. About 90 minutes later I got a phone call from Andy over at Traeger and he gave me some ideas as well. On Facebook, Traeger left a comment stating that I should call them and they would help me out. Nothing on the Twitter channel. I haven't had a chance to try out their suggestions yet but I've got to say that I'm pleased thus far with the folks at Traeger.

How can I get Spring 3.0 MVC to use content negotiation for errors?

2011-03-29T09:22:00.000-04:00

I'm a big fan of the Spring framework and have come to appreciate its REST support in the MVC module. I especially like how the client can request a specific representation by setting the Accept header in its request to a mime-type that the server understands, like application/json. That was easy enough to get running with the reference documentation and a little trial and error. What I did struggle with, however, is getting Spring MVC to honor the requested format when returning error information. It took some time tracing things in the debugger to finally figure out the secret sauce so I figured I'd save people some time and share what I know with the rest of the world.

First, a little context. I use JAXB annotations on my DTOs and let the Spring OXM layer translate between Java and XML. One of those DTOs is a Fault object that contains an error code, error message and a link to more details. The Fault DTO is also annotated with JAXB so it can be serialized to XML. I use Spring annotations on my controllers to indicate URI endpoints and fault handlers. Here is an example of a fault handler:

@ExceptionHandler( Deviation.class ) // says call this method whenever Deviation is thrown
@ResponseBody // says use the return value as the response body
public Fault handleDeviations( final Deviation deviation,
                               final HttpServletResponse response ) throws IOException
{
    response.setStatus( deviation.getErrorCode() );
    final Fault fault = new Fault();
    fault.setCode( HttpStatus.NOT_IMPLEMENTED.value() );
    fault.setMessage( deviation.getLocalizedMessage() );
    return fault;
}

The trick to get Spring to honor the requested media type which is controlled by the AnnotationMethodHandlerExceptionResolver object. The secret is to hand-configure the exception resolver to use the XML and JSON message converters in addition to its default converters. The resolver loops through its list of converters, asking each one if it can support the requested media type. The first one to say yes gets to serialize the fault object. Here is some example configuration code:

<bean class="org.springframework.web.servlet.mvc.annotation.AnnotationMethodHandlerExceptionResolver" id="annotationExceptionResolver">
    <property name="messageConverters">
        <list>
            <ref bean="jsonHttpMessageConverter">
            <ref bean="marshallingHttpMessageConverter">
            <bean class="org.springframework.http.converter.ByteArrayHttpMessageConverter">
            <bean class="org.springframework.http.converter.StringHttpMessageConverter">
            <bean class="org.springframework.http.converter.xml.SourceHttpMessageConverter">
            <bean class="org.springframework.http.converter.xml.XmlAwareFormHttpMessageConverter">
        </bean></bean></bean></bean></ref></ref></list>
    </property>
</bean>

Once your message converter are in place you should be good to go.

XBMC on Acer Aspire Revo AR3700-U3002

2011-01-03T09:52:00.000-05:00

Santa was kind to me and brought me a brand new Acer Aspire Revo AR3700-U3002 for Christmas. I liked the HTPC setup I created last year so much, I decided to create another one for the second TV. This unit is a bit more expensive than last years but it has more current hardware and a few more bells and whistles, such as WIFI. Unlike last year, I decided to leave the OS as is: Windows 7 Home Premium. As I noted before, the Windows drivers seems to yield better performance than its Linux counterparts. All I did for this set up was to image the drive and then remove all the bloatware that I did not want or need. I visited the nVidia site and updated the drivers to the current version as well as installed Adobe Flash for Hulu support. Nothing unusual. I then dropped in XBMC 10.0 and was off to the races. The current version of XBMC is really nice and played well with the hardware. The remote I have, was recognized automagically by Windows and I can use it to control XBMC, Hulu and Windows Media Center. All is not perfect, however. When I play Hulu desktop in full screen, it stutters. I was really surprised by this because the older hardware does not have this problem. I've got to believe I've missed a setting somewhere. The only difference that is obvious to me is that the older hardware is running 32-bit os while the newer one is running 64-bit. Are there issues with Adobe Flash under Windows 7 b4-bit? I'll let you know when I finally figure it out.

XMBC + Windows XP = 720p Goodness

2010-12-21T13:05:00.000-05:00

Last year, I wrote about how I set up a Linux-based HTPC. Overall, I think the system worked very well. My only complaint would be that I cannot run Hulu Desktop in full-screen mode. The playback is jittery and annoying. I just assumed that the processor and/or video card just weren't up to the task. I was wrong. Recently, a co-worker was contemplating a similar purchase but didn't want to waste money on a system that wouldn't work for him. He hails from India and cannot easily get video content from his native region here in the US so files are traded electronically between friends and family. As a favor, I took a rip of a Blu-Ray movie and told him I would try it out on my box at home. I played the movie under the standard Linux/XBMC combination but there were annoying hesitations and skips. No joy. When I built the box, I kept the original Window XP installation and set up a dual boot configuration. As a test I decided to try playing the file under Windows.

Since I rarely boot into Windows I had to apply a zillion updates to make the OS current. A couple of those updates proved to be significant:

Flash Player 10+
nVidia chipset and video drivers
XMBC 10

What I found after the updates was that I was able to play Hulu in full-screen without skipping. Yay! My guess is that the support for hardware acceleration is present in the Windows software but not the Linux version. I then proceeded to fire up the Blu-Ray rip and XBMC played it in its full 720p glory. Being such a Linux fan it had never occurred to me that Windows might be a better performing solution. It is a bitter pill to swallow but the support for the hardware, at least in this case, proved to be better than Linux. Granted, I'm not running the most current release of Ubuntu but I would be surprised if any significant performance gains were made in the past 12 months. Now that I have determined that Windows+XBMC is the best solution for my hardware, I'll need to go back and solve some of the same problems I've already solved in the Linux world, such as how to get XMBC to automagically start when Windows starts or how to make the remote control work. Such as the life of geek: always tweaking and never satisfied with the status quo.

Atlassian Stack: FishEye Startup

2010-08-31T13:03:00.000-04:00

Ubuntu uses Upstart as it mechanism for starting/stopping processes during bootup/shutdown. FishEye includes two shell scripts: start.sh and stop.sh. I created two files: /etc/init/fisheye-start.conf and /etc/init/fisheye-stop.conf that controls the FishEye process. The scripts are dirt simple and are just rip-offs of the previous Startup scripts with the only difference is that we only specify a "start on" or "stop on" stanza, depending on what we are trying to do. This seems to work well. I have noticed that upon booting the machine I have to wait several minutes for the CPU to calm down before I try logging into the various services or they won't be available.

When I configured FisheEye, I used the file:/// URL form to eliminate the use of the network and boost performance a bit. Tomorrow, I'll do some more FishEye configuration and integrate it with the rest of the stack.

Greetings, Earthlings

2010-08-30T12:22:00.000-04:00

I've started this new blog not because I wanted but because I had to. You see, the blog I was using -- screaming tiger -- became unavailable to me. I have been using my Google Apps account to log into Blogger and one day, it stopped working. Blogger insisted that I use my regular Google account. I waited hoping things would fix themselves. I know the Googlers are hard at work trying to integrate Google Apps into the rest of the Google portfolio so I had some reason to be optimistic. When that failed, I tweeted hoping that somebody out in the Twitterverse would hear my cries and tell me that everything is going to be all right but, alas, silence. I can't complain too loudly because I'm not paying Google anything for the use of their services but I am concerned about how the lights suddenly went dim for my account. Unless things change, I won't ever be able to get into my other account and get to my data. Luckily, I can still view the blog and pull out any useful tidbits of information I may have stored there. So, at least for now, this is my new campsite on the web.