Rehan’s blog

I just came across Rapleaf’s About page, where they’ve listed some Special Thanks at the bottom to acknowledge some people that have helped them through their startup phase.  It’s an excellent example to show how a network of peers can help each other and grow together for the benefit of the community.

Kiwi Bloke makes a great case for Toronto becoming the Web 2.0 capital of the North.  The recent activity from Toronto startup and the tech community in general has been very positive.  Joey DeVilla also posted some thoughts in his On Becoming Silicon Valley series of posts. In the last couple of weeks, several Toronto-based projects have received their short bits of fame — Bumptop on digg and other sites, FileMobile (local demo coming soon) on TechCrunch, and BubbleShare also on TechCrunch…that’s all great stuff. 

But then if you take a look at the list of FooCampers of 2006 there’s a strong Canadian representation, yet none of them are from Toronto (not living here at the moment, at least).  Something doesn’t quite jive there.

That’s okay, though.  We have our own thriving *Camp community.

Ryan McKegney of Clear Sky Media (creators of RedFlagDeals.com and PriceCanada.com) has started a new blog to chronicle their startup adventures — StoryofaStartup.com.  Derek Szeto and Ryan have done a great job of making both sites quite successful, so it’ll be an interesting blog to read.  Keep an eye on it.

There has been a bit of a surge of activity in the local tech community in the last few months — conferences, unconferences, workshops, informal meetings, etc..  It’s a great way to meet others doing similar things as you.

To be honest, I’m a novice at social/business networking and it’s definitely something I need to learn more about.  So to continue my usual everything-i-know-i-learned-from-google style, I crawled the search results to try to find some useful information. 

With some ideas from what I found and from my other observations and experiences, I’ve cobbled together my list of 10 Networking Tips for Unconferences like BarCamp, DemoCamp, and {insertYourFlavor}Camp:

1. Be prepared. Know the crowd, know yourself, and bring everything you’ll need.  More to come later.
2. Listen and understand first. And then seek to be understood. (apologies to Covey )
3. Contribute. Participate. For unconferences, this is a given. Be an asset, and try to give more than you get. 
4. Be proactive. Don’t just wait for people to come to you…take the initiative to engage others.
5. Be genuine. Nobody likes a phony, and word can spread fast.
6. Have fun! The most effective networking sessions are usually those where you had the most fun.  So enjoy yourself.
7. Take notes. For me, written (or typed) notes are much better than mental notes. Use a Moleskine or PDA or laptop or whatever is handy. 
8. Follow up. If you told someone you’d do something, then do it. And do it sooner rather than later.
9. Continue the networking online. Use mailing lists, your blog, e-mail, etc. to continue the conversations after the event.
10. Attend more events. The more you interact face-to-face, the better you can nurture your network.

There you have it.  As I mentioned above, I’ll post more about ”Be prepared” later, because that is one of the more important points and deserves more than just a few words.

I’d love to hear from anyone else that may have other tips or experiences to add to this.  Just leave a comment below.

Last night was another good DemoCamp gathering, with five more interesting presentations.  You can find some detailed recaps from Brian Ivanovick, Olivier Yiptong, and Pranam Kolari.

A couple of the more interesting aspects for me were in the Paruba presentation by John Lax and the Perl 6 presentation from Damian Conway.  John did more than just a “show and tell” about Paruba; he also commented on some of the challenges Teehan+Lax encountered while they were working on the project. Short version: they were hoping to do it in their “spare time”, but it wasn’t until they isolated resources and dedicated them to the project that they actually made good progress on it. Personally, I like hearing those kinds of experiences even more than seeing the app demos.

Although Damian Conway spoke about a language that gets little attention these days, his dynamic presentation style was very entertaining. And his loud and clear voice also made him the easiest presenter for everyone to hear. Damian talked about the changes that are going to be introduced in Perl 6, which has now been in development for 6 years.  There are certainly some interesting features that the language will have, but I don’t see Perl ever regaining the prominence it had years ago in web applications. Incidentally, a major part of the project that I worked on the last 6 years for a large company was a text processing script written in Perl 5; that’s the kind of stuff for which Perl will remain a good choice especially with the improvements in Perl 6.

It’s pleasantly surprising to see that there seems to be no shortage of Toronto techies working on neat little applications. Eight out of ten presentation slots for the next two DemoCamp events are already filled!  John Philip Green recently made some changes to the BarCamp wiki to promote the idea of DemoCamp events in other cities as well. Based on what I’ve seen in Toronto, I think that’s a great idea for other communities to have a reason to get together regularly. Update: David Crow has just put up a great post about organizing a DemoCamp in your own town.

A backup is only as good as the ability to restore from it.

I’ve often seen a lot of emphasis put on the backup process, but not nearly enough on the restore. The risks of not testing your restore process should be obvious. But sometimes seeing someone actually being affected by it can be a reminder that we should be diligent about it.

The CouchSurfing Project is was an interesting project that allowed travelers to find accomodations in the homes of other people around the world; and judging by the numbers (almost 90k registered members), it was fairly popular.  But this week, “the perfect storm” apparently killed the project.  TechCrunch reported that the CouchSurfing.com website now says:

Two days ago CouchSurfing experienced what could be described as the perfect storm. The database administrators we hired made two critical mistakes. First, we had a major, avoidable hard drive crash. Secondly, the incremental back-ups weren’t executed in the correct manner, and twelve of our most important data files didn’t survive.

I have been working non-stop trying to repair the data, but as difficult as it is for me to say, it has become clear that certain essential pieces are not recoverable. This crash happened at a particularly vulnerable time, in a transition between two back-up methods. If the crash had happened a week ago, or next week, we would have had a different outcome.

It is with a heavy heart that I face the truth of this situation. CouchSurfing as we knew it doesn’t exist anymore. We’ve had an amazing two and a half years.

…

I have devoted the last three years of my life to CouchSurfing. I have literally poured every cent I have into the site. I’ve sacrificed my health, my time, and my own ability to travel and meet people. In many ways I’ve put my life and wanderlust on hold to build this network. I’m not complaining; it’s been a fantastic ride. As devastating as it is to consider, it looks like the ride is over.

Ouch!

On the technical side, Dharmesh Shah very wisely points out that aspiring Web 2.0 startups should not cheap out on their technology infrastructure. I would assume that the bigger players have their act together, but I know that backups are considered a premium service in the web hosting world and some customers simply choose to go without an appropriate solution. Is it really worth the risk? 

And on the business end of things, there has been some discussion about issues with CouchSurfing’s business model.  It’s mostly speculation of course, but those points are also worth considering…especially for Web 2.0 entrepreneurs.

Anyway, if you haven’t tested your backup and restore processes lately, now is a good time!

Some of you may have realized that my tagline at the top of this website is a reference to Rene Magritte’s painting La Trahison des Images (err…ignore the fact that my version doesn’t really make as much sense as Magritte’s…). I just came across the picture above, which is Dan Kurtz’s very cool PowerBook…it’s a rendition of another Magritte painting, The Son of Man. In his blog Dan provided the files for this ‘tattoo’ and mentioned a couple of suggestions for other artwork on notebooks. I wonder if anything would look half decent on a boring old Thinkpad.

Congrats to Anand Agarawala, whose BumpTop demo I mentioned in an earlier post on recorded demos. He demonstrated the technology during the TorCampDemoCamp6 last month. In the last 24 hours or so, his demo has been linked from Slashdot, digg, Gizmodo, and many other sites (he has some links at the bottom of his demo video page).  Technorati shows that about 250 of the 321 blog posts mentioning BumpTop are from the last day!

This again shows the value of having a screencast, especially if you have something cool to show off. I think Anand was in the market for a job at the time he presented at DemoCamp, so hopefully this exposure will lead him to some good opportunities.

Don Dodge’s latest blog entry summarizes Kleiner Perkins 7 rules for start-ups, which they use when considering companies for funding.  I think it’s an excellent list not only for VC-hunting software start-ups but even for bootstrap entrepreneurs in that space, because it provides a good guideline for many of the ways good websites are structured these days. Go take a look.

This is Part II of a series of posts with some thoughts about improving the operation of events and people gatherings. More than anything else, this stuff is just meant as a reminder to myself…these are things that I should be more proactive at doing myself.  And my focus is on small or medium sized events that take place regularly - like weekly gatherings of a hundred people - because that’s what I’m most familiar with.

In Part I, I mentioned feedback and lessons learned, which I believe are essential components of improving upon past experiences.  What I want to discuss in this ‘installment’ are a couple of “Write Once, Use Many” items: checklists and infosheets.

Checklists
I was hoping to attend the last BarCamp Toronto event earlier this month, but I ended up having to go to a funeral in the morning and then a different all-day event in Brampton, where I was looking after the audio/video and technical aspects.  At that conference, everything went very well except for one thing — none of the organizers brought a camera to take pictures!  So in the middle of one of the presentations, I rushed home to get my camera and the conference was saved (okay, maybe I’m exaggerating just a tad about the success of the conference being hinged on the camera).

Would you step on an airplane if the pilot told you he didn’t need to bother with a pre-flight checklist? If you would, then you’re far more daring than I am. One of the key values of a checklist is that it greatly reduces the risk of actions being omitted because they were forgotten. And the greater the importance or complexity of your tasks, the greater the value of the checklist.

So if you want to increase the likelihood of an event running smoothly, you have two options: 1) use a checklist, or 2) rely on your memory.  I keep forgetting that my memory is terrible, so I had not ‘bothered’ to make a checklist for my responsibilities at the conference.  If I had used a checklist, the camera would not have been forgotten.

Infosheets
What I mean by infosheet is a single sheet of paper that has the most important information about the tasks condensed onto it for reference. It’s sort of like the idea of cheat sheets that are sometimes used for university exams, with the essential information laid out where it’s easy to access.

As an example, for the building where we had the conference I mentioned earlier, I use an infosheet that lists things such as:

• basic steps for startup and shutdown of the audio system
• locations of the 24 mic inputs throughout the building
• locations of the 4 video inputs and mapping to channels on the closed circuit TV system
• a quick guide to the audio control panels for the listening zones
• contact information with cell number listed for any questions

I use this infosheet as a guide to train others to use the system, and a copy is stuck on the wall in the a/v control room so we can reference it at any time.  There are times even I would be fumbling through the a/v settings if I didn’t have this handy.

Write Once, Use Many
WOUM is not quite as appealing as WORM, eh?  Anyway…

The great thing about using checklists and infosheets for routine tasks and recurring events is that you write them once and then use them many times.  If you’re running events regularly then certainly there may be minor variations in the specifics from event to event. But by and large, the operations will be similar for the vents and these tools will be easily available for use.  So there is a little bit of work required upfront to create these resources, but the payback comes quickly.

Needless to say, these are “living documents” and they should change based on the feedback and lessons learned that you get from each iteration.