Relevance Blog

Agile Reboot: Putting the Man back in Manifesto

2012-02-07T14:02:00Z

“Individuals and interactions over process and tools. Working software over comprehensive documentation. Customer collaboration over contract negotiation. Responding to change over following a plan.” That's the entirety of the Agile Manifesto, by the way. Seems simple, doesn't it? Yet there are flotillas of books and courses with detailed instructions and steps for "doing" Agile, as if it were a thing with specific rules and regulations. Hogwashery! Hear me now, the road to hell is paved with book covers and exam notes, it's time to rise up and put the 'man' (and woman) back in 'manifesto'. Spoiler alert: getting the 'fest' back in as well will be the topic of a future post...

Great teams do not "do" Agile, great teams "are" Agile. Being agile is not about burn-down charts, or attendant posture during some meetings, or not having other meetings, or some other "official rule" you must follow to pass a certification test. Being agile is a state of mind, a frame of reference from which to make decisions. If you are in the business of delivering software solutions and your strategy for success is adopting formulaic "Agile Processes", you are costing everyone a lot of extra money. Stop it. Stop it now, and let the healing begin.

Here's a quick test to see if you are a member of an agile team. Does the team trust each other and communicate frequently and honestly? Give yourself a point. You're moving faster towards clear, shared goals with less hesitation and fewer missteps. Individuals and interactions - sound familiar? The Speed of Trust can be measured, don't waste your client's money on avoidable drag.

Are team members (regardless of employer) passionately focused on overcoming hurdles blocking the path to shipping as a cohesive unit? Collaboration! That's the spirit! Is the team focused on building effective solutions that make people smile, or on how closely the product matches the original specification? Hint - you should be making people smile.

Teams are not formed to create documentation (not agile development teams anyway), they are formed to do magic, to enable people to do things not previously possible. Never forget that. Real agile teams do not start projects without first mapping a path, but they do not hesitate to adapt when market forces and other realities shift during flight. Respond to change, don't just follow a plan. Seeing a pattern here?

If your team is struggling to ship products on time, or continually ships products that fail to move the ball forward, or is constantly duplicating work due to miscommunication and misunderstandings, simply changing toolsets or making new rules is not going to save you. If every one of your team members cannot clearly state what success means for a project, why the project has been undertaken, and what risks and challenges stand between them and a solution, you're not going to cross the finish line (at least not when and where you want to). Forget the charts. Forget the rules. Talk, trust, learn, adapt. The tools are just that, tools. Use the ones that work for you. On this project. With this team. Success does not hinge on whether you use Jira, or Mingle, or Pivotal Tracker, Google Docs, or Excel, or sticky notes, or hand signals and a series of grunts.

Successful agile teams are characterized by quickness, lightness, and ease of movement. They are mentally quick and alert. They have a resourceful and adaptable character. They are well-coordinated in movement and have the ability to think and draw conclusions quickly. That's the entirety of the dictionary definition of “agile” by the way. Seems simple, doesn't it?

ThinkRelevance: The Podcast - Episode 005 - Michael Parenteau

2012-02-03T15:00:00Z

Ever since I began thinking about doing a Relevance podcast, I knew that I was going to want to have Michael Parenteau on the show. Michael is head of our design department, and a designer himself. He has a great attitude, and brings both that and his considerable talent to everything he does. I happened to be down in Durham the week that we released the new website, which Michael had a big hand in bringing about, so I knew the time was right to have a conversation with him about it.

In this episode, we talk with Michael Parenteau about being a designer at Relevance, Sanskrit, the importance of remembering the human part of software, and washing feet at Burning Man. Enjoy!

Download the episode here.

The show is finally available on iTunes! You can also subscribe to the podcast using our podcast feed.

You can send feedback about the show to podcast@thinkrelevance.com, or leave a comment here on the blog. Thanks for listening!

Show Notes

Our guest, Michael Parenteau
- @parenteau
- Michael on GitHub
We have a brand new website! You're probably looking at it right now.
- Note the hand-drawn illustrations on the team page
- And the How We Work section
- Plus the neat background image
- And don't forget about the interesting typography
- Check out what unmatchedstyle had to say about the website, too
- Please send us feedback about the website
People we mentioned during the podcast
- Jen Myers @antiheroine
- Kevin Altman @itg
Other things that came up on this show
- ClojureScript One
- Pair programming
- Git
- GitHub
- HAML
- Slim
- Jekyll
- Ruby
- Liquid
- Agile Principles
- Clojure
- Software Craftsmanship
- Sanskrit
- Devi Mandir
- Burning Man

Where to Find Relevancers this Month!

2012-01-27T08:50:00Z

Want to meet a Relevancer in person? Here's where you can find us in the next month:

Durham, NC Every Tuesday - 7pm @ Splat Space
Splat Space Open Meeting
Attending: Alan Dipert, Splat Space founder and Meetup organizer

Baltimore, MD 2/1 - 7:30pm @Revelytix
BaltimoreFP Presentation/Hack Night
Speaking: Alex Redington

Aruba 2/6-2/10
SpeakerConf
Speaking: Michael Nygard and Stuart Halloway

Durham, NC 2/6/2012, 7pm @ Splat Space
Monthly TriClojure Meeting
Speaking: Brenton Ashworth, ClojureScript One
Attending: Chris Redinger, TriClojure Founder and Meetup Organizer

Atlanta, GA 2/23-2/24
We're proud sponsors of Lessconf
Attending: A dozen Relevancers

ThinkRelevance: The Podcast - Episode 004 - Aaron Bedra's Valedictory

2012-01-25T19:30:00Z

When I heard that Aaron Bedra was leaving Relevance, I was surprised and a bit saddened. But I also thought, "Hey, we should have him on the podcast." And that's just what we did. I think it's great to work at a place where it's cool to record an interview with someone who has decided to move on.

In this episode, we talk to Aaron about what brought him to Relevance, some of the things he's worked on while he was here and even a bit about what the future holds for him.

Download the episode here.

You may have noticed a sweet new feature on the podcast: cover art! Our crack design team offered to produce "album covers" for our shows, and I realized that I'd be an idiot not to take them up on the offer. It's a fun detail, and one I hope you'll enjoy.

As a reminder, you can subscribe to the podcast using our podcast feed. I'm still working on getting the show added to iTunes, but that should happen pretty soon.

You can send feedback about the show to podcast@thinkrelevance.com, or leave a comment here on the blog. Thanks for listening!

Show Notes

Our guest, Aaron Bedra
Music
- Intro: Red Baron, performed by Billy Cobham off of "Spectrum"
- Outro: Aeroplane, by the Red Hot Chili Peppers, off of "One Hot Minute"
People
- Muness Alrubie: @muness
- Stu Halloway: @stuarthalloway
- Justin Gehtland: @jgethland
- David Liebke: @liebke
- Chris Redinger: @redinger
Links
- Groupon
- RailsConf
- Streamlined
- RubyConf
- ThoughtWorks
- MetaSploit
- Programming Clojure: First Edition, Second Edition
- Building Safe Applications, a PeepCode book by Aaron Bedra
- test.generative
- QuickCheck
- EasyCheck
- Heroku
- Casting SPELs in Lisp
- Land of Lisp
- Rails Recipes
- GitHub
- Strange Loop
- Clojure/conj
- Clojure/West

ThinkRelevance: The Podcast - Episode 003 - Brenton Ashworth on ClojureScript One

2012-01-12T00:00:00Z

