Background

As a Rails developer I normally spend most of my time on backend development, implementing features and functionalities. I am really confident about my Rails skills for backend work but rarely have I felt any happiness doing frontend work before. But things have changed since working on the new responsive intridea.com. I started some interesting frontend work from this project and fell in love with many UI skills and JS tricks, especially Pjax which I want to talk more about in this post.

I'm a huge fan of Heroku. I mean I'm a huge fan of Heroku. Their platform is much closer to exactly how I would want things to work than I ever thought I would get. However in the past few weeks Heroku has had a number of serious outages...enough to the point where I started thinking that maybe we needed to start working out a backup plan for when our various Heroku-hosted applications were down. That's when I realized a big problem, and it's not just a problem with Heroku but with any Platform-as-a-Service.

Creating a more beautiful web, one application at a time.

Our website has always been more than just a sales tool for displaying our services. As a web development and design company our website is our brand; it embodies the essence of who we are: our values, our culture, and our discipline.

We don't take a redesign lightly; when we approach the task of a redesign we begin with long, thoughtful discussions about our company, our image, where we're going, and what we want to communicate about ourselves to the rest of the world. Our website has to exemplify our passion for elegant and functional design, quality code, collaborative work, and our obsession with emerging technologies.

Who is old enough to ride the big kid rides at the carnival? Us! That's right, we turn 5 this month and to celebrate we're getting a facelift; you're going to love our new site! But first thing's first - a birthday toast to honor our past and celebrate our future.

In the Beginning

In the beginning there was a single idea: build a different kind of web development company. Co-founder Dave Naffis partnered with like-minded DC developers to execute on this vision and together they created Intridea, a unique and agile software design company.

The co-founders had a few ideas they kicked off with:

Last weekend I participated in the first Hack the Midwest, a 24-hour hackathon in Kansas City. I was very impressed by the event: nearly 100 developers from the Kansas City area participated with tons of API sponsors and great prizes. I decided to go it alone and throw my hat into the ring with an idea that I had been thinking of for a while: what if there were email alerts for Netflix Instant? 24 hours later, the result was Qup.tv.

Rails views are typically rendered after some controller action is executed. But the code that powers Rails controllers is flexible and extensible enough to create custom rendering objects that can reuse views and helpers, but live outside of web request processing. In this post, I'll cover what a Rails controller is and what it's composed of. I'll also go over how to extend it to create your own custom renderers, and show an example of how you can render views in your background jobs and push the results to your frontend.

I really like using MongoDB and Mongoid, but a while back I ran into some shortcomings with querying timestamps. The problem was that I wanted to query only part of a timestamp, such as the day, week or year. So for example, let's say we need to find all users that signed up on a Wednesday.

In SQL there are date functions that let you to parse dates inside your query (although they seem to vary between engines). So in Postgres, you could do something like this:

If you're running any kind of service that uses e-mail as a communication method (which is just about everyone) and you want your users to be able to take some kind of action from the email (as just about everyone does) then you should be using Signed Idempotent Action Links. Now I know what you're thinking, "Signed Idempotent Action Links? But EVERYONE knows what those are!". I know, but here's a refresher anyway (ok so I made up the term, but it's descriptive!).

This past weekend I participated in Hack the Midwest, a Kansas City hackathon. The event was a huge success drawing a crowd of around 100 developers. As one of the visiting developer evangelists said, it was a great turnout for a New York hackathon, much less one in the midwest.

At the competition I built Qup.tv, a simple service that will send you email alerts when Netflix adds new titles to its streaming catalog. I was lucky enough to win top honors at the event, but this wasn't my first rodeo. With three Rails Rumbles, two Node Knockouts, and a Startup Weekend under my belt I'm beginning to get a sense of what works and what doesn't. So here's my list of things to keep in mind when competing in a hackathon: