Midnight Oil

Hosting a Rails app has always been a bit of a pain. Standard shared hosting was always pretty much out of the question, so most people naturally migrated to some sort of VPS. The obvious upside of being able to do whatever you want is a big draw. However, there is a dark side to every VPS: sysadmin work. Updating with patches, installing software, setting file permissions, and all that plumbing takes a lot of time. Then, there’s the big-daddy of them all: managing your own SMTP server. Sure, turning on Postfix or Exim is pretty easy. I just hope you don’t mind it when all your emails disappear into spam boxes.

For Obsidian Portal, we have been happily hosting with Slicehost for a while. Their uptime has been great, and we appreciate their services like automated backup and DNS management. However, we have been handling all our sysadmin tasks ourselves. So, when Ryan recently met one of the representatives from Blue Box Group, and he said that they’re happy to handle all that for us (at no additional charge!), we were quite interested.

Since we’re currently spinning up DoLeaf, we decided it would be a good time to see what we can get with a more hands-on hosting provider. And, after just a few days, we’re very impressed.

Choice of Distro

Blue Box’s basic installation is some flavor of Red Hat. Ryan and I are Ubuntu guys, so this was a problem. A single email to the support staff: “Hey, can you rebuild our server with Ubuntu server edition?” Answer: “Yep, it’s done.” Awesome.

Firewall

Anyone else think iptables is a bit of a pain? I can use Firestarter or Webmin, but when I try to manage it manually, forget it. Luckily it only has to be done once. Or, in the case of BB, never. Just send an email with the ports you want open. They set it up and replied, plus added a few standard ports that we forgot.

Rails Stack

BB supports several different Rails stacks. We’re used to Apache2 + Ruby Enterprise Edition + Passenger + Rails 2.3.2 + MySQL 5. Even though this kind of setup is pretty straightforward, it always seems to take me at least 1-2 hours just to get things set up in the most basic configuration. Now? You guessed it. Send an email and I’m done.

Functioning SMTP – The Great White Whale

We’ve always had problems with emails disappearing en-route. Getting Postfix set up is a 5 minute job, but your emails randomly get flagged as spam, especially by the big boys like Google and Yahoo. There are many different ways to counter this, like SPF and DKIM, but they are a pain to set up, and it’s always tough to know if you got it correct. This was the tipping point for me with BB. They have an SMTP server preconfigured with SPF and DKIM and you can use it for sending emails from your app. They limit you to 750 emails / hour, which is way more than most apps need, especially in the beginning. Considering that we had evaluated similar solutions that wanted to charge $0.01 / email, having this included for free in our hosting plan was mind blowing. Never again will I host anywhere that doesn’t do this.

And the cost?

The most surprising thing is that I haven’t been charged $0.01 for additional support. I’m still testing the waters to see exactly where that line is, but so far, I haven’t hit it. Plus, their prices are quite competitive. Slicehost is a little bit cheaper, but when you factor in the time saved on setup, I’d say we’re already way ahead.

We’ve only just started with Blue Box, and things may go south at some point, but for now we’re ecstatic with what we’ve received. If you want to spend more time coding and less time on irritating sysadmin tasks, then I highly recommend taking a look!

In Part 1 of DoLeaf’s TechStars story, I covered “the facts.” I tried to dispassionately catalog what we did during the application process, in order to provide some comparisons for teams that are considering applying. In this installment, I’m going to examine whether or not it was good for us to apply, and why.

There are a few ways to look at this, and I’m going to try and be brutally honest and not take the “It was a fun learning experience” way out. I don’t want to offend the powers-that-be, but at the same time, I want there to be more honest info out there for confused entrepreneurs like myself.

Random Thoughts

I can’t figure out how to organize this post, so I’m just going to toss a bullet list out and let you figure it out for yourself. Some are examples of things we did wrong. When I say “wrong,” I mean wrong for our team, not wrong for the application process. They might have increased our chances of acceptance, but obviously not enough to get in. Other points are pieces of advice that I would give to anyone applying.

Techstars for a Day

