From the Dev Couch: Redwood, Backbone, and Capfire

by Dan DeMeyere - @dandemeyere

Apps to Improve your Workflow

App: Redwood

I'm about to gush: <earmuffs> this app is fucking awesome </earmuffs>. I hate searching for things - it's a complete waste of time. A while back I installed Alfred App to allow me to 'jump' straight to launching an application after hitting a hot key and it's a huge time saver (not to mention I never have to organize my application folder again). So Alfred is for your apps, but what about for all your files? Enter Redwood.

If you're like me, you have emails, messages, and attachments scattered throughout Gmail, Basecamp, and Dropbox. Only Dropbox is mounted locally and I use Thunderbird for my mail needs so I have to log into Gmail to search and I just pray that I'm searching on the right Gmail account. Redwood is a local app that allows you to add Gmail, Basecamp, PivotalTracker, and Google Docs accounts to and gives you the ability to search across all of the them.....amazing. So I have Alfred mapped to Ctrl + Spacebar, Redwood to Opt + Spacebar, and Spotlight to Com + Spacebar. Hello efficiency world.

Learning About New Technology

Technology: Backbone.js
Example: todos.js

If there was a ranking for the adoption rates of new (so excluding jQuery/Prototype) JavaScript frameworks/libraries, I would bet Backbone.js is second only to Node.js.

Backbone.js allows you to create a MVC of sorts inside your JavaScript. If you're anything like us, a lot of the functionality on your website is handled with JavaScript. Whether it's AJAX posting, error checking, or complicated modals, odds are you've dealt with JavaScript spaghetti. So similar to Rails, or any other good MVC, Backbone provides you with a framework of how to organize, write, and structure your code. It's sort of hard to explain, so here's the official summary of Backbone.js:

With Backbone, you represent your data as Models, which can be created, validated, destroyed, and saved to the server. Whenever a UI action causes an attribute of a model to change, the model triggers a "change" event; all the Views that display the model's data are notified of the event, causing them to re-render. You don't have to write the glue code that looks into the DOM to find an element with a specific id, and update the HTML manually — when the model changes, the views simply update themselves.

I haven't created anything with it yet (my learning plate runneth over), but give it a try and let me know what you think.

Rails Gems Worth Checking Out

Gem: Capfire

The thredUP Dev Team has started to use Campfire as our chat collaboration tool of choice. Questions, Github commits, and countless emoticons dominant the chat room. As a development team of 10, we come across many issues about learning different parts of our app or programming language specific questions and it doesn't scale to just ask one person every question - so we post the question to the Campfire chatroom and let the first available person answer it. So far it's working out really well. So where does Capfire come into play?

Capfire is a gem that automatically posts a message to your Campfire chatroom after someone (namely someone who has Capfire installed) deploys your app. We already have Github hooks in place for pushes to remote repositories, but I think it's valuable to know when new code is being deployed to an app - especially if you have code in that deploy. To install Capfire, check out these install instructions as they're the best I came across.

Transitioning from Newbie to Novice

I'm at the point in my development of Ruby on Rails learning where the grace period of being a beginner has worn off and it's time for me to transition to an intelligent Rails developer. I need to start engineering my mind to look for the elegant solution at the beginning of the project as opposed to looking back on my code at the end and wondering how I could have done it better. I believe the development community uses the expression 'cut my teeth' to describe this chapter of professional development for a developer. I believe the first step is to admit that there will be many roadblocks along the way where I will become frustrated with wrapping my head around certain concepts and humbled by discovering how much I have yet to learn. I plan to catalog the roadblocks I encounter on this blog as a way for other Rails developers to hopefully learn from my mistakes.

My new priority will be stepping back and opening my mind to tackle problems with the new tools I have been learning. I'm going to go after projects that I have no idea how to do and instead of looking for a block of code on Google to solve my problem or asking one of my colleagues what they would do, I'm going to work through the solution process myself. I expect to re-invent the wheel a couple of times, which would typically be thought of as inefficient, but I'm hoping the short-term losses in productivity will yield greater gains in the long run. With that having been said, bring on the pain!

Dan DeMeyere
Ruby on Rails Newbie...err...Novice and Front-end Engineer