• Read more about Redesigning Agile: Part I - Challenges

One of the best comments I've heard about Agile development is that "adopting Agile is itself an agile process". It sums up very nicely the fact that each team and each project will have their own needs when it comes to finding a process that works for everyone, including the stakeholders. It also means that no matter how much you like a specific methodology, it's virtually impossible to implement that process on your team following its strict definition.

As a Scrum Master I've always been partial to Scrum, but after spending six months trying to make it work on one of our large client projects, I reevaluated and started from the ground up to design a whole new Agile process. We'll be introducing our new process in a future blog post, but for now I wanted to talk about some of the challenges we faced implementing Scrum.

There was nothing specific that was wrong with Scrum for our project. We just ran into enough minor hiccups that we started to lose some of the benefits that we should have been able to reap by using it. Before starting, I needed to figure out exactly what wasn't working (and also what was working well) with Scrum so that those issues could be addressed by our new process.

Here are some highlights of our challenges:

• Missing or ambiguous roles

  Scrum works best when a strong Product Owner and a strong Scrum Master maintain a bit of tension between them. The PO needs to demand more and the SM needs to keep things reasonable. The result is an aggressive schedule with a great deal getting done, but development kept to a sustainable pace.

  This can break down if your Scrum Master needs to do a lot of the product planning and prioritization (or isn't involved enough in the planning process). Likewise you can also run into significant problems if you have trouble finding someone who is both empowered and knowledgable enough to be a strong Product Owner.

  Another potential issue is that as painful as it may be, priorities sometimes need to be set by a committee. If the client can’t abide by a single person who selects the features for the upcoming iteration, the process needs to be flexible enough to support that. This also means that if the person who is most responsible for setting priorities is unavailable, then one or more surrogates can easily step in.

• Self-organization doesn't work for every project

  Even when you have competent and self-motivated developers, not all teams work well when attempting to self-organize. For our team, there were a few factors that made it a challenge.

  First, we were regularly adding and removing people. As other projects spun up or down, we would have fairly regular shifts in team composition. While we always had the same number of developers, we frequently had new developers coming on who were new to the system. Since our product is highly complex, they simply could not figure out which of the backlog items from the current iteration were good ones to try to work on.

  Second, with a team spread out across the world, real-time collaboration is hard. In our case we have developers across the US and China and were working with client contacts in every US time zone as well as Spain and South Africa, making it impractical to rely on instant availability. The consequence is that your team needs to be more autonomous and focused on working independently. In my experience, self-organization works best when the whole development team is collocated and able to work with one another face-to-face.

  Last, the client will sometimes need more detailed insight into who is working on what. In traditional scrum, having a backlog story hanging out and unassigned at the beginning of a iteration can make some clients uneasy.

  To get around these issues, we found that the project manager for the development team needs to assign tasking to provide focus and avoid issues with non-real-time collaboration. This needs to be done in such a way that the clients are aware of the assignments, but the developers are still empowered with technical and design decisions without needing approval.

• Rigidly timed iterations can break velocity

  There are a number of situations where having a fixed-time iteration doesn’t work. In the web development world, you will often have short (e.g. 1 week) iterations. Many features easily fit into one iteration, but often a large feature needs to be spread across multiple iterations and simply cannot be broken down into concrete backlog items that can be deemed complete during a single iteration. Also, changes in client schedules, shifting personnel, and unexpected things like conferences, holidays, etc. can make iteration timing problematic.

  Scrum requires a stable team that has a consistent velocity. That velocity is used to determine how much to tackle in the next iteration. The problem is that a team’s velocity is based on the past performance of that team (i.e. how much they got done during the last few iterations). When you have a team that either changes frequently because of personnel or unstable iteration times and shifting customer requirements, then the velocity can become unstable.

  When these factors affect velocity, your most important planning metric becomes meaningless.

• Better transparency into release schedules

  With web development, you often end up in a cycle where major new features come out each iteration and marketing of those features can get lost in the noise. We need a way to say “the next major version of our site is online and it includes features foo, bar, and baz”. The client needs an opportunity to brag about progress and plan ahead for potential downtime.

• Incorporate a mechanism for QA and bug fix cycles

  There needs to be a clean way for the QA team to be fully integrated into the iteration cycle. The acceptance criteria and the planning of regression tests need to be a core part of the process while not holding up the development team. If you have separate QA and development teams then your developers can end up sitting around waiting for QA at the end of a sprint in Scrum.

  At the same time, there needs to be a real dedication to continuous code improvement and bug fixing that isn't dependent on the Product Owner deciding to prioritize those fixes.

While accommodating all of these changes, we still needed to harvest some of the benefits of Scrum and other Agile processes.

Even though we were looking for a process that would allow our clients more insight into who was working on what, we still wanted our developers to be able to focus on the task at hand and not be concerned with shifting priorities or popup crises. The client needs to remain hands-off and the process needs to be set up to make that comfortable for both the client and the development team.

Obviously one of the biggest advantages with Agile development is that you are able to respond to changing requirements (the idea of dropping “ready, aim, fire” in favor of “ready, fire, aim, aim, aim, aim, …”). The new process needs to support that as well or better than the process it is replacing.

These are some of the most important issues that we needed to incorporate into our new process. In the next post in this series, we'll actually describe our new process and how it works. After that, we'll include some tips for implementing it on your project and some of the challenges that might come up.

• Read more about Ninjas, Zombies, and Tips for QA in Agile Web Development

About a year after I started at Intridea I went to a QA conference in Las Vegas. Up to that point I had only really done QA in an agile web development environment, and I remember being absolutely floored when I took a mental survey of the people I had been attending talks with and realized the following: 1) Most of them were involved in only one project at their jobs; 2) Most of them had entire MONTHS for testing between new releases and deploys; and 3) Many of them either hated or feared the developers of the software they were testing. I was taken aback! “SAYWHAAAA?” I uttered dramatically.

