Setting the Stage: BeersDB

It’s the start of Iteration 2 on our fictional BeersDB project, a simple Grails app for tracking and rating different beers. In Iteration 1 we came up with a simple domain class to model the relevant information about a Beer and some real-world data for testing the app:

class Beer {
  enum Style {
    GERMAN_ALE, GERMAN_LAGER, BRITISH_ALE,
    BRITISH_LAGER, AMERICAN_ALE, AMERICAN_LAGER,
    OTHER
  }
  String name
  Style style
}

After some testing, the client prioritized a few stories in Lean-to to make the app more useful:

All of these stories require evolving the Beer class and the underlying database schema. Since we have existing data, we’ll be using the database migration plugin to capture and manage migrations in a structured manner. At the end, we’ll package everything up for a production release.

NOTE: all of the code for this blog post is available out at GitHub in the Refactr open-source repo. I’ll only be highlighting the major changes but I’ve tagged the full code for each step if you want to explore further. The code for this initial step is tagged as initial:

$> git checkout -f initial

With all of that out of the way, let’s start tackling stories!

Story 1: Add Origin and Type

For the first story, the client wants to be able to search for beers by country of origin, e.g. Germany, and by type, e.g. Ale or Lager. This information is encapsulated in the existing Style property but not in a form that is convenient for searching. The plan of attack is to add two new properties Origin and Type and write a migration to populate them for the existing beers in the database.

The new Beer class looks much as you would expect:

class Beer {
  enum Style {
    GERMAN_ALE, GERMAN_LAGER, BRITISH_ALE,
    BRITISH_LAGER, AMERICAN_ALE, AMERICAN_LAGER,
    OTHER
  }
  enum Type { ALE, LAGER }
  enum Origin { GERMANY, BRITAIN, USA, OTHER }
  String name
  Style style
  Type type
  Origin origin
}

We’ve left the existing Style property around for the time being; it’ll get cleaned up in a later story.

For the migration, we’ll let the plugin’s grails dbm-gorm-diff script take a first pass at writing the migration. It takes care of adding the new columns for us:

databaseChangeLog = {

  changeSet(author: "josh (generated)", id: "1-1") {
    addColumn(tableName: "beer") {
      column(name: "origin", type: "varchar(255)",
        defaultValue: Beer.Origin.OTHER) {
        constraints(nullable: "false")
      }
    }
  } 

  changeSet(author: "josh (generated)", id: "1-2") {
    addColumn(tableName: "beer") {
      column(name: "type", type: "varchar(255)",
        defaultValue: Beer.Type.ALE) {
        constraints(nullable: "false")
      }
    }
  }
}

This is a good start, it adds the new columns and sets a default value so the columns can be created as not nullable. The final step is to hand-write a migration to set actual values for origin and type based on the style column of existing data:

changeSet(author: "josh (generated)", id: "1-3") {
  grailsChange {
    change {
      Beer.list().each { beer ->
        switch(beer.style) {
        case Beer.Style.GERMAN_ALE:
          beer.origin = Beer.Origin.GERMANY
          beer.type = Beer.Type.ALE
          break
        case Beer.Style.GERMAN_LAGER:
          beer.origin = Beer.Origin.GERMANY
          beer.type = Beer.Type.LAGER
          break
        case Beer.Style.BRITISH_ALE:
          beer.origin = Beer.Origin.BRITAIN
          beer.type = Beer.Type.ALE
          break
        case Beer.Style.BRITISH_LAGER:
          beer.origin = Beer.Origin.BRITAIN
          beer.type = Beer.Type.LAGER
          break
        case Beer.Style.AMERICAN_ALE:
          beer.origin = Beer.Origin.USA
          beer.type = Beer.Type.ALE
          break
        case Beer.Style.AMERICAN_LAGER:
          beer.origin = Beer.Origin.USA
          beer.type = Beer.Type.LAGER
          break
        case Beer.Style.OTHER:
          beer.origin = Beer.Origin.OTHER
          beer.type = Beer.Type.ALE
          break
        }
        beer.save(failOnError: true, flush: true)
      }
    }
  }
}

We use the migration plugin’s ability to run Groovy and Grails code to loop through each Beer domain class and set the properties accordingly. Running the migration results in what we’d expect in the database—the origin and type columns match what is in the style column:

If you’re following along at home, you can see the full set of changes and migrations with:

$> git checkout -f story1

Story 2: Clean up Style

With the new origin and type properties, the client has indicated that the style property is no longer needed. Let’s remove it up from the domain class and generate a new migration with grails dbm-gorm-diff:

databaseChangeLog = {

  changeSet(author: "josh (generated)", id: "2-1") {
    dropColumn(columnName: "STYLE", tableName: "BEER")
  }
}

The migration doesn’t require any manual modification. Running it against our database results in the style column going away:

Same deal as before, the code for this step is available with:

$> git checkout -f story2

Story 3: Add Rating

Our final change will be to add a rating property so the beers can be rated on a 0-5 scale:

class Beer {
  enum Type { ALE, LAGER }
  enum Origin { GERMANY, BRITAIN, USA, OTHER }
  String name
  Type type
  Origin origin
  int rating

  static constraints = {
    rating min: 0, max: 5
  }
}

Again the grails dbm-gorm-diff script writes the migration for us:

databaseChangeLog = {

  changeSet(author: "josh (generated)", id: "3-1") {
    addColumn(tableName: "beer") {
      column(name: "rating", type: "integer",
        defaultValue: 0) {
        constraints(nullable: "false")
      }
    }
  }
}

The database looks as we would expect with a new rating column initialized to 0 for the existing beers:

Ship It!

With that, we’re ready to push out a new release. It’s always a good practice to do a dry run of your migrations against a copy of your production database to catch any issues before the actual release. We can simulate this by checking out our original database and then running the database migration update script against it:

$> git checkout -f story3
$> git checkout initial devDb.h2.db
$> grails dbm-update

ERROR liquibase - Change Set change1.groovy::1-3 failed.
...
Caused by JdbcSQLException:
  Column "THIS_.RATING" not found;

FFFFFFFUUUUUUUUUUUUUUUU-

We ran each of the migrations without a problem so why is it blowing up now? Turns out you have to be very careful if you try to load domain classes in your migrations. The error above is in our hand-written migration to populate the values of the origin and type properties. Hibernate is expecting there to be a rating column in the database even though that column wasn’t added until a later migration. The migration has no way to know what our domain class looked like at the time the migration was written, only the current state of our code. Since the current version of Beer has a rating property, Hibernate expects it to exist in the database as well.

The solution here is to rewrite our migration in Story 1 to use SQL directly instead of relying on GORM to load domain class instances. We also have to be careful not to reference properties such as the Style enum which may change or disappear over the lifecycle of the project:

changeSet(author: "josh (generated)", id: "1-3") {
  grailsChange {
    change {
      // set origins
      sql.executeUpdate
	"UPDATE BEER SET ORIGIN = 'GERMANY'
        WHERE STYLE LIKE 'GERMAN_%'"
      sql.executeUpdate
	"UPDATE BEER SET ORIGIN = 'BRITAIN'
        WHERE STYLE LIKE 'BRITISH_%'"
      sql.executeUpdate
	"UPDATE BEER SET ORIGIN = 'USA'
        WHERE STYLE LIKE 'AMERICAN_%'"

      // set types
      sql.executeUpdate
	"UPDATE BEER SET TYPE = 'ALE'
        WHERE STYLE LIKE '%_ALE'"
      sql.executeUpdate
	"UPDATE BEER SET TYPE = 'LAGER'
        WHERE STYLE LIKE '%_LAGER'"
    }
  }
}

Conclusion

The Database Migrations plugin is a powerful tool for managing database changes in a Grails project. It requires some structure to integrate into a project but the benefits of tracking database changes alongside your code far outweigh the extra effort. Sparing and careful use of GORM methods inside your changesets will minimize potential issues down the road.

Too often in past years have we been approached with a cool project opportunity, only to have to turn it down because we were all too busy. We hate for that to happen and are planning to hire and build more teams of smart software designers and developers this year. We are confident that the culture we have built can withstand growth, especially considering how carefully we recruit and hire.