I think it was a mistake for all of us (or any of us) to go to TS4AD. It was fun to meet up and go to Boulder, and I got to meet Drew (who has done so much for us), but it was pretty expensive. I guess we all have day jobs so we can afford it. However, if you’re a struggling bootstrapper reading this and trying to decide whether or not to go to TS4AD, just realize that even if you go, the odds are still stacked against you. In addition to the expense, we also lost several days worth of productivity. As always, I recommend focusing on your project and keeping your head down into your work.

Sweating the small stuff

We quibbled and fought sometimes over the emails that we were going to send to David or Brad. We’d edit them a couple times to put our best foot forward. I’m a nitpicky editor, and Sarah got tired of my harping on small issues in the emails. Time spent on this was not time spent working on DoLeaf, and it caused friction in the team. What did we get for it? Nothing.

Invest your time wisely

As a startup, time is your most precious resource. If you’re a bootstrapper like we are, then you’ve only got a precious few hours each night and on the weekend to do your work. It’s amazing what you can do, but it still takes time.

We didn’t track how much time we spent on TechStars related work, but I would guess that all the emails, discussion, and planning took a lot of time. Further, TS4AD took two days for each of us, totaling six work days. That’s a pretty big time investment. In two days of straight work I could have probably added 2-3 big features, like integrated shipping controls or an intra-site messaging service. Plus, I wouldn’t be writing this jaded blog post right now and would be working, instead

The illusion of progress

David strongly suggested sending him and all the mentors regular updates regarding our progress. When we initially posted our application we already had a working demo. In the final month of the application process we completed several major milestones. However, these features were often subtle and not frontpage eye popping changes. Hence, after submitting our application, we never had major dramatic changes that jump out at you. We assume the TechStars folks had hundreds of applications to sort through and little time to do a daily checkup on progress. So, since ours looked the same time after time, it probably gave the impression that we were doing nothing.

There are two options when dealing with this: organize your work to show new zazz on the frontend every few days, or work like hell on what you think needs it and hope it shows. Option one is better for your TechStars application, while option two is better for your company. Guess which one I recommend?

Never compromise your vision!

If you do apply, and give it 110% like we did, you’ll probably end up getting some advice from David or the other Techstars people. In our case, none of the advice was contrary to our vision, so we went ahead and followed some of it. However, if you’re unsure about any of the advice, discard it. At the application stage, they’re just not invested enough in your idea, so their advice has to be weighted as such. Well intentioned, sure, but not to be taken as gospel.

You can’t get them excited

Don’t go out of your way to get the mentors excited. We tried hard to keep them in the loop and get them excited, but I don’t think it worked all that well. My advice would be to let your work speak for itself. If your idea is exciting to them, they’ll seek you out for more info. If they don’t find your idea or team exciting, then there’s probably nothing you can do to change that.

Read the responses (or lack thereof) to get a clue as to their excitement level. We should have picked up on this early on, but we were blinded by our own excitement. See David’s comments below and you’ll see that he and the others didn’t go nuts over a plant marketplace. There is really no way for us to change that. No sense trying.

The cost in morale of rejection

There are no units to measure here, but this is probably the second highest cost, next to time. When you’re doing a nights-and-weekends project for no money (yet), the only thing you have to keep you going is your excitement. Anything that endangers team morale should be considered a big threat.

We did our best to keep expectations low, but we inevitably started to make plans around TechStars. We daydreamed about what it would be like to hang out in Boulder. I thought about the envy my fellow startup guys in Atlanta would feel when DoLeaf got selected. Sarah and I discussed what we would do with our house during the summer. Looking back now, I remember having some of these same sorts of thoughts when buying a lottery ticket.

So, when the rejection letter came, it was a kick in the nuts. All of us were very disappointed, and it’s hard to work when you’re sad. We’ve recovered now, but there’s always the danger that you just quit working. I’m not afraid of that for our team, but I’ve seen it happen to others.

Actively plan your life as if you won’t get in

