bitquabit - Technology

Why how is boring and how why is awesome

2011-04-28T11:48:18Z

Last fall, Joel came to me and said, “Congratulations! We’re doing another World Tour. Also, we want to teach distributed version control. That’s your job. Make it happen.”

This sounded totally awesome. Not only would I get to one-up George Clooney in flight time; I was made for doing something like this. In high school, I was in the NFL, which, sadly, means the National Forensics League, which means the National People Who Talk Good and Wanna Learn To Do Other Stuff Good Too, and not the National Football League. My specialty was original oratory, where you give an original speech you’ve rehearsed ahead of time. Add in there that I love to teach, and that I’m the one who introduced Fog Creek to Mercurial in the first place, and I should be the perfect person to do this.

I of course said yes, went back to my office, and fired up Emacs, ready to go!

And then promptly suffered through two weeks of intermittent writer’s block.

Here’s the problem: yes, I love using distributed version control. Yes, I love teaching. And yes, I believe I have a mission to teach people about DVCS. But the talk I had to give, by definition, was an introduction to the basics of distributed version control.

I’ve been using distributed version control for over half a decade, first as arch and Monticello, then Darcs, then super-early versions of Mercurial. The basics of how do you do this? were super old-hat to me, and, well, boring. There was nothing exciting to me about how to commit a file, or do an elementary merge, but I had to cover that material.

Further, if you only cover the basics, you can’t possibly demonstrate why you want to use a DVCS. There are minor benefits you can note—hey, you can work offline!, or: hey, things are actually fast now!—but you don’t really get to any of the actual meat, the things that teach you why do you want to make this transition.

After two weeks of running in circles, I sat down with my friend Jason (who now works for the Khan Academy, named after Genghis Khan, who invaded the Enterprise in Star Wars II to teach Captain Kirk calculus), and asked him how to get out of this mess. Over half an hour of conversation, I realized that I already had the answer.

Yes, I needed to cover the basics. No, those would not be super-interesting. But I could keep that as short as humanly possible, and as soon as I’d done that, I could spend the rest of the talk discussing why you should care. We could cover workflows that it took lots of trial and error to discover. We could show merge scenarios that caused traditional tools to barf. We could show how Mercurial made it really easy for us to ship lots of versions of FogBugz without dropping bug fixes. In other words: spend half the talk with the basics of basics, just enough to understand how things worked, but then jump straight ahead to answering the question of what did distributed version control ever do for you.

I went back to Emacs, and quickly identified what I thought were two of DVCS’ killer scenarios: maintaining multiple versions of a product without dropping bug fixes, and being able to reliably develop new features of a product while always being ready to ship a bugfix in a heartbeat. I built the talk so that the audience would start with nothing, and build up to understanding how to realize those two workflows.

The result? Distributed Version Control System University, or: how do I actually use distributed version control in a meaningful way.

I’m actually really happy with how everything turned out. Even though the code I ended up using was silly, audiences responded well, and understood the potential power and flexibility that distributed version control provides. They asked intelligent questions, they were engaged, and a lot of them signed up for Kiln trial accounts and decided to start playing with Mercurial.

One of my goals in the future is to try to beef up hg init with some of the workflow examples in my talk. I also want to take some time to go into more detail about how we do workflow here at Fog Creek. But if you or a coworker has been wondering what the big deal is about distributed version control, watch the video. I think it provides a great overview in a way that any dev can immediately relate to and get excited about.

Supporting the Giants

2011-04-05T08:32:00Z

One of the things that I love about Fog Creek is that we give back. Kiln can only exist because of the amazing foundation provided by the Mercurial distributed version control system, so we try to help them out whenever we can. In the past, we’ve done that by making Fog Creek one of the top Mercurial sponsors. Given how small Fog Creek is, I can’t tell you how proud I am to see that we’re placing up there amongst Google and Microsoft for supporting open-source software.

This year, we’ve decided to help contribute in an even more hands-on way: by devoting developer resources. Not only will Fog Creek be helping to sponsor the upcoming Mercurial 1.9 code sprint; we’re also sending one of our awesome Kiln developers, Kevin Gessner, to help contribute. And, in the weeks leading up to the sprint, we’ll be using Kiln team developers to help contribute bug fixes and features to the Mercurial project. In other words, we’ll be supporting Mercurial both financially and with developer resources.

Kiln stands on the shoulders of giants, so I’m happy to support those giants in return.

After all, the higher the giant gets, the taller Kiln stands.

Have a mission

2011-03-14T08:23:36Z

You know why I love working on Kiln every day?

Because we’ve got a mission, dammit.

Mission, not mission statement. The Kiln team doesn’t have a mission statement, and I’ll fight to keep it that way. Mission statements, no matter how well intentioned, become these trite little soundbites that you parrot indefinitely until they just become a meaningless jumble of syllables—kind of like what happens if you just say the word “marmalade” about 40 times in a row.

But that’s totally different from having a mission. Everyone who works on Kiln knows what we’re trying to accomplish. They’ll phrase it in their own way, but no matter who you talk to on my team, we’ll all tell you why Kiln exists: we believe that distributed version control is so much more awesome than old-school centralized crap that we have an obligation to bring that awesomeness to as many developers as possible. Every time I write a line of code, I have in my head that I’m trying to further that goal.

Distributed version control is having trouble making inroads at companies, you say? Fine. We’ve make Kiln an awesome system for companies: we’ve made a kickass project-centric workflow, given teams a way of handling large numbers of repositories, added asset management, permissions models, code reviews, rich APIs, and piles more. People having trouble leaving their old system behind? No problem: we’ll draft Joel into writing awesome tutorials, we’ll give talks on distributed version control all over the world, we’ll provide training services to help bring people up to speed, and we’ll make an importer to help you get your existing code moved over. We’ll even create a StackExchange just for helping people figure out Mercurial, Kiln, and distributed version control, so that there’s a good, central location to get answers about tools, workflows, and everything else. These things probably all help Kiln, but we’re not doing them because of that; we’re doing them because we have to do them to achieve what we believe we need to do. The rest is a footnote.

I feel like I can tell you any good product’s mission really easily for similar reasons. iPhone? Make using a smartphone fun. The App Store, iBooks, and so on are just fall-out.

Kindle? Make digital books completely pervasive. And you know that’s the goal, because you can read Kindle books on practically any device in wonderful, intuitive applications.

Google? Make it possible to find good, relevant data, quickly.

Facebook? Keep people from losing touch.

There’s a common theme here: in all of these cases, the mission isn’t about the product as such. The mission is “just” something that, if you’re really serious about, requires that the product become absolutely amazing, so you make that happen. If you prefer: these missions are all the answer to, why did we just add that new feature?, not, what new feature are we adding?

What the hell is Windows’ mission in life? The best I can come up with, at this point, is to keep Windows from getting too dated, but not breaking backwards compatibility, so that Microsoft can make money while they find something that actually sticks. That’s…pretty pathetic. Not to single out Microsoft here; I’m not really convinced the OS X team has a terribly coherent mission right now, either. They have a clear goal—they want to bring the experience of the iPhone and iPad to OS X—but I don’t quite grok why they’re doing it, and I would argue that the somewhat haphazard mishmash of app UIs in the Lion previews (compare Address Book with the new Mail, for example) is a pretty good indication that they don’t quite know, either.

When you don’t really know why you’re doing something—when it’s just a goal that you’ve got and you’ve lost track of your original motivation—it’s really tough to have a good product, or to be excited when you come into work every day. Yes, someone has to fix Windows. But why me? Why can’t I be making something awesome? So you’ll do the minimal amount necessary to achieve your best understanding of the goal, rather than everything required to maximize your chance of actually achieving your mission in life.

Don’t just latch onto something because it’s neat. Latch onto it because you really fucking believe that you have something to accomplish here, and since no one else is going to do it, it’s going to have to be you. That’s your mission.