We understand with growth and added capacity comes the responsibility to make sure we stay busy. We can’t rely on the good fortune we have had to date – work just coming our way. So it is with pride and pleasure that Refactr welcomes Matt Bjornson to our team as President. Matt comes to us from Object Partners (OPI) where he was a key person that helped OPI grow to what it is today. Matt was an early advocate of the Grails and Rails frameworks, aided in the sales and marketing efforts, and generally kicked some ass. We are excited to have his help in this new chapter of Refactr’s history as we grow into our reputation as a leading software agency in Minneapolis. We’re looking to grow while maintaining our core values of cross-functional, small, self-managed teams helping our clients innovate faster than they thought possible. Want to join us?

We work on relevant and interesting projects as teams.

Our ideal project is 2-4 cross-functional application developers on an interesting project for 3-5 months at a time. Our developers (a term that includes designers and front-end developers as well as the more traditional definition) self-manage their work and most client interactions throughout the course of a project – from definition, through weekly reviews, to completion. We don’t do staff augmentation. We help companies get things done quickly, at a high quality level, as a team.

Our low overhead, smaller size, and impressive stature in the tech community affords us the opportunity to learn about many projects and accept the most interesting ones that are a great fit for how we want to work. We’re not right for every project and we’re not afraid to say so. Refactr is not interested in taking J2EE or .NET project work. We may, on occasion make a case for a more nimble technology in those cases but we’re not zealots, either. Some projects and some companies are just better served using technologies that we don’t.

For the record, rapidly developing Groovy/Grails, Ruby/Rails, and Mobile (Web/iPhone/Android) applications is what we excel at and what we are interested in taking on.

We are collecting the smartest people we know.

If you get invited to interview with us, you should feel pretty good about our impression of you. We only want to work with the smartest people we find. Regardless of your experience, we are interested in working on projects with curious, passionate, thoughtful, and communicative people. It goes back to that fulfilling work thing – if we are going to hang out and be pals we want to be sure you’re interesting and that you’ll stay interested in your coworkers.

We look for varied backgrounds, experiences, and interests. We’ve got a pair of rocket scientists, a few robotics experts, several artists and musicians, a couple home brewers, and we’ve – collectively – been to every continent. Everyone here is passionate about something and curious and interested in learning about too many things to count.

We have an open and collaborative culture.

What’s more, we get all these smart, curious, passionate people and we put them all in one big room! There is constant collaboration and sharing, not to mention storytelling and joking, that occurs because we are all working together – despite being on different projects. Ideas are sought from, and implemented by, everyone. There are no formalities or barriers to communication – there are no offices and really no hierarchy. We’re all in this together to build cool things and have fun doing it.

We stay relevant by researching new technologies and techniques.

We invest in learning daily. Our developers are encouraged to buy books, spend time on technical sites and blogs, and attend events and conferences. While we don’t just use the latest shiny technology for the sake of it, we have heard about them and if it’s practical and worthwhile for our clients we’ll encourage its adoption.

Getting things done is at the heart of our process

You won’t find a lot of bureaucracy at Refactr. In fact, you won’t find many things that get in the way of getting things done. Our process helps to eliminate those things that tend to bog down and distract from that goal. We call it “little a” agile and it means that we’re pragmatic about the way we go about running projects and really the company as a whole. As things are discovered that work better, we implement them, or as things start to not be as efficient, we eliminate them. We hold a stand-up meeting every morning, we’ll pair program when it makes sense, we write user stories and have one or two week iterations, and we communicate closely with our clients and their stakeholders.

All work and no play makes us something, something…

We don’t just code all day, we also have fun together. Whether its DJ-ing in a Turntable.FM room or in the real world via our Sonos system, taking the Nice Ride bikes across the river for lunch at a food truck, creating something new together at our monthly hack day, eating corn dogs at the state fair, creating popular 3DS experiments, renting a house in Mexico for a month, heading out to a brewery tour or haunted forest, hitting up a happy hour, catching a movie or concert or any number of things we do – the point is, we do things together. And yes, we said renting a house in Mexico. Maybe the next one won’t be in Mexico but we have another trip in the works.