Hopefully, it should go without saying that you shouldn’t plan your life as if you’ll get in. Don’t quit your job, sell your house, give away your dog, or anything like that. But, more than that, you should actively plan as if you won’t get in. This means signing up for things and making plans that conflict with TechStars. In my case, I signed up for a 200 mile AIDS charity bike ride and a yearly 10k run. If accepted to TechStars, I would have had to pull out of both. But, we didn’t get in, and chances are that we wouldn’t, so I’m glad I didn’t put the rest of my life on hold. Think of it as hedging your bets. If you get accepted, it will be a happy occasion to cancel your conflicting events. If you get rejected, you didn’t leave a big gaping hole in your schedule.

Meeting with Drew

On a happy note, my favorite part of the whole process was meeting with Drew of Fifth Street Creative. Drew and Ryan have been friends for a long time, and Drew has done some great work on Obsidian Portal as well as DoLeaf. He happens to live near Boulder, so we got to go see him when we went to TS4AD. I had meant to thank him somehow for all his work, but my thanks ended up being sleeping in his guest room and drinking his beer. I’m a real gentleman, aren’t I?

Was it the right choice?

Any question like this has to be evaluated in the context of what you knew when you first started. Here’s what we knew:

• We have an excellent team.
• We have past execution experience. Obsidian Portal is a profitable startup and still growing.
• Our team is 2/3 technical, which is the exact ratio that Brad Feld recommended.
• We had an existing prototype, and were just entering a closed beta.
• Our idea has potential revenue from day one. It’s not earth-shattering, but it’s definitely something that can make money.
• Techstars had selected a similar team with similar idea in the past. This can be seen as both a positive and a negative.

In addition, we didn’t know the exact numbers (527 applications, 20 selections, <4% acceptance), but we did know the odds were stacked against us.

In short, we have all the markers of a TechStars selection. So, at the time, we thought our chances were at least as good as anyone else. We were not starting with any handicaps.

Starting with all the info we had, I think there is a clear answer to the “Was it right?” question. I think we did the right thing in applying, but that we handled the application poorly. We worked on it too hard. We should have invested less time in the application process and more time in our project. The morale hit would have been easier to bear and the project would be further along at this point.

Concluding Thoughts

Applying to a seed stage program can be useful, but can also be a big waste of time. In order to be seriously considered, it seems that you need to put in a lot of effort, at least for TechStars anyway. For us, we spent a lot of time, but didn’t get selected.

I could say it was a learning experience, but I really didn’t learn all that much. Plus, most of what I learned came from the people at Foodzie. They were (and continue to be) extremely helpful. This is not a dig on TechStars, it’s just my opinion that, as far as “learning experiences” go, the TechStars application process had a low return compared to the time investment. The same was true of our Y-Combinator application, although we spent much less time on that. What I did learn (or re-learn) is the main thrust of this blog post: Invest your time wisely!

Perhaps I’m just conservative, but I prefer to spend my time on things with a higher probability return. Coding, advertising, promotion, and customer interaction all have some sort of guaranteed benefit for the time you invest. With these seed stage programs, you can spend a lot of time (like we did) and come up empty handed (like we did). That kind of all-or-nothing activity is something I prefer to avoid. Granted, I do recognize that in the improbable chance we were selected by TechStars this would have been a completely different post about how the investment was worth every hour spent. Then again, I’m guessing most lottery winners will tell you it’s a good idea to buy lottery tickets.

The one main benefit to the process is the initial application form. Both the forms for YCombinator and TechStars force you to think about your idea in a little depth. From that perspective, filling out the form is useful, like writing a business plan. It will help you come up with a revenue model, elevator pitch, and competition evaluation. So, submitting the application is a great idea. However, after that, minimize your time investment on the application and instead spend that time working on your project.

Based on my experiences, here is what I would suggest as a way to maximize the benefit of an application:

1. Fill out the application form, and save it somewhere for access in the future. Think of it as a business plan. Plus, you can re-use the application in future rounds.
2. Get back to work and forget about the application.
3. If the program sponsors contact you with questions, answer them quickly and concisely. Don’t quibble. Then get back to work.
4. If the program sponsors invite you for an interview and offer to pay expenses, definitely go. They’re showing a lot of faith at this point. If they invite you to a meet-and-greet, go if it’s close, not if it’s far. Think hard before shelling our your bootstrap cash to buy a plane ticket, hotel, etc. After the interview/meeting, get back to work.
5. Work some more.

If you get selected, that’s great. If not, that’s OK too, since your investment is minimal. Instead, you spent that time working on your project and are that much closer to a release / new feature / milestone / whatever.

Above all, remember that your startup is what defines your success, not acceptance into a program. In the end, if you can break free of the dayjob world and work for yourself on your own project, who cares if you’re a Y-Combinator / TechStars / Whatever company? The goal of all this is not to be associated with any particular seed stage program, the goal is to love what you do and work on something you’re passionate about. So go do that!

Addendum: David’s Feedback

Once we became one of the Non-Selected TechStar Applicants we followed up with David asking for some feedback on what we were lacking. Below are the questions we asked and David’s responses (reproduced with his permission):

Micah: The team – Do we look good on paper (in our application)? In person? By email? Do we have a good skillset? Where do we compare to other teams?

David: The team looked good on paper and better in person.

M: Past experience – We think this is one of our best areas, as we’re very proud of what we’ve done with Obsidian Portal, our other startup. Did this come across well? What are we missing? Does it count against us that we’re running one startup while pitching a second?

D: I had assumed that the first startup was not going to be your focus on you started on this, so I wouldn’t say it was a negative factor at all.

M: The idea – We’re afraid that our idea just isn’t that exciting. We think it’s definitely a good one, but not the sort of thing that gets most people jumping up and down. It appeals to a special niche, which
we think is a good thing. Was this a factor in the decision?

D: Exciting? Ecommerce for nurseries – yeah, maybe not the most exciting thing. But that doesn’t matter. Most investors I know (including us) look for markets over excitement – the old adage is “boring=revenue”.

M: Ability to execute – Again, we think our ability to go nose-to-the-grindstone and execute instead of blowing smoke is one of our strengths. Did that come across well? Did other teams do massively
more than us in the application time span?

D: You guys did a lot during our diligence process, which is why you scored highly. But yes, I would say other teams advanced their technology much more rapidly during this timeframe. Obviously, it’s hard to judge just be that – but it’s one component.

Comments

I’d love to hear what you think about all this. I especially welcome comments from other rejected-but-successful companies out there. The chosen few Accepted often come out in support of their seed stage program, but like I said, lottery winners encourage you to buy lottery tickets, too.

On January 23, Gabe over at Penny Arcade gave a fairly glowing review of Obsidian Portal. It was short and simple, but basically said “They get it” when it comes to managing a D&D campaign. Minutes later, the PA masses started streaming in, and thus began the craziest couple of hours in Obsidian Portal’s history, and what I will forever call PA Day.

Beware the Cave of Tits!

The Epic Tail

Our traffic spiked by at least 1000% pretty much immediately. Page load times skyrocketed from a second or so into nearly a minute range. To compound the issue, I was at work plugging away on a hard deadline of “right now!” I couldn’t just ditch and go work on Obsidian Portal, so I watched helplessly as we were wanged.

Luckily, Ryan was a little more flexible than me, and he got to work. Logging into our slicehost panel, he immediately started spinning up a slice with 2GB of memory. All the while he was giving me updates via IM. It was like something out of a BSG episode, with the heroes spinning up the FTL drive while the Cylons are swarming them. (Note: We don’t consider the Penny Arcade users to be Cylons, although they might like that.)

Ryan: It’s at 30%
…
Ryan: 60%
…
Ryan: 90% almost done
…
Ryan: 100% – New slice is ready. It’s syncing and doing the switch
Ryan: come on…come on…
Ryan: We’re up!

All the while, I was terrified that something would go wrong in the switchover causing both the original and the new slice to be inoperable. Further, what if there was a problem with the DNS, causing requests to go to the old slice instead of the new one? I thought I was going to throw up, I was so nervous.