I was particularly excited to record this, our third episode of ThinkRelevance: The Podcast. That's because on today's show, we talk with Brenton Ashworth about ClojureScript One, which was released just this week. As Brenton will explain, ClojureScript One is a project aimed at helping people learn how to use ClojureScript quickly and effectively.

Download the episode here.

As a reminder, you can subscribe to the podcast using our podcast feed. I'm still working on getting the show added to iTunes, but that should happen pretty soon.

You can send feedback about the show to podcast@thinkrelevance.com, or leave a comment here on the blog. Thanks for listening!

Show Notes

Our guest, Brenton Ashworth
Music
- The intro song on this episode is Fight Fire With Fire, by Metallica.
- The outro song is Paranoid by Black Sabbath.
People
- Luke Vanderhart: @levanderhart, GitHub
- Jen Myers: @antiheroine, Blog, GitHub
- Kevin Altman @itg
- Michael Parenteau @parenteau
- Rich Hickey: @richhickey
- Fogus: @fogus, Blog, GitHub
- David Nolen: @swannodette, Blog, GitHub
Links
- ClojureScript One
- ClojureScript itself
- Google Closure
- Domina - A ClojureScript DOM manipulation library
- Hiccup - A fast library for rendering HTML in Clojure
- How We Pair- A bit about pair programming at Relevance
- The "Hammock Talk" - Rich's excellent talk about how to solve hard problems

ThinkRelevance: The Podcast - Episode 002 - David Liebke on Avout

2012-01-05T00:00:00Z

Hello, and welcome to the second episode of ThinkRelevance: The Podcast. We had so much fun last time that we thought we'd do it again! This time, we talk to David Liebke (@liebke), a developer here at Relevance. The main thrust of our conversation centers on Avout, a Clojure library for managing distributed state in a consistent manner. Avout is pretty cool, and we get to hear David explain it, as well as talk a bit about the source of the names of all David's projects, the book Anathem.

Download the episode here.

In other exciting news, the show now has an actual feed, just like a real, grown-up podcast. You can find it at http://feeds.feedburner.com/thinkrelevance/podcast. I'll work on getting the show added to iTunes as the next step.

Also, I believe I forgot to mention this last time, but please send feedback about the show to podcast@thinkrelevance.com. Thanks for listening!

Show Notes

David Liebke on the Internet
The intro and outro music today both come from IOLET by David Stutz. The CD is inspired by some of the concepts and themes in Anathem. The intro song is Deriving the Quadratic Equation, and the outro is Approximating Pi.
Avout can be found on the web at http://avout.io. You can ask questions on the Clojure mailing list.
Some of the technologies we talked about on this episode:
The people we mentioned today include:
- Rich Hickey: @richhickey
- Stuart Sierra: @stuartsierra, Blog
- Neil Stephenson

ThinkRelevance: The Podcast - Episode 001

2011-12-19T00:00:00Z

Relevance is a fascinating place to work. The primary reason for that, in my opinion, is the great people that work there. I find I'm constantly having interesting conversations with my coworkers, and it's not always about tech stuff. More than once I've had a random hallway conversation and thought, "Wow, if I had recorded that, it would make a pretty good podcast episode."

So that's what I'm doing. On a roughly weekly basis, I'm going to be releasing conversations with the people I am privileged to work with. We've got no set agenda: just have an interesting conversation about whatever people want to talk about.

As this is our first episode, I'm still figuring out how to do all the usual podcast stuff, like getting it on iTunes, creating a feed, and all that jazz. So for our inaugural episode, we're just going with a simple download link. I'll get all the fancy podcast stuff figured out, soon, I promise.

In this episode, I talk with Justin Gehtland, who's sort of our CEO (he explains the "sort of" in the episode). As is always the case when talking to Justin, it was a fun conversation. I hope you'll agree.

Show Notes

We mention a lot of people in the podcast. Here's a list of where to find them on the web:

Justin Gehtland: @jgehtland, Blog
Alan Dipert: @alandipert, Blog
"Scary" Ron Sumida: Current web whereabouts unknown
Don Box: @donbox, Wikipedia
Chris Sells: @csells, Blog, Wikipedia
Brent Rector: Website
Keith Brown: @keithbrown42, Website
Stu Halloway: @stuarthalloway
Tim Ewald: Current web whereabouts unknown
Glenn Vanderburg: @glv, Blog
Jason Rudolph: @jasonrudolph, Website
Rob Sanheim: @rsanheim
Rich Hickey: @richhickey
Andy Hunt and Dave Thomas are The Pragmatic Programmers

Other notes:

The intro to the podcast is the song Jet City Woman by Queensrÿche.
The outro to the podcast is the song Sultans of Swing by Dire Straits.
Justin, Stu Halloway, Tim, and I all used to work at DevelopMentor.
Relevance's Fridays policy.
You can find out more about B Corporations at www.bcorporation.net.
Justin's books:
Band Together is on the web at www.bandtogethernc.org.
Read about Fan, the obscure programming language. Apparently it's called Fantom now.
Programming Clojure, by Stuart Halloway.
Ruby on Rails.

Documenting Architecture Decisions

2011-11-15T00:00:00Z

Context

Architecture for agile projects has to be described and defined differently. Not all decisions will be made at once, nor will all of them be done when the project begins.

Agile methods are not opposed to documentation, only to valueless documentation. Documents that assist the team itself can have value, but only if they are kept up to date. Large documents are never kept up to date. Small, modular documents have at least a chance at being updated.

Nobody ever reads large documents, either. Most developers have been on at least one project where the specification document was larger (in bytes) than the total source code size. Those documents are too large to open, read, or update. Bite sized pieces are easier for for all stakeholders to consume.

One of the hardest things to track during the life of a project is the motivation behind certain decisions. A new person coming on to a project may be perplexed, baffled, delighted, or infuriated by some past decision. Without understanding the rationale or consequences, this person has only two choices:

Blindly accept the decision.

This response may be OK, if the decision is still valid. It may not be good, however, if the context has changed and the decision should really be revisited. If the project accumulates too many decisions accepted without understanding, then the development team becomes afraid to change anything and the project collapses under its own weight.
Blindly change it.

Again, this may be OK if the decision needs to be reversed. On the other hand, changing the decision without understanding its motivation or consequences could mean damaging the project's overall value without realizing it. (E.g., the decision supported a non-functional requirement that hasn't been tested yet.)

It's better to avoid either blind acceptance or blind reversal.

Decision

We will keep a collection of records for "architecturally significant" decisions: those that affect the structure, non-functional characteristics, dependencies, interfaces, or construction techniques.

An architecture decision record is a short text file in a format similar to an Alexandrian pattern. (Though the decisions themselves are not necessarily patterns, they share the characteristic balancing of forces.) Each record describes a set of forces and a single decision in response to those forces. Note that the decision is the central piece here, so specific forces may appear in multiple ADRs.

We will keep ADRs in the project repository under doc/arch/adr-NNN.md

We should use a lightweight text formatting language like Markdown or Textile.

ADRs will be numbered sequentially and monotonically. Numbers will not be reused.

If a decision is reversed, we will keep the old one around, but mark it as superseded. (It's still relevant to know that it was the decision, but is no longer the decision.)

We will use a format with just a few parts, so each document is easy to digest. The format has just a few parts.

Title These documents have names that are short noun phrases. For example, "ADR 1: Deployment on Ruby on Rails 3.0.10" or "ADR 9: LDAP for Multitenant Integration"

Context This section describes the forces at play, including technological, political, social, and project local. These forces are probably in tension, and should be called out as such. The language in this section is value-neutral. It is simply describing facts.

Decision This section describes our response to these forces. It is stated in full sentences, with active voice. "We will ..."

Status A decision may be "proposed" if the project stakeholders haven't agreed with it yet, or "accepted" once it is agreed. If a later ADR changes or reverses a decision, it may be marked as "deprecated" or "superseded" with a reference to its replacement.

Consequences This section describes the resulting context, after applying the decision. All consequences should be listed here, not just the "positive" ones. A particular decision may have positive, negative, and neutral consequences, but all of them affect the team and project in the future.

The whole document should be one or two pages long. We will write each ADR as if it is a conversation with a future developer. This requires good writing style, with full sentences organized into paragraphs. Bullets are acceptable only for visual style, not as an excuse for writing sentence fragments. (Bullets kill people, even PowerPoint bullets.)

Status

Accepted.

Consequences

One ADR describes one significant decision for a specific project. It should be something that has an effect on how the rest of the project will run.

The consequences of one ADR are very likely to become the context for subsequent ADRs. This is also similar to Alexander's idea of a pattern language: the large-scale responses create spaces for the smaller scale to fit into.

Developers and project stakeholders can see the ADRs, even as the team composition changes over time.

The motivation behind previous decisions is visible for everyone, present and future. Nobody is left scratching their heads to understand, "What were they thinking?" and the time to change old decisions will be clear from changes in the project's context.

Experience Report

You may have noticed that this post is formatted like an ADR itself. We've been using this format on a few of our projects since early August. That's not a very long time in the global sense, but early feedback from both clients and developers has been quite positive. In that time, we've had six to ten developers rotate through projects using ADRs. All of them have stated that they appreciate the degree of context they received by reading them.

ADRs have been especially useful for capturing longer-term intentions. We have several clients who are stabilizing their current systems, but looking toward a larger rearchitecture in the not-too-distant future. By writing these intentions down, we don't inadvertently make those future changes harder.

One potential objection is that keeping these in version control with the code makes them less accessible for project managers, client stakeholders, and others who don't live in version control like the development team does. In practice, our projects almost all live in GitHub private repositories, so we can exchange links to the latest version in master. Since GitHub does markdown processing automatically, it looks just as friendly as any wiki page would.

So far, ADRs are proving to be a useful tool, so we'll keep using them.

Now with four more awesome

2011-10-24T00:00:00Z

We may have stopped pretending to be Apple but we haven't stopped adding more awesome to our team: Naoko Chamberlain, Clinton Nixon, Russ Olsen and Jenn Hudson.

Naoko's personality drove her to project management/coach calling. She’s a planner and couldn't help that if she tried. She hugely appreciates the details. It comes naturally to observe and attend to her surroundings, and she truly enjoys teamwork whether at work, play, or playing ball. She also loves to organize everything -- even her sock drawer is organized by color and type.

When Naoko is not planning to-do's or organizing her sock drawer she expresses her love for wine, conversations, and sports. When all three are in one place she is in an extra good mood (except for when Boilermakers, Yankees, or Colts are losing an important game).

Clinton has spent the last 12 years all over the technology industry, from monitoring network security at Three Letter Agencies to hacking for startups to managing teams of developers. After discovering both Ruby and Durham, NC six years ago, he's been a huge fan of both. He's spent enough time at Relevance game nights and other events that he's felt like part of the family for a long while. He has perfectly normal, non-nerdy hobbies outside of programming, like playing Dungeons & Dragons and playing the ukulele.

Russ Olsen started his career doing that other kind of engineering, the sort that involves electricity, gears and getting dirty. Pretty rapidly the wonder of computer programming lured Russ away, which probably explains why most of his fingers are still intact today.

Since turning to coding, Russ has worked on everything from 3D design and image processing software to database query engines and workflow systems. Russ first discovered Ruby back in 2000 when he went looking for a simple programming language to teach to his son. The seven year old lost interest, but Russ never did and he has been building increasingly sophisticated systems in Ruby ever since.

Russ also spends a fair bit of time promoting Ruby via public speaking and he helped found RubyNation, a regional Ruby conference held each Spring in Northern Virginia. Russ has also written extensively about Ruby in the form of two highly regarded books: The first, Design Patterns in Ruby was published in 2008 and is a complete reworking of the classic Gang of Four patterns for a modern dynamic programming language. Russ's second book Eloquent Ruby is a guide to writing idiomatic Ruby. Eloquent Ruby was an instant hit in the Ruby and Rails community when it was published earlier this year.

Russ also has been secretly enamored with parentheses since a very early age and lately has been dabbling in Clojure.

Jenn has 20 years of accounting and analytical experience in a wide range of industries including software, alternative energy, legal, construction, retail and photofinishing, working with both small business and major corporation settings. She has extensive experience at managing an entire business including preparing strategic plans, implementing new programs and products, marketing and analyzing performance. While away from the office, she enjoys cooking and entertaining, travel to far away places and following her daughter's volleyball team around the country.

I'd also like to wish our alumnus Shay Frendt the best of luck with our friends at Chargify. We love you, we miss you.

We're still looking for more awesome. If you'd like to join this awesome team, introduce yourself.

Friday Update 1.1

2011-08-08T00:00:00Z

Welcome to the latest installment of the critically acclaimed "Friday Update"! This week's theme is "In-browser Awesomeness (plus one more)", and boy do we have an exciting lineup for you today!

First up, our brilliant intern Vojto (pronounced VOY-toe) has spiked out a Cocoa library called Atmosphere which waits for client-side changes and pushes those changes to the server automagically. You can read more about it on his blog.

Next we have the illustrious Chad Humphries, who is investigating using Rails 3.1, Backbone.js and Jasmine to build applications. He is excited to announce that the Jasmine tests run both inside and outside the browser.

Continuing our theme, Bobby Calderwood and Alex Redington are working on an in-browser ClojureScript evaluator. A server is required to perform compilation, but, in conjunction with some additonal work from Alan Dipert and Brenton Ashworth, we could soon have a browser-connected REPL!

And our c-c-c-combo breaker: David Liebke is working on a Clojure library called cogito. It's a Clojure implementation of System-Z+, a probabalistic reasoner.

That's it for now!

And don't forget to sign up for Clojure/conj!

Friday Update 1.0

2011-08-01T00:00:00Z

An important part of Relevance's culture is the work we do on Fridays. Many of you have likely heard of 20% time. Perhaps you've even heard it from us! But for those who haven't, 20% time is time that is devoted entirely to personal development and contributing to the open-source community. It doesn't have to be open-source, but it almost always is. In fact, we used to call the 20% time "Open-source Friday," but decided to stop lest we discourage people from following interests or scratching itches that couldn't be open-sourced.

Since this time is so important to us, we've decided to share a cross-section of our Friday projects with the rest of you! Consider this the first of many Friday Updates.

On the Clojure front, the Clojure/core team has been focusing on porting Clojure and its libraries to the recently announced ClojureScript. In particular, keep your eye out for David Liebke's port of Annalemma, dubbed Apogee. And if you haven't seen it already, Stuart Sierra recently wrote a blog post about ClojureScript.

The team is also busy organizing the second Clojure/conj! Which you should sign up for today! Early bird pricing ends soon!

Rob Sanheim and Jamie Kite put together a Rails 3 engine called Honey Badger which sticks a badge onto the page of a running Rails app with the environment, current git SHA, or anything else you'd like displayed in non-Production environments.

Craig Andera recently released ShadowSpawn, a Windows utility for working with shadow copies. Check out his announcement for more details.

And last, but most certainly not least, Jess Martin has released an iOS library called CoolButtons. It allows you to draw glassy iOS-style buttons, all using CoreGraphics and no images.

See you next week!

Rails 3.1 HackFest Wrap-up

2011-07-25T00:00:00Z

Thanks to everyone who participated in the Rails 3.1 HackFest! I hope you enjoyed sharing your love of Rails, plus a few beers, as much as we did. It was great getting to know some of our neighbors.

In addition to upgrading a few Rails apps to the latest 3.1 release candidate, we also submitted a few RailsGuides patches, found a bug and submitted a failing test. We didn't even have a chance to fix it before grzuy picked it up and submitted the patch.

We ran into a few bumps moving to the 3.1 asset pipeline, but overall the upgrade from Rails 3.0 to 3.1 has been smooth. As for the 2.3 to 3.0 upgrade, Rails provides deprecation warnings in the previous point release, 3.0.9 as I write this, so the upgrade goes a little something like this:

Upgrade to Rails 3.0.9
Upgrade other gems as necessary (e.g., haml 3.0 to haml 3.1 + sass 3.1)
Run tests, fix tests, rinse and repeat
Walk through the application and fix any deprecation warnings that crop up in the rails log
Upgrade to Rails 3.1

And now...your moment of zen.

Rails 3.1 HackFest comes to Bull City, July 22-23

2011-07-20T00:00:00Z

Join us at Relevance Inc. this Friday and Saturday as we participate in the Rails 3.1 HackFest.

Come on down for two days of upgradin', pipelinein', bug fixin' good times! This is a great opportunity to meet some local Rails hackers, work through the 3.1 upgrade process, and give back to the larger Rails community. If you're in town this Friday or Saturday, please drop by any time.

UPDATE: The Relevance office will be open Friday and Saturday from 8:30am until 6:00pm or after. Grab your laptop and swing by for an hour or camp out for both days; we'll be here...with pizza.

Find us at:
514 South Duke Street
Durham, NC 27701

For more information, please contact us via email at info@thinkrelevance.com or by phone at 919-283-2748.

Heroku-ification of a Clojure App

2011-07-10T00:00:00Z

Here at Relevance, Inc we often use Heroku for our Rails apps. Unfortunately, there hasn't been a similarly easy deployment story for our Clojure web apps. Recently, Heroku has changed that with their Cedar stack.

My colleague, Craig Andera, has been working on a web port of a board game called Artifact. I noticed he added a GitHub Issue "Deploy app to Heroku" This seemed like the perfect time to show off just how easy it is to deploy a Clojure web app to Heroku.

I grabbed a recent commit that was configured to run a local Jetty server. Here is the simple process I followed to get his app deployed to Heroku. As a prerequisite, you should have a Heroku account as well as the heroku gem installed. That process is described on their site.

Start with cloning the repo

git clone git@github.com:candera/artifact.git
cd artifact

The next step is to create a new heroku app on cedar called artifact. When this command is run from inside your app, the remote heroku repository is automatically added for you.

heroku create --stack cedar artifact

Then modify the -main function to work with how Heroku manages ports. The change we are making here is to read the port from the environment variable when it is available.

In core.clj, change the following block of code from

(defn -main [& args]
  (run-jetty app {:port 8080}))

(defn -main [& args]
  (let [port (Integer/parseInt (get (System/getenv) "PORT" "8080"))]
    (run-jetty app {:port port})))

Next, create a Procfile in the root dir of the app to tell Heroku how to start our app. This tells the web dyno to use leiningen to launch the web server.

web: lein run -m artifact.core

Commit the changes and push to Heroku.

git add .
git commit -m "Heroku-ify"
git push heroku master

And finally view the page.

heroku open

You can see the app at http://artifact.herokuapp.com. It is still in early development, so expect to run into rough edges. If you'd like to help, I'm sure Craig would love your contributions.

The process of taking a working Clojure web app and moving it to Heroku took me less than ten minutes, a small code change, and an additional line of config. This is a major development in the life of Clojure web development. With Heroku, we can build an app with the power of Clojure and the ease of deployment that Heroku provides to other frameworks, such as Rails. This helps us continue to expand our business and offer choice in deployment strategies to all our customers.

For more detail than just this simple intro, be sure to read "Building a Database-Backed Clojure Web Application".

Relevance Welcomes Mike Nygard to the Team

2011-06-03T00:00:00Z

It is with great pleasure that I get to publicly welcome our newest team member, Mike Nygard. We've known Mike for a long time, and have been attempting to brainwash him into believing we deserved to have him join for nearly that long. After years of #hbb, too-smoky-to-drink-Scotch, and adopting a new language to play with, we finally managed the task.

Mike's bio:

Somewhere in the mid-90's, Michael went from "young hotshot" to "grizzled veteran". He's still not sure quite when or how that happened. It might have been the beard.

It might also be that Michael has worked in many different kinds of software development across many different domains, starting with assembly in the 8-bit micro days up through Java, Scala, and Clojure for massive distributed systems. That experience includes massive companies like Unisys, Best Buy, 3M, and Target, along with two startups that grew from 30 to more than 100 people, plus three terms as an independent consultant. He's always looking for people who know they can do anything, and that describes Relevance.

His desire to teach others shows in daily work, in speaking engagements, and in writing. Michael wrote "Release It!"---about building large scale systems to survive the real world, rather than just passing QA---and has contributed to several other books. These days, he is devoted to improving the odds that a client's system will make money for them, through a deep understanding of time, uncertainty, risk, ignorance, and architecture.

He finds it astonishing that the most buzz-worthy technologies of the past two years are Emacs, Vi, Lisp, and batch processing (Hadoop).

We were unable to convince Mike that we were really LivingSocial during his "interview". We did, however, convince him that we understood how to use parentheses appropriately when coding, and this seems to have done the trick.

Welcome aboard, Mike!

The one where we welcome two more to the family

2011-04-20T00:00:00Z

Our Apple gambit paid off. Two poor, easily deluded suckers......I mean, two fine, intelligent and wonderful people have decided to join our growing chorus. Let me introduce you to:

Jamie Kite Jamie is passionate about creating elegant solutions to complex problems. After receiving her B.S. in Computer Science from UCF (University of Central Florida, or alternately "Under Construction Forever"), she stumbled upon a social media marketing start-up in Orlando, FL where she went from Front-End Developer to Senior Ruby Developer and Project Lead faster than you can say "cakeplow." Jamie is equally comfortable debugging Ruby code as she is reworking designs in Photoshop or writing poetic CSS. She lives her life by the "Under Construction Forever" mantra, always learning and eager to pick up new technologies and techniques to improve her craft. When she's not writing code or designing user experiences, you can find her presiding over wedding ceremonies, pulling weeds, or cooking and writing for her food blog.

Lynn Grogan Lynn arrived in Durham after a two month road trip looking for a new place to live. She found Relevance and lured them in with two lines in her cover letter which read: I have memorized exactly two jokes in my life, but they are inappropriate for a cover letter and I would have to meet you in person to gauge whether or not they are appropriate to tell during an interview. One of them involves Willie Nelson, the other one involves a runny nose. Clearly these were good jokes because they hired her on as an office manager. Prior to Relevance, Lynn was working as Director of Operations at VonChurch, Inc. a firm in San Francisco that specializes in recruiting for the video game industry. Prior to that she was doing lots of stuff that mainly involved art galleries and coffee. Lynn was born and raised in the fine state of Wisconsin and has a B.A. from UW-Madison in Sociology.

I think we can stop pretending to be other giant companies now. Sorry, Groupon and Apple. We're still hiring, though, so this time, if you are interested, I'll just let our awesome team speak for itself.

When You Start, Define How You Will Behave

2011-04-06T00:00:00Z

When you are starting a new company, there are a lot of things you are asked to announce at the start. What are you going to do? Why are you doing it? What makes you so special? Why is your social coupon FPS better than LivingDiscountKillzone? Exactly when do you reach the magical $12B valuation?

By all means, answer these questions. Each is important to some constituency, be it the employees you will try to attract, the investors who are clamoring to get in, the customers you hope to target, etc. The great thing about the modern world of “lean startups” and “the pivot” is that you are expected to throw each of these answers away after three months. After all, the purpose of a startup is to discover a sustainable business model. Your first guess is going to be wrong.

I’d suggest that, in addition to these ephemeral things, you also consider strongly announcing to the world how you are going to behave while you build this thing. This, however, is not ephemeral. It isn’t something you should pivot away from. It can’t be subject to A/B testing, and it can never be diluted through Series DD financing. It is the absolute statement of what you should expect of yourself, in normal times and in the face of crisis.

I recently had to craft a document for a new venture, and it includes the following paragraph:

I expect that we’ll create a company dedicated to the idea that you can be a capitalist, and still be a decent person at the same time. That we will treat employees, customers, investors and vendors with fairness, honor and dignity. We will empathize before we criticize, but criticize when it is important to do so. We’ll endeavor to understand our company’s externalities, minimizing the negative ones, accentuating the positive ones. We will, in all ways, act as if people actually matter.

Whenever the organization faces a tough decision, whenever it operates under stress, whenever it asks itself “what do I do now?”, it will have this statement as a guide. I guarantee that such a statement will eliminate a world of possibilities from the choice it has to make, and will draw a big Skitch-style red arrow at the right choice. You can pivot away from what you do, but you can’t pivot away from who you are.

Introducing Postfixer

2011-04-05T00:00:00Z

"Have you got anything without spam?"

We recently heard from a client concerned that a few of his customers weren't receiving automated emails. His email account was filling with hundreds of bounce notifications, customers were getting frustrated, and there was nothing he could do about it.

Inspection of the Postfix logs on his and several other servers revealed a systematic problem. When these apps were first deployed, most emails were successfully delivered to customers (although a few might have ended up in the Spam/Bulk folder). Over the years, however, the spam problem has only gotten worse; and email clients, ISPs, and mail services aggressively terminate suspect messages with extreme prejudice.

Enter Postfixer

Most of us aren't Postfix gurus, let alone email experts. Postfixer helps with the following error-prone tasks:

Configuring Postfix properly
Setting up the necessary DNS entries
Testing everything to ensure your emails make it to the Inbox

Postfixer is a standalone utility powered by Capistrano. Git clone it, drop in a config file, and say goodbye to the Spam folder.

$ git clone https://github.com/sumbach/postfixer.git
$ cd postfixer
$ cp config-hostname.example.com.yml config-errbit.thinkrelevance.com.yml

Here's a sample config:

#
# config-errbit.thinkrelevance.com.yml
#
canonical_hostname: errbit.thinkrelevance.com
additional_hostnames:
  - utility.thinkrelevance.com
email_domains:
  - thinkrelevance.com
forwarding_address: utility-errors@thinkrelevance.com
envelope_sender: bounces@thinkrelevance.com
application_user: deploy

sudo_user: deploy
address: errbit.thinkrelevance.com

Let's break it down:

canonical_hostname: Fully-qualified domain name (FQDN) for your application server

additional_hostnames: Any additional hostnames that this server is known by (may be empty)

email_domains: All domains for which this server should be able to send email

For example, if your application is accessed as http://errbit.thinkrelevance.com/, but its email comes from errbit@thinkrelevance.com, then email_domains should be "thinkrelevance.com".
Every entry in email_domains should have DNS MX Records set up. You almost always want to send email from your registered domain (thinkrelevance.com), NOT from a hostname or subdomain (errbit.thinkrelevance.com, www.thinkrelevance.com, etc).

forwarding_address: Email address for local messages (such as errors from cron jobs)

I typically use "errors@" followed by the first entry from email_domains.
The domain (the part following the @ sign) MUST be included in email_domains.
Email addressed to local user accounts (root, nobody, etc) will be forwarded to this address.

envelope_sender: SMTP envelope sender (where bounce messages end up)

As with forwarding_address, the domain (the part following the @ sign) MUST be included in email_domains.

application_user: Local user account under which your application runs

Emails addressed to this user's account (for example, error messages from cron jobs) will be sent to forwarding_address.
Outgoing email from this user's account (messages sent by ActionMailer without an explicit From address or sent using the /usr/sbin/sendmail binary, for example) will be rewritten to change the From address to the forwarding_address set above.

sudo_user: Local user account with root sudo permissions

Postfixer will SSH into the server using this account. Might be the same as application_user.

address: FQDN or IP address used to SSH into this server

Once you've updated your Postfixer config, a number of cap tasks are at your disposal:

$ export CONFIG=errbit.thinkrelevance.com   # specifies which .yml file Postfixer uses
$ cap email:send_test_email                 # send a test message
$ cap email:check_dns                       # print a report of your existing DNS entries

The send_test_email task uses the very helpful port25 verifier. If you're like me, the response to the test email looks something like this:

==========================================================
Summary of Results
==========================================================
SPF check:          softfail      (BAD)
DomainKeys check:   neutral       (BAD)
DKIM check:         neutral       (BAD)
Sender-ID check:    softfail      (BAD)
SpamAssassin check: ham           (GOOD)

Yuck! Let's fix that up.

$ cap email:install_packages                # install DKIM-milter (and Postfix, if not installed)
$ cap email:backup_config                   # archive your current config files
$ cap email:generate_config                 # generate new config file based on the .yml
$ cap email:install_config                  # copy new config files to the server
$ cap email:restart                         # restart Postfix and DKIM-milter
$ cap email:print_dns                       # generate a report of the DNS changes you should make

Based on the output from print_dns, you should add/update your DNS configuration. If you're using Slicehost for DNS, log in and edit DNS entries via SliceManager. Otherwise, check with your registrar (Namecheap, GoDaddy, etc).

(Note: print_dns assumes you're using Google Apps. If you're using your ISP's or your own incoming mail server, replace "include:_spf.google.com" in the SPF records with something appropriate to your setup.)

Once you've updated your Postfix config and DNS entries, give cap email:send_test_email another try.

==========================================================
Summary of Results
==========================================================
SPF check:          pass          (GOOD)
DomainKeys check:   neutral       (BAD)
DKIM check:         pass          (GOOD)
Sender-ID check:    pass          (GOOD)
SpamAssassin check: ham           (GOOD)

Ahhhhh, much better.

Caveats

Postfixer does not (yet) check if your server is on a blacklist

I recommend the awesome DNSBL Lookup tool from mxtoolbox.com
If your server is on a blacklist, you'll need to request to be removed (the process should be available on the blacklist provider's web site)

Postfixer does not check for general DNS issues

I recommend dnsvalidation.com

Posfixer does not (yet) support Yahoo DomainKeys (as seen in the port25 verifier results above)

It does support the newer DKIM (DomainKeys Identified Mail) standard which has largely displaced Yahoo's legacy solution.

Thanks

Huge thanks to Relevance for giving me Fridays to make these kinds of contributions.

Thanks also to Shay Frendt for being my first guinea pig and for his new feature ideas.

Thanks to Mike Bailey for deprec, from which I got the idea to generate config files locally (using ERB templates) and deploy via Capistrano.

I'd like to contribute

That sounds great; I'd like you to contribute, too! Postfixer is available on Github and distributed under the MIT license.

Pull requests are welcome.
Please post bugs and feature requests in Github issues.

Relevance Turns 30 (people)

2011-03-02T00:00:00Z

All that pretending to be Groupon the last time around really helped with recruiting (not to mention revenue, what with all the coupons we sold). As a result of all this gorging on awesome software development, we had to convince some more folks to join our team. Since last we spoke, we've been incredibly lucky to add:

Ben Vandgrift Ben Vandgrift has devoted himself to the cause of 'better living through automation' for the past 15 years. After completing a BS in Software Engineering (Kentucky), he entered the world of enterprise software development. He has since been recovering--despite a growing startup habit--by applying himself to progressively smaller and smaller companies doing bigger and better things. An entrepreneur at heart, Ben also dabbles in art and music as time infrequently allows.

Marc Phillips Marc went to Colorado College where students take one class at a time for three and a half weeks straight followed by the next one, with three and a half days off in between for the whole school year. That means geology classes are month-long camping trips, literature courses require a novel a night, and biology labs often result in the sharing of hopes and dreams with fetal pigs. After waking up one morning in Seattle he got his first job at Microsoft in 1997 by explaining his ride had already left and they might as well give him something to do. After 10 years in mobile devices and forgetting to cash in his stock options before they expired, he spent the next 4 years in emerging markets and technology incubation, moving into online services and managing teams inspired by rapid iteration and agile development practices. His passion for taking risks, making mistakes, and learning from them for the benefit of others was exhibited in its purest form when on a trip to the Costa Rican jungle he led a group through the trees after their jeep broke down, discovered a hidden mud hole by sinking in it up to his waist, then located and diverted a swarm of army ants that was preparing to raid their cabin with his bare feet while trying to clean his pants, all in under 30 minutes. While he now focuses his action-oriented iterative style on more technical projects, he still frequently does his best work without pants.

Michael Fogus Fogus started out as a philosophy major (with a focus on Nietzschian vs. Kantian philosophy), but finished with a B.A. in Computer Science from St. Mary's College and an M.S. in Computer Science from Johns Hopkins University (with a focus on A.I.). As a software developer with experience in RTOS development, distributed simulation, machine vision, code generation, and expert system construction, Fogus has spent significant time with C, C++, CLIPS, Common Lisp, Java, Jess, Python, Scala, and Clojure. Additionally, Fogus has been involved in the Clojure and Scala communities as the Co-author of the book "The Joy of Clojure", author of numerous Clojure libraries, and a one-time external maintainer of the Scala XML language facilities.

Luke Vanderhart From a young age, Luke has been fascinated by the possibilities of computation. Through highschool, he worked for a startup in Colorado, developing a distributed semantic network knowledge management product. He took a break from software development to get a degree in Philosophy and Linguistics from the College of William and Mary, only to discover that both are profoundly relevant to the art of creating software. After college, he worked as a consultant for several large corporate and government clients, doing enterprise-scale data management and search. During this time, he became fascinated with the beauty of functional programming, particularly Clojure, and ended up writing a book on it (Practical Clojure, published by Apress) with the help of Stuart Sierra. He lives in Annapolis, MD with his wife Hannah, who is a poet.

I think for the next round of recruiting we're going to pretend to be Apple. I hear they are doing some interesting things.

The Legend of Team Iron Chef

2011-02-22T00:00:00Z

This year, instead of holding our retreat the way we always have (holing up in the office for two days and pretending to discuss important things between Magic duels and Rock Band shenanigans) we decided to do something different. Since we're much larger now (28 this year compared to 11 last) and since a lot of folks are now remote, we decided to go offsite, and off-road, and holed up in Snowshoe, WV.

Now, you might think that a well-known ski resort like Snowshoe would have a lot going for it, and you'd be right, as long as you were thinking of things like nice slopes and good powder and relatively efficient lifts. If you were thinking of food, though, you would be sorely, sadly, and, alas, hungrily mistaken. Essentially, Snowshoe has a 7-11 with a Dominos Pizza built into it, and that's about it for food options. With 26 employees and a bunch of families around, we were going to be sadly limited in our comestibles without some heroics.

Enter Team Iron Chef. Before heading up to the retreat, we collected some volunteers to handle our cooking duties (2 breakfasts, 2 lunches and a dinner, all for 30 people). Our intrepid team of dupes^{H^{H^{H^{H^Hheroes}}}} consisted of Muness (@muness), Jared (@jdpace) and Michael (@parenteau). This wonderful crew sacrificed their sleep, their energy and their participation in parts of the retreat to keep our rogue band well-stocked with calories. And did they ever.

Breakfast consisted of an onslaught of french toast, mounds of sausage, gallons of scrambled eggs, mountains of potatoes, rivers of coffee. They had to rise at 7 to hit the stoves and slave away all through breakfast to keep the food available for the rest of us to shovel gluttonously down our gullets. Then we would head off to the business portions of the retreat.

Then lunch would arrive; on the first day, Team Iron Chef left the retreat a little early to prepare an Italian feast, essentially an infinite supply of carbohydrates. There was pasta, and bread, and lasagna, and bread, and mushroom calzones, and bread, and a stunning marinara, and bread. And comas. The second day, they left a LOT early, and Jared showed off his skills as a master sushi chef and wowed us with a rainbow of fish flavors. The immortal cry of "Volcano Rollllllllll!" will not soon be forgotten in the hills of West Virginia.

And dinner, oh dinner, Michael and crew crafted an Indian feast. Pots of stews, piles of flavors, bowls of chutney. And bread.

For a company that takes so much pleasure in feeding itself, Team Iron Chef completely and utterly knocked it out of the park. It was an unbelievable accomplishment, that was coupled with enormous personal sacrifice. It was the very embodiment of team focus, and the retreat was made immeasurably better through their efforts. When I am asked in the future for examples of people pulling together as a team, and for a team, I will scream "Volcano Rollll!" and think fondly of Retreat '11.

Band Together Rocks -- You Should Help

2011-02-02T00:00:00Z

For the past two years, we've been working with Band Together, a North Carolina non-profit organization with an incredibly cool mission. Every year, they throw one amazing party at which they raise money for a different North Carolina non-profit. Last year, that party was a concert featuring Michael Franti, The Old Ceremony, One EskimO and others, and they gave StepUP Ministry $358,000. That's big time.

And what a party we had last year. It rained like hell all over The Old Ceremony, which sucks because they are one of my favorite local bands, but it eased up enough for us to take the dance train to funky town as Michael Franti, my favorite artist anywhere, rocked the house.

This year, Band Together has launched a two-year fund drive to benefit Alliance Medical Ministry and Urban Ministries of Wake County. The goals are bigger, the concerts get better every year, and I encourage anyone who likes great music and crazy good ways to help the community to get acquainted with Band Together and check out the show this year. Relevance will be there, in force, in the VIP booth. Will you join us?

And we grow, again.

2011-01-11T00:00:00Z

Continuing a trend of both collecting truly awesome people and blowing right past any reasonable internal forecast of potential growth, we are enormously pleased to announce the following new additions to our team. Between them, they expand our corps of coaches, level us up at systems architecture, add a slew of awesome technical skills, and make us more likable and cuddly, to boot.

And here they are:

Maggie Litton: Maggie is a veteran project manager, scrummistress, and coach. After studying Film, Philosophy, and English at New York University and the University of Kentucky, she explored several career paths before falling in love with software development. Before joining Relevance, she spent the last several years scaling agile development practices for enterprise projects at IBM.

Sam Umbach: Most of all, Sam is passionate about the user! He finds not just the technology solution, but also the humane design to go with it. After several years of embedded systems work in network security and, most recently, video games, he is now addicted to closing the feedback loop, iteratively discovering and building what the user needs. When not at his computer, you'll probably find Sam at one of the many Triangle music venues, enjoying a concert and a beer.

Tim Ewald: Tim Ewald has 18 years of experience building distributed systems. Over the last decade he has worked primarily with web technologies. Tim is a pragmatic architect focused on designing effective solutions to complex problems. Prior to joining Relevance, he was VP of Architecture at SeaChange International, a world-leader in video-on-demand infrastructure for cable and telcos, where he worked on integrating Internet technologies with television infrastructure. Before SeaChange, he worked at Microsoft, where he helped design and build the first version of MSDN2 for delivering technical content to developers. Tim's primary technical interests include advanced languages like Clojure and Ruby and hypermedia service APIs based on REST. Tim holds a Bachelor's in Computer Science from Hampshire College and is a well-known conference speaker.

Craig Andera: Craig graduated with a master's degree from MIT in 1995, and has spent the intervening time working variously in C++, C#, and (most recently) Clojure. Specializing in large-scale web system implementation, Craig has written for MSDN Magazine and has spoken at conferences both nationally and internationally.

Bobby Calderwood: Bobby is half developer, half businessman, and all family-man. He graduated with a degree in Engineering and Economics from Dartmouth College. During his time in college he also played fullback on the football team and served a two-year mission for his church in Arizona. He has spent his whole career splitting the divide between business analyst and developer for small startups and large institutions alike, including being a technology consultant and developer for the FBI and the DoD. He, his wife, and their two small children enjoy playing guitars and singing together, participating in their church congregation, and chasing their dog, Wally.

Welcome to you all, I only hope that we live up to the fantastic expectations you must have of us after we pretended we were Groupon during your interviews.

hooppps - A Mobile dribbble Browser

2010-11-16T00:00:00Z

I wanted to make a dribbble browser for my phone, so I convinced some of my Relevance teammates to help me in this endeavor. The result: hooppps! hooppps is an open-source Rails 3 app hosted on Heroku. Under the covers it uses the swish gem, a Ruby wrapper for the dribbble API.

A screenshot of hooppps (from a desktop web browser):

(On the screenshot above, the images inside hooppps are shots on dribbble by: David Lanham and Dan Cassaro)

What is dribbble?

"Dribbble is show and tell for designers, developers and other creatives. Share sneak peeks of your work as 'shots' — small screenshots of the designs and applications you’re working on" - Quoted from the dribbble blog.

I love dribbble. People ask me, "What is dribbble?" and I always reply, "It's like Twitter, but for designers." The truth is, although there are similarities, it's very different from Twitter. dribbble is a community of some of the most talented designers and artists in the world! A dribbble user (AKA "player") is asked the question, "What are you working on?" You respond by uploading an image (AKA "shot") no larger than 400px x 300px. This community is invite-only (AKA "draft"), and you can only post a limited number of "shots" per month. "Players" can follow each other, "like" shots, and leave comments. There is a lot of feedback shared amongst players, and keeping in the spirit of the application's basketball theme, players can "rebound" shots. A "rebound" posts a shot that is inspired by another shot. If you like looking at beautiful art and design, you should definitely check out dribbble.

Why make hooppps?

While dribbble is amazing in a desktop browser, they have not yet created a mobile interface. So when dribbble came out with an API, it made me think of how cool it would be to browse dribbble on my phone via a lovingly-crafted mobile interface.

Not just for iPhones

Even though I personally use an iPhone, I didn't want to limit the functionality to just that segment. Others have released native iPhone clients for dribble that you can buy in the App Store. And they are great apps. What I wanted though, was a simple and lightweight browser that anybody could access via their smartphone browser. So, if you are on Android or iOS, you can experience dribbble on your phone in a mobile-friendly format via hooppps.

Start small and iterate

hooppps is not a complete implementation of dribbble, nor does it attempt to cover every feature of the dribbble API. It is a simple experiment meant to improve the dribbble mobile experience. So far, that initial goal has been accomplished. However, this is just the first release. We want to make hooppps better. As the API provides more functionality, we'll add that functionality to hooppps as we see fit.

Release 1

With the first release of hooppps, we hoped to get initial responses and feedback from people.

The first release features include:

Views

popular shots
shot detail
player detail
go to player

Extras

comments on shots
pagination
share shot on Twitter
follow player on Twitter
iPhone home screen icon

In addition to the features in hooppps today, the dribbble API also provides access to "shots by everyone" and "debut shots." We did not implement these extra views...yet.

Coming soon!

When I created the first view on hooppps, I thought, "Let's implement the popular shots thread, because it's popular." Well, it turns out that it may be full of popular shots, but it's not the most popular view in dribbble. Since we first mentioned hooppps on Twitter, people have noted that the "everyone" thread is more interesting, and that is what people view the most. So that was our first feature request. We are implementing that, and we will include the "debut" thread as well.

What would you like to see in hooppps?

Desktop browser vs. mobile browser

I originally designed hooppps to just be experienced on a phone. But as I got to thinking about how people would be introduced to hooppps, I realized that a lot of people would end up on hooppps via their laptop or desktop computer. Simply showing them the mobile layout in their desktop browser would result in a subpar introduction to hooppps. But I didn't want to focus on a layout for desktop browsers, because dribbble already has a wonderful desktop interface. Nevertheless, I wanted people to have an awesome first impression of hooppps, which meant that hooppps needed a special layout for the desktop browser: a preview of sorts.

So then I got to thinking, "Why not make hooppps functional in its desktop preview?" I created a position:absolute div over an iPhone image with overflow: hidden. Then, using the jQuery mousewheel plugin, I enabled scrolling of the content inside of that div, simulating the mobile experience. (Thanks to Larry for solving that problem!) In short, hooppps has a fully functional mobile interface visible in a desktop browser!

Collaboration and fun

hooppps has been a really fun project for me. I have learned more about Rails and designing for the mobile experience. It has also been really fun to get other developers here at Relevance involved. (For a list of contributors, see the README.)

From the very beginning, the idea was to open this up for others to contribute or fork to make their own dribbble browser. So, all of the code is public on GitHub. I would love to help other designers get involved (or even get started with their own implementation), so @reply me on Twitter with any questions.

Thanks!

I want to say thanks to everyone here at Relevance for helping me get hooppps out the door. Thank also to Jeremy Weiskotten for the swish gem. Without that, I probably would have not been ramped up so quickly. I also want to say thanks to Dan Cederholm and Rich Thornett for doing such an awesome job with dribbble. And thanks to everyone out there that contributes to open-source software. It is really awesome to have so many tools and a wonderful community to work with!

Thoughts and Lessons from Rails Rumble 2010

2010-11-09T00:00:00Z

I met Nick Plante working at Relevance and discovered that he was one of the people who organized the Rails Rumble. I asked him about it and expressed my interests in participating. It was too late to get in on a team, but he invited me to be a judge.

I was asked to review 20 apps in about 72 hours, judging each by 4 categories: Appearance, Completeness, Innovativeness & Usefulness. I took this all very seriously, and I created a template to give detailed feedback in all areas. (I know I would have loved to get feedback that way if I had entered.) There were many things that raised my brow throughout my review of the suggested apps. Without a doubt, there were some amazing wins. But, there were also several common fails for many of the apps I reviewed.

First and foremost, let me start by recognizing that these apps were all made in just 48 hours by a team of no more than four people. That's a serious feat! All of the apps had some serious sweat poured into them and just participating in the Rumble is a win, as there is much to learn from accepting such tight constraints. And under these constraints, it was clear that most teams fell apart around the same thing -- Minimal Viable Product (MVP).

Minimal Viable Product

A Minimal Viable Product, in this case, would be the most simple and achievable feature set used to demonstrate a solution to users with limited time (i.e., the judges) with a goal of getting feedback on its value. Almost every great virtual product starts out small and introduces enhancements to test the value of new features, while all the while its core remains usable and intact.

The applications that I noticed most positively were those that had a clear understanding of MVP. They served a specific purpose. They were polished in appearance. And the minimal feature set was functionally complete. When certain features were not implemented, these apps clearly indicated that these features were "coming soon"; they were thoughtfully and tastefully integrated in appropriate locations throughout the app. These features were also enhancements not blatant omissions. The teams who got this right created products/tools that demonstrated solutions. They did so with clean interfaces that told the user what to do when and where. And it was clear that the tool was working by the feedback provided to the user post-interaction via validation and messaging. Even upon first laying eyes on these apps, they informed the user as to why they were there and what they should expect from their experience. They had clear calls-to-action that guided me to where I needed to be at each stage of my interaction with the app. Kudos to all who put such thought and work into your app so I didn't have to figure out how to use it!

The applications that I noticed most critically were those that completely missed the MVP boat. These apps may have had great functionality on the inside, but signing up was complicated. Or broken. Or upon landing, there was no clear explanation as to what problem the app was trying to solve. Other apps got the landing right, but then fell apart on the inside due to excess features which resulted in poor organization, poor flow, or general incompleteness. Some apps failed to guide the user through their experience; they lacked clear labeling and messaging. These apps seemed to lack focus and/or balance.

Questions that could be helpful in a Rumble

How do we apply this learning to future Rumble events? Asking the following questions could give you a head start on the competition.

For MVP:

What is the problem that I am solving? How can I solve it in the most simple and focused way?
Can we solve the overall problem one feature at a time?
Are there future (post-Rumble) features that I want to preview to the users? Can I provide those previews without compromising the core functionality of the app, or would these enhancements just be a distraction?
Is what I am working on essential to the current release of this product?

For Usability:

Have I clearly stated what the user should be doing at every stage — from landing, to signup, to sign in, to using the tool, to logging out?
Do I have validations, confirmations, and essential messaging in place?
Have I labeled forms and form elements clearly?
Are there any broken links?
Have I made it easy for users to recover from mistakes they might make when entering data?

Rails Rumble apps I reviewed that "wowed me"

Of the apps that were assigned to me for judging, these entries were the shining stars. (Note: they are not the list of top apps for the Rumble. For that list, you should check out the complete scores and all of the amazing stuff that came out of this 48 hour whirlwind of productivity.)

Commendable Kids (The clear winner IMHO)
Monitaur
puzzlegasm
rails3templates
snoopdoc
stillalive
beargeo
Motivation Dashboard

Synopsis

All in all, it was really great to be a part of the Rumble. I enjoyed looking over all the applications, and I was even more amazed and humbled to get thanks from teams for my thorough reviews and honest feedback. I would do it again in a heartbeat, but I definitely hope to join a team and participate in the thrill of the competition next year. I look forward to Rails Rumble 2011 and hopefully your feedback!

The Relevant Bits - Nov 2, 2010

2010-11-02T00:00:00Z

In addition to pulling off a successful "Conj", here is the run down of what we at Relevance were doing with our 20% time in October:

Chad continued his quest for Vimlander 2 The Quickening to be the only vim config around.
Stuart H has been knocking out tickets and applying patches to Clojure. Grab 1.3.0 Alpha 2 if you want to keep up with the latest in Clojure development.
Michael was an expert panel judge for the Rails Rumble.
Aaron shows off how to do mobile org in his emacs config.
Stuart H, Michael and Jon enhanced Mycroft. If you're already using it, see the history to see what's new. If you're not already using, grab it and start inspecting your JVM data.
Jon and Michael added paginated lists to their fork of swish.
Stuart S released Lazytest 1.0.1, 1.0.2, 1.1.0, 1.1.1 and 1.1.2 of his testing framework. See the changelog to figure out what your version of Lazytest provides.
Jon and Aaron updated labrepl, the environment for learning Clojure, for Clojure 1.3.0 compatability and closed out some GitHub issues.
Stuart H uploaded his slides from his Clojure presentation on protocols at JAOO.
Chris released 1.0 of ValidationReflection, for Rails 3 compatibility.
Alan updated reconfig to be Clojure 1.3 compatible. Check out this library if you want to reload config files in Clojure on SIGHUP.
Stuart S created Message, experiments in message-passing architectures in Clojure.
Chad, Alex R and Larry forked ruby-saml and started adding some new features, including optional HTTP parameter passing and more test coverage.
Alex R created Dwarf, a data mining tool for Rails 3.

Relevance Blog

Agile Reboot: Putting the Man back in Manifesto

ThinkRelevance: The Podcast - Episode 005 - Michael Parenteau

Show Notes

Where to Find Relevancers this Month!

ThinkRelevance: The Podcast - Episode 004 - Aaron Bedra's Valedictory

Show Notes

ThinkRelevance: The Podcast - Episode 003 - Brenton Ashworth on ClojureScript One

Show Notes

ThinkRelevance: The Podcast - Episode 002 - David Liebke on Avout

Show Notes

ThinkRelevance: The Podcast - Episode 001

Show Notes

Documenting Architecture Decisions

Context

Decision

Status

Consequences

Experience Report

More Reading

Now with four more awesome

Friday Update 1.1

Friday Update 1.0

Rails 3.1 HackFest Wrap-up

Rails 3.1 HackFest comes to Bull City, July 22-23

Heroku-ification of a Clojure App

Relevance Welcomes Mike Nygard to the Team

The one where we welcome two more to the family

When You Start, Define How You Will Behave

Introducing Postfixer

"Have you got anything without spam?"

Enter Postfixer

Caveats

Thanks

I'd like to contribute

Relevance Turns 30 (people)

The Legend of Team Iron Chef

Band Together Rocks -- You Should Help

And we grow, again.

hooppps - A Mobile dribbble Browser

What is dribbble?

Why make hooppps?

Start small and iterate

Release 1

Coming soon!

Desktop browser vs. mobile browser

Collaboration and fun

Thanks!

Thoughts and Lessons from Rails Rumble 2010

Minimal Viable Product

Questions that could be helpful in a Rumble

Rails Rumble apps I reviewed that "wowed me"

Synopsis

The Relevant Bits - Nov 2, 2010