We are a part of, and supporters of, the technology community.

We believe local and distributed communities are only as strong as their members make them. We’re trying to do our part to ensure the communities that are important to us are successful. We provide space for many local user groups to meet each month. Ruby Users of Minnesota, Groovy Users of Minnesota, Minnesota JavaScript User Group, Minnesota Clojure User Group, Lean Startup Circle, and Mobile Twin Cities all currently meet each month in our office.

We organize, sponsor, or otherwise support a wide range of groups, events and conferences. MinneBar and MinneDemo were co-founded by a Refactr founder and we’re all heavily involved with these leading tech events in the area. We have sponsored Ignite Minneapolis, Gr8 in the US, and No Fluff Just Stuff and have spoken at these and other local and national conferences.

We’re at the epicenter of innovation in the Twin Cities.

Not only do we support technology and community in a broad sense – we are really at the heart of technology innovation in the Twin Cities. We are asked our opinions about innovation by media types. We even built our own product to help us and others manage innovation. We are involved with many early stage companies (even some of our own creation) and we can offer unique and exciting opportunities to our consultants. We have a model in place that will allow us to create, grow, fund, or otherwise be involved with 2-3 such opportunities each year. These opportunities will be there when members of our team are interested in doing something new or just looking for a change of pace.

We take care of our team.

Though we don’t often sit around a campfire and sing Kumbaya, we do all care about each other. We know each other personally and we’re interested in each other’s lives and families. Knowing that to be true makes a huge difference in how we feel about coming to work each day.

But it isn’t all touchy-feely stuff. We offer great benefits for a small company, we offer great benefits for a company of any size, actually. There’s the free medical benefit that allows you to choose how you spend the funds amongst a number programs, the 401(k) that is matched at 4% of gross pay, a phone stipend, top-of-the-line MacBook Pros, and the time off that you take as you need it. We encourage travel and vacations and don’t want an arbitrary number of days per year to deter people from life experiences. Did we mention the kegerator?

We share success.

Refactr is only as good as our team and the work we do. It makes sense to share success as it happens. These can be little things like celebrating releases or larger like sharing the profits of the company.

UPDATE: WE”RE HIRING.
In case it wasn’t apparent, we’re looking for great developers; good communicators; interesting, curious, passionate people to develop mobile (iOS, Android, and mobile web) and web-based software with us using primarily Grails and sometimes Rails. Contact us for more info team@refactr.com.

I tend to be too much of a perfectionist when it comes to home projects. This can be something as big as remodeling a room or as small as sweeping the deck. To avoid my perfectionism wasting time on the unnecessary, I like to apply the “simplest thing that could possibly work” principle. It really does help me to not spend more time than is necessary on things that don’t really need it.
- Jesse O’Neil-Oine (Developer)

My wife and I share one car and fill the gaps with public transit and bike rides.
- Hiromi Matsumoto (Designer)

To simplify my life, I sell, donate, or just throw away anything I haven’t used in the last year. I don’t own a lot of things, but what I do have, I use. I also don’t have to store closets full of stuff I don’t use.
- Spencer Hartberg (Developer)

I write code (either for work or for side projects depending on upcoming deadlines) while riding the bus to and from work.
- Steve Vlaminck (Developer)

Outside of work, one of my hobbies is brewing beer. While brewing requires a certain minimum time commitment, I’ve found some simple ways to make that time and effort go further. All my spent brewing grain gets turned into loaves of bread, dog treats, or compost for the garden, and any leftover beer gets turned into malt vinegar to give as gifts around the holidays. This saves several trips to the store throughout the year.
- Josh Reed (Developer)

This summer I have been minimizing the use and expense of driving my car to the grocery by visiting local farmers markets on my bike and supporting local farmers.
- Dane Messall (Designer)

I used to carry a lot of keys “just in case” I needed them and I realized that I rarely use the key to my in-laws house. So now I typically carry just the keys I need on my key chain: one key for the car, one for the house. And I have a separate key chain for each car, rather than two keychains that each have keys for both cars. At the office, we have a finger scanner lock, so that I don’t have to carry a key to our suite door. Likewise, I downsized my wallet. I got a card carrier and now carry only my essential credit cards and I keep cash in a money clip, rather than a “Castanza wallet“.
- Scott Vlaminck (Developer)

