unethical blogger - Slide

Being a Libor, Addendum

R. Tyler Croy — Tue, 18 May 2010 16:00:00 +0000

A couple of weeks ago I wrote a post on how to "Be a Libor", trying to codify a few points I feel like I learned about building a successful engineering team at Slide. Shortly after the post went live, I discovered that Libor had been promoted to CTO at Slide.

Over coffee today Libor offered up some finer points on the post in our discussion about building teams. It is important, according to Libor, to maintain a "mental framework" within which the stack fits; guiding decisions with a consistent world-view or ethos about building on top of the foundation laid. This is not to say that you should solve all problems with the same hammer, but rather if the standard operating procedure is to build small single-purpose utilities, you should not attack a new problem with a giant monolithic uber-application that does thirty different things (hyperbole alert!).

Libor also had a fantastic quote from the conversation with regards to approaching new problems:

Just because there are multiple right answers, doesn't mean there's no wrong answers

Depending on the complexity of the problems you're facing there are likely a number of solutions but you still can get it wrong, particularly if you don't remain consistent with your underlying mental framework for the project/organization.

As usual my discussions with Libor are interesting and enjoyable, he's one of the most capable, thoughtful engineers I know, so I'm interested to see the how Slide Engineering progresses under his careful hand as the new CTO. I hope you join me in wishing him the best of luck in his role, moving from wrangling coroutines, to herding cats.

God speed mooncat

Be a Libor

R. Tyler Croy — Fri, 30 Apr 2010 14:45:00 +0000

I reflect occasionally on how I've gotten to where I am right now, specifically to how I made the jump from "just some kid at a Piggly Wiggly in Texas" as Dave once said, to the guy who knows stuff about things. I often think about what pieces of the Slide engineering environment were influential to my personal growth and how I can carry those forward to build as solid an engineering organization at Apture.

The two pillars of engineering at Slide, at least in my naive world-view, were Dave and Libor. I joined Dave's team when I joined Slide, and I left Libor's team when I left Slide. Dave ran the client team, and did exceptionally well at filling a void that existed at Slide bridging engineering prowess with product management. Libor often furrowed his brow and built some of the large distributed systems that gave Slide an edge when dealing with incredible growth. In my first couple years I did my best to emulate Dave, engineers would always vie for Dave's time, asking questions and working through problems until they could return to their desk with the confidence that they understood the forces involved and solve the task at hand. Now that I'm at Apture, I'm trying to emulate Libor.

(Note: I do not intend to idolize either of them, but cite important characteristics)

To understand the Libor role, the phrase "the buck stops here" is useful. A Libor is the end of the line for engineering questions, unlike some organizations the "question-chain-of-command" is not the same as the org-chart. If a problem or question progressed up the stack to a Libor, and between an engineer and a Libor the pair cannot solve the problem, you're screwed.

What does it take to be a Libor you may be thinking: * No Guessing: When acting as a Libor, knowing is crucial. That is not to say you must understand everything about all the nooks and crannies of the code-base, but when you give an answer it is crucial you actually know what the hell you are talking about. The consequences of being wrong are far worst than the consequences of not knowing, if a fellow engineer builds on your guess, when that code ships live in a few days/weeks there is a serious risk of everything falling over.

Grok the stack: A Libor is expected to hold a wealth of information internally, much like a clock maker, a Libor should understand where every single gear and spring fit together in a large complex system. It is not necessary to understand how each component individually works but instead, understand how all the pieces operate in concert. Some amount of acting as a Libor requires direct discussions with the operations team as well as the rest of engineering, when all that JavaScript and Python rolls out to 10, 20, 100, or 1,000 machines, somebody should have at least considered the ramifications of adding 3 more database calls to every request, that's the Libor.
Maintenance and accountability: Typically working at the lower ends of the stack, a Libor has to relive and tolerate last month's and last year's short-sighted decisions over and over. A Libor should not let himself nor colleagues "fire and forget" code, poor judgement will haunt a Libor for much longer than most people's New Year's resolutions. Because of this mistake-longevity, a Libor should be quite concerned with how well thought-out and tested new changes, particularly drastic ones, are.
Focus on Engineering: Code quality and extendability are Libor's primary focus, that is not to say that a Libor's role is to impede product development, but rather ensure that it is properly framed. While a product manager's primary concern may be to get a feature deployed as soon as possible, the primary concern of a Libor is to ensure that once that feature is shipped it doesn't break or otherwise degrade the quality of service of the rest of the site. When interfacing with other engineers a Libor should be asking questions about code, intentions and implementation. Code review is as important as communication with the team, flatly rejecting code is unacceptable, but discussing with engineers the potential pitfalls of certain approaches ensures that the group moves forward.

Playing the Libor character at Apture has been interesting to say the least, I've done a lot of work getting a number of systems in place to help educate my decisions, particularly in our production environment. Focusing on the entire stack as a complex system has allowed us to make some adjustments here and there that have literally started to pay dividends the day after they ship.

Non-engineering also benefits from having a Libor character in the organization, at Apture the product development narrative has changed, I find myself emphasizing:

Tell me what you want, we'll find a way to do it

That's a breakthrough.

Daniel felt left out.

R. Tyler Croy — Sat, 24 Oct 2009 00:59:10 +0000

Dear Slide, I luv u guys, srsly. kthxbai.

Photo credit: Meghan

End of a journey

R. Tyler Croy — Fri, 23 Oct 2009 15:29:19 +0000

See parts 1, 2 and 3

My journey at Slide comes to an end today, when I leave this evening I will once again return to being a free agent (if only for two days). Some of my coworkers have casually referred to my writings over the past few days of my "memoirs", which isn't too far off to be honest. When I leave Slide this evening, my employment will have accounted for roughly 10% of my entire life and 50% of my adult life. Writing my side of the story down, to some extent, has been more about telling a story to myself and less about telling it to anybody else (apologies). So much of my time spent at Slide has been in a state of controlled choas that at times it's hard for me to remember when things were done, who was doing them and the order in which they happened.

The two questions I've invariably gotten since I gave my notice and subsequently started writing this series of posts have been: why are you leaving and where are you going? My reasons for leaving are irrelevant, I will say that if I could take the people I've been working with at Slide with me, I would. I've learned such an incredible amount from those that I've worked with, both technical and non-technical, while at Slide. Whenever I would pitch friends on the idea of joining Slide, my take-home point was always "when you join Slide, you will not be the smartest person there." I feel lucky that I was given the opportunity to "come of age" as a young engineer in a company of so many tremendously talented individials, given the chance for a do-over, I would still play my cards the way I've played them. I joined Slide a punk kid from Texas, I'm leaving Slide a slightly-more-learned punk kid from Texas.

As to where I am going, after an extended vacation of Saturday and Sunday, I will be joining my second startup ever (Slide's a pretty good first time out) on Monday. When I started looking at other companies I had a couple of criteria, I wanted to join a smaller team (Slide's upwards of a hundred people or so) and I had to really like who I would be working with. Tristan, Jesse, Can (John) and the team from Apture fit both criteria. I'm not going to go into detail about what I'm really going to be doing there or where Apture is going as a company. I will say that after two and a half years of working and studying at Slide, I'm looking forward to employing what I've learned and continuing my education at Apture.

See you on the beaches of the world.

My journey at Slide (part 3)

R. Tyler Croy — Thu, 22 Oct 2009 09:08:05 +0000

Continuing on from part 1 and part 2

Prior to joining Slide, a friend of mine "whurley" had nicknamed me the "Angry Young Man" which I promptly put on my first set of business cards (my current business cards list my title as "Meta-Chief Platform Architect, Enterprise Edition", I received them after mentioning a failed poaching attempt by LinkedIn to Max); when Top Friends went dark on Facebook, I was a little more than an "angry young man."

Given my close involvement with the product, the amount of sleepless nights working on it, the actions against Top Friends felt personal to me, regardless of the posturing between Slide and Facebook's executives. As hours turned into days offline, it became clear to me that the suspension of the application was far less about our privacy hole and far more about Facebook making an example out of Top Friends to the rest of the platform development community. The message was heard loud and clear by the majority of the developers that I knew, this is not your platform, these are not your users and you will play by our rules or we will wipe you from the face of the site. Building on the platform was not only no more fun, it was also a risky business decision.

At the time of the suspension, Keith and I had already started discussing what a "TopFriends.com" might look like, as the signals of platform instability for applications were already being sent. When Top Friends went offline, I prepared a few page outline for Max and Keith detailing "my vision" for what Top Friends would become, I was convinced by that time that its future lie as a social network unto itself, rather than a network contained bu another network (yo dawg..). Not content to simply be "vanity and personal expression" inside of Facebook, I wanted Top Friends to become a separate entity by itself, your VIP club on the internet, at one point there was even executive support for the drawing of users away into a destination site for Top Friends. When the seven days of suspension were over and Top Friends came back online, Slide's strategy shifted drastically. Our new mission for TF on Facebook was to "get as close to Facebook as you can," we were to integrate into a user's experience as much as conceivably possible. Previously we had wanted to run as far away from Facebook as we could, taking our users with us, but the fear that was enstilled by the application suspension caused us to rethink that stance and push Top Friends to be a squeeky clean platform citizen, while we contemplated a possible exodus for FunSpace and SuperPoke!.

Around this time in Slide's history I became quite jaded and cynical with regards to the platform, Top Friends had been neutered by Facebook, and my notion of what Top Friends should have been was neutered by Max. Regardless, we still had plenty of work that needed to be done to try to succeed with our new strategy. Months prior, Tony Hsieh (not the Zappos guy) the original Top Friends PM had failed to win the visa lottery and moved back to China, leaving TF without a product manager for some time. While we continued to look for senior PM to take on the role, I had to play both product and engineering manager (with help in both places every now and again). Quite the twist of fate for me, I had often poked fun at PMs at Slide, once creating a powerpoint (one should speak the language) titled "PM Flowchart". The presentation consisted of one slide, with a fairly simple state diagram on it, one block labeled "Write Spec" had an arrow pointing to another block labeled "Bitch." which pointed back at "Write Spec". Suffice to say, product managers and I usually had a tenuous relationship.

Passionate about the product to begin with, I started meeting more and more often with Max and Keith to discuss product strategy for TF, in between doing my "real job" of Engineering Manager. Some meetings Keith and Max would square off and I would sit back and watch, other times Keith and I squared off against Max, I rarely took Max's side against Keith's though. Not that I always disagreed with Max, but he was at a slight disadvantage in these discussions, Keith and I generally shared a lot of fundamental ideas of what TF should be, stemming from months of discussing the product by his desk before he ever "officially" worked with the project. The transition over a year and a half from quivering in fear as the director of engineering cursed at me on Dave's house phone, to arguing with the CEO about the product he pitched me on, was surreal to say the least. How I didn't get fired is either a testament to my charm or Max's patience.

In fall of 2008, when Seema finally joined as the Top Friends product manager, not only was I more than ready to relinquish the post, Top Friends was in the midst of an identity crisis. Our "facebook zerg rush" strategy of getting closer and closer to the platform played out as you might of expected (hindsight and all), Facebook redesigned the profile, changed viral communications channels and did a lot of things that were likely good for Facebook, but terrible for applications. TF had a lot of momentum on the "old profile" thanks to users dragging the TF profile box all the way up on their profiles. When Facebook rolled out their new profile which put applications not in the backseat, but in the way-back seat, the strategy of "be lovey dovey with Facebook" started to break down, they weren't being lovey dovey back.

Times were also changing outside of Top Friends at Slide, the SuperPoke! Pets product was starting to take off and actually make money directly from users. This was important! Users, giving us money, for pixels! Brilliant! Being a much more reliable revenue stream than the advertising oriented model that FunSpace, SuperPoke! and Top Friends had been built around, Pets quickly became the "top" product at Slide. With ad revenue drying up for Top Friends, we were tasked with experimenting with virtual currency (like Pets) and ultimately "premium items" (like Pets) within Top Friends. It seemed almost as if Top Friends was changing visions, strategies and directions on a bi-weekly basis. One week we were building virtual currency experiments with "Top Dollars", the next, virtual economy experiments with an "Own your friends' profiles" feature, the next, premium virtual goods with "Top Gifts". As the "Top Friends guy" and the manager of the engineering team, I was so confused and disoriented about what we actually did and where we were actually heading, I didn't stand a chance at convincing Paul, Geoff and Jason of it.

2008 winding down, the writing was on the wall, Top Friends was not going to live long, at least the Top Friends Team wasn't. We had gained a reputation of being very self-sufficient and competent, but with that autonomy came uncertainty from outsiders. I regularly had to remind coworkers that I was a Slide engineer, not a Top Friends engineer, regardless of the TF team's internal view of itself as a "microstartup." When we failed to meet goals set out for us, it was decided that the staff behind Top Friends were too valuable to spend time on a failing product.

Jason, Paul and Seema went to start a new project, while Geoff and I, together since the desktop client days, joined the Server/Infrastructure team. My personal "love" for Top Friends had all but dissolved by this point, I was sick of Top Friends, I was sick of Facebook, I was sick of policy, I didn't care all that much about the product anymore. The breaking up of the team though, was crushing. As far war metaphors go, the TF team was a small rag-tag group of guerrillas, capable of taking large projects and finishing them in record time. We often talked about what we did as "playing jazz music" because our work had an improvisational style, but the trust and understanding of where we all fit into the act, allowed us to tackle large tasks in stride; that was all over though. The dream team was broken up.

My time on the server team at Slide is unfortunately a boring story of working with stellar engineers capable of writing solid code and deploying it without incident. As exciting as wood filler "this worked out just fine, the end." After years of frenzy with Top Friends and the Facebook platform, my first project for the server team took three weeks to build, was pushed without a hitch and has only required two minor updates since. With my nose to the grindstone building services and scalable architecture, I went months without particularly concerning myself with "product direction", company strategy and their ilk. The closest I would come to application development would be jumping up into application code to fix bugs, all the while cursing app developers' laziness while conveniently forgetting how often I was guilty of the same offense in my tenure with Top Friends.

When I finally stuck my head back up, near the end of the summer, I started to realize that I was working at a different company than I remember joining. Slide had grown tremendously and changed direction once again. Since stepping back from the front-lines, I had changed and Slide had changed too.

It was about time Slide and I started seeing other people.

Continue on to the end

My journey at Slide (part 2)

R. Tyler Croy — Wed, 21 Oct 2009 05:47:48 +0000

