Powered by the CalorieKing nutritional database, GoMeals allows you to search thousands of foods and dishes from popular restaurants, grocery stores and the items you have in your own kitchen to easily see the nutritional value (i.e. calories, carbohydrates, fats, protein, etc.) of the foods you eat. You may also track your daily food intake by saving food items to your "Today’s Plate" on the application’s calendar. You can monitor each day’s caloric intake, as well as the distribution of carbs, fats, and proteins. If you’re going out to eat, use the restaurant locator to easily find restaurants nearby and browse their menu and the nutritional information for the menu items to help support the best choices for you. Everything you need to develop a more nutritious eating plan is in one easy application.

It doesn’t look like it’s a particularly new app (press release) but it’s just now graced the New and notable list.  Should likely receive a healthy bump in # of users.

It may seem strange for a pharmaceutical giant like Sanofi to be developing iOS applications (motivations?), but it does look like an interesting health outreach project on the company’s part. 

There’s even a twitter account for the application (gomeals).

Here’s hoping they make special note of the so-called death on a bun Ultimate Grilled Cheeseburger Melt (1500+ calories, ~100g fat and more sodium than you can shake a fist at).

I recently bought a small cloud server from Rackspace with the goal of amalgamating various services I had hosted previously at Webfaction.

The SVN –> GIT migration was simple and painless (thanks to Jon Maddox for the reference instructions).  Importantly, all the commit history from Subversion was maintained.

Create a new git user:

adduser git

As the git user

mkdir repos

cd repos

mkdir trunk_tmp

cd trunk_tmp

git-svn init http://x.y.z/svn/trunk –no-metadata

git config svn.authorsfile ~/repos/users.txt

git-svn fetch

 

The users.txt should contain a mapping of svn to git users in the following format:

svnusername = My Full Name <my email address>

After the git-svn fetch operation has completed (it will download all revisions from subversion and may take a while), do the following:

git clone trunk_tmp trunk

rm –rf trunk_tmp

~git/repos/trunk is the new home of your GIT repository.

To access it remotely (over ssh):

git clone ssh://git@<host>/~git/repos/trunk

Simple as that.  I’m the only one using the repository so tunnelling it over a single user account is satisfactory.  I’d recommend setting up ssh private/public keys to make authentication more seamless.

Resource

• http://git.or.cz/course/svn.html – Provides a reasonable mapping of SVN –> GIT commands.
• http://www.jonmaddox.com/2008/03/05/cleanly-migrate-your-subversion-repository-to-a-git-repository/ – More detailed instructions on the repository migration.

The boys at JBoss had recently released Hibernate Search 3.2.0 and it looked pretty sweet. The possibility of performance improvements around indexing was enough to make me upgrade.

Unfortunately, like most software frameworks, Hibernate Search introduced/forced some new dependencies on us. We had previously been using Seam 2.2.0 and Hibernate 3.3.0 (both JPA1), neither of which were compatible with Hibernate Search 3.2.0.

We’re using Maven, so I’ll quickly outline the dependency changes I had to make (all dependences are available via the JBoss Nexus Repository):

<dependency>
    <groupId>javax.persistence</groupId>
    <artifactId>persistence-api</artifactId>
    <!– bit of a hack to make sure we aren’t transitively pulling in the persistence api (should be referencing hibernate-jpa-2.0-api now) –->
    <version>explicitly-fail</version>
</dependency>

javax.persistence:persistence-api is the JPA1 API and is no longer relevant and should never be included as a dependency. The explicitly-fail version will trigger a build failure if it ever manages to sneak in.

<dependency>
<groupId>org.hibernate.javax.persistence</groupId>
<artifactId>hibernate-jpa-2.0-api</artifactId>
<version>1.0.0.Final</version>
</dependency>

org.hibernate.javax.persistence:hibernate-jpa-2.0-api is the new JPA2 API published by Hibernate. 

All previous hibernate dependencies had to be upgraded to 3.5.2.Final, and Hibernate Search bumped up to 3.2.0.Final.

If you’re using Seam, you’ll also need to upgrade it to 2.2.1.CR1.  Note that this is not yet a final release but is necessary in order to support JPA2.

Unfortunately, Seam 2.2.1.CR1 lacks a complete Hibernate Search integration.  I could no longer able properly inject a FullTextEntityManager (via @In).

Instead I was forced to obtain a FullTextSession programmatically:

private FullTextSession getFullTextSession()
{
    Session session = (Session) entityManager.getDelegate();
    return Search.getFullTextSession  (session.getSessionFactory().getCurrentSession());
}

Seam also enhanced it’s EntityManager so that it now returns a JDK proxy when getDelegate() is called. 

That would be fine and dandy, but unfortunately the proxy does not implement org.hibernate.classic.Session, as required by the FullTextSession in Hibernate Search. 

Session.getSessionFactory().getCurrentSession() will return an org.hibernate.classic.Session and does allow you to move forward. 

A bit annoying and hopefully something that will get corrected in the near future.  I’m hoping that either Hibernate Search will be upgraded to not require a classic session, or Seam will provide an EntityManager delegate implementing the classic session interface. Better yet, Seam should just provide a fully supported integration with Hibernate Search 3.2.0.

Honestly, that was about it as far as the upgrade went.  We were able to index using either the new MassIndexer API or the old suggested best practice from Hibernate Search 3.1. 

It’s interesting to note that on my test system, the MassIndexer API was slower than the previous indexing code. The documentation does cover many different tuning possibilities so it’s entirely possible the situation could be improved.

Also, the MassIndexer API runs in a series of transactions and unless your timeout is set sufficiently high (ie. higher than the default JBoss 5 minutes), you will see transaction timeouts.

I didn’t attempt to work around this and opt’d to stick with existing indexing code that already runs in a separate Seam @Asynchronous method (thus avoiding timeouts).

Somewhat less than ideal, but if you’re keen on running Hibernate Search 3.2.0 w/ Seam in JBoss 4.2.3, it is possible and not too much work.

That same weekend, I also picked up a Netbook for the girlfriend. It was a much easier buying experience, they’re everywhere. We ended up picking up an Acer from Costco for $499.

First things first, the iPad is not a laptop replacement IMO. It’s certainly sexy and crowd pleasing, but if you’re looking for a communication device in the sense of sending emails, video conferencing, etc., you’re better off with a Netbook (MacBook Air included). The virtual keyboard is passable, but not terribly suited to significant correspondence. Plan on grabbing the Apple bluetooth keyboard if you’re looking to publish content via the iPad. Lastly, if you’re the attention seeking type sporting a permanently popped collar, the iPad is a surefire crowd attractor.   

On the flip-side, if you’re looking for a new content consumption device (twitter, google reader, books, etc.) it really is your ticket to ride. I’ve been running a little test over the past couple weeks where I’ve restricted Twitter and RSS usage to the iPad. It’s completely anecdotal, but it seems much easier to keep up to date on the iPad versus say using Tweetie or Google Reader on the MBP.

The Flash argument is a non-starter for me, 99% of the sites I access on a regular basis are fine. Once FailBlog converts over to HTML5, I’ll be set.

Furthermore, just being able to sit on the couch or lay in bed and not end up with a 3rd degree burn, makes the iPad worth the price of admission.

As I type this, the girlfriend is happily skyping with friends and tagging faces in Picasa. Being able to do both at the same time is an obviously technological and patentable marvel!

GenoLogics is a leading provider of lab informatics solutions for translational research, with solutions crossing the clinical and discovery domains. GenoLogics focuses on providing best-in-class informatics solutions for genomics/next generation sequencing, proteomics, and biorepositories.

Traditionally we’re a strong Java / Groovy shop, so if the thought of living and working in lovely Victoria, British Columbia appeals to you. Let’s get in touch.

Relocation costs would likely be discussed if you’re an out of towner (Seattle, Calgary, etc.)

You can reach me at: adam.jordens –at- genologics –dot- com

More information on the jobs themselves can be found here

Old Laptop (2.333ghz, 5400rpm HD, 3GB DDR2)

mvn clean install - 8-10 minutes depending on system load

mvn clean install -DskipTests - 4-5 minutes depending on system load

JBoss startup - 70-90 seconds depending on system load

IntelliJ Responsiveness – Slow

New Laptop (2.8ghz, 128GB SSD, 4GB DDR3)

mvn clean install - 3 – 4 minutes

mvn clean install -DskipTests - 70 seconds

JBoss startup - 32 seconds

IntelliJ Responsiveness – Blazing Fast

Night and day difference. I haven’t counted yet, but on average, I would anticipate doing probably between 8 and 12 build + deploys a day. A realistic estimate would put my daily build time savings around 30 minutes. And that’s discounting the morale and efficiency boost coming from not having to context switch every time the machine bogs down because something is running in the background.

I’m a developer and speed geek. I’m that guy who grew up with the 300A Celeron overclocked to 450mhz. I’m greatly annoyed with inefficiencies and constantly find myself tweaking aliases, just to get that 5 step build process down to one.

Fuzzy Math

Assuming a pie in the sky daily wage of $300 (to make the numbers easier), a 30 minute savings per day equates to $18.75. Multiply that by 250 days worked in a typical year (2000 hrs) and you’re looking at a theoretical productivity gain of over $4500.

I would argue that regardless of how efficient you think your programmers are today, you will always see positive benefits from ensuring they always have access to decent hardware and build environments.

Now take this new laptop. It cost under $3000 (apple premium). If laptops aren’t your thing, a desktop can be had probably half.

If you cannot justify spending $3000 per developer every 1.5years, at least consider upgrading core components. I don’t have numbers, but I’m guessing that a significant portion of the improvements I’m seeing were a result of the SSD.

Either way, if you value the time of your programmers, I don’t see how you can lose.

Time is money, and efficient programmers == happy programmers.

There’s nothing I like better than to come home from a day in the office and marvel at the amount of work accomplished (easily measured as tasks completed, bugs squashed, etc.). See that burn down chart trending downwards can bring a tear to a man’s eye!

Working hard is not what burns me out, it’s the soul sucking meetings and status updates along the way.

As a working example, I’m going to outline the high level processes, tools and techniques that my team and I regularly follow during our quest to develop good software and get it into the hands of our customers.

First, I’ll quickly outline the various tools that are used to make our collective lives much easier.

Tools

We are huge believers in the entire Atlassian stack. We started out with JIRA five or six years ago, and our tool box has expanded to include Confluence, Fisheye, Crucible, Bamboo and most recently GreenHopper.

If you’re a development shop (of any size really) looking for a kick ass suite of tools, look no further than what Atlassian has to offer.

For the purpose of this post, I’m going to focus on JIRA/GreenHopper, Crucible and Bamboo.

JIRA is a typical bug tracking software, GreenHopper is a set of agile extensions that allow you to easily manage and prioritize User Stories, Tasks, Bugs, etc., visualize burn downs, and manage sprints/releases on a per-project basis.

Every single piece of work we work on is estimated and tracked in GreenHopper. Burn downs are generated automatically and actively monitored. Prior to GreenHopper, we were manually tracking cards on a whiteboard and generating burn downs through Excel. Very cumbersome. I don’t even want to remind anyone of what happens when someone knocks all the cards off your whiteboard.

Crucible is essentially online code reviews done right. Simply point it a repository (subversion in our case) and you can completely manage the peer review process through a web browser. Prior to moving to the online review process, we were doing over the shoulder reviews prior to check-in. This required someone to drop whatever it was they were doing, and head over to your desk for 15-20 minutes. With Crucible, code is committed first and reviews setup immediately after. You can easily track what code has been reviewed and what hasn’t.

Bamboo is the last piece of our puzzle and manages all of our continuous integration builds. We have a series of builds that are either run per check-in or nightly. Performance reports are generated and published to a Maven site nightly.

Process

For the past two years we’ve been developing software in effectively two week chunks with a release every month.

Each two week iteration starts on a Wednesday and consists of the following:

• A 1hr kick-off and retrospective meeting
• Daily 10 minute scrums with members of Development and QA.
• A 1hr sync. session with Product Management every Thursday to quickly review progress and have any outstanding questions answered.
• An all hands on deck 2hr test session every second Thursday. This includes members of Development, QA and Product Management.
• A 15 minute show & tell every second Tuesday (last day of the iteration) with members of Development, QA, Product Management and Technical Writing.

Ignoring the scrums, that amounts to < 5hrs of meetings an iteration. Sounds simple right?

All of our kick-off meetings involve a review of our backlog and upcoming iteration. The backlog is a JIRA version that theoretically contains all the user stories, tasks, bugs, and anything that we could possibly work on. It’s prioritization is a collective effort by both Development and Product Management. Items in the backlog may or may not be estimated, and each 2 week iteration includes roughly 1-1.5 weeks of estimated work per developer. This 1-1.5 dev weeks / iteration / developer is essentially our velocity and can be adjusted to account for risk and granularity of tasks being worked on.

Once tasks are pulled into an iteration, they must be (re)estimated (typical granularity is 1-3 days). Design is a considered a critical task and it’s not uncommon to see dedicated design and review tasks in our iterations.

At the end of each iteration we run a retrospective. This gives us an opportunity to review velocity from the previous two weeks, as well as identify things that we did well as a team and things we would like to improve upon. We identify 2-3 items from the list to focus on for the next iteration.

Every morning we kick off the day with a quick 10 minute scrum. This scrum provides each member of the team with an opportunity to highlight what they’ve worked on in the last day and identify any blockers to the group. Depending on whether or not everyone is in the office, we may choose to run this in-person or via Jabber/XMPP.

Once a week we take an opportunity to sit down with Product Management and review our backlog. We’ll take a stab at estimating the highest priority items and may even move them into a coming iteration / release. We typically only plan an iteration or two into the future.

Finally, to end of an iteration we have an all hands on deck test day on the last Thursday. This involves all members of development, our QA representative, and at least one person from Product Management. We prepare our test cases ahead of time and take over a board room for 2 hours. It’s important to get everyone in the same room in order to make efficient use of time. Questions must be answered quickly, and it’s important to have representation from both Development and Products.

Throughout an iteration we will do frequent deployments for other people in the organization to play with. With only one technical writer for the whole company, it’s been a difficult haul to keep user facing documentation up to date with each release. In addition to documenting the expected and actual behaviours as part of User Stories, we’ve started doing quick 20 minute show & tells on the last day of an iteration. This gives the technical writer and product management one last opportunity to review features before the iteration is closed and the release goes out the door.

Assuming everything goes to plan, we close everything down on a Tuesday and prepare ourselves to start fresh on the Wednesday. It’s important to note that we purposely start and end our iterations mid-week. We found the stress level to be significantly higher when we attempted to rush for a Friday completion date.

That’s it in a nutshell. We’ve been following this basic process for the last year or so with a decent amount of success. Of course nothing is perfect and we’ve made minor modifications as necessary.

I’d be interested to hear what others are doing for a lightweight agile process and what forms of tooling they’ve incorporated.

Cheers!

Often times we’re forced to make sacrifices, but when is it the right time to push back or accept defeat?

Obviously what follows here are my own opinions but I’m a firm believer that a well executed plan only 80% complete, is worth leaps and bounds more than a flawed plan 100% complete.

A few questions I commonly ask myself:

• Is what I’m working on tied to a software release.  We release on a month basis in two 2 week iterations.  I know that if I want to make it into a release, I need to have it done sufficiently ahead of time in order to ensure adequate testing.  This may mean cutting scope.  Cutting scope is fine IMO, just do so in a way that you avoid silly shortcuts that create headaches for yourself when you inevitably have to come back and add functionality.
• Who is the consumer. Is it a paying customer (ie. they have already paid)? Is it for a demo? Is it for another developer? If its a customer, what are they actually trying to accomplish? Often times, we get caught up in our own expectations of how something should look or behave, and lose sight of what the customer is actually trying to do.  If the customer is currently using pen & paper to track something, a simple (ugly?) web form may be perfectly acceptable. Don’t overcomplify. With good feedback, you can always come back and do a better job. Focus on the present, don’t get distracted on what you *might* need to do in the future.
• How often is the functionality used. If the feature or function being worked on is used by a handful of backend administrators, you may not need to go over the top on day one.  If they come back and tell you that they absolutely cannot use the system without A, B or C.  Make sure you understand what A, B and C are and get cracking.  Quick turnaround built loyalty and trust.  You need both as early in the customer relationship as possible.  If the feature is public facing and used by a large percentage of the audience, by all means, perfect it.
• Do I need to modify the database. From a technical perspective, this has always been a killer.  Make a flub manipulating the database, and you’ll cause yourself countless hours of time trying to correct customer datasets. Get representational datasets, migrate them automatically and test test test!  Speaking from experience, do not cut corners testing or working with your database migrations.
• Have I been burnt in this area before. Maybe the work you’re doing is in direct response to a filed bug.  Either way, if you’re working a particularly risky area of the codebase, it’s worth going that extra step to ensure you’ve got solid code coverage (unit, regression, selenium tests, etc.).  Fool me once… Fool me twice…

There are plenty more, but in general, I err on the side of trying to get releases out the door.  If we spend 20 calendar days in a release (4 work weeks), up to 6 of those will be spent either performing non-automated regression tests (don’t worry, we have automated tests as well) or fixing post code-complete deficiencies. 