I buy clothes in similar shades and tones so I can mix and match clothes without too much care. This works especially well when packing for a trip.
- Ben Edwards (Designer)

Are you applying agile principles to your life outside of work? Tell us how!

Due to timing of concept agreement with the Ignite staff, we only had a few days to create the community in order to give it time to have an impact on the event. Needless to say, we made it happen, and by the night of the event, the community received about a dozen ideas and had over 75 votes and many comments. Even after the event, the site still generates the occasional idea and votes continue to be cast on the ideas from the Ignite participants.

This got us thinking: If we could put together an idea community in a matter of days using MileMarker’s IdeaCapture and IdeaShare widgets, our customers can, too! What impressed me the most (yes, even as a co-founder of MileMarker) was that after finalizing a design (which only took a couple of days), we had the community up and running in less than 48 hours. We knew this was possible using the tools within MileMarker, but it really put us to the test, as we had an immovable deadline in front of us.

Of course, the moral of the story is less about the time it took and more about the ease of it. We talk with many customers who have great ideas about how to engage their audiences in generating ideas and helping to innovate on their products and services. Often, there seems to be either a technical roadblock or a financial one. Our goal, and what we’ve seen so far, is that it shouldn’t be difficult to stand up a basic community, and MileMarker facilitates this with such ease.

If you haven’t seen the Igniting Ideas community, make sure to check it out. We hope that you’re as excited by this kind of opportunity as we are.

Build Customer Loyalty:

Many companies recognize their most loyal customers to be the most satisfied. But what about the customers who are dissatisfied? Is it possible to build loyalty among even the most dissatisfied of customers?

According to a study carried out by customer experience research company Technical Assistance Research Programs Inc., customers that complain or have constructive feedback, and then see the problem solved, are up to 8% more loyal than those who didn’t even have a problem in the first place. (Increasing Customer Satisfaction, U.S Consumer Information Center, Pueblo, CO, 1986) But, what does this mean? Fixing customer satisfaction requires that we first listen to the problem.

It’s that simple: show your customers you care about them enough to hear what they have to say. There may not be a solution to building 100% customer loyalty, but listening to your customers is an excellent starting place.

Lower Research Costs:

Take another look at customer feedback. Instead of only viewing it as “listening,” think of it as free market research for your next business roadmap.

A leader in product innovation management, Accept Corporation found that around 25% of all customer ideas and feedback turn into new products. Findings from this study also showed a lost opportunity when it came to companies failing to develop products based on features that customers want and will pay for. Remember, great ideas can come from your customers.

Many companies are growing because they are listening to their customers. Take e-commerce company Volusion – their customers gave free ideas for new products and product features. This led to more than 90% of new product ideas coming from customers, which increased company revenues. Use your customer’s ideas as input for your next product roadmap. Your clients will tell you what they want, you just have to be willing to listen.

Free Marketing:

When you receive good customer service, you are more likely to recommend the company to your friends. Well, the result is the same when companies listen to and act on customers’ thoughts: a.k.a. word of mouth marketing.

You can – and should – use feedback as part of your marketing campaign. Here’s a tip: Every time you are recommended by a customer or get good feedback, you should ask to use it as a testimonial. If you receive constructive or negative feedback, act on it. Show your customers that you are listening to them and want to be better. People talk positively about the companies they have good experiences with, and listening to your customers creates good experiences. It’s simple, listen to your customers to keep them happy, and in return they will promote your business.

Start Listening:

It isn’t expensive nor is it difficult to listen to your customers, however failing to do so can be costly. Whether you are using surveys, social media, or idea capturing and management apps like MileMarker, the key is simply make listening to your customers a priority.