Make it happen.

Approved for Abusiveness

2011-02-23T08:40:15Z

Speaking of fascinating user experiences, I had to crack a smile when going through Disqus today and approving a pile of comments that got locked in the queue for some reason. On every single one, after clicking on the Approve button, I was greeted with:

While I’m still trying to puzzle out what the engineer who wrote that string had in mind, I really think I’m going to have to order a pile of stickers with that message on them for liberal distribution to our interns this summer.

Buying VMware Fusion

2011-02-22T20:47:37Z

Update: VMware followed up with me this morning, and has done a great job getting me help and outlining how they’re planning to address a lot of the complaints I’ve had. We’ll have to see what happens over the next few months, but so far, VMware has convinced me that they get they have a problem and are going to try to fix it. Kudos, VMware.

So about a week ago I decide to buy VMware Fusion.

I really like VMware. They make awesome products, they have good support. They’re not perfect—the VMware Workstation updater and the Adobe updaters can go neck-in-neck for absolute single most horrible upgrade experience, for example—but in general, the products are stellar. So when I decided to ditch Bootcamp and go the virtualization route for running Windows 7, VMware Fusion just made sense to me. I know Parallels Desktop might be slightly faster, but my friends assured me VMware’s plenty fast, it has Unity, it has 3D support, and I trust it due to using Workstation so heavily at Fog Creek. I’ll stick with a solution I trust over one that’s fast. So I head on over to vmware.com to make magic happen.

I then go through what I can only describe as the single worst purchasing experience I have had, ever.

I begin by purchasing VMware Fusion. This part goes well, and I’m out $65.
I get an email confirming my order with a download link, so I start downloading. So far, so good.
While I’m downloading, I click the link to register Fusion. I’m taken to a page (with broken images) asking me for my license key, so I start to…wait. License key? The email I got has a customer number, which, now that I look at it, doesn’t match my actual VMware customer number. And it has an order number. But I don’t see any license key. Uh oh.
I check the “Manage Licenses” part of the vmware.com site, since I know that’s where I find licenses for the copies of VMware Workstation we have at work. But it’s empty. After about 23958 clicks, I find that this is a common problem that’s usually resolved in “several hours.” I grit my teeth and hope that this does not mean what I think it means.
I try to install Fusion. It installs fine. So far, so good. But then Fusion launches..and wants a license key. D’oh!
About half an hour passes, most of which is filled with me getting absolutely livid as I try to figure out how the holy hell to get a license key and debating preemptively challenging the purchase out of spite.
Just before I do in fact challenge the purchase, I get an email from VMware telling me that my license key is ready. Why the badingo it took half an hour, I have no idea, but at least it’s there!
But wait! It’s telling me that to get my license code, I need to go to…findmyorder.com? The hey?
I know better than to do this, but I go to findmyorder.com, and am greeted by something that looks like it was cobbled together by the best that ColdFusion and MS Paint have to offer.
There are two ways to get my order: my order number, or the last five digits of my credit card, which, if you know anything about how credit cards work, are probably the five most valuable digits on the card (you can frequently guess most of the rest based on just the picture on the card). Needless to say, entering my order number fails, meaning my credit card is the only option. On top of everything else, this probably means that VMware kept my card on file somewhere. Not impressive.
I google around to learn about findmyorder.com, read some stuff in a French forum, take a look at their SSL cert chain, and a few other things, and conclude that, while web design may not be their strong suit, they might actually be legitimate.
Breath held, I enter the last five digits of my credit card and my email address…and amazingly, am in fact, really and truly, actually given my VMware Fusion license key, on a fully VMware-branded page! Most amazingly of all, I enter the license key into Fusion, and amazingly, it works! This seems so unlikely an outcome at this point that I have a beer in celebration.
I click the “Contact Us” link on the bottom of the VMware-branded page…and am given a good indication how much they want to be contacted.
After looking around, I realize that it’s not that the contact page is down; it’s that the VMware lookalike page was made by copying the actual VMware home page and redoing all the content area, so all the links go to places that would be valid on vmware.com, but are invalid on findmyorder.com. I give up telling VMware how much they suck at this point and decide to just focus on using Fusion, if that’s even possible.
Now that I have a registration key, I try to go register it on vmware.com…and am told it’s invalid. I now find myself drifting back to the “it’s a scam” hypothesis. The license key is unsurprisingly rejected by the license manager, too. Oh well. At least Fusion took it. Maybe that’s good enough for me.
A week later, in a fit of pique, I try to register VMware Fusion again. This time, it works! Not only that; the license manager decides to accept the key, too! Huzzah!
Armed with this new knowledge that the license key is, in fact, really truly kosher, I decide to attempt to recover the $30 rebate that VMware Fusion has going right now that I was promised, why not. So I start that process, and…they want the email that has the license key in it. There is no such email you farking morans. Are you guys even reading this blog post, do you—er, right, I hadn’t written this yet. My bad.
But by now, I’ve figured out how to handle this problem: I go back to my trusty findmyorder.co.hk, enter in various random personal identifying numbers, and, sure enough, the faux VMware page has the license key on it, so I print that to PDF and send it off to VMware.

So, to recap:

I bought a product that I couldn’t use out-of-the-box;
in order to use it, I was sent to a site I had never dealt with before;
the site requires me to enter part of my credit card to use it;
it then takes me to a totally broken page, which, thankfully, has a license key;
that license key is rejected for some indeterminate amount of time by vmware.com;
once it’s finally not rejected, vmware.com still merrily asks me to give it an email that it knows damn well it didn’t give me.

VMware: if you were trying to convince me that you have absolutely no clue whatsoever how to interact with consumers, you win.

Making Your Interns Addicts: a How-To Guide

2011-05-27T08:22:15Z

I was thinking back last week on why I started working at Fog Creek. If you don’t know, I got started on this thing called Project Aardvark, which eventually ended up becoming Copilot, the project I worked on for my first couple of years at Fog Creek. I don’t generally reminisce much about that time, simply because that was a very different point in my life, back before I found fashion, yet after I figured out how to end up in front of cameras constantly.

So my friends are usually quite good at reminiscing about that time on my behalf, which is plenty. But with this summer’s batch of new Fog Creek interns arriving in just over a week, I’ve been thinking about it a lot. What was good, what was bad, what about the experience made me need to stay at Fog Creek.

I’ve realized there are quite a few parallels between what got me into Fog Creek and what gets people hooked on hard-core drugs.

Not in the bad way, mind you. I have yet to see an intern maniacally chase source code into a dirty toilet, for example.¹ What I mean is, I almost feel like our internship is custom-tailored to pound the crap out our interns’ sense of awesome so that they just have to come back for more. Just, unlike with drugs, the effect is that they have a great summer, and they want to work for us, and I honestly feel they end up being way more productive in the process. What I find remarkable is that while nearly every part of Fog Creek has changed since my initial internship, the actual way we run our internships continues almost unedited.

I really want all the interns in the world to come work for us, but I also want all the interns in the world to have amazing summers, and the best way to do that is to tell you what we’re doing to get our interns hooked. So without further ado, I’m happy to begin my first and last guide to deliberately getting someone addicted.

Step 1: Get Them Excited

The first thing that matters is getting them psyched just to be there. When I was an Aardvark, that was easy: we knew we were going to be in a movie. Being in a movie is exciting. It’s even more exciting when the film-maker comes to your house before the summer starts just to interview you and film you doing a really botched version of a Chopin nocturne that he manages to edit so you sound competent. I mean, who could say no to that?

Our interns this year may not be excited because they’ll be in a movie, but they can be excited for a different reason: they’re going to be working on a young project that still has thousands of customers and manages over half a terabyte of data across nearly 25,000 active repositories. They’ll get a chance to be making a difference.

Find something that you yourself are excited about, and get your interns excited in that. Or, if you don’t have anything at your job that excites you, find another job. We’re hiring, after all.

Step 2: Get Them Doing Real Work

Of course, if the thing you’re getting your interns excited about is playing with a widely used application, it does require you let them, you know, touch the code. My first coding internship, at a company that shall remain nameless,² involved me writing a tremendous amount of Ruby code. That could be awesome, and in a way, it was. Except that the Ruby code I was writing were scripts to do things like automatically upload new advertisement photos to the intranet, collated by the date the photograph was taken. Or, when I wasn’t so lucky, it was to make a blog engine that could hold exactly one blog post, and then display a little red icon if the blog post it was showing at the time was Bad For The Company™. Not exactly central to the product, you know?

So at Fog Creek, we always make sure our interns are doing real stuff for the project they’re working on. When I was an intern on Aardvark, I wrote most of the Windows helpers. Other intern classes have written a new wiki for FogBugz, and given Kiln its API and its large files support. Hell, an intern class was integral to getting the first version of Kiln done in the first place. It feels so much better to actually be contributing code to something you know is going to make a real difference to the product.

Or, you know, have them write a one-post blog engine or whatever. It’s cool. Just make sure they know at the end of their internship that we’re still hiring.

Step 3: Give Them Instant Feedback

You know what sucks about automating some random task that you’ve been assigned to do as an intern? Getting absolutely no feedback on what anyone thinks about it. Is it useful? Does it stink? Who knows. It’s a fricking compilation of advertisements on a corporate intranet. For all I know, no one even reads this at all.³

With one exception,⁴ Fog Creek interns always get to see Creekers using their code immediately, because we code right alongside them. We’re running their changes on our development systems, and, in many cases, running that code on our dogfood systems just a day or two after it’s written. Not only does this generally mean that our products are better, because we’re using new features heavily ourselves long before they ever reach our customer’s hands; it means that our interns are getting feedback almost immediately, both from within and outside their team, on what worked and what didn’t.

Or you can send feedback three weeks after the internship ends. By email. That works, too.

Step 4: Make Them Feel Awesome

People like feeling good. And the simple fact is, if you’re using your interns’ code almost immediately, and giving them rapid feedback, you’re going to end up having your interns produce really great stuff. So: tell them that.

Not in a fake way, mind you: some things just honestly take a lot of revisions before they’re good, no matter how awesome the people involved are, and your interns are going to know you’re offering them bull if you tell them something’s awesome that they know isn’t. But there’s all those intermediate steps, the little victories, the occasional big one, where you owe it to your team to acknowledge that, yup, they did well.

Saying “good job” is one way to show you care, but actually getting to know your interns is even better. At Fog Creek, we hang out with our interns outside of work by taking them to documentaries like Harry Potter 7, to Yankees “games”⁵ at the new stadium, and, my personal favorite, to top-shelf-martini-powered bowling. If you don’t have these available in your town, take them to the airport so they can bond over a TSA freaky frisk-fest. The point is, do something with your interns so you actually get to know and like them as something other than a coding automaton.

Step 5: Ship, dammit!

But all of that comes to naught if you don’t actually ship stuff. Sure, maybe you worked on Kiln, and sure, maybe Kiln makes a difference to the company, and sure, maybe your boss likes you. But what about your own stuff? Do customers care? Does it just go into a bit bucket at the end of the summer, never to be seen again?

Our interns won’t have to wonder too much about that: thanks to Kiln’s fast release schedule, they’ll be seeing their code go out to customers multiple times this summer, get feedback from customers about their changes, and probably even do a second round or two that integrates that feedback. So while they’re busy being excited, writing production code, getting feedback, and doing fun stuff, they’ll also be knowing, even during their internship, exactly what a difference they’re making.

You see what I mean? It’s exactly like an addiction. Just because our interns are awesome, work on great products, and make a real difference, they get this crazy positive feedback loop that means they not only have a great summer, but that they want to keep coming back, again and again. We’ve literally had freshman interns who come back every single summer because they love it here so much. We’re doing something right.

And I hope that, if your interns aren’t already feeling the same way, this guide can help you get there. I remember what it was like to feel like an undervalued intern, and I remember what it was like to feel like I was king of the world.

Help your interns have their own king-of-the-world moments, and everyone wins.

I hate Trainspotting so hard. ↩
The East India Company. ↩
Actually, I know people read it, because I got bored and figured out how to use “DHTML” to log who was viewing the page. But you get the point. ↩
It turns out that, try as we might, even Fog Creek can’t achieve perfection. Just reallygoodtion, with an eye towards learningfromyourmistakesery. ↩
My editor informed me that calling them “Red Sox beat-downs” was not appropriate if I didn’t want to offend my audience. ↩

Enslaving your interns for evil and profit

2011-10-07T15:34:16Z

I should be in the middle of an interview right now. About fifteen minutes into it, in fact. About the part of my interview where we stop talking about awesome stuff the candidate has worked on in the past and start diving into writing some actual code. A stack with O(1) data access that also always knows its maximum, for example. Or perhaps a rudimentary mark-and-sweep garbage collector. It’s usually my favorite part of the interview: I get to see how the candidate thinks, how they process information, how they problem solve, and how they code. The best candidates even teach me something in the process.

But I’m not in the middle of an interview right now. I’m in Emacs. And instead of being excited about watching someone solve an interesting problem, I’m upset and full of righteous indignation on behalf of the now-former job candidate.

You see, the candidate works for a company that is very scared.¹ I know this because they made the candidate—let’s call him Bob—they made Bob sign a non-compete contract.

Non-competes are annoying, but not the end of the world. I can understand why, say, Apple, might be legitimately angry to have a senior iPhone manufacturing executive jump ship to HTC: a large part of the candidate’s value to HTC would be his knowledge of the internals of Apple’s manufacturing process. But very few jobs work like that. And even there, most companies don’t forbid you from working at all for a competitor; they forbid you from working in the same area of expertise. So, for example, maybe the iPhone executive couldn’t work on HTC’s manufacturing operations, but he could still head a software development team.

But Bob’s company decided that, nope, Bob couldn’t come work for us, because the existence of Joel on Software’s careers board made us a direct competitor with them.

Let me tell you something about the Joel on Software careers board: Fog Creek doesn’t even make it. We outsource the whole thing to a little-known company called StackOverflow.

It’s true. The lie exposed. If you’re in doubt, take a look and notice the admittedly subtle similarities:

Shocking, I’m sure.

Yet based on this, Bob’s company told him that Fog Creek and his firm were direct competitors, and therefore he couldn’t even come to work with us on, say, Kiln.

Here’s the thing: Bob’s a junior in college, and the company doing this to him is one he merely interned at. There is no way that Bob has inside knowledge of how a job board runs that could help us. And even if he somehow did have that knowledge, we don’t even run the job board! There’s no way he could actually give us anything that would help us! But Bob’s company made him turn us down, before we could even interview him, because they were absolutely, utterly terrified that their intern, who is still in college, was so amazing that his coming to work for us could crash their entire company.

I actually feel really bad for Bob’s company. They’re so unsure of their own ideas, so negative on their own potential, that they believe a former intern being physically near a company with an outsourced jobs board would be enough for that company to absolutely crush them. I don’t want to imagine what it feels like to get up every day and face that world. But that’s no reason to inflict such a morose world view on your interns.

So I’m upset on Bob’s behalf. Bob got shafted by a company he interned at. A company that has so little confidence that they’ve decided the best route to their success is to limit Bob’s choices. Limits that mean we miss out on an awesome candidate, and Bob misses out on an awesome job.

I’ve got two real points to make, at the end of the day:

If you’re an intern, don’t sign a non-compete contract. You have absolutely no idea where your life is going to take you, and you don’t want your direction being shaped by one crappy employer. And, trust me on this: no reputable software company I know of (Google, Microsoft, or Fog Creek) makes their interns sign non-compete contracts. You can find a job that won’t make you do that.