But within only minutes our new slice was up and running and doing a much better at handling the influx of traffic. Still, just to be sure, Ryan went in and started tweaking Apache / Passenger settings to make sure that everything was in tip-top shape. As we all know, Apache is pretty damned complex and it’s pretty hard to get the settings just right for your particular instance, especially on the fly. Things were running much better, so I was finally able to start relaxing.

The Fallout

Obsidian Portal had a massive spike in both visitors and signups. Our overall traffic was up 1,000% from the previous day, but even better, thanks to Gabe’s endorsement, the Penny Arcaders were signing up at a rate twice as high as regular visitors. Compare that to your average digging, reddit, or slashdotting, where visitors browse through and possibly leave a hate-filled comment, then move on.

By the time the dust settled on Monday afternoon when Penny Arcade posted a new story on their homepage, we had received thousands of new signups and hundreds of new campaigns. All in all, it was a fantastic weekend.

Visits were way up, but even better…

Pageviews stayed high even as visits declined. That means we hooked some of them!

Lessons Learned

Success or Failure?

Campaign updates were streaming in.

When the first wave hit us and our server started collapsing, it seemed as though we had failed. Here were thousands of people trying to get to our site, and they just plain couldn’t. Ryan especially seemed very frustrated.

However, when I thought about it later, I realized that it was a success, even if the site would have crashed and burned. Why? Simply because thousands of people were trying to get to our site. People were eagerly attempting to connect to our server and in the meantime were spreading the word about our site through the blogosphere, twitter, and others, letting all their friends know how the guys at Penny Arcade thought Obsidian Portal was so awesome. They also found resources in other locations such as previous reviews, Obsidian Portal’s Twitter account, Obsidian Portal’s Facebook Page, and even Michael Harrison’s Viemo Video World Building with Obsidian Portal.

The lesson? Maybe you scale, maybe you don’t, but at least you proved your idea. It’s a lot easier to take a popular site and make it faster than it is to take a screaming fast site and make it popular. The technology issues are by far simpler than the social ones.

Break out the credit card immediately

The very first thing Ryan did was to spin up a bigger slice, and that had by far the biggest impact on the number of requests we could serve. We could have tweaked MySQL settings, adjusted Apache processes, or experimented with exotic caching. Maybe it would have helped, maybe not. Optimization is a tricky business. When you’re at the point where your server is on its knees, you don’t have time to figure everything out, so spend money instead of time. Call your host and say “Gimme the biggest one you got!” You can always downgrade later.

Make basic optimizations ahead of time

Go ahead and spend a couple hours doing basic optimizations. For example, on Obsidian Portal, we had already applied some aggressive caching to the home page prior to PA Day. It took Ryan a couple hours to figure out. That’s a couple hours we didn’t have on PA Day, so we’re glad we spent them up front. Lesson? Don’t go nuts and try to optimize everything, but go ahead and do the basics. Do it now! Don’t wait!

Always have two sysadmins

I’m glad I have a day job (and a paycheck!), but that means I’m not always available to handle issues with the site. On PA Day, I was in crunch time at work and therefore pretty much helpless for Obsidian Portal. Luckily, there are two of us who can essentially do everything. That way, there’s a much better chance that if something happens, one of us can get to it and fix it before it causes too much trouble. It’s important to have failover backups for people as well as hardware, and someone to double check your ideas before implementing them in a hurry.

Yay Slicehost

Getting bigger iron was our fastest, safest, and best course of action. Slicehost made it easy. We were able to spin up a new identical slice with double the RAM and CPU in only a few minutes. Essentially, Ryan flipped a switch, waited 15 minutes, and we were on a beefed up server. No service call, no email, just raw speed. Perhaps other hosts offer this solution, I don’t know. What I do know is that Slicehost has always preformed exceptionally, and we thank them for that.

Yay Passenger

When Ryan wanted to move from Mongrel to Passenger, I was a little skeptical. I’m always hesitant to “fix” that which isn’t broke. Seems a little like running in place to me.

