
First, let me introduce myself, my name is Alex and I’m an apprentice here at thoughtbot. You may recognize me from this, this or this.
As an apprentice I get to immerse myself in the world of thoughtbot. I sit next to amazing developers and designers, and do work on the exciting projects that come through the door. As a result I’m learning crazy fast, every day I write code that I could not have written the day before. However, even bigger than the knowledge I’m gaining about how to write code is what I’m learning about process of developing software. One of the things that’s really important is the way people work.
I had heard words like XP, agile, and scrum used to describe software development but had never seen them in practice. After 5-plus weeks here I can tell you that the way they do things works.
Every morning at 10:00 am the entire team gathers in the conference room. We each go around the room and say something along the lines of the following:
Alex: Yesterday I worked on ______, I implemented ______ I had to do ______ to make it work. Today I will be working on ______. I am blocked on ___________.
Someone else: Yesterday I worked on ______, I did ______. Today I will be working on ______. I have no blockers.
These standups are the lifeblood of thoughtbot. They improve communication internally and provide accountability. If I say I’m gonna do something in standup then I do it. It ensures that if someone is blocked on a problem that someone else can solve, then that problem gets solved.
We work in teams. Each team usually consists of one designer and 2 to 3 developers. Each team dedicates its time to one project. Once a week each team meets with the client to discuss what was done during the week. As part of the retrospective each person on the team as well as the client goes around the table describing how they are feeling about the project and airing any grievances they may have about the way the project is progressing. These meetings make sure that the team is all on the same page and that we are doing work that our clients approve of.

Airing of grievances
Before we work with a client we ask them to pitch to and converse with the developers and designers (not just the management) on their product. We want to know:
The reason we do this is simple. People do better work on projects that they’re excited about. By having potential clients pitch the product to us we can choose products that we want to work on.
Before I started at thoughtbot I was of the opinion, like many others, that testing your code is a waste of time.
It was part of my job as an apprentice so I did it. But I was not as exuberant about it as most of the other people here.
But then something changed.
I began to write cleaner code that solved real problems and when code introduced breakages I knew about it right away.
Now I get scared when I see code without tests and I am test driving all my code, even the stuff I work on outside of thoughtbot.
We practice what we preach and use Trajectory to manage product development. What this means is that there are no emergencies. If a client finds a bug or needs a feature developed, they simply put it in Trajectory and prioritize it. The developers and designers are able to take the top story off the stack and have a discussion around it. All from within the app.
We use Campfire extensively. We have a bunch of rooms:
These Campfire rooms provide a non interruptive internal dialogue. People can look into the room when they want to and ignore it when they’re busy coding (or designing).
One of my first days here, someone was explicitly told not to work on a client project on the weekend. This threw me for a loop. Shouldn’t a company want its employees to work all hours of the day? The thing is that thoughtbot understands that the best code is written during bank hours. This doesn’t mean that thoughtbot employees don’t code at home. Everyone is encouraged to work on open source and side projects at home; however, all client work is done during bank hours when we are writing our best code.
One of thoughtbot’s informal mottos is there is a better way to build software. After 5 weeks here I can tell you that the fine folks here have got something right. They write great code in a great atmosphere with no stress.
Last night, Fluid 0.9.3 was released. This release adds Userstyles, a way to specify CSS that overrides the CSS on a page. If you’d seen my previously released campfire scripts for fluid, you’ll know that I had a catchall script that made various improvements for using Campfire with Fluid. Well, with this release of Fluid, I’ve made some improvements to this script, changing the way input is handled, and utilizing the new Userstyles.
You can get the latest version here: https://svn.thoughtbot.com/hackfest/campfire/fluid/campfireFluid.user.js.
The best feature of this script is the improvements to Campfire input handling that it makes. This script adds additional input handlers, so that when you type in Campfire, even if the focus isn’t on the input box, the focus is moved to the input box. It also makes it so that you can hit the ESC key and remove focus from the input. This didn’t previously work if you were pasting. If you wanted to paste something, you needed to manually focus the input and paste it. Well, no longer. Now, when you paste something, even if the input doesn’t have focus, it’ll focus it and then paste into the input.
One of the other things the script already did was override the CSS to remove the header HTML tabs, so that you can more seamlessly use the features of Fluid: tabbed browsing, and dock menu items, as seen here:


Now that Fluid includes the ability to specify CSS overrides built-in, I’ve removed this functionality from the script itself. To do this using Userstyles, upgrade to the latest Fluid, and then open Preferences in your Campfire Fluid App, and click on Userstyles. Create a new userstyle, with the URL pattern shown below.

And copy and paste the following Userstyle into the box.
body #Header { display: none; }
body #MainTabs li a { display: none; }
body.modal { background-color: #fff; }
body.login { padding-top: 0; }
.login div#Modal { margin: 0px; width: 100%; }
#Modal { border: none; }
Once you refresh the page, the style should take effect. I’ve also made the CSS to use available here.
I hope you enjoy the improvements. If you have any idea for how it could be improved further, please let me know.
At thoughtbot we’re a distributed team: 7 in Boston, 3 in New York City, 1 in Chicago, another in San Francisco, and myself in Philadelphia – we use Campfire constantly for team communication throughout the day. Almost all of us used Pyro to access Campfire, but after upgrading to Leopard things started going downhill – so we started experimenting with Fluid.
We’ve been toying with these scripts for a while with Greasekit, and now that Fluid has been upgraded with built in userscripting, I figure its time to get it out there.
The one feature that we all wanted was some notification when someone said your name in Campfire, so thats the first script I made – we call it Campfire Name Watcher. When the fluid application window doesn’t have focus, and someone says your name (or any word or phrase you provide) Fluid sends a Growl notification. I have mine set to make a sound as well. Just for fun, It’ll also highlight your name.

This works especially well when you enable tabbed browsing in your Fluid Campfire app, and open each Campfire room in a separate tab. Now, not only will you get notified when you’re not in the Fluid app itself, but you’ll get notified when someone in another chat room that you’re currently not paying attention to says your name.
The name watcher script uses cookies to persist your list of things to watch for, so that you don’t need to resupply it every time. The first time you go into Campfire with this script installed, it’ll ask you to provide a comma separated list of things to watch for:

To edit the list of names, right click on the campfire app dock icon and choose Name Watcher.
Opening each room in another window is really nice, as it allows you to quickly switch between rooms, and makes your Campfire Fluid app even more like Pyro. However, the UI gets messy because you have your Fluid tabs as well as the HTML Campfire tabs.
The second script is a bunch of stylesheet and behavior changes to make using Fluid tabs, and Fluid in general with Campfire more useable. Unfortunately, its not possible to script things to open in new tabs in Fluid, so you have to make sure to Apple-Click the links in the Lobby to get new tabs.
The script hides all the HTML tabs:

and moves their functionality into dock menu items:

It also makes other little changes to make it better to use Fluid with campfire, for example, it makes it so that if the input box doesn’t have focus and you begin to type, it’ll move focus to the input box, and it makes it so that search and other function open in new windows.
Get the scripts from:
https://svn.thoughtbot.com/hackfest/campfire/fluid/campfireFluid.user.js https://svn.thoughtbot.com/hackfest/campfire/fluid/campfireNameWatcher.user.js
Get Fluid from here:
Get a nice icon for it here:
http://www.37signals.com/svn/images/campfire-logo-for-fluid.png
Things in Fluid and userscripting are rough right now, consider it the “wild west” of campfire. Lots of us at thoughtbot are using these scripts and Fluid on a day to day basis now, but we’re definitely not quite there yet in where I’d want the actual functionality and usability of all of this to be. I’d definitely be interested in hearing your thoughts and even getting your patches.