When I finished up writing part 1 of my journey at Slide yesterday, I had just recounted becoming "the Top Friends guy", savvy readers might have noted that I had not moved off of Dave's couch at the time. I am uncertain whether it is a record to be proud of, but I held the position of "the guy on Dave's couch" for two months. With the leadup to the "F8" conference I didn't have a whole lot of time to find an apartment, Dave being an all around nice guy and amazing cook, wasn't helping my motivation to leave either. That said, I'm a delightful house guest, honest.

Shortly after the initial successes of the Top Eight product, and the launch of "FunWall" (renamed "FunSpace" later), Slide quickly converted the desktop client team to the "Facebook Team" with 4-5 engineers hacking on Facebook applications to capitalize as quickly as possible on the wild-west nature of the platform at the time. We subsequently launched another couple apps, such as "My Questions" an application that allowed you to poll your friends (likely our most "useful" application). I ended up writing another application alongside Top Eight called "Fortune Cookie", contrasted to My Questions, it was probably our most useless application. The application was absolutely brilliant (Mike and Max get credit here again), the profile box for the application was a picture of a fortune cookie with a fortune overlaid. Brilliant. If/when the user clicked through to the application's canvas page, they were met with a simple grid of checkboxes and friends' faces, checkboxes checked with a giant blue button that said "Invite your Friends!".

Never underestimate the power of "Select All", Fortune Cookie exploded, alongside our "Magic 8 Ball" application (guess what that was), it spread through the Facebook ecosystem like an epidemic. By mid June Top Eight was renamed Top Friends after we bumped the number of "top friends" you could list from 8 to 24 (innovation!); with the power of an intrisicly simple value-proposition to users, 24 friend tiles and "Select All", Top Friends held the rank of #1 application on Facebook. Following Top Friends was iLike, a major initial success, with Fortune Cookie pulling in third place. Further down the list were a couple of familiar applications: Free Gifts, created by Zach Allia, a Northwestern student at the time and a regular on the #facebook channel on Freenode; Rock You!'s "X Me" application was likely one of the first acquisitions on the Facebook platform, after being created by a student who joined the #facebook channel frantically asking for help as his server was crumbling under the load of pure virality, and SuperPoke! an application created by a then part-time Microsoft employee and two friends.

The first couple weeks of the Facebook platform were sheer insanity, determined to one-up our competitors Rock You!, Slide acquired SuperPoke! and the three engineers that wrote it, Nik, Will and Jonathan. Slide was determined to own the market of "virtually do virtual things to your virtual friends on Facebook". In short order the SuperPoke team moved down from Seattle to join the "Facebook Team" in Slide's office at 2nd and Howard, Jon went to the metrics team (being a PhD and all) while Nik and Will shared a desk and started learning Python to port SuperPoke! over to Slide's stack to allow it to scale faster and better than could have been possible on the PHP/MySQL stack it used at the time. Prior to joining Slide, the SuperPoke! application icon was some picture of a goat Nik had plucked from the internets, by joining Slide they had access to real designers, not goats from Google Image Search. Slide's most senior designer, Johnnie, can be credited with helping define the brand that would ultimately be synonymous with the Facebook platform and Slide: the SuperPoke sheep. While SuperPoke! and X Me battled it out for 4th and 5th place in the application rankings, journalists started writing articles discussing the Facebook platform, in both positive and negative light, without fail mentiong the absurdity of "throwing sheep" at your friends. I always got the impression that Mark Zuckerberg would have considered the Facebook platform successful when IBM ported Lotus Notes to it, being a "utility fetishist", I can only imagine how "delighted" he must have been with the top applications on the platform being the likes of Top Friends, Fortune Cookie, Horoscopes, Graffiti, X Me and SuperPoke!.

After the SP guys had joined Slide, Facebook hosted a mid-morning event at their Palo Alto office to help kickstart some developer relations and have top application developers do some lightning-round style presentations. The meeting starting at 9, it was only logical that Nik, Will, Max and I meet at the Slide offices at 8:45; we piled into Max's BMW M3 (a gorgeous car, I highly recommend it) and sped southwards from San Francisco on the 101. Despite driving between 90-100mph through rush-hour traffic towards Palo Alto, we arrived fashionably late; walking in during a presentation, Dave McClure announced to the whole room "Slide has arrived."

Roll around in an M3 enough, have people announce your arrival enough and you too will feel like a Web 2.0 rockstar. Being the "Top Friends guy", I certainly had a bit of an ego going, I still kind of do, but I'm far more modest now about being a complete badass.