However, Passenger made scaling a snap, at least as far as server management went. No editing the mongrel cluster. No managing and restarting via God or Monit. Just leave Apache running and it will do its thing when the requests start rolling in. It’s just one less thing to worry about.

Going forward

Things have calmed down a bit now, and we’re back to the sure and steady growth that we’ve been seeing all along. Our new Penny Arcade fans have been successfully hooked and are steadily churning out new storylines, characters, and campaigns.

On our end, we’ll keep working on the site, adding features, fixing bugs, and improving server performance to be better prepared for more days like PA Day. The continual good feedback we get keeps us energized and hopeful that it will continue to grow. We may not be rich (yet), but we’re creating something that people love, and that feels great.

And one last thing. It’s a site written in Ruby on Rails and we made it scale!

Obsidian Portal was mentioned today on Wired’s Geekdad blog as a great place to do worldbuilding. Well, I would hope so since that’s one of the main purposes of the site.

A big thanks to the author, Michael Harrison, for the bump! I can’t wait for part two!

Today, we received a note from the Earl of Stirling regarding what I assume is his appearance on Obsidian Portal. (Search for “sterling”)

Please do not use my name in your gaming/whatever. I am the Earl of Stirling (short form Lord Stirling).

Thank you,
Stirling

Unfortuntely, I think we’re going to need a little more proof than a yahoo.com email address to verify the identity of a Scottish noble.

Update: This guy might be legit…or at least he thinks so. Check out his blog, where you can buy your very own Scottish Title! Impress your friends and get girls! Only US$90,000! Act within the next 30 minutes and we’ll throw in a free set of castle blueprints and a 25% off coupon for your next order at Arms & Armor!

Update 2: As always, the true story is on the Wikipedia article discussion. Long story short, a blowhard from Indiana claims to be Scottish nobility through some arcane legal loophole, friendly Wikipedians keep reverting his edits to the Earl of Stirling page, he repeatedly threatens legal action, he gets banned for threatening legal action. Ain’t Wikipedia great?

Today, Yax at DungeonMastering put up a good post about energizing your campaign by using a wiki. I thought this was common knowledge by now, but there were apparently lots of people who hadn’t thought of it. I still forget that I’m not a very good representative sample of the technical savvy of your average Joe.

Yax was an early adopter at Obsidian Portal, and was kind enough to give us a nod in his article. In what I’m sure is a total coincidence, we got a ton of traffic today and about twice as many new signups as our previous high.

So, thanks Yax and keep the good press coming!

Wizards of the Coast has announced they are shutting down Gleemax. Although I was never a big fan (being a teeny-tiny competitor…), it’s sad to see an online meeting place for RPG players disappear. In addition, despite all the bumps and stumbles, they somehow garnered the support of some really great people.

Of course, now all those supporters are going to be left out in the cold. I suggested to the powers-that-be that they allow people to retrieve their entire blogs as an RSS feed. It shouldn’t be that hard to do and would vastly simplify the process of moving a blog to another platform. We’ll just have to see if the WizOs have mercy on their loyal followers.

To all you Gleemaxers who need a place to brag about your campaign, Obsidian Portal is still open for business…

I’ve had my first brush with EC2 today, and I’m thoroughly confused and exhausted. It definitely has a much steeper learning curve than the other Web Services. However, since you’re dealing with booting and configuring fully functional virtual machines, I guess that’s to be expected.

Still, I managed to spawn an instance, set all the necessary permissions, and then connect to it via ssh. Not exactly something to brag about, but it is a milestone. I consider it $0.20 well spent. (I had to terminate and re-run the instance because I didn’t store the key-pair RSA key the first time.)

The goal

For Obsidian Portal, the map processing and tiling is very CPU and RAM intensive. If run on our Slicehost VPS, it totally bogs down the whole system, making the main website completely unresponsive.

So, we’ve offloaded the processing to a machine in Ryan’s attic. Although it’s worked so far, it’s not exactly a professional solution. Plus, Ryan’s getting ready to move and his machine will be off for at least a week. That means we need a new place to run our stuff. Since I’ve been meaning to dive into EC2 for a while now, this seems like the perfect opportunity to put in place a permanent and professional solution.

The plan

Whenever we need to tile a map, I plan to spin up an EC2 instance and run the tiler. I’ll keep the instance up for the rest of the hour, in case more maps come in. When the hour runs out, if there are no more maps to process, then we’ll spin down the instance. Computing power on demand…nice!

grempe-amazon-ec2

If you’re a Ruby hacker, skip the EC2 toolset altogether. Just go get the grempe-amazon-ec2 gem and run all your EC2 requests through an irb shell. This allows for opening up the EC2 developer reference and learning the API commands straight from the docs, rather than having to learn the EC2 toolset. You’re probably going to have to spawn/terminate instances dynamically at some point, so you may as well just learn how right from the start.

Besides, the EC2 toolset route involves setting up a JVM, setting JAVA_HOME, and all that Java mumbo-jumbo that always takes way longer than it should. Save yourself a headache and go straight to the source.

ec2onrails

I’m not looking to run a full Rails server (yet), but we do want to run some rake tasks. Rather than hand build an image, I’ve decided to start with the ec2onrails image and see if that gets me most of the way there.

The main downside is that this image will need to install RMagick, ImageMagick, and possibly other gems and packages each time it spins up. ec2onrails has built-in support for this, but it means that the map processing can’t start for several minutes after the image boots up, meaning our users have to wait to see their maps. For now, it should be acceptable, but it’s something to improve on.

Next Steps

I’ve had enough for today, but there’s still a ways to go. I need to complete the following:

1. Setup the cron job on our VPS to spawn the EC2 instance whenever a map needs processing (and there’s not already an instance running)
2. Setup the script (rake task?) for the EC2 image that will do the processing. It may as well just run forever. Maybe it can be responsible for terminating the image? Hmm…that sounds dangerous. If it should crash out, then the instance will keep running and billing us!
3. Surely there’s more…

Oh, and one other next step: I’d better go terminate the instance I left running!

We’ve taken a small leap and added several microformats to Obsidian Portal. It was just so easy, there was no reason not to. For starters, we’re going with hCard and XFN.

Right from the start, we’re going whole-hog on hCard. I made a helper function to output an hCard every time we display a user’s avatar. So, every comment, every recent update, every friend link has an hCard on it. If the microformat-aware spiders cannot figure out who is who on Obsidian Portal, then they’re brain-dead.

Secondly, we’ve added XFN rels on the friend-links in the user’s profile. I don’t know of any (non-trivial) tools that are using XFN yet, but it’s easy enough to add, so we did. We’ve got rel=me on links to user’s other websites, and even self-referential rel=me links on the profile pages. We’re basically screaming “I am me” at the spiders.

Still on the TODO list is rel-tag for the NPC character tags. We’ve got a lot of plans for tags in the future, we just need to free up some time to work.

In the future, I might look at adding hAtom for the Adventure Logs, but honestly, we’ve already got RSS feeds, and I can’t see the value-add here. Am I missing something? Let me know.

Examples

• My profile – hCard and XFN enabled
• The homepage – Notice the hCard for each recent-update user
• An Adventure Log post – Notice the hCards for the comments

Resources

• Microformats.org – The definitive source for information.
• Operator – A microformat parser plugin for Firefox. Adds a nice little toolbar that lights up when microformats are detected.
• Tails Export – Another microformat parser plugin for Firefox. Seems to handle de-duping better than Operator.
• rel-lint – A validator / checker for XFN and rel-tag

Recently, I noticed that the LoneGM had put together a pretty good review of ObsidianPortal. He focuses on it from a play-by-post perspective, which is not exactly what it’s for, but still gives us a good rating.

Like me, it seems that most of the people using OP can see what it should be, even if it’s not there yet. We’ve all been searching for a good campaign management tool for a long time, and building it up to match that perfect ideal will be a long road.