What is OpenStreetMap?
Most online maps get their data from copyrighted sources. For example, Google Maps gets a lot of their U.S. data from NAVTEQ. This means that any third-party app built on top of Google Maps is considered a derived work. Any information taken from their map, such as a location’s latitude and longitude is still under their copyright. This puts restrictions on how a third-party app can work. For a developer looking to charge money or build a completely open-source application free from restrictions, this presents a problem. The solution is OpenStreetMap, a user-generated map released under a Creative Commons license.

Standard Map View

How does it work?
OpenStreetMap follows the Wikipedia model by letting users freely edit a user generated online map. Some existing map data is already in the public domain (like TIGER data) and has been imported into the map, but most map features are user created. After making an account, a user is free to add or delete anything from the map. Users import coordinates taken from handheld GPS units, or trace satellite photos to map out features. OpenStreetMap uses the powerful Potlatch flash program to make edits within a web browser.

In-browser edit mode

There are several projects that mimic Google Maps API functions to provide developers with the ability to embed maps and add interactive features. A popular one is OpenLayers, which implements an open source Javascript API. When combined, these two software projects allow developers to build totally open source geographic web applications on par with anything built with Google Maps API. Developers interested in building mapping applications should definitely check them out.

http://www.openstreetmap.org/
http://www.openlayers.org/

So we created FlashBang in 2009. The app is simple to use. When you see lightning, hit the word “Flash” and then hit “Bang” when you hear it crack. FlashBang then calculates how far away the lightning is from you. Since it’s initial release, we’ve had tens of thousands of downloads – apparently people love storms just as much as we do.

Two weeks ago, we released our first update, and let’s just say people were excited to use the updated app. Within the first 2 weeks, we had over 400 new downloads and over 3,000 updates.

Here were some of the cool changes we made for FlashBang 1.1:

• We created a new user interface with high resolution graphics to support retina display.
• There is also a better user experience for iPads. (That’s right, we designed new high resolution graphics that will fit the entire iPad screen)
• In FlashBang 1.0 we let you switch from Kilometers to Miles by editing your preferences in the information page. With FlashBang 1.1, we made that easier. On the main page you can now switch between the two with one tap of your finger. Touch the word ‘Miles’ and the distance will switch to ‘Kilometers’ and vice versa.

Download FlashBang for the next storm: FlashBang

Here’s the goal. It’s only April and we know that many people have already attended 15 industry events ranging from minne✱ to MIMA to SXSW. And let’s be honest with ourselves, by the time we’re done attending these events, a break from the speeches, networking, and long days is often needed. So we’re taking it to the community to find out “How would you make events in the Twin Cities even better?” What gets you excited about attending event after event after event, and how can these events keep you coming back for more?

By using MileMarker’s IdeaCapture and IdeaShare widgets, we’ve create an online community that allows people to submit, comment and vote on ideas. Our team is also using the Igniting Ideas site to launch the start of our new voting features, and we’re excited to see what people have to say.

Be part of the community. Check out Igniting Ideas to submit and vote on your favorites.

Being a fan of new technology (and video games), I of course couldn’t resist the urge to buy Nintendo’s new 3DS. After playing with the Augmented Reality cards that come with the 3DS, I couldn’t help but wonder how exactly the device recognizes it’s looking at an AR card. If you’re not familiar with Nintendo’s Augmented Reality cards and how they work, check this out.

Knowing that the cards themselves can be reprinted to any size, or even viewed from an iPhone, I thought I would try to test the boundaries further by creating a gray-scale card. I was skeptical that the 3DS would recognize it, but it worked flawlessly.

After some brainstorming in the Refactr office about what technique to try next, we decided to make a white board AR card. With some encouraging words from the guys who pay our salary (“No, that’s not a waste of time–that’s awesome!”) we got to work.

We projected the gray scale image onto the white board, traced the borders, and filled in the dark parts. Our first shading attempt was a little sloppy. The only way the 3DS would recognize it is if we projected white light onto the board to make the bright spots brighter.

At this point it was pretty obvious that contrast is a major factor for the 3DS to recognize the card. After a night of partial defeat we came back ready to try again. We erased the shaded parts and more tediously filled them in darker.

Knowing this attempt was our last hope, we took a deep breath and opened the 3DS.

And then we just had some fun.

**Update**

Followup Video: