• Read more about We Stand With The Internet

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.

Intridea's website and blog will be unavailable tomorrow between the hours of 8am and 8pm Eastern time during which time a simple message will be displayed declaring our position and urging visitors to learn more and take action.

Of course, we're also software developers, so our preferred method of protest will be enacted through an open source Rack middleware called "Censorstrike." If you run a site using Ruby and would like to join the protest, you can learn how on Censorstrike's GitHub page.

SOPA and PIPA stand to threaten the amazing, open internet that has given us the chance to succeed as a business and is the lifeblood of our company as well as that of our clients. We urge you to take action in any way you can to prevent these bills from becoming law.

• Read more about Hunting Down Execution Order Test Failures

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:

     rspec spec/controllers  # succeeds     rspec spec/lib/my_lib_spec.rb  # succeeds     rspec spec/controllers spec/lib/my_lib_spec.rb  # fails 

In this scenario you know that one of the spec files in spec/controllers is not jiving with your lib spec, but if you have hundreds of spec files, it's hard to tell which. Never fear! There's a Ruby one-liner for that:

     ls spec/controllers/*.rb | ruby -pe '$_=`rspec #{$_} spec/lib/my_lib_spec.rb`' 

Let's break this command down into its components:

     ls spec/controllers/*.rb 

gives you a list of spec files to run alongside your lib spec

     ruby -pe 

'e' for execute, and 'p' means wrap the code in a loop and assign each line of STDIN to $_. We're piping in STDIN from the ls command.

     $_=`rspec #{$_} spec/lib/my_lib_spec.rb 

The 'p' flag also prints out the value of $_ at the end of each loop. So we assign the output of running rspec with the 2 files (one from ls alongside my_lib_spec).

My bash buddies would wag their fingers at me for using a ruby one-liner here, but it's a familiar syntax and it's easier for me than remembering other shell commands and regex flags. If there's something another unix program is better at processing, then I can then take the output of the ruby one-liner and pipe it into another command. It's a very simple and versatile way to munge on text.

• Read more about Looking Ahead: 2012 at Intridea

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, how we penetrated the enterprise software market with a new suite of enterprise collaboration tools and the design awards our talented UX team won throughout the year for our site design.

But we won't do that. 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:

• A Growing Family - We definitely have our work cut out for us; as our reputation for delivering quality, innovative applications for clients has grown, so has the demand for our services. Thus, in 2012 we'll be focusing on bringing more remarkable, driven and diligent designers and developers to the Intridea team. To our advantage, we can look in every city (and country) for the right people. With that in mind, if you think your presence on our team would be mutually beneficial, consider applying to work with us!
• Upgrades - In early 2012 we'll be releasing an interactive community section of Intridea.com, designed to keep our readers up to date on all the events in which we are attending or presenting, provide open source training documents and slides from presentations, give news and updates on our open source contributions, and more.
• Open Source - We ramped up our open source work in 2011 with Omniauth, RefactorMyCode, Grape, Hashie, and our financial support of other projects like Pry - a full-featured alternative to the IRB shell for Ruby. In 2012 our team will be focusing on maintaining these existing open source projects as well as making time to create new open source gems and plugins from the code we're writing for upcoming projects.
• Maturation - As Intridea enters its fifth year we'll be fine-tuning our internal processes, optimizing our development methodologies, and identifying the areas in which we can improve. We'll be implementing an ongoing cross-training program between developers and designers. 2012 will be a Wonderland in which designers learn the basics of Rails and developers learn the tenets of good design, for the purpose of increasing the depth and complexity of everyone's talents, leading to more well-designed and well-architected applications.

Of course you'll also be seeing us at the usual round of events, presenting at conferences, hosting and supporting user groups around the country, and sharing our technical knowledge with you via our blog. We're looking forward to all that the coming year holds.

As our Intridea East members would say, ???? (Happy New Year)!

• Read more about How to Find and Kill a Rogue Server Process

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:

 ? ./script/server => Booting WEBrick => Rails 2.3.11 application starting on http://0.0.0.0:3000 => Call with -d to detach => Ctrl-C to shutdown server [2011-12-22 11:41:15] INFO  WEBrick 1.3.1 [2011-12-22 11:41:15] INFO  ruby 1.8.7 (2011-02-18) [i686-darwin10.7.0] [2011-12-22 11:41:15] WARN  TCPServer Error: Address already in use - bind(2) Exiting

I Googled around for some information, but ultimately Paul was able to troubleshoot my issue over corp chat. Here’s the solution that worked:

Enter this into the terminal:

 lsof -i TCP:3000

It will yield a result that might look something like this:

 renaebair@siren ~/workspace/intridea/newsite (master)  ? lsof -i TCP:3000 COMMAND  PID   USER       FD     TYPE     DEVICE     SIZE/OFF    NODE   NAME ruby   68780   renaebair   6u    IPv4     0x10898278     0t0      TCP     *:hbci (LISTEN)

Grab the process number (a.k.a. PID) (in this case it was 68780) and then type “kill #{that_pid}”:

 kill 68780

Then try restarting your server and all should be well!

Paul here with a few quick words about what’s going on in this case:
When Renae closed her terminal session with the rails server still running, the server process became orphaned. It was still active and serving pages on localhost:3000, but without a controlling terminal window, Renae was not sure how to stop it. Also, because it was bound to port 3000 it prevented a new rails server from starting on the same port. The lsof command is used to list open files, in this case the pseudo-file for tcp port 3000. (It can also be used to figure out what processes are logging to a file lsof log/development.log. This is sometimes useful when a plugin is writing to the rails log instead of its own log file.)

Once we have the PID for Renae’s orphaned process, we can send a signal to it, telling it to close itself. The kill command is the mechanism for sending that signal. To be polite, we first send a TERM signal, which roughly means, “Would you please finish up what you’re doing and close, dearie?” If that doesn’t work in a reasonable time, we can send a KILL signal (side note: I find it unfortunate that the signal and the command share a name, but that precedent is older than I am) kill -9 some_pid which translates to “KILL IT WITH FIRE”. As in real life, being less polite may result in needing to handle some cleanup yourself.

There is a slightly easier option. If we suspect that port 3000 is bound to a rogue rails process, you can use the killall command as a more “shotgun” approach. But what fun is that?

• Read more about Announcing OmniAuth BrowserID

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.

What is BrowserID?

BrowserID is a Single Sign-on service for the web, much like you can implement using OpenID or even Facebook or Twitter. However, BrowserID is fantastic for its simplicity: as an implementation of a simple "verified email" protocol, it is simply a way to be able to obtain the email of a user (and know that it's verified).

For now, this works via a Javascript authentication flow on a website that Mozilla is maintaining. However, the future of this technology is that you would verify your email directly within your browser and would then be able to sign in to supported websites using your browser itself.

But, you ask, why do we want authentication in the browser? Browsers are called User Agents for a reason: they are simply tools that help connect you to the content of the internet that interests you. And a lot of that content right now requires you to manage dozens of different passwords and store sensitive login information with a third party. BrowserID doesn't entirely solve this problem in its nascent web-based form, but once it is integrated into the browser itself BrowserID becomes a single, secure way to access content on the internet.

BrowserID + OmniAuth

I want BrowserID to succeed, and it will only succeed if people start using it. To that end, I've created OmniAuth BrowserID, a simple OmniAuth strategy that works with the BrowserID protocol. You can use it in your application like this:

# in Gemfile gem 'omniauth-browserid'  # in application use OmniAuth::Builder do   provider :browser_id end 

That's it! Now send your users to /auth/browser_id and they will be able to sign in using the BrowserID service. Of course you may prefer to implement your own Javascript flow. That's fine, too, just take a look at the project README for more information about customizing the flow.

BrowserID is an important idea and whether Mozilla's implementation is ultimately the one that gets adopted it's high time we started moving authentication to where it belongs: in the user agent.

• Read more about On Becoming an Intridean

A few weeks ago I joined the Intridea team; I knew enough about Intridea through various conversations at local 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 my new office was right around the corner (in the next room). If I thought I might miss those friendly water cooler talks, I was mistaken. On my first day our managing 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.

That day I was inundated with messages from other Intrideans welcoming me to the team. Many of them asked questions about my past, about my design process, my hobbies, etc. We delved into deeper conversations about progressive web technologies and design methodologies. What I learned immediately was that there is no shortage of communication on this team, despite being distributed. We have many outlets to communicate with each other, one of which we built in house called Socialspring, an internal social enterprise platform to connect you with your coworkers.

I was new to Ruby on Rails and git but my team members took time out of their schedules to help me one-on-one to get projects setup, and even gave a couple quick lessons on git and Ruby so that I would be able to work faster in the future. I was amazed at this, since I was admittedly a little nervous about how I would get up and running as a new Intridean. But the process was so simple and my co-workers made me feel welcome.

My second observation as a new Intridean was that this team is all about helping out and doing things right from the start; they understand that taking the time to pay attention to the details and do things right sets us all up for success. They make sure that everyone on the team has enough support to get the job done. Each week we communicate about team resources and discus whether we feel we need to spend more time on something else or whether we need additional resources to get a task completed. Our project managers and team leaders are adept at communicating with their developers and designers and understanding the resources, limitations, blockers, etc across all of the projects.

After my first two months here I can say that Intridea is focused on creating great products, while enabling their developers and designers to succeed and feel challenged. I am happy to have joined this team of smart, hard working individuals who want to see their company succeed.

• Read more about City Programmer, Country Programmer - Building Rural User Groups

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.

Portland, Maine isn't a tech hotbed by any means and when Adam Bair and I took over our small Ruby User Group after the last coordinator moved to NYC we were pretty sure that garnering attendance and participation would prove difficult in our area. However, to our surprise it wasn't hard at all. In fact, we found that Maine had a scattered yet hardcore group of programmers, each looking to find other programmers. We meet monthly and the size of our group fluctuates from 6-15 people depending on the month. We do very little outreach aside from Twitter announcements and messages to the Google Group. So what's the secret? How do you call the mavericks out of their programming caves and get them to join you?

Here are some tips for getting your own user group started, even if your village is but wee and agrarian:

1. Location - We host the user group right at our house. Since we already have all the necessary hardware (laptops, HDMI cables for hooking laptops up to the TV, seating, etc) it's convenient to just host everyone at our place once a month. It's much easier than lugging a bunch of equipment around, negotiating with companies to use their space, setting up equipment and so forth). Additionally, people tend to feel more relaxed in a house-setting which leads to more in-depth conversations, knowledge-sharing and time spent together.
2. Money - If you're hosting the user group in your own space (or in another free/low-cost charge space) you won't need a lot of financial support. It's worth asking your own employer if they would be willing to sponsor the event with pizza and drinks in return for handing out a few stickers and mentioning their support. Intridea sponsors our small group each month (along with several others) with pizza and drinks! If your employer can't help you out chances are that another member's employer might be willing to help you in exchange for some promotion.
3. Content - Herein lies the challenge that most user group coordinators are faced with! It can be cumbersome to come up with good presentations every month. Here are a few ideas:

• Presentations are not necessary for a rural user group. In fact, many of your members might dread public speaking and would probably appreciate a more casual format to the meetings until you all get to know each other better. Instead of official presentations, consider volunteering to show off some code you've been working on to the group. Afterward, it's likely that someone else will feel inclined to show some code as well. If the members can trust each other to be low-key (who wants to feel like they're going to work at the office when they go to a user group?) then everyone will end up sharing more information in the long run.
• If you do offer a presentation, keep in mind that it doesn't need to last 60 minutes, nor does it need to be delivered to the group as though you were presenting at RailsConf (unless of course, you are presenting at RailsConf and need somewhere to practice!). If you just want to run through some new code you've been working on and that takes 20 minutes, that's ok. If you want to put together a presentation on CoffeeScript, keep it light and engaging. Programmers just enjoy getting together to talk shop with each other. If we don't have anything officially prepared for the group then we'll open up the floor to people that want to show off some code.
• Ask other members to give presentations - if you hear that one of your members has been learning Backbone.js for a new project at work then ask him to present at the next meeting.
• It's beneficial to maintain a good relationship with other local/nearby user groups. Often our Portland members will caravan down to the New Hampshire and Boston Ruby User Groups if we don't have any concrete plans for our own group that month. This way, our members are still getting together and talking about programming.
• Twitter is your friend - Make sure you follow local (and local-ish) devs. If you catch wind that one of them is coming close to your town exercise those social skills and reach out to them - invite them to speak at your user group while they're in town! We've been fortunate to have generous programmers from the New Hampshire and Boston area who have travelled to give presentations to our group in Portland.
• Burn Out - If you start to feel burnt out, rather than let the user group die off, reach out to another regular member and ask for some help. There's no shame in taking a sabbatical!

With all of those tips in mind, there's also one more important thing to remember: a user group is a community. It takes a little bit of time and effort to build it, but once you've done that work it comes with all the benefits of any other close-knit community. If the community is cared for then it can become a tremendous resource to all of its members for anything from code advice, job hunting and mentoring to board game partners and craft beer enthusiasts.

If your area is lacking a user group, step up and host one; people will be thankful that you did! A house, a laptop, and a few conversations on Twitter is all you really need to get started. And maybe a year from now you'll be able to look around you and see a strong community of programmers gathered together, sharing stories, strategies, and experiences.

• Read more about Planning a Big Data Migration

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.

Backup

Before even considering a massive destructive mutation of your data, you should have working backups. The keyword is "working". Take production dumps of your data, and make sure you can load the same data on a cloned environment. If anything goes wrong when migration day comes along, these backups will be your last line of defense. Backups are also useful for doing practice runs of a migration.

Logging

Create a logger that logs to a separate place from your application logs that's specific for the migration. When the migration is running, the logger should warn on strange data and error on exceptional cases. To keep the log useful, it's important not to flood it with debugging information. Log only the most important details needed for troubleshooting problems: a timestamp, an id reference to the failing record, and a brief description of the failure reason.

Atomicity

Regardless of whether the destination data store supports transactions or not, the migration should always define an invariant for when a record is successfully imported. If this invariant is broken, then whatever has been done to break the invariant should be undone so that your data isn't in some zombie half consistent state.

Idempotence

Not strictly the definition of idempotence, but similar to maintaining consistency, your code should be able to handle re-migrating the same data. If the migration crashes halfway, having this property allows you restart and import again without worrying about weird state issues.

Batch Processing

Having atomicity and idempotence lets your migration be split up into smaller migrations. Instead of migrating a million records in an all-or-nothing migration and crossing your fingers, you can split them up into small 500 record batches. If any single batch fails, you can redo just that single batch, rather than redo the entire migration. This also allows you to balance the migration across more resources like multiprocessors, different servers, and different slave databases.

Validation

After a migration is complete, it's important to be able to validate that everything is still working. This means running your test suite, your integration tests, and also logging in as existing users and clicking around.

Live Migrations

Running a migration with scheduled downtime is hard enough as it is, but in certain applications, a big chunk of downtime is unacceptable. If this is the case, then it's critical to add bookkeeping code that tracks which records has been migrated and which haven't. This allows you to query and incrementally upgrade parts of your system while co-existing with old data and old code.

Plan Ahead

Data migrations will always be a chore. But with the right strategy, at least it'll be one that can be finished, rather than something that drags along and repeatedly slows down your whole team.

• Read more about PROJECT README, Y U NO HAVE?

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.

The lack of a good README is one of my major pet peeves. When starting on a new project, more often than not, I'll find myself staring at this README:

== Welcome to Rails  Rails is a web-application framework that includes everything needed to create database-backed web applications according to the Model-View-Control pattern. 

That's a fantastic README introduction... for the Rails framework. But it also happens to be the default scaffold README for every new Rails project. Think of a README as a first impression of your project. Just like open source projects, your README should introduce the project the new developers.

Take 5 minutes of your time to write a README that explains the following things:

What is it?

A short elevator pitch about your application. Examples:

• Travis is an attempt to create an open-source, distributed build system for the Ruby community that allows open-source projects to register their repository and have their test-suites run on demand...
• YARD is a documentation generation tool for the Ruby programming language. It enables the user to generate consistent, usable documentation that can be exported to a number of formats very easily, and also supports extending for custom Ruby constructs such as custom class level definitions.
• Spree is a complete open source commerce solution for Ruby on Rails. It was originally developed by Sean Schofield and is now maintained by a dedicated core team. You can find out more about by visiting the Spree e-commerce project page.

How do I set it up?

List any dependencies your project has, both libraries it depends on, as well as external services it uses. Also remember to include any commands to start required services. Example:

Development Setup  # install redis, mysql brew install redis brew install mysql  # install rvm: http://beginrescueend.com/rvm/install/  # within the project directory bundle rake db:setup foreman start # visit: http://localhost:3000 

Project Workflow and Tips

Usually, I like to add an additional section for developers to add tips and tricks that help with their day to day workflow. The notes listed in this section are optional and individual developers can choose to use them or not.

Seed and Test Data

Often times, existing developers and stakeholders will have their environments configured and won't remember what seed data the system assumes to exist. Versioning a gzip dump of the test data is perfect for someone to come along and get a sense of what the app data looks like.

Who do I contact for help?

If the project is a client project, it's good to list the stakeholders and their roles. It's also a good place to put down the names and contact information for members who may have worked on the project in the past.

Relevant links

A list of links to other sources of documentation or project management tools.

• bug tracker
• comps, wireframes, and design prototypes
• wikis
• staging, qa environments
• other servers

Having a good README can help you onboard developers faster and have a single starting point for your project. It's easy and fast to write, so go forth and write yours today!

• Read more about What's the Real Future of Web and Mobile Design?

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.

The atmosphere of FOWD was energetic and there were a lot familiar buzzwords being tossed around; “Mobile”, “responsive”, and “HTML5”, were the most prominent. I did hear two presenters (Steve Fisher and Josh Clark) talk briefly about content manipulation and APIs, but I was surprised I didn’t hear more on this topic.

When I took time before FOWD to consider what my own vision of the future of web (and mobile) design was I immediately thought of Rails and other RESTful APIs. In fact, the future of design is tied closely with the future of web development. More and more companies are demanding robust, scalable web applications that have the functionality to manipulate and generate content. And they don’t need just one application, they need several: a desktop app, a web app, an Android app, an iOS app, etc. And yes, they want those applications to be aesthetic and intuitive, but gone are the days when a business needs just a static, well-designed page to reach and engage their audience.

Using a RESTful API for design makes perfect sense. Let’s manipulate data in one defined way, but allow that action to take place over any platform. Obviously an HTML view is not always going to be the perfect experience for every platform, but in using a RESTful API all you have to care about is a connection to transfer data. You can swap out the HTML views for a native iOS or Android interface, and then you just have to think about the data transfer.

And isn’t that what we need with any application that deals with time-sensitive content? New York Times is on board with this idea (developer.nytimes.com), as is Facebook (open graph). As web designers we need to think about how to build our own APIs for our applications so we can more easily and more fluidly design corresponding mobile (and desktop, etc) applications.

But how does Rails play into this? Most people think of Rails as just a means for developing web applications; but what about that RESTful architecture that it’s built on top of? It’s perfect for extending mobile apps as well. You can easily use Rails as an underlying method for serving up CSS and styles for multiple platforms. Why not let Rails be the foundation for web and mobile design? When it comes down to it, Rails is an API right out of the box. You just need to style it as one.