Test cases are a given.  If you’re working Java or any other programming language with tooling like JUnit or TestNG, I really see no excuse not to use it.  If nothing else, it’s a good safety net if you ever need to refactor a particular area of the code base. 

If I had to pick a guiding principle, it would be:  Get it in, Make it right, Make it fast. 

Get it in because you need the feedback.

Make it right because that’s what we’re paid to do and stakeholders expect it.

Make it fast because it’s no fun staying up until 2:00am trying to debug performance problems on a customers live system.

The trivial case worked.

@XmlRootElement
public class ExtMessage
{
    private String owner;

    @XmlElement
    private ExtConcreteBody body;

}

What I set about doing next caused some immediate grief.  My intention for ‘body’ is to actually be one of many JSON entities. First attempt was to introduce a JSONBody interface and use that instead of ExtConcreteBody.

@XmlRootElement
public class ExtMessage
{
    private String owner;

    @XmlElement
    private JSONBody body;

}

Of course that didn’t work.  At marshalling time, the JAXB provider complained about not supporting interfaces.

A quick search on Google said I wasn’t the only person who had run into this problem before. 

Best resource I found was the JAXB User Guide.  Seems to have some funny rendering and be slightly out of date, but it led me down the correct path.

Essentially you need to make use of an XmlJavaTypeAdapter.  JAXB ships a default one (AnyTypeAdapter) that will generate a ‘type="xs:anyType"’ in your xml schema.  If you want specific type support, you can implement your own Adapter. 

After adding the class-level @XmlJavaTypeAdapter(AnyTypeAdapter.class) to JSONBody, I thought I had it licked.

Then the JAXB provider complained that “Marshalling Error: class [...] nor any of its super class is known to this context”.

WTF?

Fortunately that led me to a comment on a random blog post on Collections and JAX-RS mentioning that you should use an @XmlSeeAlso(…) if you want to avoid that error.

Finally it works.

@XmlRootElement

@XmlSeeAlso(ExtConcreteBody.class)
public class ExtMessage
{
    private String owner;

    @XmlElement
    private JSONBody body;

}

@XmlJavaTypeAdapter(AnyTypeAdapter.class)
public interface JSONBody
{
}

@XmlRootElement
public class ExtConreteBody implements JSONBody
{
    private int id;

}

The JSON looked like:

{"extMessage":{"body":{"@type":"extConcreateBody","id":"0"},"owner":"dummy.user"}}

Which seemed reasonable to me.

Hopefully this helps anyone else out there that is having grief trying to do the same thing!

I won’t claim to work for a big company, it’s still very much the opposite.  But over the past 5 or 6 years, I have seen a transition in how customers are marketed to and interacted with from sale to solution implementation and beyond.  We’ve gone from a group of 2 to a company of more than 70 complete with departments, budgets, vice presidents, BoDs, etc. 

I’m not a marketer so I’m not going to comment on our web presence or our quarterly e-mail campaigns.  They seem to be working as that mythical funnel remains full.  Needless to say, our sales process was very rudimentary back in the day, there certainly was no funnel.  We develop enterprise solutions and have always made the $100k+ deals.

All things aside, when you start considering customers as a number or percentage point in some quarterly metric you’re trying to hit, you’ve lost an edge.  The startup isn’t even going to have the metric in the first place, they’re going to be concentrating on getting the customer’s attention, getting them product, iterating on said product, and maintaining the relationship.  The product may suck (our first few releases definitely did) but that’s addressable over time.  The relationship is far more important and can be lost very quickly. 

The other thing that changes as a company gets larger is focus.  No longer do you have that laser guided focus on getting product to a single customer, you’re now dealing with existing and new customers simultaneously.  Your decision making ability slows as you’re forced to consider the implications of change to all customers.  It’s one of those annoying but necessary evils that comes with maturity and customer successes.  . 

I shouldn’t say it’s impossible to maintain the focus, it just becomes more difficult.  Your ability to focus on a particular customer is, in my mind, a key indicator of your ability to be successful.  It’s one of the reasons we track a customer satisfaction metric.  I won’t get into how it’s calculated, but essentially its a gauge of how often we’re communicating with a customer and whether or not the relationship is positive and if they’re happy with their particular solution.  Green is good, Red/Yellow is bad.

The other key indicator in my mind is not making the same mistake twice, but that’s a topic for another post.  It’s an item of significant competitive advantage that the slightly larger company has over the startup.