If the thought of “agile development” incites images of developer-ninjas leaping through the office in stretchy black attire, and squashing codebugs with their killer ninja stars, you’re wrong. Well, 1/2 wrong. Really, it just means you work on a much faster paced development cycle, which requires ninja-like devs!

Instead of having 3 months between deploys, you might have one week or even just three days; and working for a web development team means you’re working with 5+ projects at a time on that super schedule instead of just one. It can get pretty hectic and overwhelming, and you never run out of things that need to be done. You need to be in tune with your inner ninja. Here are a few tips for ensuring quality in an Agile environment (and coming out with your psyche intact):

Create a Wiki or Knowledgebase

When you’re working on 5 projects, and each project has a staging server, a dev server, and a production server in addition to multiple logins for each server, you’re going to have a lot of credentials to remember. Add to that each nuance of procedure for each project and even if you can commit that many usernames, passwords and procedures to memory, odds are, someone on the team will forget.

One day I realized that I was spending quite a bit of my day going into my notepad, and copying over some URL or login or procedure detail that someone on the team had questions about. I’d say I spend 50% less of my day answering those questions now that we have a wiki with info on every project we work on! When someone asks a question that’s covered in the project’s wiki I refer them to the URL that won’t just give them the answer to that question, it’ll tell them everything they need to know for the project! When there’s a change I update the wiki instead of emailing the changes to everyone. Every time I have new info, they have new info.

This level of transparency ensures that people can easily reference information, and everyone is working from the same set of facts and assumptions.

Relax!! No one is out to get you.

I think that as a group, QA engineers are cynical and suspicious by nature. Unfortunately, I’ve seen that cynicism cross over into paranoia that a particular developer has it in for you. They’re OBVIOUSLY bouncing this ticket back and forth with you because they enjoy wasting your time and watching you squirm, AND they block you with 500 errors while you test. Sneaky sneaky developers. If you sometimes find yourself thinking along the same lines, just remember: they’re thinking the same thing. Odds are they’re also really frustrated about a bug that they think they’re solving and you think they aren’t.

I think it’s important to keep in mind that at the end of the day you’re both trying to do the same thing: deliver a quality product to the client. When you’re elbow deep in ticketing and regression testing it’s hard to keep perspective, but the developers want to deliver a product they’re proud of just as much as you do. You’re on the same team, and you should make an effort to keep that in mind.

Take time to organize

Sometimes the best thing you can do for the QA project is “go dark” and turn your computer off for a few. When I need a plan of action I like to get out a pad of paper and pen (or colorful markers) and make lists. Sure you can make lists with your computer ON, but it’s important to eliminate distractions and really focus on what needs to get done. Email, Present.ly, IM, and Campfire notices create a huge distraction for me, and I’ll find myself looking down at my list saying “now where was I?” four or five times before I’m done. When you have lots of projects that all need QA hours, taking 20 minutes to focus only on scheduling will ensure you don’t forget anything; more importantly, it’ll ensure that you have a realistic idea of what kind of hours you have over the next few days which helps to eliminate accidental over-scheduling (A QA Manager’s nemesis).

Take a break when necessary

Zombies are no good at QA and are usually being used for some evil purpose! (the dictionary said so.) Avoid zombiedom by taking breaks. If you feel your eyes start to cross, or your blood pressure start to change drastically, or if that odd tick in your eye-cheek area comes back, TAKE A BREAK!

Take 5 minutes to look out the window (the other glowing square in your room), or take 10 to walk around the building (hire a dog to chase you if you lack motivation), or get a snack and a drink (screw carrots we’re talking chocolate), but whatever you do, don’t work as a zombie. You’re not doing anyone any favors, and your refreshed mind will get more work done in 45 minutes than your zombie mind would have done in 2 hours.

Be nice!

We’ll still have our moments, and as much as we try to stay zen and draw patterns of peace in the sand, you’re probably going to reach a point that you’d rather be strangling someone than pretty much anything else. Instead of using your caps lock for evil and commenting “STILL NOT FIXED TOM. please reassign to me when it’s FIXED AND READY FOR VERIFICATION. (read: do your job)” why not be nice? Why not say “Hmm…This seems to be a tricky one. I did a cache clear, reboot, and tried on 3 different computers, but I get the same error every time. These are the steps I take:” and then re-list each step you take, re-word what you did before, but add any details you think might be helpful. Sometimes I offer to schedule a time to re-create the error at a time that the dev can watch the logs as it happens, because in the end we all want the same thing (remember: THEY’RE ON YOUR TEAM!).

The agile environment demands a lot from developers and the QA team. It requires that you come into the process with a clear and focused mind, ready for organized and productive pandemonium. Luckily, I’ve been able to identify some ways to target and enhance my inner ninja, and hopefully these tips can help you in your own agile processes!

• Read more about Mobomo's RaceMate iPhone App for the 35th Annual Marine Corps Marathon

For those of you who enjoy marathon races, the Marine Corps Marathon (MCM) is one of the largest in the world. It is the eighth-largest in the world, fourth-largest in the U.S., and the largest such race with no prize money -- hence it's nickname, The People's Marathon. Past races have had participants from as many as 50 countries. At a course length of just over 26 miles, there's a lot for runners to prepare for and onlookers to track. Mobomo's new, first of its kind RaceMate(tm) mobile app is exactly what you need to enhance the MCM race-day experience. The app is available for the iPhone, iPod Touch,  iPad, and Android Phone.

RaceMate is packed with features, including a countdown timer, a course map, pre-viz animation, a pace calculator and more. The embedded marathon map not only shows landmarks such as aid stations, water & food spots and mile markers but actual GPS-based locations of race participants. Track your favorite runner in real-time.

Can't make it to the race? With an expected 30K runners and many more spectators, not everyone can or wants to be present. The Location-Based Services (LBS) mobile technology used in the RaceMate app means that you can cheer on and track your favorite runner on race day without being present. Both runners and spectators will need their smartphones; however, market research suggests nearly 85% of runners own a smart phone and that almost half of race participants will carry a smartphone will carry a smartphone during the marathon (MCM press release).

More info: The 35th Annual MCM takes place on Oct 31st, 2010, in Arlington, VA. The Marathon Tour starts Oct 20th and passes through several American cities on the way to Arlington. An associated free two-day Health and Fitness Expo starts Oct 29th and includes a Speaker Series as well as over 200 exhibitors. The marathon race itself is open to runners aged 14 and up. For more details, visit the following links:

• Marine Corps Marathon -- Official site. Will provide race split times and finisher data.
• Wikipedia -- MCM profile.
• Mobomo RaceMate mobile app for the iPhone. Only $1.99

The Android edition of RaceMate is now available at your favorite Android app marketplace.

Upcoming, Spring 2011: editions for other races in Los Angeles, London and Boston.

Need advice on how your business can leverage the mobile platform? Feel free to contact us to discuss your app idea or mobile campaign needs.

• Read more about Intridea Insider: Amelia Saletan

She began college coursework at the age of 15, practices the Brazilian art of capoeira, and started her career by organizing fundraising events for political campaigns. She's part of the virtual glue of our company. In this week's Intridea Insider, meet Amelia Saletan, one of our champion Executive Assistants.

Born and raised in "the little blue dot in the sea of red," Amelia shares the story of her novel upbringing in Austin, Texas; "I lived across the street from a middle school and two churches and never set foot in any of them." She was home-schooled by her progressive parents, a chemist and a polling consultant. Amelia's blend of homeschooling and unschooling was enriched with formal math classes taught by her mom, correspondence classes in middle school, soccer practices, acting classes, and then college coursework that she added to her schedule at the age of fifteen. Between classes, self-directed learning, part-time jobs, and time with friends, she also spent 2-3 hours of her day in a pre-professional ballet program.

In referencing being homeschooled in Texas, Amelia admits, "We got weird reactions when we told people we homeschooled; it was kind of funny for me to realize people thought I must be strange. It wasn't until I was a teenager that I realized people thought we must be religious fundamentalists! But there was a large community of homeschoolers in Austin, and very few of them (if any!) were doing it for religious reasons."

Amelia set off for American University in Washington, D.C. after taking additional classes at a community college, working and spending some time traveling in Europe. "I had applied to ten colleges because I really didn't know where I wanted to go. They varied, but were mostly smaller liberal arts colleges. I ended up coming to D.C. and I got my Bachelor's in International Studies." Although she stuck with International Studies, she admits that her true love was domestic political campaigns. "After my freshman year I got a summer internship and stayed in D.C. I continued to intern for political consultants the rest of my summers here. I think students in D.C. are a lot more professionally focused than in some other parts of the country. People are very concerned about getting jobs, internships, and building a resume." While she was certainly driven like her peers in D.C., she says that really, "I just loved what I was doing. And it was way more interesting than sitting around at home."

The internships she had with consultants helped to develop and sharpen her research and graphic design skills, which landed her a job on the finance staff of a state race in Mississipi after graduating from AU. "I spent six months organizing fundraising events across the state. We unseated a 30+ year incumbent in the primary, but we lost the general election." Afterward, a job in political fundraising consulting brought her back to the D.C. area.

She found her place at Intridea after seeing an ad on Craigslist for an executive assistant. "I applied, and thankfully I heard back! No one responds to applications anymore!" After a few phone interviews, she met Dave Naffis, co-founder and Senior Partner, and she was hired to help run the administrative side of Intridea. The work she does is always changing, and each day always brings something new, but you can count on talking to Amelia if you call Intridea. She answers the phones, enters info into our CRM, fields HR questions, manages paperwork for employees and the senior partners, processes expense forms, pays bills, works directly with our accountants, and a hundred other miscellaneous projects that come her way. Amelia puts her research skills to use by scouting for and then scheduling relevant events that Intrideans might be interested in attending.

Amelia often works directly with the Senior Partners, including Chris Selmer, who is always confident about Amelia's ability to manage the chaos that comes with her position: "Amelia is the consummate professional - whether handling pushy salespeople on the phone, overdue contractors in the office, or dealing with HR issues over email, we know she leaves a lasting positive impression of Intridea."

The majority of Intrideans are programmers and work from the comfort of our home offices, living rooms and porches. Amelia's job, however, is a bit harder to do strictly from home, so you'll usually find her in our D.C. office. "Although working with a distributed team can be challenging sometimes, I like the flexibility of being able to work from home occasionally. It definitely came in handy during Snowpocalypse. I miss being able to go right up to someone and get an answer if I need it right away, but I'm learning to anticipate things in advance and bring them up." Internal communication aids like our enterprise microblogging and collaboration application, Present.ly, help to bridge the physical gap between our distributed team by essentially putting us all in the same virtual "room". Present.ly, along with other communication tools like email, Skype, and Instant Messaging help to make Amelia's job a bit easier whenever she has to communicate with distributed Intrideans.

Although Amelia isn't a programmer, we still consider her a "geek" by our standards. When she was a teenager in Austin, she helped run an online text-based role-playing game, Redwall MUCK. "It was similar to a MUD or MUSH, but there were no levels, so you didn't have to spend time leveling up. The focus was on good writing, good characters, and good stories. That's when I developed an interest in 1) how you get people to follow rules, 2) writing how-to documentation, and 3) making things as easy as possible for oneself down the road. For example: Developing good processes and good documentation = fewer questions and snags down the road." Spoken like a programmer! In fact, my interview with Amelia leaves me wondering if she might ever dive into programming one day. "I have an interest. But I haven't gotten around to it. I'm not sure if it will make it off my list of 'things I'd love to learn' onto my list of 'things I'm putting in serious time to learn', but we'll see!"

Amelia probably won't stay in the D.C. area forever, but for now she enjoys living in her upper NW D.C. neighborhood, which she says is "kind of like living on the main street of a small town." She has quick access to groceries, dry cleaning, little restaurants and a tiny movie theater. She spends several evenings a week doing capoeira classes, which she describes as a fluid, Brazilian martial art:

Capoeira

Capoeira is a dance, a fight, and a game, as people say. Capoeira has groups, which are a little like gangs, sort of like the dance-fighting gangs from West Side Story. I am part of Oficina da Capoeira, which is based in Brazil and has a presence in many countries. We have classes at BETA Academy in Columbia Heights. There's also an Oficina group in Baltimore. We work on technique and different movements and sequences in class, but when you actually play capoeira you do so in a roda (circle). People take turns going into the center of the circle, two at a time, and playing. There are slow and fast games, games that emphasize floreios (flourishes or tricks), and games that emphasize more aggressive moves. The people making up the circle and watching the two in the middle clap, play instruments, and sing songs.

Amelia maintains a healthy work-life balance, between her busy days with Intridea and her active nights of martial arts with a network of friends she has established at capoeira classes. We think of Amelia as an Intridea "support beam." Her efforts fortify and prop us up, so we can focus on the mechanics of programming, project management, healthy client relationships, code quality, open-source contribution, and more.

Much more than your average executive assistant, Amelia is unique in that she understands the tech space, brings PR and graphic design experience, and is self-directed (a quality she attributes to her education back in Austin). Plus, she can hang with the geeks as well as any programmer can, so we can't help but love her.

This post is part of a weekly series, called "Intridea Insider"

• Read more about OmniAuth: Flexible, Unassuming Multi-Provider Authentication for Rack

The web application landscape has changed drastically in the past year or two. Where once every site was a silo unto itself and could reasonably expect users to create a unique login and password for each site, it is now a different story. I sigh every time I have to fill out yet another registration form, wishing instead for a simple "Connect with Facebook", "Sign in with Twitter", or "Log in with OpenID". At the same time, services are more interconnected than ever. One of the best ways to increase the popularity and viability of a new service is by piggybacking it onto the existing user bases of apps such as Twitter, Facebook, and Foursquare.

There are lots of authentication solutions out there for Rails. Many of them even have ways to connect to services such as Facebook or Twitter. But as I used these in project after project I noticed an emerging pattern: they all make too many assumptions about how I want to handle authentication in my application. Sure that makes it a quick start for the vanilla use case, but I honestly can't think of a time when I've dropped in an authentication solution and I was good to go. It's time for a change in perspective.

OmniAuth: The Unassuming Authentication Library

Today is the public release of OmniAuth. OmniAuth is a Rack-based authentication system that abstracts away the gritty, difficult parts of external authentication without assuming anything about what you actually want to do with that authentication information.

What does this mean for you? This means that you can make your app authenticate through Twitter, Facebook, LinkedIn, Google Apps, GitHub, Foursquare, and more and then have complete control from there.

Installation

OmniAuth is available as a gem:

gem install omniauth 

Diving In

Using OmniAuth is as simple as using any other Rack middleware. Of course, that's because OmniAuth is simply a Rack middleware. No complicated framework-specific configuration, just a collection of middleware to take the pain out of external authentication. Let's say I have a Sinatra app that I want to be able to authenticate via Twitter or Facebook. Here's what's required:

require 'omniauth' use Rack::Session::Cookie # OmniAuth requires sessions. use OmniAuth::Builder do   provider :twitter, "CONSUMER_KEY", "CONSUMER_SECRET"   provider :facebook, "APP_ID", "APP_SECRET" end

That's it! Now if I want to send my user to authenticate via Twitter, I send them to the URL /auth/twitter. For Facebook, /auth/facebook. The user will automatically be redirected to the appropriate site where they will be able to authenticate. Once authentication is complete, they will be redirected back to /auth/providername/callback and OmniAuth will automatically fill the omniauth.auth environment key with information about the user, so for my Sinatra client I just need to add:

get '/auth/:provider/callback' do   auth = request.env['omniauth.auth']   "Hello, #{auth['user_info']['name']}, you logged in via #{params['provider']}." end

Of course, I could do a lot more than just print out the user's name. I could also:

• Check for an existing user via the uid key of the auth hash and log them in if one exists.
• Create a user based on the uid and information from the user_info hash.
• If a user is already logged in, associate this new account with the user so that they can log in using either service or post to both services using respective APIs.

The point here is that OmniAuth doesn't assume that you simply want to log a user in. It lets you make that judgment call and gives you all the information you need to do just about anything you need to do.

OmniAuth works right now for a wide variety of providers, and this list will continue to grow. OmniAuth today supports:

• Facebook
• Twitter
• 37signals ID
• Foursquare
• LinkedIn
• GitHub
• OpenID (meaning Yahoo, Aol, Google, and many more)
• Google Apps (via OpenID)
• CAS (Central Authentication Service)
• LDAP

A Breath of Fresh Auth

OmniAuth has been my worst-kept secret library for some time now. I've been using it as the go-to authentication strategy for new projects big and small for the last few months, and it feels really refreshing to have so much control over authentication without losing the drop-in ease of use. If you need external authentication but have found existing solutions to lack flexibility, please take a look!

OmniAuth is on GitHub with a growing set of documentation on the GitHub wiki and I have also set up a Google Group to handle any questions that might arise.

• Read more about Intridea Insider: Tom Zeng

Mastermind behind TweetSentiments.com, programmer of many languages, and reformed Java guru, Tom Zeng is a powerhouse. He's the kind of programmer that every one wants on their team, and he's the focus of this week's Intridea Insider!

Born to two chemical factory workers, and raised in an industrial city in the Hunan province in China, Tom focused much of his energy on being a good student at the factory's school. "I don't remember too many details, except that since around junior high-school, I became very interested in studying the sciences and I stayed in the top 5 in my class until I got in college." After earning a B.A.Sc at a university in central China, he was accepted into a grad program in Canada, at the University of Waterloo.

In undergraduate school Tom took programming classes in BASIC and FORTRAN, but he was never enthusiastic about programming until he was exposed to some business apps in grad school which piqued his interest in database software. While he was earning his M.A.Sc, he developed his passion for computer programming. "I worked as a research assistant for my supervisor, developing software for sports - an electronic playbook. That was my first paying job. During the same time I developed a database application for storing stats for a professor at the nearby Wilfrid Laurier University."

Tom, now a Software Architect at Intridea, has spent most of his adult life programming in Java in the banking and ecommerce industries. As "enlightened" Ruby developers, we realize how stodgy that world must have been for Tom. So when he discovered Grails, and eventually Ruby and Rails, he did what most of us would expect any Ruby neophyte to do: he went to his (Java) development team and proselytized. "I was never able to rally enough support in the development team which was composed of all Java developers. No one wanted to learn a new language. So I ended up learning and playing with Rails on the side."

Tom's journey to Ruby from Java was bridged by Grails: "My previous employer was in the corporate risk management field. It was a niche market and had a constant revenue stream throughout the .com bust and the recession. However, being a small company in a competitive field, we always faced resource shortages, and our Java app started to get increasingly complex. Features were either promised and never delivered, or, delivered but behind schedule. So I had been looking for ways to improve productivity. I heard about Rails three years prior, but never bothered to try it because it wasn't Java. Then Groovy and Grails came along, and I saw the Grails' equivalent of the 5-min blog app and got really hooked on it."

Thanks to a pushy Ruby evangelist, Tom eventually found his way to Ruby, despite himself. "I was on the Groovy and Grails mailing list, and there was this guy named Charles Nutter who was one of JRuby's developers. Charles kept bashing Groovy and promoting JRuby/Rails, which was really annoying at the beginning, until one day I decided to check out Ruby and Rails; I was amazed by it and all the plugins that Grails didn't have."

Although Tom couldn't convince his company to transition to Ruby to help with their productivity predicament, he found ways to get intimate with this new language anyways. He taught himself Ruby and Ruby on Rails, and it was during this period that he developed Tweet Sentiments, an application that uses machine learning technologies to analyze the sentiments of tweets. The site shows the Tweet Index, a calculation of the positive, negative and neutral sentiments of tweets worldwide. Users can plug in their own Twitter username to analyze the sentiment of their own tweets, analyze particular topics, or view the sentiments of every one else's tweets.

Tom explains the internals:

Tweet Sentiments Tweet Sentiments uses a machine learning algorithm called Support Vector Machines, which is based on very complex mathematics. Luckily, one does not have to understand the math behind it in order to implement it. I came across the LIBSVM C++ library developed by a professor and his team from Taiwan National University. It's one of the most popular implementations of LIBSVM. I wrote a Ruby gem to allow Rails apps to make use of LIBSVM. Tweet Sentiments actually uses LIBLINEAR which is a special implementation of LIBSVM that can handle large data sets at a decent speed.

While Tom was toiling away in the Java enterprise machine, learning Ruby and Rails, and finding time to create Tweet Sentiments, he met Chris Selmer, Senior Partner at Intridea. Last year, when Intridea needed a talented Rails developer, Chris called Tom and offered him a job. I asked Tom what it was like, to finally work with Rails full-time; "I think it's kind of this sense of relief. Ruby and Rails is just so much fun to work with; there have been a lot of "wow moments" as I discover all the things that can be accomplished so simply (with Ruby) that are such headaches to do in Java. Working with Intridea is very refreshing - ideas and innovation are encouraged, rather than feared like they are in a Java shop because it would mean more work that cannot be accomplished. In a Java shop the developer mentality eventually becomes, 'do as little as possible.'

By that definition, Tom has proved himself to be quite the opposite of a Java developer; he is the quintessential Rubyist. Thadd Selden, a project manager at Intridea, has spent a lot of time working with Tom on a large project, and speaks highly of Tom's dedication: "Tom is the ultimate "anytime" engineer. If I'm stuck on something at 2:30 in the morning, chances are he's up and tinkering too and can help me out. I don't know how he survives on so little sleep, but he's bailed me out more than a few times." Also, as a truly passionate programmer, Tom always loves learning new technologies; "Right now I am enjoying learning NoSQL (MongoDB, Cassandra, Riak) and keeping an eye on Scala and Closure." He balances his work and technical hobbies with sports like rollerblading and biking.

Tom has settled down with his wife Jane and his 19 month-old son Luke in Ellicott City, MD, an historic community that is conveniently situated between Baltimore and DC. "I met Jane here in Maryland, but fate would have it that we were born 30 miles apart in China, and she went to a university in my home town. And here in Maryland, we worked a couple of miles from each other before we met." Jane works as a graphic designer in Annapolis, and their son Luke is one of the cutest babies you'll ever see. "He's so much fun. I always felt that I was not ready to have a child for many years, but I wish I had known that having a baby is so much fun." Ellicott City, MD is a far cry from the industrial city that he was raised in. Tom says that his hometown in China has been growing and changing throughout the last few years, but he's happy to be able to raise his son here in the states.

Most Intrideans love working from home and Tom is no exception. Being able to work from his basement office not only saves him from a daily 2 hour commute, it also allows him to use his HD projector as a monitor for his desktop. He likes working down there with his servers (he builds all his own machines); he's currently building a 48core 96GB and 12TB super-server for TweetSentiments.com.

We are incredibly lucky to have Tom as part of our team at Intridea. He brings a diverse collection of talents, along with a superlative personality to the team. We love him for his scrupulous programming skills and his infectious merriment.

• Read more about Alias Your Mom, and 4 Other Tips for Productive Development

As a software engineer, I'm like an over-caffeinated monkey for two reasons. First, much like most monkeys caffeinated or not, software development doesn't come naturally to me. I'm sure you're thinking, "How could that be?" I know. I know. I work for Intridea, which means I should be a rockstar ninja Ruby pirate with a double-rainbow tattoo, right? Wrong. This stuff is difficult for me which means I have to work really hard at it. Where some guys can play with a new technology over the weekend and come out with a firm and thorough understanding of it, I would need a week of working with it every day in order to achieve the same results.

And second, I'm easily distracted by shiny things, like internet video or sites with nothing but animated GIFs. Don't you dare send me that YouTube link before noon. This is a recipe for disaster, and I will let you know it by replying in ALL CAPS with lots of exclamations points at the end!!!!!

So, what do my monkey-like tendencies have to do with anything? Well, this means that I need to be as efficient and focused as possible to get the job done. Here are a few tips in no particular order that I use to help me get through my day:

1. Alias everything. Seriously, I would alias your mom if I thought it might actually save me a few keystrokes. If a command is either not that long but I use it every day, or long and tedious but I know I'll use it occasionally, then I'll alias it. And the vast majority of my aliases are only 2-3 characters. What's the point in an alias if it still takes you several seconds to type it out?
2. Vim. Fullscreen. You do use Vim, right? If not, you should. Nothing beats Vim, in fullscreen, on the biggest monitor you own. The benefits of Vim usage are two-fold, even as a novice user. Split-pane view, modal editing, and hundreds of plugins lead to serious productivity gains. Then there's the fullscreen mode, which I love. It hides everything else and lets you focus on just the code. There's no distracting menu bar, osx dock, or instant messenger windows.
3. Turn off notifications. I would say quit the apps entirely, but c'mon - let's be realistic. Just turn off the distracting notifications. That means growl notifications, dock icon badge counts, audio notifications (ding!), and anything else that might pull you away from what you're doing. Whatever it is, be it a Twitter reply, Campfire chat, or another email in your inbox, it can wait.
4. Quick docs. I have a horrible memory, so I look at documentation a lot. So instead of opening a new tab in a browser, then either searching or typing in a url, I keep a folder of links to API docs that I browse frequently. Then I have QuickSilver (any app launcher should work) scan this folder regularly so that I can quickly and easily pop open whatever docs I need, usually in 2-3 keystrokes.
5. Mobile browsing. I won't pretend like I'm 100% focused during the day. I take breaks and do my fair share of casual browsing, but when I do I try to force myself to browse on my iPhone. Sitting there, hunched over, staring at the little screen keeps me from getting too sucked in by anything.

There you have it. Five simple tips to help keep your inner monkey focused and productive.

• Read more about Mobomo's Leadership and Values: Entrepreneurial Core Values iPhone App

The Leadership and Values iPhone app, created by Mobomo for Concordia University, helps you determine what your core values are, discover what makes a leader. Do you have the core values and skills of a leader?

Leadership and Values offers a fun game-style interface as well as visual help screens to help you navigate your way through the app. Choose from the stack of 52 cards listing possible core values and drag each card into one of three columns: "Definite core value", "Maybe core value", and "Not core value." After you've grouped all 52 cards into the three columns, you can browse each stack to verify your choices or move them to another stack.

The next step is to select your top 5 core values. Edit your Top 5 stack until your satisfied. The Leadership and Values app then displays a beautiful screen quoting one famous or semi-famous person for each of the five core values that you selected.

This iPhone app is designed to promote core leadership values and enable students, teachers, and alumni to interactively discover their top leadership values. Using a fun step-by-step process, the user is educated on Concordia’s core leadership values, and is ultimately presented with a personalized result. This project demonstrates how Mobomo can create engaging mobile applications to educate individuals. Similar interfaces can be developed, for example, for FTC consumers to learn “how to” file a complaint or order a truly free credit report.

Get the Leadership and Values iPhone app free from iTunes or the Apple App Store now.

Need advice on a mobile app for your business? Just want to know how you can leverage the mobile platform in general? Feel free to contact us to discuss your app idea or mobile campaign needs.

• Read more about From Super Mario to Super Developers

Today, in honor of Nintendo's 121st birthday, and as an homage to their 8-bit NES console that shaped the gaming industry, Michael Bleigh has designed and released a commemorative 8-bit version of our website. Many of our developers at Intridea grew up playing video games in the 80's and 90's and recall the hundreds of hours they spent playing Nintendo games with great fondness.

In 1985, Nintendo released the Nintendo Entertainment System, known simply as the NES, and breathed life back into the recently dismantled video game industry in North America. The video game "crash" of 1983, in which the world discovered the mediocrity of the console game development industry, both soured and ripened the soil, ensuring Nintendo's fated success.

Although the big players (like Atari) in the console gaming market were sinking, Nintendo did encounter several challenges in entering the American market with the NES; as a result of the market crash, U.S. retailers had declared console gaming to be a fad that had run its course, and they didn't want to give shelf space to video games. In addition, gamers were disenchanted with console games after suffering through a montage of really bad titles from Atari, ColecoVision, Magnavox Odyssey and others. Nintendo would have to earn back the interest and the trust of gamers by delivering unquestionably addictive games. The biggest challenge Nintendo met was rising competition with the computer gaming industry, since the prices on Commodore computers had dropped significantly in 1982.

Despite the challenges that Nintendo faced in releasing their new console in the American market, the NES went on to be the best selling console of the 1980's, totaling 61.91 million sales, more than double the number of Atari 2600's that were sold. Nintendo continued making consoles, games, and handhelds, shaping Japan as the mecca of the world-wide gaming industry. Today, when we think of Nintendo, many of us are nostalgically pulled back into the eternally magical worlds of Mario, Zelda, Duck Hunt, and Donkey Kong. The Nintendo characters of these worlds are cross-cultural and cross-generational. But few people know that Nintendo was created 121 years ago by Fusajiro Yamauchi, as a producer of intricate and beautiful playing cards, called Hanafuda cards. The company was passed on through the Yamauchi family, and grew in different directions over the generations; it once dabbled in the instant rice business, and even had a chain of "Love Hotels", before Hiroshi Yamauchi met a maintenance man who inspired him to steer Nintendo into making toys. Later, he met an artist and designer, Shigeru Miyamoto, who would later create Super Mario Bros, one of the most popular video games in the industry.

It's common to hear developers talk about the video games they grew up playing as children. Through my research and personal experience, I'm finding that a side effect of the gaming surge of the 80's and 90's is that many bright, young kids were able to connect with technology in a meaningful and fun way. What resulted for many of them, was a desire to learn more about the hardware and software that fueled their entertainment. The gaming industry has given us many exceptional developers. A lot of programmers that I talk to tell me that their first encounters with programming were during their younger years, and say that it was gaming that initially got them interested in programming. Our Director of Mobile Development, Brendan Lim, says that gaming as a kid resulted in him becoming a programmer later in life.

Brendan Lim

As a kid, I played video games non-stop. Video games were also my incentive for doing well in school. I remember a deal I made with my mother in elementary school. If I got into the "gifted and talented" program, she would get me Super Mario Brothers 3. Needless to say, I got my copy of Super Mario Bros 3.

Around the time the Nintendo 64 came out, I would always read N64.com to check out video game news, game previews, and reviews. It was one of the first popular video game websites, and the first game network that ended up being part of IGN (Imagine Gaming Network). After my brother introduced me to basic HTML, I decided to try and create my own website called n64Xtreme. I provided a fairly constant stream of Nintendo 64 news. Once I realized that the public relation companies of video game publishers would offer review units to popular websites, I started reaching out to them and started getting new games to review all the time. Since I didn't know about making dynamic web pages yet, I decided to create a Visual Basic application to make the process of creating the HTML for these game reviews much quicker.

I later expanded onto multiple consoles with a new site I started, VGamers.com, which led to me learning more about HTML, CSS, and JavaScript. After a few months of doing VGamers.com, I was contacted by Gamers.com in 1999 to help with their site. I was 15 at the time and this was my first job where I earned decent money (especially for a kid). After Gamers.com, I spent a little time helping out with a game cheat codes site, GameSages, which has now been absorbed by IGN.

The more I worked for these sites, the more I had a chance to get hands on experience with web development. I even dabbled a bit with mod creation with Unreal Tournament and other PC games later in my childhood. All of this led to my interest in computer science and helped me get to where I am today.

Adam Bair, our Director of Development, was also led to the path of programming by spending much of his youth gaming. In his Insider interview back in June, he talked about how gaming sparked and drove his love for technology.

Adam Bair

I started gaming with text adventure games on BBS's (known as MUDs) and became obsessed with PC gaming when games like Wolfenstein and Doom were introduced. Back then, there was much leg-work to be done in order to support a hardcore gaming hobby. For example, I had to learn how my modem worked so I could play Doom with a friend by dialing into his modem directly over a phone line. I even replaced the telephone lines running to my house; I had to make sure I had the fastest, cleanest connection. The lines get fragile over time from exposure to the elements, and that can affect the speed and quality of the connection.

Today, someone can be a 'gamer' and not necessarily (or even likely) be a geek. But back then, you had to be a geek in order to be a gamer. Those were the 'good old days'. I would stay up all through the night, playing around with old Linux distros, reading about electronics, reading 2600 magazines, connecting to BBS's and gaming. I had to learn how to piece together multi-zip files, and how to run games in DOS. I remember spending hours playing Doom 1, Asteroids, Missile Command, and Mario Bros. When my Mom woke up at 5 in the morning for work, we'd have coffee together before I went to bed. It was all that gaming that turned me into a geek, and put me on the path to being a programmer.

Adam learned Ruby in 2005, and has been teaching classes on Ruby and Ruby on Rails intermittently for the last couple of years. Recently, he taught a class at Lone Star Ruby Conference, in which he live-coded a complete OpenGl Asteroids clone using Gosu, the 2d gaming library. Of all the classes that he has taught, this was by far his favorite. "We weren't writing another web application - we were building something fun, and the process was exciting. It was kind of like archaeology. We were digging into a classic arcade game to figure out how it worked, what math was involved, and how the graphics were done. It was interesting how something from my childhood could be so engaging on a different level as an adult. You can assume that most programmers today grew up playing classic arcade games, and Nintendo games. So in my class we weren't just connecting as programmers, we were connecting as gamers. With a game, you're trying to create "fun", and that's different to different people. By the end of the day, each student had their own twist on the game."

I set out in the Twitterverse to investigate the almost predictable relationship between being a programmer and being an avid childhood gamer. I talked to Ben Hamill, an Austin-based Rubyist, working at OtherInbox.

Ben Hamill

I started playing video games with the NES (like Mega Man 2 and Super Mario Bros.) and old school Mac games. It wasn't really until Jr. High and early high school that I started toying around with programming, but I feel like those early games instilled this idea that you could make a computer do what you wanted and that you could build systems that would behave by rules and it would be fun... or produce fun. I built an association between being bored and having a computer dispel the boredom. So I wrote the creatively named, "Guess The Number" on my TI-82 calculator when I was bored in Calculus. It kept a high scores list and everything. The language was a lot like what I've seen of BASIC. All GOTO and WHILE and such.

About that time, I got into MUSHing, which is basically text-based roleplaying over Telnet. The engine that the MUSH ran on included this Lispy scripting language. Lots of nested function calls(like(you, would), never(see(in, ruby))). I became intrigued with it because you could make commands on yourself for your own convenience and as I got better, I eventually got appointed as the coder guy. I ended up rewriting substantial portions of the most commonly used commands.

And THAT is the biggest tie, for me, between gaming and programming. There was a strong feedback loop between the two. I even started a few (never launched) MUSHes with other folks and wrote a mail/bulletin-board system that was fairly complex. It was, and I'm sure this isn't rare, more fun than playing the game at times.

My brother, Jared Hodgkins, is studying Computer Science at a local college in Maine. He says that he was inspired to learn programming at the age of 13 because, "I wanted to be able to make my own games that would make up for the flaws in the games I was already playing." There were times when he would pass out on the living room floor, NES controller still in his hand, after playing far too many hours of Mario when he was only 6 years old.

Sarah Frisk, a recent CS and English grad at Colby College, revealed, "Gaming actually did inspire me to become a programmer. It's partly why I'm an English & CS major - I want to make RPGs someday."

And Darcy Laycock, a web developer with the Frontier Group in Perth, Australia wrote to me about how his first encounters with programming were gaming related.

Darcy Laycock

My first introduction to programming was with Tim Sweeney's (of Epic Games) amazing application, ZZT. ZZT was a great application that let users visually build games (the graphics being all ANSI-character based) and then use a simple programming language, ZZT-OOP to build out the game.

I took the plunge and over a weekend or so I taught myself a little bit of ZZT-OOP and wrote my first game - The affectionately titled, "Destructo Guy" - a game about an awesome guy who basically destroyed stuff like his enemies. Of course, the game turned out horribly, but this didn't deter my young mind; I cracked down and wrote more and more and released better versions of the game.

Since then, I've learned a lot and have become a much better programmer. I'm currently in a university working on my degree in Computer Science, and working for a great company, whilst still being involved in lots and lots of open source stuff that can be found here and here. But the lessons I learned from ZZT got me hooked and have stuck with me ever since. It's really only because of games that I eventually learned programming (and don't even get me started on how Counter Strike Source got me started in web development!)

Of course, not every programmer was once a hard-core gamer. And not every gamer out there will become a programmer and level-up from their parent's basement. But there is an undeniable connection between programmers and gamers. The people I interviewed hinted at the source of that connection briefly. What I think it comes down to is the awakening that happens within the gamer at the point when he/she realizes that the power to create these systems of sheer fun is within their own reach. This moment of awakening spawns a young developer that will work tirelessly to learn the very system that they have enjoy manipulating with a controller. And because programming is inherently joyous, (it is almost intoxicating when you first realize that you can essentially create anything your mind desires out of nothing), those who have the capacity to absorb and understand the work of the programmer, generally go on to become blissful developers.

The rapid growth of both console and computer gaming in the last two decades has defined a generation of geeks. It wasn't long before the media caught on to the trend and our burgeoning geeks had access to tech channels like ZDTV, niche magazines, and a plethora of online resources to learn about anything related to technology. Although I am witnessing a growing obsession over intricate sandbox games like Dwarf Fortress and Minecraft amongst programmers, many developers I talked to are so absorbed in their work that they have difficulty finding time to play video games anymore. But developers like Brendan and Adam look back upon those gaming years with reverence; amidst their adolescent happiness, they found a way to learn a skill that would keep them both employable *and* happy.

So today, as Nintendo celebrates 121 years of awesomeness, we pay our respects to the gaming giant that pioneered the industry for our generation. We hum a little Mario tune, our thoughts turn all 8-bit for a moment, and we pay a moment of silent respect to our mums and dads for letting us play video games as kids.

• Read more about Ruby Intrigue at Lone Star Ruby Conf

At this year's Lone Star Ruby Conference, Intrideans Brendan, Pradeep, and Adam presented a full-day training, "Ruby Intrigue", in which they walked through the construction of three separate applications: a web crawler, an Asteroids clone, and an SMS server.

Web Crawler Pradeep live-coded four different versions of a web crawler using varying techniques including: single-threaded (crawly), threaded (thready), forking (forky), queuing (queuy), and event machine (eventy). Students followed along asking questions as they went. Once a crawler was complete an open discussion would happen regarding the benefits and drawbacks of the method in question.

Asteroids Clone Adam live-coded a full-blown OpenGL Asteroids clone using Gosu, the 2D gaming library, in just over two hours. Students followed along and successfully built their own versions written on Windows, Linux, and OS X. The clone implemented the player's ship, projectile, asteroids (of different sizes), collision detection, lives, levels, scores, and title/end game screens.

SMS Server Brendan discussed and live-coded different ways to setup a server to send SMS messages using his gem/plugin sms_fu. Though students were able to setup SMS servers, they also received a crash-course in gem publishing as they found a few bugs in sms_fu which resulted in new versions of the gem.

All of the code, labs, and lesson plans are available as open-source and can be found on Intridea's Github account. Adam has also extracted the Asteroids clone into a separate repository to include contributions, updates, and optimizations submitted from the class and can be found here.

As a bonus, the attendees of our class received a custom vintage LSRC shirt, printed on Alternative Apparel shirts and designed by David Potsiadlo. These t-shirts were a huge hit and we'd like to thank A.B. Tees for their quality shirts!

This was the third year in a row that we have had a team of developers teaching a Ruby class at Lone Star. Every year we have a great time connecting with Ruby developers from the local Austin area and beyond. Many thanks to the Lone Star team for organizing this annual conference and all the hard work that goes in to making happen!