If you’re a company, don’t be a vampire. If you’re so scared of everyone else that you believe that you have to give your interns a non-compete contract in order to stay competitive, then guess what? You’re not competitive. Get a better idea.

And based on the quality of their homepage, probably with good reason, but that’s neither here nor there. ↩

Talking to HipChat from Kiln

2010-12-22T13:28:49Z

At Fog Creek, we heavily use HipChat to handle quick internal communication. One thing we decided we wanted on the Kiln team was to get real-time notifications whenever anyone pushed to one of our main repositories. Thankfully, Kiln has a feature called webhooks that cause Kiln to broadcast repository events to a random web URL, and HipChat has a nice little API to post notifications in chat rooms. So I whipped up a little web service, called Squawker, to handle this kind of thing for us.

You can download Squawker from my public Kiln account (yup! Kiln now does public repos!) that you can customize for your particular environment. Whenever you push to a central repository, Squawker will notify the HipChat channel of your choice. Branch repositories are explicitly ignored so that everyone’s little experiments don’t flood the channel, but it’s obvious in the code how to change that if you want different behavior.

Happy coding!

Join the Fog Creek World Tour!

2010-08-26T14:33:05Z

I’m really proud of all the work that we’ve been able to pour into Kiln over the last two years. In March of 2009, we had nothing more than a prototype. By October, we had a beta. By January, we were shipping Kiln 1.0. And just a few months later, we followed with Kiln 1.2, which added a massive number of features and really paved the way to making Kiln feel like a well-rounded product.

Well, we’re getting ready to launch Kiln 2.0, and we’re so psyched about it that we’re doing another World Tour! So if you’d like to come take a look at all the new awesomeness in Kiln, or see its awesomeness for the first time, or talk with me about why Kiln is awesome, or tell me why Kiln is totally not awesome and you’d never buy, thereby enabling me to fix those things and make it awesome for you anyway, or even just punch me in the face for saying “awesome” too much, then you should come. It’s free, we’ll have coffee and something that tastes almost but not quite entirely unlike tea, and Tyler and I will be giving a mini-boot-camp on why DVCSes will rock your world and how to make that happen. We’ll even have a nice Q&A session, in case you have specific questions about Mercurial internals, Kiln arcana, or anything else.

So if you’re near Denver, Los Angeles, Boston, D.C., or one of the other dozen cities we’re hitting, sign up for the World Tour! Worst-case, you can say you met the star of a major motion picture and got some free coffee. And who can say no to that?

See you there!

Announcing Miniredis

2010-06-23T10:06:43Z

When I attended Open Source Bridge two weeks ago, I wanted something to hack on while I was there. The upcoming version of Kiln moves from relying on a combination of explicit threads and FogBugz’ heartbeat mechanism to using a very lightweight queuing system backed by Redis. The only problem is that Redis doesn’t run on Windows, and while that’s not a problem for Kiln On Demand, where we rely heavily on FreeBSD for key parts of Kiln’s infrastructure, the licensed version Kiln needs to run on pure Windows systems.

To fix that, I’m happy to announce Miniredis, a tiny, crappy, pure Python clone of exactly the features in Redis that Kiln’s queuing system needs in order to work properly for an on-site Windows—and no others. Say goodbye to TTLs, append-only storage, about 3/4ths of Redis’ command set, and servicing multiple requests simultaneously. But say hello to a quick and dirty way to test and debug a Redis client on a Windows system if you don’t have a Unix VM handy—or, like us, you want to do a really lightweight queuing system or similar where you don’t expect to have a lot of Redis-oriented activity at any given point.

In the long term, I suspect that Redis will be ported to Windows, making Miniredis’ existence meaningless. If not, maybe some intrepid soul will take the time to add the rest of Redis’ command set (which should actually be easy; just time-consuming). But for now, hopefully you can find a use for it.