The summer of 2007 was mostly a blur, the majority of my "workdays" ended up being 14-16 hours usually ending with Geoff, Sergio, Kasey and I drinking into the wee hours of the morning, pushing code and smoking on the fire escape (building management didn't really care for that part). The night before the iPhone launched, a bunch of Sliders had arranged to wait in line in shifts at Apple's Market St store (we were third in line). Given my schedule at the time, I worked most of the night and then manned the 4-7 a.m. shift in line. I didn't even want an iPhone but Tony, the product manager we hired for Top Friends, and I hung out on the sidewalk, smoked fancy cigars and watched the streets get cleaned. My (now) fianceé was still in Texas finishing up with school, so I had nothing to do but hang out, drink, smoke, write code, push the site and sleep every now and again. My apartment, right in the middle of the colorful Tenderloin district, only served as a place to shower and crash. For the duration of my lease, I didn't own any dishes and rarely had anything in the fridge other than left-over pizza and Cokes.

By the latter part of 2007 we hired Keith Rabois to be the VP of Business Development, presumably to help us ink deals with big important companies about big important things (with big important sacks of money). Initially, I hadn't a clue what the hell Keith did, other than walk around in his shiney silk shirts talking on his fancy iPhone, loud enough to hear across the office. The layout of Slide's office was such that on one end was the open floorplan engineering "pit" and on the other end, separated by a ping pong table and a copy machine were the "non-engineers". The ping pong table was usually as far as I went. At some point, I don't remember exactly when, I started consulting with Keith on product related matters. He had this chair by his desk, so I would stroll over, plop down and gab for longer than he probably had time for about subjects ranging from the latest Facebook gossip to long-term strategy; Keith's involvement with Top Friends would only increase from then moving forward.

By the beginning of 2008, the Facebook platform wasn't fun anymore. Too many emails contained the words "policy" and "violation" and often dastardly combinations of the two. At the same time, Slide had upped its commitment to Top Friends hiring Jason, who I had known for some time from the #facebook IRC channel, his compatriot Paul, and assigning Geoff, a senior QA engineer who had put up with my shit on the client team since I joined the company months earlier. I was promoted to Engineering Lead and shortly thereafter to Engineering Manager. My role had changed dramatically, no longer simply just a monkey coding like there was no tomorrow, I now had people I had to be accountable to, all the miserable hacks I had thrown into Top Friends in the previous 8 months I had to sheepishly explain to Jason and Paul, mentioning from time to time how I could do it better given the time.

Jason and Paul being hired and assigned to my team was likely the luckiest thing that ever happened to me at Slide, overnight I went from a hard-working "army of one" to part of a team of four hard-working bone crushers with an incredible drive to succeed. In a few short months we had shipped an "Awards" feature, built out a "Top Friends Profile" and started pushing our way back to the top.

In June, a reporter for CNet reported on a hole in the Top Friends Profile that allowed a user to view information about other users they could not have otherwise seen. The reporter used this an instrumental piece of a larger article bashing Facebook on their privacy record and the openness of the Faceobok platform. When Keith texted me that night, I rushed home and pushed a fix for the hole within the hour, went to dinner by myself and had the worst Pad Thai I've ever eaten, watching the exchange of emails between Slide's and Facebook's executive team on my Blackberry.

Top Friends had tens of millions of users and with the flick of a switch, Facebook took Top Friends offline.

Continue on to part 3 and the end

My journey at Slide (part 1)

R. Tyler Croy — Tue, 20 Oct 2009 05:40:53 +0000

As some of you may, or may not know, this friday October 23rd will be my final day as a Slide employee. With my journey at Slide nearing its completion, I wanted to document some of how I've gotten here and where I've started, if for nobody other than myself.

Officially I started at Slide April 2nd, 2007, though my journey to Slide started far earlier. At the end of my fourth semester at Texas A&M my then girlfriend, now fianceé and I decided we were through with College Station and to move to San Antonio; most Texans would consider this a lateral move at best. I had every intention of resuming my studies at UTSA following a brief stint at San Antonio College clearing up pre-requisites with a slightly lower price tag. By the end of fall semester it had become clear that I wasn't cut out for college, I stopped attending and focused full time on software. At the time most of my experience and contacts were through the Mac development community, primarily via IRC on the Freenode network and developer mailing lists for various open source projects. Through my involvement in the Bonjour mailing lists and work with the API, I had at one point impressed Bonjour's original inventor Stuart Cheshire enough to land an interview at Apple for the Core OS group, working on Bonjour.

Sitting on the Continental flight out to San Jose, I practiced writing network services using BSD sockets and pouring over as much C as I could possibly manage, all told I likely wrote around 3 multicast service/client pairs on that flight. What I wasn't prepared for was the "computer science" nature of the interview; I bombed it with my rudimentary algorithms knowledge and lack of experience working with C on a day to day basis. Fortunately, my last interviewer of the day was Ernie Prabhakar then a product or marketing manager for the Core OS group; Ernie indulged me in a very interesting conversation about Apple's position in the open source universe, product direction, etc. Despite bombing the technical portions of the interview, I suppose Ernie saw enough enthusiasm in me to refer me to Dave Morin at Facebook (the two worked together at some point).

Those that know Dave Morin understand that the man wields a Jobsian reality distortion field, even via email 1500 miles away in Texas I felt the power of the field and was drawn to Facebook. While I was ultimately disappointed to not have landed my then-dream-job at Apple, I was incredibly excited to be flying back to Silicon Valley to interview at Facebook. When I mentioned to daver (Dave Young) on IRC that I would be flying back out to see the nice folks at Facebook in Palo Alto, he also arranged an interview at Slide the day after.

A number of factors likely lead to my failure to excite my interviewers at Facebook, not having a Facebook account for one didn't help, I also think I uttered "fuck" under my breath once or twice while sketching out problems on a whiteboard. Considering my interview was done mostly in "the game room" due to a scheduling error, I didn't think I was being too unprofessional. As one could assume, my interview with Slide went substantially better, I accepted an offer to join Slide as a junior software engineer working on their now defunct desktop application(s).

My start date was set for April 2nd, within three weeks I had terminated the lease on my apartment in San Antonio, tossed, sold or otherwise gave away the majority of my belongings and furniture and packed my VW Jetta to the brim and drove west. I didn't particularly have a plan other than "show up, get to work" (I was 21, how young and foolish), so I crashed on daver's couch while I settled in and started searching for an apartment.

My early days at Slide were all about getting up to speed on Python (Slide's language of choice) and ActionScript 2 (Slide's only option for Flash at the time); I started helping with the Windows client, mostly in the spagetti-driven Flash-based screensaver product. Towards the beginning of May, Jeremiah (then Director of Engineering, now CTO) and Bobby (another engineer) were working with some preview APIs from what would ultimately become the Facebook platform. For whatever reason I started working on trying to incorporate some data from Facebook into our desktop client (optimal synergy, etc) and became the third engineer working at Slide on the Facebook platform in its infancy. As May came to completion, we (Slide) were invited to "F8" to unveil some of the applications for their new platform we had built.

Donning my trusty brown cordoruy sport jacket, dark blue Slide t-shirt, I helped man Slide's booth presenting some of our apps: SlideShows and YouTube Skins (both products turned out to be utter failures). As the business/presentation portion part of F8 wound down, I grabbed a 19" monitor and told Max and Jeremiah that I wanted to stay for the hackathon but didn't have any idea what to hack on (being a desktop developer and all). Max leaned in and muttered "Top Friends" on his way out, leaving me to set up shop with the only dual screen setup in the hackathon, at a lonely table by myself (I hadn't figured out how to socialize at that point). Coming from a desktop background, I hadn't a clue what I was doing, I could barely figure out how to get pages working on Slide's infrastructure, let alone all this FBML, FQL and JavaScript malarkey.

Fortunately in the days following the hackathon, I was able to enlist the help of Sergio, the best web front-end engineer Slide had to offer to help me create a grid of drag and droppable images along with some other pieces of front-end to make the application palatable. All said and done, if I remember correctly, Top Eight launched less than a week after the platform did, my first "big" project at Slide. Originally I couldn't get database resources for the app, so I stashed the friends list inside of the profile FBML and then would subsequently retrieve back from Facebook when I needed it, using regular expressions (had help with that too) to pull the list of Facebook user IDs out; that hacked up solution lasted for all of maybe 30 minutes on live as soon as everyone saw how god-awful slow it was.

Day three of Top Eight, I learned what "viral meant". My parents had neglected to pay their phone bill, taking my "family plan" number out with it, meaning I couldn't receive the frantic calls from Jeremiah as I slept-in that morning. Turns out by giving the Top Eight a callback URL with Facebook that hit "www.slide.com" was proving impossible to load balance, resulting in a couple hours of site issues for the rest of Slide, as Top Eight skyrocketed hundreds of thousands of users in a single day. I awoke that morning to pounding on Dave's door (I was still on their couch), opening it I saw Carey (another desktop developer at Slide) who said "your phone's off." Not my preferred way to wake up, but it sufficed. I sheepishly called Jeremiah on Dave's house phone.

Jeremiah was pissed. Not "who ate the rest of my hummus" pissed, righteously pissed, at me. Here I was, living on a friend's (who I met on the internets) couch, without a proper mailing address trying to figure out how this startup thing worked, and Jeremiah was furious with me. If there were such a thing as an "ideal time" for an earthquake, I would have gladly accepted that as an alternative.

Once the smoke cleared and tempers cooled, we looked at some of the installation and growth numbers of Top Eight during the previous 6 hours; I had found myself a new job at Slide. From that day forth, I was "the Top Friends guy."

Continue on to part 2, part 3 and the end

IronWatin; mind the gap

R. Tyler Croy — Tue, 13 Oct 2009 21:57:49 +0000

Last week @admc, despite being a big proponent of Windmill, needed to use WatiN for a change. WatiN has the distinct capability of being able to work with Internet Explorer's HTTPS support as well as frames, a requirement for the task at hand. As adorable as it was to watch @admc, a child of the dynamic language revolution, struggle with writing in C# with Visual Studio and the daunting "Windows development stack," the prospect of a language shift at Slide towards C# on Windows is almost laughable. Since Slide is a Python shop, IronPython became the obvious choice.

Out of an hour or so of "extreme programming" which mostly entailed Adam watching as I wrote IronPython in his Windows VM, IronWatin was born. IronWatin itself is a very simple test runner that hooks into Python's "unittest" for creating integration tests with WatiN in a familiar environment.

I intended IronWatin to be as easy as possible for "native Python" developers, by abstracting out updates to sys.path to include the Python standard lib (adds the standard locations for Python 2.5/2.6 on Windows) as well as adding WatiN.Core.dll via clr.AddReference() so developers can simply import IronWatin; import WatiN.Core and they're ready to start writing integration tests. When using IronWatin, you create test classes that subclass from IronWatin.BrowserTest which takes care of setting up a browser (WatiN.Core.IE/WatiN.Core.FireFox) instance to a specified URL, this leaves your runTest() method to actually execute the core of your test case.

Another "feature"/design choice with IronWatin, was to implement a main() method specifically for running the tests on a per-file basis (similar to unittest.main()). This main method allows for passing in an optparse.OptionParser instance to add arguments to the script such as "--server" which are passed into your test classes themselves and exposed as "self.server" (for example). Which leaves you with a fairly straight-forward framework with which to start writing tests for the browser itself:

#!/usr/bin/env ipy
 
# The import of IronWatin will add a reference to WatiN.Core.dll
# and update `sys.path` to include C:\Python25\Lib and C:\Python26\Lib
# so you can import from the Python standard library
import IronWatin
 
import WatiN.Core as Watin
import optparse
 
class OptionTest(IronWatin.BrowserTest):
    url = 'http://www.github.com'
 
    def runTest(self):
        # Run some Watin commands
        assert self.testval
 
if __name__ == '__main__':
    opts = optparse.OptionParser()
    opts.add_option('--testval', dest='testval', help='Specify a value')
    IronWatin.main(options=opts)

Thanks to IronPython, we can make use of our developers' and QA engineers' Python knowledge to get the up and running with writing integration tests using WatiN rapidly instead of trying to overcome the hump of teaching/training with a new language.

Deployment Notes: We're using IronPython 2.6rc1 and building WatiN from trunk in order to take advantage of some recent advances in their Firefox/frame support. We've not tested IronWatin, or WatiN at all for that matter, anywhere other than Windows XP.

Investment Strategy for Developers

R. Tyler Croy — Tue, 11 Aug 2009 06:34:19 +0000

It seems every time @jasonrubenstein, @ggoss3, @cablelounger and I sit down to have lunch together, we invariably sway back and forth between generic venting about "work stuff" and best practices for doing aforementioned "work stuff" better. The topic of "reusable code" came up over Mac 'n Cheese and beers this afternoon, and I felt it warranted "wider distribution" so to speak (yet-another-lame-Slide-inside-joke).

We, Slide, are approaching our fourth year in existence as a startup which means all sorts of interesting things from an investor standpoint, employees options are starting to become fully-vested and other mundane and boring financial terms. Being an engineer, I don't care too much about the stocks and such, but rather about development; four years is a lot from a code-investment standpoint (my bias towards code instead of financial planning will surely bite me eventually). Projects can experience bitrot, bloating (read: Vista'ing) and a myriad other illnesses endemic to software that's starting to grow long in the tooth.

At Slide, we have a number of projects on slightly different trajectories and timelines, meaning we have an intriguing cross-section of development histories representing themselves. We are no doubt experiencing a similar phenomenon to Facebook, MySpace, Yelp and a number of other "startups" who match this same age group of 4-7 years. Just like our bretheren in the startup community, we have portions of code that fit all the major possible categories:

That which was written extremely fast, without an afterthought to what would happen when it serve tens of millions of users
That which was written slowly, trying to cater to every possible variation, ultimately to go over-budget and over-schedule.
That which has been rewritten. And rewritten. And rewritten.
Then the exceptionally rare, that which has been written in such a fashion that it has been elegantly extended to support more than it was originally conceived to support.

In all four cases, "we" (whereas "we" refers to an engineering department) have invested differently in our code portfolio depending on a number of factors and information given at the time. For example, it's been a year since Component X was written. Component X is currently used by every single product The Company owns, but over the past year it's been refactored and partially rewritten each time a new product starts to "use" Component X. In its current state, Component X's code reads more like an embarrasing submission to The Daily WTF with its hodge-podge of code, passed from team to team, developer to developer, like some expensive game of "Telephone" for software engineers. After the fact, it's difficult and not altogether helpful to try to lay blame with the mighty sword of hindsight, but it is feasible to identify the reasons for the N number of developer hours lost fiddling, extending, and refactoring Component X.

Was the developer responsible for implementing Component X originally aware of the potentially far reaching scope of their work?
Was the developer given an adequate time frame to implement a proper solution, or "this should have shipped yesterday!"
Did somebody pass the project off to an intern or somebody who was on their way out the door?
Were other developers in similar realms of responsibility asked questions or for their opinions?
Is/was the culture proliferated by Engineering Leads and Managers encouraging of best practices that lead to extensible code?

I've found, watching Slide Engineering culture evolve, that the majority of libraries or components that go through multiple time/resource-expensive iterations tend to have experienced shortcomings in one of the five sections above. More often than not, a developer was given the task to implement Some Thing. Simple enough, Some Thing is developed with the specific use-case in mind, and the developer moves on with their life. Three months later however, somebody else asks another developer, to add Some Thing to another product.

"Product X has Some Thing, and it works great for them, let's incorporate Some Thing into Product Y by the end of the week."

Invariably this leads to heavy developer drinking. And then perhaps some copy-paste, with a dash of re-jiggering, and quite possibly multiple forks of the same code. That is, if Some Thing was not properly planned and designed in the first place.

Working as a developer on products that move at a fast pace, but will be around for longer than three months is an exercise in investment strategy (i.e. managing technical debt). What makes great Engineering Managers great is their ability to determine when and where to invest the time to do things right, and where to write some Perl-style write-only code (zing!). What makes a startup environment a more difficult one to work on your "code portfolio" is that you don't usually know what may or may not be a success, and in a lot of cases getting your product out there now is of paramount importance. Unfortunately there isn't any simple guideline or silver bullet, and there is no bailout, if you invest your time poorly up front, there will be nobody to save you further down the line when you're staring an resource-devouring refactor in its ugly face.

Where do you invest the time in any given project? What will happen if you shave a few days by deciding not to write any tests, or documentation. Will it cost you a week further down the road if you take shortcuts now?

I wish I knew.

Writing for Stability (or: I hate writing tests)

R. Tyler Croy — Wed, 29 Jul 2009 07:30:08 +0000

Since moving to the infrastructure team at Slide I've found the rate at which my software gets deployed has plummeted, while the quantity of the code that I am deploying to the live site has sky-rocketed. When on an applications-team within Slide, code is typically pushed in small incrememnts a few days a week, if not daily. This allows for really exciting compact milestones that make more fine-grained analysis achievable, post-push for product management and metrics purposes. On the infrastructure team however, the requirements are wholly different, the "fail-fast, ship-now" mentality that prevails when doing user-facing web application development just does not work in infrastructure. The most important aspects of building out infrastructure components are stability and usability, our "customers" are the rest of engineering, and that has a definite effect on your workflow.

Code Review

One of the things that @jasonrubenstein and I always did when we worked together, was occasional code review. In the majority of cases, our "code review" sessions were more or less rubber duck debugging, but occasionally it would escalate into more complex discussions about the "right way" to do something. When you're writing infrastructure software for services that are handling tens of millions of users the notion of "code review" goes from being optional to being absolutely required. Discussions are had on the correctness or performance characteristics of database indexes, the necessity of some objects instantiating default values of attributes or having them lazily load, or debating garbage collection of objects while meticulously watching memory consumption.

For one of my most recent projects, I was working on something in C, a rarity at Slide since we work with managed code in Python the majority of the time. As the project neared completion, I counted roughly two or three hours of code review time dedicated by our Chief Architect. The attention to detail paid to this code was extremely high, as the service was going to be handling millions of requests from other levels of the Slide infrastructure, before getting cycled or restarted.

A particularly frustrating aspect of code review by your peers is that a second set of eyes not only will find problems with your code, but will likely mean refactoring or bug fixes, more work. In my case, whenever a bug or stability issue was discovered, a test needed to be written for it to make sure the bug did not present itself again, the workload would be larger than if I had just fixed the bug and moved on with my life.

Testing, oh the testing

If you expect to write an API, have it stablize, and then be used, you must write test cases for it. I'm not a TDD "nut", I actually hate writing test cases, I absolutely abhor it. Writing test cases is responsible and the adult thing to do. In my experience, it can also be tedious and usually comes as a result of finding flaws in my own software. The majority of tests that I find myself writing are admissions of defeat, admitting that I don't crap roses and by george, my code isn't perfect either.

On the flipside however, I hate debugging even more. Stepping through a call stack is on par with waterboarding in my book, torture. Which means I'm more than willing to tolerate writing tests so long as it means I can be certain I will be cutting down on the time spent being tortured with either pdb or gdb. In almost every situation where I've written tests properly, like the responsible developer that I am, I find them saving me at some point. It might be getting late, or I'm just feeling a little cavalier, but tests failing almost always indicates that I've screwed something up I shouldn't have.

Additionally, now that the majority of my projects are infrastructure-level projects, the tests I write serve a second "undocumented" purpose, they provide ready-made examples for other developers on how to use my code. Bonus!

The more and more code I write, the more amazed I am at the pushback against testing in general, there exists decent libraries for every language imaginable (well, perhaps BrainfuckUnit doesn't exist), and its sole purpose (in my opinion) is to save develpoment time, particularly when coupled with a good continuous integration server. Further to that effect, if you're building services for other developers to use, and you're not writing tests for it, you're not only wasting your time and your employer's money, but the time of your users as well (read: stop being a jerk).

Sure there are a lot of articles/books/etc about writing stable code, but in my opinion, solid code review and testing will stablize your code far more than any design pattern ever will.

Slide Open Source

R. Tyler Croy — Wed, 08 Apr 2009 06:56:20 +0000

It's not been a secret that I'm a big fan of open source software, I would likely not be where I am today had I not started with projects like OpenBSD or FreeBSD way back when. While my passion for open source software and the "bazaar" method of developing software might not be shared by everybody at Slide, Inc, everybody can certainly get on board with the value of incorporating open source into our stack, which is almost entirely comprised of Python (and an assortment of other web technologies).

Along those lines, there's been some amount of discussion about what we can or should open source from what we've developed at Slide, but we've not really pushed anything out into the ether as of yet. Today however, I think we finally put our foot in the door as far as contributing back to the open source community as a whole, we're now on GitHub as "slideinc", yay! (coincidentally we have a slideinc twitter account too)

Currently the only project that's come directly out of Slide, and shared via the slideinc GitHub account is PyVE, a Python Virtual Earth client that I hacked together recently to tinker with some Geocoding (released under a 3-clause BSD license). In the (hopefully) near future we'll continue to open source some other components we've either created or extended internally.

If you're not a GitHub user, you should definitely check GitHub out, it's a pretty impressive site. If you are a GitHub user, or a Python developer, you should "follow" the slideinc user on GitHub to catch the cool stuff that we may or may not ever actually release ;)

Do not fear continuous deployment

R. Tyler Croy — Fri, 13 Mar 2009 08:13:29 +0000

One of the nice things about living in Silicon Valley is that you have relatively easy access to a number of the developers you may work with through open source projects, mailing lists, IRC, etc. Today Kohsuke Kawaguchi of Sun Microsystems, the founder of the Hudson project, stopped by the Slide offices to discuss Hudson and the "cloud", continuous deployment and our workflow with Hudson here at Slide. Continuous deployment being the most interesting topic for me, and the most relevant in terms of the importance of Hudson in our current infrastructure.

Since reading Timothy Fitz's post on the setup for "continuous deployment" at IMVU, I've become obsessed to a certain degree with pushing Slide in that direction as an engineering organization. Currently we push a number of times a day as necessary, and it's almost as if we have manual-continuous-deployment as it is right now, there's just a lot of room for optimizations and automation to cut down on the tedium and allow for more beer drinking.

@agentdero continuous deployment = when build is green, autoship? sounds terrifying...

(@tlipcon)

As a concept, continuous deployment can be quite scary "wait, some robot is going to deploy code to my production site, wha!" It's important to remember that the concept of continuous deployment doesn't necessarily mean that no QA is involved in the release process, it is however ideal to have enough good test cases such that you can do a fully automated unit/integration/system test run. The biggest difficultly with the entire concept of "continuous deployment" however is not writing tests or actually implementing a system to deploy, it forces you to understand your releases and production environment; it's about eliminating the guess work from your process and reducing the amount of human error (or potential for human error) involved in deployments.

In my opinion, continuous deployment isn't about making a hard switch, firing your QA and writing boat-loads of tests to ensure that you can push the production site straight from "trunk" as much as humanly possible. Continuous deployment is far more about solidifying your understanding of your entire stack, evolving your code base to where it is both more testable and better covered by your tests, then putting your money where your mouth is and relying on those tests. If your codebase moves rapidly, unit/integration/system tests are only going to be up to date and valuable if you actually rely on them. If breaking a single unit test pre-deployment becomes a Big Deal™, then the developer responsible for the code being deployed will make sure that: (a) the test is valid and up to date and (b) the code that the test is covering does not contain any actual regressions.

Take the typical repository layout for most companies which is, as far as I've seen, made up of a volatile trunk, stable release branch and then a number of project branches. In an engineering department QA would be responsible for ensuring that projects are properly vetted before merging from project branches (also called "topic branches" in the Git community) into the more volatile trunk branch. Once the CI server (i.e. Hudson) picks up on changes in trunk, the testing process would begin at that particular revision. Provided the test suites passed with flying colors Hudson would start to kick up the process to do a slow/sampled deploy as Timothy describes in his post. If the tests failed however, alarms would start beeping, sirens would wail and there would be much gnashing of teeth, somebody has now broken trunk and is blocking any other deployments coming down the pipe. In this "disaster scenario" the QA involved in the process would be thoroughly shamed (obviously) but then given the choice to block future pushes while the developer(s) create a fix or revert their changes out of trunk and take them back to a project branch to correct the deficiencies. This attention to detail will have an larger benefit in that developers won't become numb to test failures to where they're no longer important.

What good is writing tests if there aren't have real-consequences for them failing? Releases shouldn't be a scary time of the day/week/month, you should certainly be nervous (keeps you sharp), but if you fear releases then it is probably an error in your release process that allows for too much uncertainty: inadequate test coverage, insufficient blackbox testing, poor release practices, etc. Continuous deployment might not be the magic solution to your woe of shipping software but the practice of moving towards continuous deployment will greatly improve your release process whether or not you ever actually make the switch over to a fairly automated deployment process as the engineers at IMVU have.

How confident are you in your test coverage?

Git Protip: Split it in half, understanding the anatomy of a bug (git bisect)

R. Tyler Croy — Sat, 07 Mar 2009 06:07:13 +0000

I've been sending "Protip" emails about Git to the rest of engineering here at Slide for a while now, using the "Protips" as a means of introducing more interesting and complex features Git offers.

There are those among us who can look at a reproduction case for a bug and just know what the bug is. For the rest of us mere mortals, finding out what change or set of changes actually introduced a bug is extremely useful for figuring out why a particular bug exists. This is even more true for the more elusive bugs or the cases where code "looks" correct and you're stumped as to why the bug exists now, when it didn't yesterday/last week/last month. The options in most classical version control systems you have available to you are to sift through diffs or wade through log message after log message trying to spot the particular change that introduced the regression you're now tasked with resolving.

Fortunately (of course) Git offers a handy feature to assist you in tracking down regressions as they're introduced, git bisect. Take the following scenario:

Roger has been working on some lower level changes in a project branch lately. When he left work last night, he ran his unit tests (everything passed), committed his code and went home for the day. When he came in the next morning, per his typical routine, he synchronized his project branch with the master branch to ensure his code wasn't stomping on released changes. For some reason however, after synchronizing his branch, his unit tests started to fail indicating that a bug was introduced in one of the changes that was integrated into Roger's project branch.

Before switching to Git, Roger might have spent an hour looking over changes trying to pinpoint what went wrong, but now Roger can use git bisect to figure out exactly where the issue is. Taking the commit hash from his last good commit, Roger can walk through changes and pinpoint the issue as follows:

## Format for use is: git bisect start [<bad> [<good>...]] [--] [<paths>...]
xdev4% git bisect start HEAD 324d2f2235c93769dd97680d80173388dc5c8253
Bisecting: 10 revisions left to test after this

[064443d3164112554600f6da39a36ffb639787d7] Changed the name of an a/b test.
xdev4%

This will start the bisect process, which is interactive, and start you halfway between the two revisions specified above (see the image below). Following the scenario above, Roger would then run his unit tests. Upon their success, he'd execute "git bisect good" which would move the tree halfway between that "good" revision and the "bad" revision. Roger will continue doing this until he lands on the commit that is responsible for the regression. Knowing this, Roger can either revert that change, or make a subsequent revision that corrects the regression introduced.

A sample of what this sort of transcript might look like is below:

xdev4% git bisect good                              
Bisecting: -1 revisions left to test after this
[bcf020a6c4ac7cc5df064c66b182b2500470000a] Merge branch 'cjssp' into master
xdev4% git bisect bad
bcf020a6c4ac7cc5df064c66b182b2500470000a is first bad commit
xdev4% git show bcf020a6c4ac7cc5df064c66b182b2500470000a
commit bcf020a6c4ac7cc5df064c66b182b2500470000a
Merge: 62153e2... 064443d...
Author: Chris <chris@foo>

Date:   Tue Jan 27 12:57:45 2009 -0800

    Merge branch 'cjssp' into master

xdev4% git bisect log
# bad: [7a5d4f3c90b022cb66fd8ea1635c5de6768882d7] Merge branch 'foo' into master
# good: [d1014fd52bebd3c56db37362548e588165b7f299] Merge branch 'bar'
git bisect start 'HEAD' 'd1014fd52bebd3c56db37362548e588165b7f299' '--' 'apps'

# good: [064443d3164112554600f6da39a36ffb639787d7] Changed the name of an a/b test.  PLEASE PICK ME UP WITH NEXT PUSH.  thx
git bisect good 064443d3164112554600f6da39a36ffb639787d7
# bad: [bcf020a6c4ac7cc5df064c66b182b2500470000a] Merge branch 'cjssp' into master
git bisect bad bcf020a6c4ac7cc5df064c66b182b2500470000a
xdev4% git bisect reset 
xdev4%

Instead of spending an hour looking at changes, Roger was able to quickly walk a few revisions and run the unit tests he has to figure out which commit was the one causing trouble, and then get back to work squashing those bugs.

Roger is, like most developers, inherently lazy, and running through a series of revisions running unit tests sounds like "work" that doesn't need to be done. Fortunately for Roger, git-bisect(1) supports the subcommand "run" which goes hand in hand with unit tests or other tests. In the example above, let's pretend that Roger had a test case exhibiting the bug he was noticing. What he could actually do is let git bisect run automatically run a test script to run his unit tests to find the offending revision i.e.:

xdev4% git bisect start HEAD 324d2f2235c93769dd97680d80173388dc5c8253
Bisecting: 10 revisions left to test after this

[064443d3164112554600f6da39a36ffb639787d7] Changed the name of an a/b test.
xdev4% git bisect run ./mytest.sh

After executing the run command, git-bisect(1) will binary search the revisions between GOOD and BAD testing whether or not "mytest.sh" returns a zero (success) or non-zero (failure) return code until it finds the commit that causes the test to fail. The end result should be the exact commit the regression was introduced into the tree, after finding this Roger can either grab his rubber chicken and go slap his fellow developer around or fix the issue and get back to playing Nethack.

All in all git-bisect(1) is extraordinarily useful for pinning down bugs and diagnosing issues as they're introduced into the code base.

For more specific usage of `git bisect` refer to it's man page here: git-bisect(1) man page

Did you know! Slide is hiring! Looking for talented engineers to write some good Python and/or JavaScript, feel free to contact me at tyler[at]slide

Head in the clouds

R. Tyler Croy — Fri, 06 Mar 2009 07:42:03 +0000

I've spent the entire day thinking about "cloud computing", which is quite a twist for me. Seeing "impressive" conferences centered around "cloud computing" I've ridiculed the concept mercilessly, it has a phenomenally high buzzword/usefulness ratio, which makes it difficult to take seriously. It tends to have an air of idiocy attached to it of the same style that the re-invention of thin-clients did a few years back. That said, I think the concept is sound, and useful for a number of companies and uses (once distilled of the buzz).

Take Slide for example, we have a solid amount of hardware, hundreds of powerful machines constantly churning away on a number of tasks: serving web pages, providing back-end services, processing database requests, recording metrics, etc. If I start the work-week needing a new pool of machines either set up or allocated for a particular task, I can usually have hardware provisioned and live by the end of the week (depending on my Scotch offering to the Operations team, I can get it as early as the next day). If I can have the real thing I clearly have no need for cloud computing or virtualization.

That's what I thought, at least, until I started to think more about what would be required to get Slide closer to the lofty goal of continuous deployment. As I was involved in pushing for and setting up our Hudson CI server, I constantly check on the performance of the system and help make sure jobs are chugging along as they should be, I've become the defacto Hudson janitor.

Our current continuous integration setup involves one four-core machine running three separate instances of our server software as different users, processing jobs throughout the day. One "job" typically consists of a full restart of the server software (Python) and running literally every test case in the suite (we walk the entire tree aggregating tests). On average the completion of one job takes close to 15 minutes, and executes around 400+ test cases (and growing). Fortunately, and unfortunately, our Hudson machine is no longer able to service this capacity during development peak in the middle of the day, this is where the "cloud" comes in.

We have a few options at this point:

Setup another one or more machines
Rethink how we provision hardware for continuous integration

The fundamental problem with provisioning resources for continuous integration, at least at Slide, is that the requirements are bursty at best. We typically queue a job for a particular branch when a developer executes a git push (via the Hudson API and a post-receive hook). From around 9 p.m. until 9 a.m. we don't need but maybe two actual "executors" inside Hudson to handle the workload the night-owl developers tend to place on Hudson, from 12 p.m. until 7 p.m. however our needs fluctuate rapidly between needing 4 executors, and 10 executors. To exacerbate things further, due to "natural traffic patterns" in how we work, mid-afternoon on Wednesday and Thursday require even more resources as teams are preparing releases and finishing up milestones.

The only two possible solutions to solve the problem are to: build a continuous integration farm with full knowledge capacity will remain unused for large amounts of time, or look into "cloud computing" with service provides like Amazon EC2 which will allow for Hudson slaves to be provisioned on demand. The maintainer of Hudson, Kohsuke Kawaguchi has already started work on "cloud support" for Hudson via the EC2 plugin which makes this a real possibility. (Note: using EC2 for this at Slide was Dave's idea, not mine :))

Using Amazon EC2 isn't the only way to solve this "bursty" problem however, we could just as easily solve the problem in house with provisioning of Xen guests across a few machines. The downside of doing it yourself is amount of time between when you know you need more capacity and when you can actually add that capacity to your own little "cloud". Considering Amazon has an API for not only running instances but terminating them, it certainly provides a compelling reason to "outsource" the problem to Amazon's cloud.

I recommend following Kohsuke's development of the EC2 plugin for Hudson closely, as continuous integration and "the cloud" seem like a match made in heaven (alright, that pun was unnecessary, it sort of slipped out). At the end of the day the decision comes down to a very fundamental business decision: which is more cost effective, building my own farm of machines, or using somebody else's?

(footnote: I'll post a summary of how and what we eventually do to solve this problem)

Git Protip: A picture is worth a thousand words (git tag)

R. Tyler Croy — Fri, 16 Jan 2009 06:14:10 +0000

I've been sending weekly "Protip" emails about Git to the rest of engineering here at Slide for a while now, using the "Protips" as a means of introducing more interesting and complex features Git offers. Below is the fourth Protip written to date.

While the concept of "tagging" or "labeling" code is not a new, or original idea that was introduced with Git, our use of tags in a regular workflow does not predate the migration to Git however. At it's most basic level, a "tag" in any version control system is to take a "picture" of how the tree looks at a certain point in time such that it can be re-created later. This can be extremely helpful for both local and team development, take the following scenario for local development using tags:

Tim is extremely busy, most of his days working at an exciting, fast-paced start-up seem to fly by. With one particular project Tim is working on, a lot of code is changing at a very fast pace and the branch he's currently working in is stable one minute and destabilized the next. Tim has two basic options for leaving himself "bread-crumbs" to step back in time to a stable or an unstable state. The first, complicated option, is to mark his commit messages with something like "STABLE", etc so he can git diff or git reset --hard from the current HEAD to the last stable point of the branch.

The second option is to make use of tags. Whenever Tim reaches a stable point in his turmultuous development, he can simply run:
git tag wip-protips_`date "+%s"
(or something similar, `date` added to ensure the tag is unique). If Tim finds himself too far down the wrong path, he can rollback his branch to the latest tag (git reset --hard protiptag), create a new stable branch based on that tag (git checkout -b wip-protip-2 protiptag), or diff his current HEAD to the tag to see what all he's changed since his branch was stable (git diff protiptag...HEAD)

This local development scenario can become a team development scenario involving tags, if for example, Tim needed QA to start testing portions of his branch (his changes are just that important). Since the current HEAD of Tim's branch is incredibly unstable, he can push his tag to the central repository so QA can push a stage using the tag to the last stable point in the branch's history with the command: git push origin tag protiptag

Tags are similar to most other "refs" in Git insofar that they are distributable, if I execute git fetch your-repo --tags, I can pull the tags you've set in "your-repo" and apply them locally aid development. The distributed nature is primarily how tags differ in Git from Subversion, nearly the rest of the concept is the exact same.

Currently at Slide, tag usage is dominated by the post-receive hook in the central repository, where every push into the central repository ("origin") in the branch release branch is tagged. This allows us to quickly "revert" bad live pushes temporarily, by simply pushing the last "good" tagged release, to ensure minimal site destabilization (while we correct live issues outside of the release branch).

For more specific usage of `git tag` refer to the git-tag(1) man page

Did you know! Slide is hiring! Looking for talented engineers to write some good Python and/or JavaScript, feel free to contact me at tyler[at]slide

But Who Will Write The Tests?

R. Tyler Croy — Mon, 12 Jan 2009 16:43:02 +0000

In addition to frothing at the mouth about Git, I've been really getting into the concept of automated unit tests lately (thus my interest in Hudson). Just like code comments however, tests are good, no tests is bad, wrong tests is worse. That means once you give in to the almighty power of unit testing, you are saddled with the curse of knowing that you will have to update them, forever.

Taking up Test-driven Development is like having a child, if you are at a point in your life where you're ready to accept that kind of responsibility, it can be wonderful, a lot of work, but ultimately you will feel satisfied with your new role as a Responsible Developer (tm). If you're not prepared to take on the burden that TDD will present you with, you will likely regret it or neglect your tests (Deadbeat Developer, I like this metaphor).

In the Top Friends Team at Slide, we practice the more "loose" definition of TDD; tests are not written before functionality is written, but rather functionality is written, and then as part of the QA and release process, the appropriate and accompanying tests are written. Our basic workflow is usually as follows:

Tickets are written and assigned to milestones and developers in Trac
Branch is created in central Git repository
General plan-of-action is discussed between developers
Hack-hack-hack
Code complete is reached, QA starts to test milestone
Developers write tests if needed for functionality
Once QA signs off, and tests look solid, code is shipped live

There are two primary flaws with this workflow, the first and most obvious one is that it is far to easy to "forget to write the tests." That is, the project scheduled to start development tends to "flow forward" into the allotted test-writing time. As important as test coverage is, at the end of the day Slide did not raise funding on having solid test coverage, and our priorities lie in shipping software, first and foremost. Solving the flow-forward of scheduled projects into any available space is something that can be worked on, but never solved, it really comes down to discipline between those in charge of setting up any given project's particular roadmap.

The second, more subtle flaw in this workflow, and I think all Test-driven Devleopment workflows, revolves around the writer of the tests. The fundamental nature of almost all bugs in software is human error, our natural tendency to make mistakes means that nothing we do will ever be perfect, including our tests. If Developer A is writing a couple new methods to handle data validation prior to that data going into the database. Chances are that Developer A's life is going to be made far easier by writing some test cases to run through some predefined user-input, and pass his validation code over it. Therein lies the problem, if the developer doesn't think of a particular edge case when he's writing the code to handle the data validation, the chances he'll remember and account for that particular edge case while he's working on the unit tests is nil.

How do you really ensure that tests are of high enough quality to actually catch errors and regressions?

I think a certain extent of intra-team test writing and code review, depending on the level of communication between developers, can really help. In this case less developer communication is better. If Developer A tells Developer B how his code works, Developer B is now going to have an unnecessary expectation when he starts to write tests for Developer A's code. If Developer B reviews the code for what it actually is, instead of what Developer A thinks it is, the tests that will ultimately be written will be more thorough than if Developer A had written the whole suite himself.

This still isn't sufficiently fool-proof to where I feel all that confident in test coverage, the tests being written are subject to the availability, thoroughness and understanding that Developer B brings to the table. Inside a small team like this one, one of those is almost always in short supply (usually availability).

One approach I'm anxious to try is the more active involvement of QA engineers in the test writing process, both in the pre-fail and post-fail scenarios. The pre-fail scenario being one like that which I detailed above, where new code is being written. In this case a QA engineer's experience can help guide the developer on what sets of user-input have typically caused issues in the past. The second case, post-fail, is actually already occuring at Slide; a live issue, data validity bug, or regression is caught by QA engineers who detail the reproduction case in Trac and as a result a regression test can be written for that specific issue.

This still is subject to the three things I cited above: availability, thoroughness and understanding of those involved. I still have a lot of unanswered questions about the ideal QA and Dev workflow however, how does this scale to a team of tens or hudnreds? Who writes the tests for large teams? What about a team of 1 Dev and a 1 QA, what about the lone-hacker? How do you write quality code, without getting bogged down in the mush of writing thousands of tests for everything you can imagine could go wrong?

Who writes the tests?

Find me on github (rtyler)

R. Tyler Croy — Mon, 05 Jan 2009 10:04:26 +0000

Rod reminded me with his comment in one of my other posts that I've not yet mentioned github.

I've got a bunch of my nonsense thrown up on github.com/rtyler, it's awesome (no really, github rocks my socks, those guys are good people).

Git Protip: By commiting that revision, you fucked us (git revert)

R. Tyler Croy — Wed, 10 Dec 2008 10:35:59 +0000

The concept of "revert" in Git versus Subversion is an interesting, albeit subtle, change, mostly in part due to the subtle differences between Git and Subversion's means of tracking commits. Just as with Subversion, you can only revert a committed change, unlike Subversion there is a 1-to-1 mapping of a "commit" to a "revert". The basic syntax of revert is quite easy: git revert 0xdeadbeef, and just like a regular commit, you will need to push your changes after you revert if you want others to receive the revert as well.
In the following example of a revert of a commit, I also use the "-s" argument on the command line to denote that I'm signing-off on this revert (i.e. I've properly reviewed it).

xdev3% git revert -s c20054ea390046bd3a54693f2927192b2a7097c2
----------------[Vim]----------------
Revert "merge-to-release unhide 10000 coin habitat"

This reverts commit c20054ea390046bd3a54693f2927192b2a7097c2.

Signed-off-by: R. Tyler Ballance <tyler@slide.com>
# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
# On branch wip-protips
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#   modified:   bt/apps/pet/data.py

+ python bt/qa/git/post-commit.py -m svn@slide.com
Sending a commit mail to svn@slide.com
Created commit a6e93b8: Revert "merge-to-release unhide 10000 coin habitat"
 1 files changed, 4 insertions(+), 3 deletions(-)

Reverting multiple commits

Since git revert will generate a new commit for you every time you revert a previous commit, reverting multiple commits is not as obvious (side note: I'm aware of the ability to squash commits, or --no-commit for git-revert(1), I dislike compressing revision history when I don't believe there shouldn't be compression). If you want to revert a specific merge from one branch into the other, you can revert the merge commit (provided one was generated when the changes were merged). Take the following example:

commit 81a94bb976dfaaaae42ae2600b7e9e88645ebd81
Merge: 8134d17... d227dd8...
Author: R. Tyler Ballance <tyler@slide.com>
Date:   Thu Nov 20 10:15:16 2008 -0800

    Merge branch 'master' into wip-protips

I want to revert this merge since it refreshed my wip-protips branch from master, and brought in a lot changes tat have destablized my branch. In the case of reverting a merge commit, you need to specify -m and a number to denote where the mainline branch for Git to pivot off of is, -m 1 usually suffices. So the revert of the commit above will look something like this:

git revert 81a94bb976dfaaaae42ae2600b7e9e88645ebd81 -m 1

Then my revert commit will be committed after I review the change in Vim:

commit 8cae4924c4c05dadaaeccb3851cfc9ec1b8efd0f
Author: R. Tyler Ballance <tyler@slide.com>
Date:   Thu Nov 20 10:20:44 2008 -0800

    Revert "Merge branch 'master' into wip-protips"
    
    This reverts commit 81a94bb976dfaaaae42ae2600b7e9e88645ebd81.

Let's take the extreme case where I don't have a merge commit to pivot off of, or I have a particular set of bare revisions that I need to revert in one pass, you can start to tie Git subcommands together like git-rev-list(1) to accomplish this. This hypothetical situation might occur if some swath of changes have been applied to a team-master that need to be backed out. Without a merge commit to key off of, you have to revert the commits one by one, but that doesn't mean you have to revert each one by hand:
for r in `git rev-list master...master-fubar --since="8:00" --before="12:00" --no-merges`; do git revert --no-edit -s $r; done
In the above example, I can use git-rev-list(1) to give me a list of revisions that have occurred on "master-fubar" that have not occurred on "master" between the times of 8 a.m. and 12 p.m., excluding merge commits. Since git-rev-list(1) will return a list of commit hashes by default, I can loop through those commit hashes in chronological order and revert each one. The inner part of the loop signs-off on the revert (-s) and then tells git-revert(1) to auto-commit it without opening the commit message in Vim (--no-edit). What this then outputs is the following:

xdev% for r in `git rev-list master...master-fubar  --since="8:00" --before="12:00" --no-merges`; do git revert --no-edit -s $r; done
Finished one revert.
Created commit b6810d7: Revert "a test, for you"
 1 files changed, 1 insertions(+), 1 deletions(-)
Finished one revert.
Created commit 83156bd: Revert "These are not the droids you are looking for
 1 files changed, 2 insertions(+), 0 deletions(-)
Finished one revert.
Created commit 782f328: Revert "commented out stuff"
 1 files changed, 0 insertions(+), 3 deletions(-)
Finished one revert.
Created commit 2b8d664: Revert "back on again"
 1 files changed, 1 insertions(+), 1 deletions(-)
xdev%

For specific usage of "git-revert" or "git-rev-list" refer to the git-revert(1) man page or the git-rev-list(1) man page

Did you know! Slide is hiring! Looking for talented engineers to write some good Python and/or JavaScript, feel free to contact me at tyler[at]slide

Git Protip: Learning from your history (git log)

R. Tyler Croy — Tue, 02 Dec 2008 22:03:40 +0000

One of the major benefits to using Git is the entirety of the repository being entirely local and easily searched/queried. For this, Git has a very useful command called git log which allows you to inspect revision histories in numerous different ways between file paths, branches, etc. There are a couple basic scenarios where git log has become invaluable, for me at least, in order to properly review code but also to track changes effectively from point A to point B.

What's Dave been working on lately? (with diffs)
- git log -p --no-merges --author=dave
The --no-merges option will prevent git log from displaying merge commits which are automatically generated whenever you pull from one Git branch to another
Before I merge this branch down to my team master, I want to know what files have been changed and what revisions
- git log --name-status master-topfriends...proj-topfriends-thing
Git supports the ability with git log and with git diff to provide unidirectional branch lookups or bidirectional branch lookups. For example, say the left branch has commits "A, B" and the right branch has commits "A, C". The ... syntax will output "C", whereas .. will output "B, C"
I just got back from a vacation, I wonder what's changed?
- git log --since="2 weeks ago" --name-status -- templates
At the tail end of a git log command you can specify particular paths to look up the histories for with the -- operator, in this case, I will be looking at the changes that have occured in the templates directory over the past two weeks
Most recent X number of commits? (with diffs)
- git log -n 10 --no-merges -p

All git log commands automatically filter into less(1) so you can page through the output like you would normally if you executed a svn log | less. Because git log is simply reading from the locally stored revision history you can quickly grep the history by any number of different search criteria to gain a better understanding of how the code base is changing and where.

For more specific usage of `git log` refer to the git log man page

Did you know! Slide is hiring! Looking for talented engineers to write some good Python and/or JavaScript, feel free to contact me at tyler[at]slide

Git Protip: Stash the goods yo (git stash)

R. Tyler Croy — Tue, 25 Nov 2008 07:50:06 +0000

For about a month now I've been sending weekly "Protip" emails about Git to the rest of engineering here at Slide. I've been using them to slowly and casually introduce some of the more "interesting" features Git has to offer as we move away from Subversion entirely. Below is the first Protip I sent around, I'll be sure to send the rest in good time.

Given the nature of how Git is structured, in that your "working copy" is also your "repository" you might find yourself switching branches relatively often. While you can actually switch branches with uncommited changes outstanding in your Git directory, it's not advised (as you might forget you're commiting changes in the wrong branch, etc). You have two options if you are halfway through some work, one is to commit a checkpoint revision, but the other is to make use of the git stash command.

A scenario where this becomes especially useful would be: Bill is working in his local branch "wip-funtime" on replacing large swaths of unnecessary useless code and Ted accidentally pushes some of Bill's other changes from another branch live and things break. Bill could commit his code and write a fairly uninformative log message like "checkpoint" which cheapens the value of the revision history of his changes or Bill can use git stash to snapshot his currently working state and context switch. In this case Bill would execute the following commands:

git stash
git checkout master-media
perform hotfixes
git checkout wip-funtime
git stash pop

After performing the git stash pop command, Bill's Git repository will be in the exact same state, all his uncommitted changes in tact, as it was when he originally stashed and context-switched.

For specific usage of `git stash` refer to the git stash man page

Example usage of `git stash`

Stashing changes away

tyler@starfruit:~/source/git/main/bt> git stash
Saved working directory and index state "WIP on master-topfriends: 7b1ce9e... TOS copy fix"
(To restore them type "git stash apply")
HEAD is now at 7b1ce9e TOS copy fix
tyler@starfruit:~/source/git/main/bt>

Looking at the stash

tyler@starfruit:~/source/git/main/bt> git stash list
stash@{0}: WIP on master-topfriends: 7b1ce9e... TOS copy fix
stash@{1}: On master-topfriends: starfruit complete patchset
stash@{2}: On wip-classmethod: starfruit patches
tyler@starfruit:~/source/git/main/bt>

Grabbing the latest from the stash

tyler@starfruit:~/source/git/main/bt> git stash pop
Dropped refs/stash@{0} (94b9722b5a999c32c4361d795ee8f368d8412f9a)
tyler@starfruit:~/source/git/main/bt>

Grabbing a specific stash

tyler@starfruit:~/source/git/main/bt> git stash list
stash@{0}: WIP on master-topfriends: 7b1ce9e... TOS copy fix
stash@{1}: On master-topfriends: starfruit complete patchset
stash@{2}: On wip-classmethod: starfruit patches
tyler@starfruit:~/source/git/main/bt> git stash apply 2
# On branch master-topfriends
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#
#       modified:   db/dbroot.py
#       modified:   gogreen/coro.py
#       modified:   py/bin/_makepyrelease.py
#       modified:   py/initpkg.py
#       modified:   py/misc/_dist.py
#       modified:   py/misc/testing/test_initpkg.py
#       modified:   py/path/local/local.py
#       modified:   py/test/terminal/terminal.py
tyler@starfruit:~/source/git/main/bt>

Did you know! Slide is hiring! Looking for talented engineers to write some good Python and/or JavaScript, feel free to contact me at tyler[at]slide

Why we chose Git, a rebuttal.

R. Tyler Croy — Tue, 25 Nov 2008 04:24:38 +0000

One thing I learned early on in the internet, when is was more of a cobbling instead of a series, of tubes, was not to feed trolls. That said, I found that my post "Delightfully Wrong About Git" had found it's way into such silly news aggregation machines as DZone, Reddit and Hacker News. Some of the points raised in the comments were valid and warrant a response, while the majority of them were the standard responses to any discussion about version control "psh, dumb. should have used [Bazaar/Mercurial/Darcs/Subversion/Team Foundation System]"

Why not another (D)VCS?
One of the most resounding criticisms/questions was this one, why not Bazaar? Why not Mercurial! My favorite, albeit childish, retort is "why?" But I can say that I have tried a variety of other version control systems, Git, Bazaar, CVS, Subversion, Perforce and some other proprietary VCSes at previous employers. While both Darcs and Mercurial seem to be very solid DVCSes, they suffer from a problem of momentum, Darcs in particular. They both appear to be victims of Git's success, while there is inherently nothing wrong with either of them, they are competing with Linus' love-child, Git. When chosing to move to a new VCS in a company that is well over 50+ employees, the staying power of the technology you chose is important. I feel confident that Git will not only be supported, but actively developed and improved for years to come.

More importantly than that though, I like Git. Is that not enough right there? Slide makes excessive use of branches, tags and other "complex" VCS concepts that centralized systems like CVS and Subversion have trouble with. With Subversion creating branches in the volume in which we create branches spiralled out of control with branches becoming "stale" quickly, meaning that if we didn't refresh the branch regularly with updates from trunk it would be nearly impossible to cleanly merge back down into trunk. With my current Git clone of our primary repository, I have 23 branches (roughly 6 personal local branches, 5 old branches, and 12 active branches). Our primary Git repository has been online for about 6 months and currently has 68 branches in it, rougly 55 are active.

Why all the love for Git, but nobody every talks about Bazaar, Mercurial, Darcs, etc? Sure Git is faster, but unless you've got a enormous code base (like the linux kernel), it seems like Bazaar or Mercurial would be a better choice than Git.

One of the better known selling points of Git is that it's fast. My cloned repository of the primary Slide Git repository weighs in at a hefty 7.1GB. The latest revision number in our Subversion repository is in the 103,000 range, tacked onto that our tree is just over 2GB in size, and you've got a lot of history to keep track of. Git handles this without a sweat. despite hitting the disk extremely hard when switching to a very out of date branch. With this fix from Nico, the last of the mmap(2) allocation issues we were experiencing vanished as well.

Stop re-inventing the wheel!
One of the more interesting sentiments I noticed perusing the various comments made regarding my previous post were that we are "re-inventing the wheel" by writing scripts, hooks and other wrappers to use a product like Git. The notion that having scripts and hooks for something you use in daily development is re-inventing the wheel, or gratuituous strikes me as laughable at best. We're developers. We write scripts. Why didn't I ever write a myriad of scripts when I was an avid Subversion user? I did.. There's an enormous different between writing scripts to compensate for a poorly performing product, and writing scripts to further enhance you or your colleagues' workflows, Git's hook support falls into the latter category.

The "religion" aspect of the whole version control debate was never considered in our transition to Git, nor was the buzz. I'm far more interested in what makes other VCSes better or worse than Git, so that Git can be improved instead of a justification to ditch Git for yet-another-dvcs. I like to think of the various tools like version control that we developers use as something more relatable: work pants. A good pair of work pants should be flexible enough to allow you to get your work done, modest enough to stay out of the way and most importantly, a good pair of work pants should keep your junk safe ;)

I'm still happy to answer more specific questions about Git and how/why it works for us as well as it has, but I think most of the questions I've seen thus far have been answered above.

Did you know! Slide is hiring! Looking for talented engineers to write some good Python and/or JavaScript, feel free to contact me at tyler[at]slide

Git integration with Hudson and Trac.

R. Tyler Croy — Mon, 24 Nov 2008 05:51:04 +0000

As I mentioned in my previous post about Git at Slide, I wanted to answer some questions that we had to answer to migrate to Git for our development workflow. One of the major questions that had to be answered, especially for our QA department to sign off on the idea was:

How will Git integrate with Hudson, Trac and our other pieces of development infrastructure?

For us to use any version control system, centralized or decentralized, there had to be a "central" point for changes to integrate into in order for us to properly test releases and then ship them to the live site. With this requirement, we oriented our use of Git around a centralized repository which developers pull from, and push to on a regular basis.

In order for Git to integrate into Trac and Hudson, we opted for baking the functionality we needed into the post-receive hook on the centralized repository instead of relying on GitTrac, or the Hudson Git plugin to do what we needed it do to.

You can find the script below, or in this GitHub repository. The script requires the Trac XML-RPC plugin to be installed in order to properly annotate tickets when changes are pushed into the central repository. The notation syntaxes that the post-receive.py script supports in commit messages are:

re #12345
qa #12345
attn bbum,fspeirs

As one might expect, the first notation: "re #12345" will simply annotate a ticket with the commit message and the branch in which the commit was pushed into. The "qa #12345" notation part of an internal notation of marking tickets in Trac as "Ready for QA", which let's our QA engineers know when tickets are ready to be verified; a "qa" note in a commit message will reference the commit and change the status of the ticket in question. The final notation that the script supports: "attn bbum,fspeirs" is purely for calling attention to a code change, or to ask for a code review. When a commit is pushed to the central repository with "attn" in the commit message, an email with the commit message and diff will be emailed to the specified recipients.

In addition to updating Trac tickets, pushes into any branch that have a Hudson job affiliated will use the Hudson External API to queue a build for that branch. In effect, it you "git push origin master", the post-receive.py script will ping Hudson and ask it to queue a build of the "master" job.

I have included the script inline below for those weary of clicking links like this one to the GitHub repository containing the script. Enjoy :)

'''
Copyright (c) 2008 Slide, Inc
 
Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:
 
The above copyright notice and this permission notice shall be included in
all copies or substantial portions of the Software.
 
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
THE SOFTWARE.
'''
 
'''
	For questions, patches, etc contact R. Tyler Ballance <[email protected]>
'''
import getpass
import os
import re
import socket
import smtplib
import sys
import time
import xmlrpclib
 
from optparse import OptionParser
 
MAIL_SERVER = 'your_mail_server.com'
MAIL_SUFFIX = '@mycompany.com'
BUILD_HUDSON = True
HUDSON_URL = 'http://hudson'
TRAC_XMLRPC_URL = 'URL_TO_TRAC/projects/MYPROJECT/login/xmlrpc'
 
def rpcProxy(user='qatracbot', password=None):
	password = password or os.getenv('TRAC_PASS')
	return xmlrpclib.ServerProxy('https://%s:%s@%s' % (user, password, TRAC_XMLRPC_URL))
 
def _send_commit_mail(user, address, subject, branch, commits, files, diff):
	print 'Sending a GITRECEIVE mail to %s' % address
	message = 'Commits pushed to %s:\n--------------------------------------\n\n%s\n--------------------------------------\n%s\n--------------------------------------\n%s' % (branch, commits, files, diff)
	_send_mail(user, address, subject, message)
def _send_attn_mail(user, destuser, diff):
	print 'Sending a "please review" mail to %s' % destuser
	message = '''Good day my most generous colleague! I would hold you in the highest esteem and toast you over my finest wines if you would kindly review this for me\n\n\t - %(user)s\n\nDiff:\n------------------------------------------------\n%(diff)s''' % {'diff' : diff, 'user' : user}
	addresses = []
	for d in destuser.split(','):
		addresses.append('%s%s' % (d, EMAIL_SUFFIX))
	_send_mail(user, addresses, 'Please review this change', message)
 
def _send_mail(user, address, subject, contents):
	try:
		if not isinstance(address, list):
			address = [address]
		s = smtplib.SMTP(MAIL_SERVER)
		message = 'From: %s%s\r\nTo: %s\r\nSubject: %s\r\n\r\n%s\n' % (user, MAIL_SUFFIX, ', '.join(address), subject, contents)
		s.sendmail('%s%s' % (user, MAIL_SUFFIX), address, message)
		s.quit()
	except:
		print 'Failed to send the email :('
 
def _update_ticket(ticket, message, options={}):
	rpc = rpcProxy()
	rpc.ticket.update(ticket, message, options)
	return rpc
 
def find_re(commit):
	return map(int, re.findall(r'(?i)\s+re\s*#([0-9]+)', commit))
def handle_re(branch, commit, ticket):
	print 'Annotating ticket #%s' % ticket
	message = '''The following was committed in "%(branch)s":
			{{{	
%(commit)s }}}
		''' % {'branch' : branch, 'commit' : commit}
	_update_ticket(ticket, message)
 
def find_qa(commit):
	return map(int, re.findall(r'(?i)\s+qa\s*#([0-9]+)', commit))
def handle_qa(branch, commit, ticket):
	print 'Marking ticket #%s as "ready for QA"' % ticket
	message = '''The following was committed in "%(branch)s":
			{{{	
%(commit)s }}}
		''' % {'branch' : branch, 'commit' : commit}
	rpc = _update_ticket(ticket, message, options={'status' : 'qa'})
 
def find_attn(commit):
	return re.findall(r'(?i)\s+attn\s*([A-Za-z,]+)', commit)
def handle_attn(branch, commit, attn):
	# Unpack commit from this: "commit 5f4c31f3c31347c62d68ecb5f2c9afa3333f4ad0\nAuthor: R. Tyler Ballance <[email protected]>\nDate: Wed Nov 12 16:57:32 2008 -0800 \n\n Merge commit 'git-svn' \n\n  \n \n"
	try:
		commit_hash = commit.split('\n')[0].split(' ')[1]
	except:
		return # fuk it
	diff = os.popen('git show --no-color %s --pretty=format:"Author: %%cn <%%ce>%%n%%s%%n%%n%%b%%n%%n%%H"' % commit_hash).read().rstrip()
	_send_attn_mail(getpass.getuser(), attn,  diff)
 
def mail_push(address, oldrev, newrev, refname):
	user = getpass.getuser()
	machine = socket.gethostname()
	base_git_diff = 'git diff %s %s' % (oldrev, newrev)
	files_diffed = os.popen('%s --name-status' % (base_git_diff)).read().rstrip()
	full_diff = os.popen('%s -p --no-color' % (base_git_diff)).read().rstrip()
	''' git rev-parse --not --branches | grep -v "$new" | git rev-list "$old".."$new" --stdin '''
	commits = os.popen('git rev-parse --not --branches | grep -v "%s" | git rev-list %s..%s --stdin --pretty=format:"Author: %%cn <%%ce>%%nDate: %%cd %%n%%n %%s %%n%%n %%b %%n %%n-------[post-receive marker]------%%n" --first-parent ' % (newrev, oldrev, newrev)).read().rstrip()
	branch = refname.split('/')[-1]
	mail_subject = 'GITRECEIVE [%s/%s] %s files changed' % (machine, branch, len(files_diffed.split('\n')))
 
	if branch == 'master-release':
		print 'Tagging release branch'
		tagname = 'livepush_%s' % (time.strftime('%Y%m%d%H%M%S', time.localtime()))
		sys.stderr.write('Creating a tag named: %s\n\n' % tagname)
		os.system('git tag %s' % tagname)
		mail_subject = '%s (tagged: %s)' % (mail_subject, tagname)
 
	if BUILD_HUDSON_JOB:
			print 'Queuing the Hudson job for "%s"' % branch
			os.system('/usr/bin/env wget -q -O /dev/null http://%s/job/%s/build' % (HUDSON_URL, branch))
 
	_send_commit_mail(user, address, mail_subject, branch, commits, files_diffed, full_diff)
 
	if branch == 'master':
		return # we don't want to update tickets and such for master/merges
 
	commits = filter(lambda c: len(c), commits.split('-------[post-receive marker]------'))
	commits.reverse()
	for c in commits:
		if c.find('Squashed commit') >= 0:
			continue # Skip bullshit squashed commit
 
		for attn in find_attn(c):
			handle_attn(branch, c, attn)
 
		for ticket in find_re(c):
			handle_re(branch, c, ticket)
 
		for ticket in find_qa(c):
			handle_qa(branch, c, ticket)
 
 
if __name__ == '__main__':
	op = OptionParser()
	op.add_option('-m', '--mail', dest='address', help='Email address to mail git push messages to')
	op.add_option('-o', '--oldrev', dest='oldrev', help='Old revision we\'re pushing from')
	op.add_option('-n', '--newrev', dest='newrev', help='New revision we\'re pushing to')
	op.add_option('-r','--ref', dest='ref', help='Refname that we\'re pushing')
	opts, args = op.parse_args()
 
	if not opts.address or not opts.oldrev or not opts.newrev or not opts.ref:
		print '*** You left out some needed parameters! ***'
		exit
 
	mail_push(opts.address, opts.oldrev, opts.newrev, opts.ref)

Did you know! Slide is hiring! Looking for talented engineers to write some good Python and/or JavaScript, feel free to contact me at tyler[at]slide

Delightfully Wrong About Git

R. Tyler Croy — Sun, 23 Nov 2008 02:51:50 +0000

A very long time ago I mentioned on Twitter that I was looking at Git as a replacement for Subversion and Perforce with my personal projects, but lamented moving to Git at Slide would not be feasible

Like most disagreements I've had with people on technology in the past, immediately after I said it, I actively tried to prove myself wrong. Back in April when I made the statement above, Subversion 1.4 was "good enough" (just barely) for what we wanted to do as far as source control, but I became more and more curious about whether or not we could move to Git.

Back in April, after spending a week with projects like Tailor and git-svn(1) I started to look at the potential of moving just my team over to Git for evaluation purposes. By the end of May I had requested Git to be installed on the machines that we use for development on a day-to-day basis and we moved the team over to Git by the second week of June.

What followed were six months of sloshing uphill, some of the most notable milestones that we had to figure out in this time frame were:

Whereas in the Subversion architecture with a central repository there is a very clear development focal point for sharing code between developers, what is this in the Git workflow?
How do you ensure developers don't forget code was committed "in that one branch, in that one repository" and keep track of code
How will Git integrate with Hudson, Trac and our other pieces of development infrastructure? (answered here)

I'll be answering these questions and share some of the scripts, hooks, and documentation we've written internally to make moving to Git throughout the company a reality. I wish I could say I was responsible for it all, but there were a number of other engineers that were extremely important in defining best practices, and what this shiny new world without Subversion would look like.

At the end of the day, I'm pleased as punch with the transition. I don't hate Subversion, I just love Git; call me "spoiled" but I think we deserve something more than a system that strives to be "a better CVS".

Update: I've posted an addendum: Why we chose Git, a rebuttal

Did you know! Slide is hiring! Looking for talented engineers to write some good Python and/or JavaScript, feel free to contact me at tyler[at]slide

Reliable Locks in Hudson

R. Tyler Croy — Thu, 06 Nov 2008 05:23:41 +0000

There has been some amount of discussion on the Hudson user's list recently about the status of the "Locks and Latches" plugin. The plugin allows for one to create "locks" for Jobs in a similar manner to how "locks" work in a multithreaded programming environment. The need for such a plugin becomes very clear once you start to run multiple jobs that depend on some set of shared resources, take the following example:

Jobs A,B,C must run unit tests that fetch data from a test site
Slave #1 can only run one instance of Apache at a time

How one would accomplish this with the Locks and Latches plugin would be to create a lock like "Site Lock" in the Hudson configuration, and then bind Jobs A, B, C to that Lock. Making the (large) assumption that the plugin works correctly and locks properly in order to prevent A and B from running concurrently, this would be enough to satisfy the requirements we have for the scenario above. Unfortunately it seems the plugin is largely unmaintained and buggy; in the past couple weeks of experimenting with such a set up on a variety of different slaves we've noticed that the locks aren't always respected, causing some locked jobs to execute in parallel spewing bad test results and build failures (the crux of this issue seems ot have been reported by Sergio Fernandes in #2450).

The Loopback Slave
The easiest way I found to work around the short-comings of the Locks and Latches plugin was to "break up" the Locks. Locks are only really useful if you have more than one "executor" on a Hudson node, in order to allow Hudson to execute jobs simultaneously. In essence, if you only have one executor, the Hudson queueing system will technically perform your "lock" for you by default. And thus the "loopback slave" was born! When explaining this to a co-worker, I likened my workaround to the fork(2) call, whereas the Locks and Latches plugin is much more of a pthread_mutex_lock(2) call. According to the "Distributed Builds" page on the Hudson wiki, you can start slave agent headlessly on any machine, so why not the master node?

Above is the configuration of one such "loopback slave" that took the place of one of the executors on the master node.

After setting up the loopback slave, it's just a matter of tying the Job to that node for building.

In short our set up was before: Jobs A, B, C all use the Lock "Site Job" in order to queue properly. With this change, now there is no lock, and Jobs A, B, C are all bound to the loopback slave in place of the lock on the master node. While certainly not ideal, given the frustrations of the Locks and Latches plugin going unmaintained this is the best short-term solution I've come up with thus far.

Did you know! Slide is hiring! Looking for talented engineers to write some good Python and/or JavaScript, feel free to contact me at tyler[at]slide

Git back into Subversion, Mostly Automagically (Part 3/3)

R. Tyler Croy — Thu, 02 Oct 2008 06:41:52 +0000

Thus far I've covered most of the issues and hurdles we've addressed while experimenting with Git at Slide in parts 1 and 2 of this series, the one thing I've not covered that is very important to address is how to work in the "hybrid" environment we currently have at Slide, where as one team works with Git and the rest of the company works in Subversion. Our setup involves having a "Git-to-Subverison" proxy repository such that everything to the "left" of that proxy repository is entirely Subversion without exceptions and everything to the "right" of that repository is entirely Git, without exceptions. Part of my original motivation for putting this post at the end of the series was that, when I originally wrote the first post on "Experimenting with Git at Slide" I actually didn't have this part of the process figured out. That is to say, I was bringing code back and forth between Git and Subversion courtesy of git-svn(1) and some gnarly manual processes.

No Habla Branching

The primary issue when bringing changesets from Git to Subversion is based in the major differences between how the two handle branching and changesets to begin with. In theory, projects like Tailor were created to help solve this issue by first translating both the source and destination repositories into an intermediary changeset format in order to cross-apply changes from one end to the other. Unfortunately after I spent a couple days battling with Tailor, I couldn't get it to properly handle some of the revisions in Slide's three year history.

If you've ever used git-svn(1) you might be familiar with the git-svn dcommit command, which will work for some percentage of users that want to maintain dual repositories between Git and Subversion, things break down however once you introduce branching into the mix.

Up until Subversion 1.5, Subversion had no concept of "merge tracking" (even in 1.5, it requires the server and client to be 1.5, it also makes nasty use of svn props). Without the general support for "merge tracking" the concept of a changeset sourcing from a particular branch or the concept of a "merge commit" are entirely foreign in the land of Subversion. In less mumbo jumbo, this effectively means that the "revisions" that you would want to bring from Git into Subversion need to be "flattened" when being "dcommitted" into Subversion's trunk. Git supports a means of flattening revision history when merging and pulling by way of the "--squash" command line argument, so this flattening for git-svn is possible.

Giant Disclaimer

What I'm about to write I dutifully accept as Git-heresy, a nasty hack and not something I'm proud of.

Flattening into Subversion

First the icky bash script that supports properly flattening revisions into the "master" branch in the git-svn repository and dcommits the results:

#!/bin/bash
 
MERGE_BRANCH=mergemaster
REPO=$1
BRANCH=$2
 
if [[ -z "${1}" || -z "${2}" ]]; then
	echo "===> You must provide a \"remote\" and a \"refspec\" for Git to use!"
	echo "===> Exiting :("
	exit 1;
fi
 
LATEST_COMMIT=`git log --max-count=1 --no-merges --pretty=format:"%H"`
 
function master
{
	echo "==> Making sure we're on 'master'"
	git checkout master
}
 
function setup_mergemaster 
{
	master
	echo "==> Killing the old mergemaster branch"
	git branch -D $MERGE_BRANCH
 
	echo "==> Creating a new mergemaster branch"
	git checkout -b $MERGE_BRANCH
	git checkout master
}
 
function cleanup
{
	rm -f .git/SVNPULL_MSG
}
 
function prepare_message
{
	master
 
	echo "===> Pulling from ${REPO}:${BRANCH}"
	git pull ${REPO}|> ${BRANCH}|>
	git checkout ${MERGE_BRANCH}|>
 
	echo "==> Merging across change from master to ${MERGE_BRANCH}"
	git pull --no-commit --squash . master
 
	cp .git/SQUASH_MSG .git/SVNPULL_MSG
 
	master
}
 
function merge_to_svn
{
	git reset --hard ${LATEST_COMMIT}|>
	master
	setup_mergemaster
 
	echo "===> Pulling from ${REPO}:${BRANCH}"
	git pull ${REPO}|> ${BRANCH}|>
	git checkout ${MERGE_BRANCH}|>
 
	echo "==> Merging across change from master to ${MERGE_BRANCH}"
	git pull --no-commit --squash . master
 
	echo "==> Committing..."
	git commit -a -F .git/SVNPULL_MSG && git-svn dcommit --no-rebase
 
	cleanup
}
 
setup_mergemaster
 
prepare_message
 
merge_to_svn
 
master
 
echo "===> All done!"

Gross isn't it? There were some interesting things I learned when experimenting with this script, but first I'll explain how the script is used. As I mentioned above there is the "proxy repository", this script operates on the git-svn driven proxy repository, meaning this script is only invoked when code needs to be propogated from Git-to-Subversion as opposed to Subversion-to-Git which git-svn properly supports by default in all cases. Since this is a proxy repository, that means all the "real" code and goings-on occur in the "primary" Subversion, and "primary" Git repositories, so the code is going along this path: Primary_SVN <-> [proxy] <-> Primary_Git
This setup means when we "pull" (or merge) from Primary_Git/master we are going to be flattening at that point in order to properly merge it into the Primary_SVN. Without further ado, here's the breakdown on the pieces of the script:

function setup_mergemaster 
{
	master
	echo "==> Killing the old mergemaster branch"
	git branch -D $MERGE_BRANCH
 
	echo "==> Creating a new mergemaster branch"
	git checkout -b $MERGE_BRANCH
	git checkout master
}

What the setup_mergemaster branch is responsible for is deleting any prior branches that have been used for merging into the proxy repository and Primary_SVN. It gives us a "mergemaster" branch in the git-svn repository that is effectively at the same chronological point in time as the master branch before any merging occurs.

function prepare_message
{
	master
 
	echo "===> Pulling from ${REPO}:${BRANCH}"
	git pull ${REPO}|> ${BRANCH}|>
	git checkout ${MERGE_BRANCH}|>
 
	echo "==> Merging across change from master to ${MERGE_BRANCH}"
	git pull --no-commit --squash . master
 
	cp .git/SQUASH_MSG .git/SVNPULL_MSG
 
	master
}

The prepare_message function is part of the nastiest code in the entire script, in order to get an accurate "squashed commit" commit message when the changesets are pushed into Primary_SVN, we have to generate the commit message separately from the actual merging. Since this function is performing a `git pull` from "master" into "mergemaster" the changesets that are being pulled are going to be the only ones that show up (for reasons I'm about to explain).

function merge_to_svn
{
	git reset --hard ${LATEST_COMMIT}|>
	master
	setup_mergemaster
 
	echo "===> Pulling from ${REPO}:${BRANCH}"
	git pull ${REPO}|> ${BRANCH}|>
	git checkout ${MERGE_BRANCH}|>
 
	echo "==> Merging across change from master to ${MERGE_BRANCH}"
	git pull --no-commit --squash . master
 
	echo "==> Committing..."
	git commit -a -F .git/SVNPULL_MSG && git-svn dcommit --no-rebase
 
	cleanup
}

If you noticed above in the full script block, the "LATEST_COMMIT" code, here's where it's used, it is one of the most important pieces of the entire script. Basically the LATEST_COMMIT piece of script grabs the latest non-merge-commit hash from the `git log` output and saves it for later use (here) where it's used to rollback the proxy repository to the point in time just before the last merge commit. This is done to avoid issues with git-svn(1) not understanding how to handle merge commits whatsoever. After rolling back the proxy repository, a new "mergemaster" branch is created. After the mergemaster branch is created, the actual Primary_Git changesets that differ between the proxy repository and Primary_Git are pulled into the proxy repository's master branch, and sqaushed into the mergemaster branch where they are subsequently committed with the commit message that was prepared before. The "prepare_message" part of the script becomes important at that step because the "squashed commit" message that Git generates at this point in time will effectively contain every commit that has ever been proxied across in this manner ever.

After the "merge_to_svn" function has been run the "transaction" is entirely completed and the changesets that once differed between Primary_SVN/trunk and Primary_Git/master are now normalized.

Mostly Automagically

In the near future I intend on incorporating this script into the post-receive hook on Primary_Git in such a way that will truly propogate changesets automatically from Primary_Git into Primary_SVN, but currently I'm utilizing one of my new favorite "hammers', Hudson (see: One-line Automated Testing). Currently there are two jobs set up for proxying changesets across, the first "Subversion-to-Git" simply polls Subversion for changes and executes a series of commands when changes come in: git-svn fetch && git merge git-svn && git push $Primary_Git master. This is fairly straight-forward and fits in line with what git-svn(1) is intended to do. The other job that I created is "Git-to-Subversion" which must be manually invoked by a user, but still will automatically take care of squashing commits into Primary_SVN/trunk (i.e. bash svnproxy.sh $Primary_Git master).

Wrap-up

Admittedly, this sort of setup leaves a lot to be desired. In the ideal world, Tailor would have coped with both our Git and our Subversion repositories in such a way that would have made this script nothing more than a silly idea I had on a bus. Unfortunately that wasn't case and the time budget I had for figuring out a way to force Tailor to work was about 47.5 hours less than it took me to sit down and write the script above. I'd be interested to see other solutions other organizations are utilizing to migrate from one system to the other, but at the time of this writing I can't honestly say I've heard much about people dealing with the "hybrid" scenario that we have currently at Slide.

Did you know! Slide is hiring! Looking for talented engineers to write some good Python and/or JavaScript, feel free to contact me at tyler[at]slide

Team Development with Git (Part 2/3)

R. Tyler Croy — Tue, 30 Sep 2008 06:22:02 +0000

In my last post on Git, Experimenting with Git at Slide, I discussed most of the technical hurdles that stood in our way with evaluating Git for a Subversion tree that has 90k+ revisions and over 2GB of data held within. As I've learned from any project that involves more than just myself, technology is only half the battle, the other half is the human element. One of the most difficult things to "migrate" when switching to something as critical to a developer's workflow as a VCS, is habits, good ones and bad ones.

The Bad Habits

When moving my team over to Git, I was able to identify some habits that I view as "bad" that could either be blamed on how we have used Subversion here at Slide, or the development workflow that Subversion encourages. For the sake of avoiding flamewars, I'll say it's 51% us, 49% the system.

The Occasional Committer

Chances are that if you're working on "something super important!" you fall into this bad habit. Because of the nature of trunk in Subversion, if you commit half-finished work into a team-branch or trunk itself, you could cause plenty of pain for your fellow developers. As a result, you tend to commit at the end of a long day working on something, or only after something has been completed. The 9 hours of sweat and frustration you've spent pounding away on 300 lines of code is now summed up in one commit message:

Turns out there was a race-condition here, re #52516

Now three months from now when you return to the same 300 lines of code and try to figure out what the hell led to this mess, you're left with the commit message above, and nothing more.

The Less-than-attentive Developer

I've worked on a Mac for the majority of my time at Slide, as do most of my compatriots, and sooner or later one of two things will happen:svn add some/directory/ and/or svn commit. This usually results in a second commit to come into the tree with a commit message like:

Whoops, accidentally checked in resource forks

This isn't that large of a problem, except for the implication of the second command there, svn commit will commit all outstanding changes in your working copy starting in the current working directory, and recursing through children directories. I'm probably more anal-retentive about my commits than most, but I usually do a diff before I commit to make sure I'm aware of what I'm about to commit, but I've seen plenty of developers skip this step.

The Over-Confident Merger

I've fallen into this trap numerous times when merging "old" branches back into trunk, especially with binary files that may have been changed in trunk, or in my branch (hell if I know!). One thing I can speak to anecdotally from our work at Slide, is that the probability of nonsensical conflicts rises with a branch's age. The rate of our repository progresses at about 50 commits to trunk per day (~150 commits across the board), if there is a branch cut from trunk, usually within two weeks it can become extremely difficult to merge back into trunk without constant "refreshes" or merges from trunk into the branch.

If you're not careful when folding that branch back down into trunk, you can inadvertantly revert old binary files or even text files to previous states which will usually cause other individuals in the engineering organization gripe at you and your QA department to pelt you with rocks. For bonus points, you could (as I have done before) accidentally commit conflicting files earning a gold star and a dunce hat for the day. This merging pain led me to originally write my merge-safe.py script so long ago.

The Slide Way to Git

Fortunately for us, I think the decentralized nature of Git has helped us enforce some best practices when it comes to the bad habits above. "The Occassional Committer" is all but done away with thanks to the ability to atomically commit and revert revisions at a whim and have those changes not propogated to other developers until there has been an explicit push or pull.

Unfortunately however, "The Less-than-attentive Developer" isn't solved so easily. To date I've sat next to two engineers that were new to Git, and watched them both execute the same fateful command: git add .
Not realizing their mistake, they accidentally commit a truckload of build and temporary files (.so, .swp, .pyc, etc) interspersed with their regular work that they meant to commit. Git cannot prevent a developer from shooting themselves in the foot, but it does prevent them from shooting everybody else in the foot along with it (unless they commit, and then push their changes upwards).

"The Over-confident Merger" grows more and more confident in the Git-based workflow. Since Git handles changesets atomically, it becomes trivial to merge branch histories together or cherry-pick one revision and apply to an entirely separate branch. I've not yet seen a Git conflict that wasn't a true conflict insofar that it was quite literally one line of code changing in two different ways between branch histories. As an aside, when using git-svn, be prepared for all the merging "fun" that Subversion has to offer when propogating changes between the two systems.

Basic Team Workflow

The manner in which we use Git is more like a centralized-decentralized version control system. We still have a "master" repository, which provides a central synchronization point when pushing stage servers, or when bringing code into Subversion to be pushed to live servers. For any particular project one of the developers will create a branch that will serve as the primary project branch, take the "superpoke-proj" branch as an example. That developer will push this branch to "origin" (or the master repository) such that other developers can "track" that branch and contribute code. For the purposes of this example, let's say Paul and Peter are working in "superpoke-proj", while Paul is working he will incrementally commit his work, but once he has resolved/fixed a ticket, he will perform a git push and then mark the ticket appropriately such that a QA engineer can verify the fix. If Paul and Peter are working on something that "breaks the build" but they need to collaborate on it together, Paul can perform a git pull from Peter and vice versa, and again, once they're done those changes will be pushed to origin. This model allows for developers to work in relative isolation so they're not inadvertantly stepping on each others' toes, but also close enough that they can collaborate in explicit terms, i.e. when they are ready for changes to be propogated to each other or the rest of the team.

Conclusion

Our workflow, like most things at companies under 500 employees is still a "work in progress™". I think we've found the right balance thus far for the team between freedom and process the allow for sufficient mucking around in the codebase in a way that provides the most amount of time actually writing code with as little possible time spent dealing with the overhead of anything else (merging, etc). There's nothing inherently special in the way we use Git, but we've found that it works for the way we work, which is to say in a very tight release schedule that's requires multiple branches per week and plenty of merging from branch-to-branch whether it be from another team or another part of the same team.

Of course, your mileage may vary.

Did you know! Slide is hiring! Looking for talented engineers to write some good Python and/or JavaScript, feel free to contact me at tyler[at]slide

Don Quixote's new side-kick, Hudson

R. Tyler Croy — Sun, 07 Sep 2008 06:04:53 +0000

I recently wrote about "one-line automated testing" by way of Hudson, a Java-based tool that helps to automate building and test processes (akin to Cruise Control and Buildbot). If you were to read this blog regularly, you'd be well aware that I work primarily with Python these days, at a web company no less! What does a web company need with a continuous integration tool? Especially if they're not using a compiled language like Java or C# (heresy!).

As any engineering organization grows, it's bound to happen that you reach a critical mass of developers and either need to hire an equitable critical mass of QA engineers, or start to approach quality assurance from all sides. That is to say, automated unit testing and automated integration testing becomes a requirement for growing both as a engineering organization but as a web application provider (user's don't like broken web applications). With web products like Top Friends, SuperPoke! and Slide FunSpace we have a large amount of ever-changing code, that has been in a constant state of flux for the past 16-18 months. We can accomodate for ever-changing code on the backend for the past year and half with PyUnit and development discipline.

How do you deal with months of ever changing code for the aforementinoned products' front-ends? Your options are pretty slim, you can hire a legion of black-box QA engineers to manually go through regression tests and ensure your products are in tip-top shape, or you can hire a few talented black-box QA engineers to conscript a legion of robots to go through regression tests and ensure your products are in tip-top shape. Enter Windmill. Windmill is a web browser testing framework not entirely unlike Selenium or Watir with two major exceptions: Windmill is written in Python and Windmill has a great recorder (and lots of other features). One of my colleagues at Slide, Adam Christian has been working tirelessly to push Windmill further and prepare it for enterprise adoption, the first enterprise to use it, Slide.

Adam and I have been working on bringing the two ends of the testing world together with Hudson. About half of the jobs currently running inside of our Hudson installation are running PyUnit tests on various Subversion and Git branches. The other half of the jobs are running Windmill tests, and reporting back into Hudson by way of Adam's JUnit-compatible reporting code. Thanks to the innate flexibility of PyUnit and Windmill's reporting infrastructure we were able to tie all these loose ends together with a tool like Hudson that will handle Jabber-notifications or email notifications when test-runs fail and include details in it's reports.

We're still working out the kinks in the system, but to date this set up has helped us fix at least one critical issue a week (with a numerous other minor issues) since we've launched the Hudson system, more often than not before said issues reach the live site and real users. If you've got questions about Windmill or Hudson you can stop by the #windmill or the #hudson channels on Freenode.

Automated testing is like a really good blend of coffee, until you have it, you think "bah! I don't need that!" but after you start with it you can't help but wonder how you could tolerate the swill you used to drink.

Did you know! Slide is hiring! Looking for talented engineers to write some good Python and/or JavaScript, feel free to contact me at tyler[at]slide

One-line Automated Testing

R. Tyler Croy — Wed, 20 Aug 2008 08:16:26 +0000

For about as long as my development team has been a number larger than one, I've been on a relatively steady "unit test" kick. With the product I've worked on for over a year gaining more than one cook in the kitchen, it became time to start both writing tests to prevent basic regressions (and save our QA team tedious hours of blackbox testing), but also to automate those tests in order to quickly spot issues.

While I've been on this pretty steadily lately, I'm proud to say that automated testing was one of my first pet projects at Slide. If you ever crack into the Slide corporate network you can find my workstation under the name "ccnet" which is short for Cruise Control.NET, my first failed attempt at getting automated testing going on our now defunct Windows desktop client. As our development focus shifted away from desktop applications to social applications the ability to reliably test those systems plummeted; accordingly our test suite for these applications became paltry at best. As the organization started to scale, this simply could not stand much longer else we might not be able to efficiently push stable releases on a near-nightly schedule. As we've started to back-fill tests (test-after development?) the need to automate these tests has arisen to which I started digging aronud for something less painful to deal with than Cruise Control, enter Hudson.

Holy Hudson Batman!

I was absolutely astounded that I, nor anybody I knew, was aware of the Hudson project. Hudson is absolutely amazing as far as continuous integration systems go. The only major caveat is that the entire system is written in Java, meaning I had to beg one of our sysadmins to install Java 1.5 on the unit test machine. Once that was sorted out, starting the Hudson instance up was incredibly simple:
java -jar hudson.war
In our case the following to keep the JVM within manageable virtual memory limits:
java -Xmx128m -jar hudson.war --httpPort=8888

Once the Hudson instance was up and rnuning, I simply had to browse to http://unittestbox:8888/ and the entire rest of the configuration was set up from the web UI. Muy easy. Muy bueno.

Plug-it-in, plug-it-in!

One of the most wonderful aspects of Hudson is it's extensible plugin architecture. Adding plugins like "Git", "Trac" and "Jabber" means that our Hudson instance is now properly linking to Trac revisions, sending out Jabber notifications on "build" (read: test run) failures and monitoring both Subversion and Git branches for changes. From what I've seen from their plugin architecture, it would be absolutely trivial to extend Hudson with Slide-specific plugins as the needs arise.

With the integration of the PyUnit XMLTestRunner (found here) and working an XML output plugin into Windmill we can easily automate testing of both our back-end code and our front-end.

Hudson in action

And all with one simple java command :)

Did you know! Slide is hiring! Looking for talented engineers to write some good Python and/or JavaScript, feel free to contact me at tyler[at]slide

Experimenting with Git at Slide (Part 1/3)

R. Tyler Croy — Sun, 27 Jul 2008 12:23:48 +0000

For the past two months I've been experimenting with varying levels of success with Git inside of Slide, Inc.. Currently Slide makes use of Subversion and relies heavily on branches in Subversion for everything from project specific branches to release branches (branches that can live anywhere from under 12 hours to three weeks). There are plenty of other blog posts about the pitfalls of branching in Subversion that I won't go into here, suffice to say, it is...sub-par. Below is a rough diagram of our general current workflow with Subversion (I've had some other developers ask me "why don't you just work in trunk?" to which I usually wax poetic about the chaos of trunk when any project gets over 5 active developers (Slide engineering is somewhere between 30-50 engineers)).

There's always a catch
Subversion at Slide
Toying with Git
Git at Slide

There's always a catch

There are three major problems we've run up against with utilizing Subversion as our version control system at Slide:

Subversion's "branches" make context switching difficult
Depending on the age of a branch cut from trunk/, merges and maintainence is between difficult and impossible
Merging Subversion branches into each other causes a near total loss of revision history

Given that branches are a critical part of Slide's development process, we've historically looked at branch-strong version control systems as alternatives, such as Perforce. Before I joined Slide in April of 2007, I was a heavy user of Perforce for my own consulting projects as well as for some of my work with the FreeBSD project as part of the Summer of Code program. In fact, my boss sent out a "Perforce Petition" to our engineering list on my third day at Slide...we still haven't switched away from Perforce.

Up until earlier this year I hadn't given it a second thought until the team I was working with grew and grew such that between me and four other engineers we were pushing a release anywhere from once to three times a week. That meant we were creating a Subversion "branch" multiple times a week, and a significant part of my daily routine became merging to our release branch and refreshing project branches from trunk/. All of a sudden Git was looking prettier and prettier, despite some of its warts. At this point in time I was already using Git for some of my personal projects that I never have time for, so I knew at the bare minimum that it was functional. What I didn't know was how to deploy and use it with a large engineering team that works in very high churn short iterations, like Slide's.

Subversion at Slide

Moving our source tree over into a system other than Subversion, from Subverison, was destined to be painful. The tree at Slide is deceptively large, we have a substantial amount of Python running around (as Slide is built, top-to-bottom, in Python) and an incredible amount of Adobe Flash assets (.swf files), Adobe Illustrator assets (.ai files) and plenty of binary files, like images (.png/gif/jpeg). Currently a full checkout of trunk/ is roughly 2.5GB including artwork, flash, server and web application code. We also have roughly 88k revisions in Subversion, the summation of three years of the company's existence. Fortunately somebody along the line wrote a script (in Perl however) called "git-svn(1)" that is designed to do exactly what I needed, move a giant tree from Subversion to Git, from start to finish (similar to svn2p4 in Perforce parlance).

Toying with Git

When I first ran the command `git-svn init $SVN` I let the the command run for somewhere close to 6-7 hours before completing, I was shocked at the size of the generated repository. If our Git repository were to be left unpacked .git/ alone would be close to 9GB, adding the actual code on top of it, ~11GB. I decided that maybe packing this repository would be a good idea so I ran `git gc` and went to grab a coke from the fridge ... and the machine ran out of memory. One of our quad-core, 8GB RAM, shared development machines ran out of memory?!

After lurking in #git on Freenode for a while I determined two things

Apparently nobody uses Git for projects this large
Git was retaining too much memory, like a memory leak, but just don't call it a memory leak.

To compound this, the rules for memory usage with Git are vastly different between a 32-bit machine and a 64-bit machine, and because we're just that cool, we're using 64-bit machines across the board. The amount of memory Git decides to keep resident while doing repository-intensive operations like the `git gc`, is 256MB on 32-bit machines, and 8GB on 64-bit machines. As these machines are shared between developers we use of ulimit(1), when you limit memory usage with ulimit(1) it restricts address space meaning both virtual and resident memory. When Git tried to mmap(2) gigabytes of address space to do it's operations, the kernel stepped in to intervene and started returning ENOMEM to Git which promptly exited.

After raising this enough times, I finally caught spearce who was able to identify the problem and supply a patch that fixed the memory allocation issues with Git and a repository of Slide's size. First obstacle overcome, now I could actually test a Git workflow inside of Slide.

Git at Slide

Now that I could pack the repository on our development machines, I could get the repository down to a reasonable 3.0GB, i.e. .git/ weighed in at 3GB making a entire tree ~5.5GB (far more managable than 11GB). Despite Git being a decentralized version control system, we still needed some semblance of centralization to ensure a couple basic rules for a sane workflow:

A centralize place to synchronize distributed versions of the repository
Changesets cannot be lost, ever.
QA must not be over-burdened when testing releases

This meant we needed a centralized, secure, repository which left us two options: Git over WebDav (https/http) or Gitosis. After discovering that `git-http-push(1), the executable responsible for doing Git pushes over WebDav has tremendous memory issues, I abandoned that as an option (a `git push` of the repository resulted in memory usage peaking at 11GB virtual, 3.5GB resident memory).

If you are looking to deploy Git for a larger audience in a corporate environment, I highly recommend Gitosis. What Gitosis does is allows for SSH to be used as the transport protocol for Git, and provides authentication by use of limited-shell user accounts and SSH keys; it's not perfect but it's the closest thing to maintainable for larger installations of Git (in my opinion).

So far the experimenting with Git at Slide is pretty localized to just my team, but with a combination of Gitosis, git-svn(1) and some "best practices" defined for handling the new system we've successfully continued development for over the past month without any major issues.

As this post is already quite lengthy, I'll be discussing the following two parts of our experimenting in subsequent posts:

Team Development with Git
Git back to Subversion, mostly automatically.

Did you know! Slide is hiring! Looking for talented engineers to write some good Python and/or JavaScript, feel free to contact me at tyler[at]slide

Parsing HTML with Python

R. Tyler Croy — Sun, 04 May 2008 06:54:43 +0000

A while ago I jotted down about seven or so ideas of stuff that I thought would make good blog posts, somehow "markup parsers in Python" is next on the list, so I might as well spill the beans on how incredibly easy it is to process (X)HTML with Python and a little built in class called HTMLParser.

There have been a few occasions when I needed a quick (and dirty) way to perform transforms on some chunk of HTML or merely "search and replace" parts of it. While it might be cleaner to do something with XSLT or the likes, using them doesn't even begin to match the speed of development of an HTMLParser-based class in Python.

Getting Started
One major thing to keep in mind when working with HTMLParser, especially if you're newer to Python, is that it is what's referred to as an "old styled" object, meaning subclassing it is a bit different than "new styled" classes. Since HTMLParser is an old-styled object, any time you'd want to call a super-class defined method you would need to perform HTMLParser.superMethod(arg) instead of super(SubHTMLParser, self).superMethod(arg)

Creating the HTML parser
For the purposes of this example, I want something simple, so we're just going to take a block of markup and "tweak" all the <a> tags within it to be "sad" (whereas "sad" means they'll be bold, blue, and blinkey). The actual code to do so is only 50 lines long and is as follows:

import HTMLParser
 
class SadHTML(HTMLParser.HTMLParser):
    '''A simple HTML transform-class based upon HTMLParser.  All links shall be bold, blue and blinky :('''
 
    def __init__(self, *args, **kwargs):
        HTMLParser.HTMLParser.__init__(self)
        self.stack = []
 
    def handle_starttag(self, tag, attrs):
        attrs = dict(attrs)
        if tag.lower() == 'a':
            self.stack.append(self.__html_start_tag('blink', None))
            attrs['style'] = '%s%s' % (attrs.get('style', ''), 'color: blue; font-weight: bold;')
        self.stack.append(self.__html_start_tag(tag, attrs))
 
    def handle_endtag(self, tag):
        self.stack.append(self.__html_end_tag(tag))
        if tag.lower() == 'a':
            self.stack.append(self.__html_end_tag('blink'))
 
    def handle_startendtag(self, tag, attrs):
        self.stack.append(self.__html_startend_tag(tag, attrs))                
 
    def handle_data(self, data):
        self.stack.append(data)
 
    def __html_start_tag(self, tag, attrs):
        return '<%s%s>' % (tag, self.__html_attrs(attrs))
 
    def __html_startend_tag(self, tag, attrs):
        return '<%s%s/>' % (tag, self.__html_attrs(attrs))
 
    def __html_end_tag(self, tag):
        return '</%s>' % (tag)
 
    def __html_attrs(self, attrs):
        _attrs = ''
        if attrs:
            _attrs = ' %s' % (' '.join([('%s="%s"' % (k,v)) for k,v in attrs.iteritems()]))
        return _attrs
 
    @classmethod
    def depreshun(cls, markup):
        _p = cls()
        _p.feed(markup)
        _p.close()
        return ''.join(_p.stack)

The actual ins-and-outs of the parser are very simple; markup like "<a href="#">Hello</a><br/>" would execute accordingly:

handle_starttag('a', [('href', '#')])
handle_data('Hello')
handle_endtag('a')
handle_startendtag('br', [])

Since HTMLParser just gives you element tag names, and there attributes, SadHTML simply builds a list of strings out of what data is passed to it via the super class and then when everything is finished, ties the list back together with: ''.join(list_of_tags).
Executing the SadHTML.depreshun method on the contents of my last blog post is a good example, part of the post was:

An informal poll at the Slide offices this past week yielded these interesting results: at Slide.com, nearly 100% of white people seem to like "Stuff White People Like".

After running it through "SadHTML", the following markup is generated instead:

An informal poll at the Slide offices this past week yielded these interesting results: at Slide.com, nearly 100% of white people seem to like "Stuff White People Like".

If you're curious as to how much more you can do with HTMLParser, do check out the documentation. It's far more lenient than using eXpat for parsing HTML, and it's still fast enough to be used on longer documents (there's also htmllib available for Python but I've not used it yet).