I've never read Amazon's Dynamo paper. I've also never had the opportunity to work with Cassandra or SimpleDB, but when Amazon announced DynamoDB I thought it was time to take a little bit of time to learn what it was just in case it was super-useful. I thought I'd share a few of my findings.

Disclaimer: I'm completely new to this style of NoSQL system and may well in fact be misusing it in places. Feel free to give me some free education if I'm doing something horrendous below.

For prototyping a new webapp, I like to get an HTML prototype on screen as fast as possible. There are a number of ways to achieve this, ranging from the heavyweight Rails, to the lightweight Sinatra. But even a barebones Sinatra app requires you to specify routes and layouts. When I'm focused on sketching out the markup structure and design, what I'm looking for is less distractions from setup. Theoretically, one could prototype everything with raw static HTML, but most designs usually share layouts and snippets that would be a pain to copy and paste between different files. Writing raw CSS is also possible, but once you've gotten a taste of Sass and Compass extensions, why would you want to? In this post I'll outline my bottoms up approach to getting a site design bootstrapped. I'll also cover how to get these prototypes up in a public area for feedback, and how these prototypes can be used as scaffolding alongside your development.

You may have heard about two pieces of legislation recently: the Stop Online Piracy Act (SOPA) or the Protect IP Act (PIPA). These bills are dangerous both to the rights to freedom of speech of our citizenry and to the fabric of the internet itself. While SOPA has been "shelved" for now it could always be brought back to life and PIPA, it's Senate counterpart, is still very much alive and may soon come to a vote. At Intridea we strongly oppose these bills and as such today we are announcing that we will be joining the one-day blackout tomorrow.

Unit tests should pass when run in random order. But for an existing legacy project, certain tests might depend on the execution order. One test might run perfectly fine by itself, but fail miserably when run after another test. Rather than running different combinations manually, RSpec 2.8 has the option to run specs in random order with the --order random flag. But even with this, it can be hard to determine which specific test is causing the dependency. For example:

2012 is here and Intrideans celebrated the end of one year and the beginning of another across the world - in Shanghai, NYC, DC, San Francisco, Italy, and places in between.

We could write a customary "year in review" post detailing the various milestones we met in 2011; how Inc 500 rated us as the 33rd fastest growing privately-held software company in the country; or we could talk about the explosive growth of our team and how we penetrated the enterprise software market with a new suite of enterprise collaboration tools. Or we could talk about how our talented design team has been racking up awards all year.

But we won't do that. Because although we're incredibly proud of our growth and achievements in 2011 and would love the chance to rant on about them we realize that you've probably already heard enough about them. So instead we're going to look 2012 directly in the eyes and and share with you what we see:

What do you do when you cannot start a new server session because the address is already in use? It happens to the best of us, such as this morning when I exited my terminal without first quitting the rails server. I found myself faced with this error in my new terminal when trying to spool up a localhost:

I've been following the progress of Mozilla's BrowserID for some time now, and I'm a big fan. Having dove much deeper than most into the quagmire of fragmented authentication I've reached the same conclusion that Mozilla has: ultimately, authentication is a function that should belong to the user agent.

A few weeks ago I joined the Intridea team. I knew enough about Intridea through various conversations at meet-ups to know that I would be joining an incredible team of designers, developers and innovators. I was excited about what this new chapter would bring to my life.

At Intridea everyone works remotely, so I knew my office would be right around the corner (in the next room). If I thought I might miss those friendly water cooler talks, I was mistaken. On the first day our Director of UX Jurgen and I had a Skype date. We talked for nearly two hours about everything Intridea-related, from regular administrative duties to our Friday afternoon Design Meetings, to our design processes and current projects. It was a good start to my first day at Intridea. Having Jurgen there to get me primed was a huge help and a great ice breaker for me.

Metro areas generally have really active user groups where Rails_Awesome_Lord presents regularly, famous hackers drop in to give presentations, and the Rails Elite throw smashing parties and drinkups after each meeting. But not all developers live in (or near) metro areas and can partake in such festivities. If you're among the rural band of outlaw programmers, this post is for you.

It doesn't matter if data is being migrated from SQL to NoSQL, from flat files to key-value store, or from XML to an object database, or every permutation of any data store to any other data store. What stays constant is the fact that data migrations are scary and painful. Without the right strategy, a big data migration will leave you with inconsistent data, strange errors, and very angry users. Read on for a data migration checklist that'll save you days of headache.

Pick any popular open source library. It'll have more documentation than your application code - I guarantee it. Test and documentation are both acknowledged as good development practices. But unlike testing, documentation doesn't get the same love from developers. For code that isn't intended for a public audience, developers keep all the docs in their head, or assume that their code is self documenting. Additionally, the tests become a kind of runnable documentation. But there's several lessons we can apply to our private application code from open source documentation. Today, we'll start the conversation with the lowest hanging fruits - the README.

Rails. No, really.

The future of web and mobile design is in Rails, Sinatra, Django, and other RESTful web frameworks that can be used to leverage design power across multiple platforms, making it easier and faster (translate: more economical) to design for web, mobile and desktop.

Our UI/UX team was stationed up in NYC for the Future of Web Design conference last week and we were able to chat with some really awesome folks who had innovative and inspiring ideas about web design.

As a new developer to Ruby you might wonder how certain methods seem to be magically available without being strictly defined. Rails's dynamic finders (e.g. find_by_name) are one example of this kind of magic. It's very simple to implement magic such as this in Ruby, but it's also easy to implement things in a way that doesn't entirely mesh with standard Ruby object expectations.

November is shaping up to be one of our busiest months for events. This week our design team is in NYC for The Future of Web Design; Ted O'Meara will be in Baltimore next weekend to support Education Hack Day; Michael Bleigh just landed in NYC after presenting at Ruby Midwest, and he, along with all the Senior Partners, will be jetting off to China in two days to meet the Intridea East team in Shanghai for RubyConfChina and then to HangZhou to attend the first Intridea East retreat.