Tag: Programming

Considering a Screencast Series

Screencasting! It’s the teaching medium that’s sweeping the nation!

I love screencasts. Certain ones, anyway. Done well they enrich understanding. Done wrong they’re a snore and a half. I’m in the middle of redesigning Jetrecord and the more I redesign the more I’m considering redoing it from the ground up (and doing some screencasts about the process).

Why? Well, I’m looking at all the shortcuts I’ve taken to get to where Jetrecord is today and frankly, it’s embarrassing. Don’t get me wrong. I LOVE Jetrecord and I think it’s both a great idea and a great product. I just think I can do better. I owe it to my customers to make it the best it can be.

I’m also one of those people who loves great foundations; well, I love the idea of great foundations. I love talking about foundations, dreaming about them, planning them, scheming. But when it comes time to build the application I get so focused on delivering a great experience and a great product that I glance right over the possibility that I may change my mind on a few foundational things, that people involved in the project come and go, that features come and go, et cetera. I know it’s impossible to plan for everything but I know there are some things I could do a whole lot better.

When I build an application I put a whole lot of time into building great user experiences (I try, anyway) and just enough time into making sure the application keeps chugging along. I tell myself, “it’s not a problem until it’s a problem,” which is a great way of looking at life for most matters. 80% of the time, we really don’t need to plan for all the contingencies we plan for. Of course, it’s that scary 20% that keeps us awake at night with a death grip on our Blackberries waiting for that 3am email from the error system. (Thanks, Internet!) An example of a 20% problem would be the current financial crisis in America. We were doing fine ignoring the underlying foundational problems for a while but now it looks like we picked the wrong year to stop sniffing glue. So when it’s a problem, it’s a real big, fat, hairy problem, with mutated teeth growing out of a tumor in your stomach.

Granted, most of us don’t encounter these problems. For small, local, mostly internal applications, applications in which we and maybe 20 other people are the only users, the 20% problems can usually be contained. It’s when we move into the realm of needing to support thousands of users in multiple countries on a 24/7 basis that we start encountering the mutant teeth kind of problems.

Jetrecord isn’t quite the super-multinational app yet but I believe it’s going there. It will, I tell you!!! Moreover, I’m at a place in its development where stopping and doing the right thing makes sense. I’m redesigning anyway and my plans already involve a better foundation. If I wait until it actually is supporting 20,000 users in 20 countries, I’ll have quite a job on my hands. I’ve racked up some code debt and it’s time to pay it off–and start saving a little.

But why do a screencast about it?

For one thing, I’ve been a code leech for most of my career. I’ve written a couple free things here and there and released them into the wild but nothing too substantial. Mostly I’ve read other people’s books and articles, attended other people’s conferences, and taken other people’s free code samples. And truly, all of these things have taught me a lot and I wouldn’t be where I am without the generosity of many, many people. But I think it’s time I did something substantial, extraordinary, and excellent for others.

Second, it’s going to force me to write the best code I can. I’m embarrassed during code reviews if there are glaring mistakes so I’m going to try hard to make sure it’s worthwhile code because it’s public. I already know I’m going to have to do a lot more research to find best practices and I’m sure I will make mistakes and I hope someone will be kind enough to suggest improvements. This will benefit me and you as coders and ultimately it will benefit the applications we build and the clients and the users we support. Win-win-win-win-win.

Lastly, I’ve been doing screencasts since 2001, since before they were called screencasts. In one of my previous jobs we were publishing “help videos” in Camtasia on our web site to show users how to use the site and some of the software products we supported. I consider myself knowledgeable enough to make a good video, or at least, to give it a go. Whether they’re actually good or not is up to you.

Having said all of that, I still haven’t fully settled this in my mind. I want to do it. I know it would be good. However, screencasts take a lot of time to do right. For every minute of production video there’s 30+ minutes of material and mistakes that don’t make it in, not to mention planning, outlines, scripts, research, creating or finding other media like music, artwork, and extra video. Then there’s editing, producing, and finding a place to host it. It’s not unlike being a T.A. in grad school. You’ve got this whole other full-time teaching job to do while you’re trying to complete your own studies. (At least, that was my experience.) It’s both fantastic and super-sucky at the same time. And you don’t get paid!

So, if the series is going to show up, it’s going to show up here on this web site, and probably very soon because I’m already building the foundation for the next Jetrecord (which is going to rock, by the way; if you’re a pilot, you should use it). If I wait too long, I definitely won’t do it.

Okay, thank you, and now for my next anti-climax…

A List Apart Web Survey, 2008

I took it. You take it.

Take the survey

You can copy my answers if you want.

Startup Weekend, Boulder, Colorado

I attended Startup Weekend in Boulder, Colorado this past weekend and I’d like to encourage everyone and anyone looking to start any kind of company to attend one if they bring the event close to your town.

The format of the weekend is like this: you gather together Friday night, meet awesome people, propose ideas, gather enough support for your idea (in terms of human capital), and then spend the rest of the weekend assembling your idea.

On Friday night there were roughly 100 people in a small lecture classroom on CU’s campus. All of them are smart, motivated, tech-focused people, the kind of people you always hope you get a chance to work with, unless you’re already working for a startup of some kind, in which case, you probably already are. Everyone’s on Twitter and/or Facebook and/or every other social web service. Everyone reads the same people you read or knows someone you should be reading. Everyone knows the same current events on the web you know or knows something you should know. Some of them have flown across the country to attend.

I pitched a few ideas but ultimately decided to work with a small group that wanted to create a poor man’s content failover service for web sites that receive unexpected Digg/Slashdot traffic. We called it Hitsurance. By 11pm Friday night we had our idea, a name registered, and a dedicated server set up with a splash page and email submission form. I went home and crashed with my brain racing away on ideas well into the night. I woke up twice to write some notes. Needless to say, sleep was fitful.

We worked Saturday from 9 to 9 and got about half way there. We had a design, a logo, the basic premise for the demo fleshed out, a blog, SEO research completed, Google Apps for Your Domain acquired, a Twitter account, and some of the backend scripting in place.

All work and no play would be boring, of course, so part of Saturday the attendees spent time socializing, working, eating, and bouncing ideas. We had a short concert from local singer/songwriter Reed Foehl, which was unexpected and strangely appropriate. By the end of Saturday most of us were fried. I went home and crashed but again, didn’t sleep very well.

We returned Sunday and worked from noon to 7, finishing up as much of the demo as we could. We got the service working around 6:30pm with just enough time to eat and do some fine-tuning before the group demo session at 7. Our demo worked as expected and, dare I say it, the site and the signup experience look pretty sharp considering we started from nothing Friday night. As for the future of the service, my co-founders and I are still discussing it. It’s definitely a useful service and a win-win all around. Content producers keep their audiences going and hosting providers stave off potential server crashes, which makes the rest of their customers happy.

You can read about the other groups at the Startup Weekend re-cap. I think the Web2Splash idea is both cool and useful. I’m also interested in seeing the IMDB for Podcasts go forward. It would mesh really well with one of the ideas I proposed. If Jetrecord doesn’t take up all of my time I might contact Andy in the future.

Now how much would you pay?! If the whole experience of building a product over a weekend with good people is not enough, all the groups got to pitch their ideas and chat with Loïc Le Meur, Jeff Pulver, Guy Kawasaki, Eric Litman, and Stowe Boyd, each individually. Where else do you get a guaranteed chance to do that, especially with an idea you just came up with the night before? All for $40?

I had a great time meeting and working with everyone and to boot I got to use a few Perl libraries that I haven’t tried before.

Again, I highly recommend it to anyone thinking about starting their own company, especially one with a web focus. But any type of high tech idea is a good fit for this event.

How To Install Darwinports/MacPorts Without Submitting Your Email

Update Sept. 26, 2007: I need to search more. MacPorts.org has the latest source sans hassle.

The latest version of Darwinports asks for your email address before you download. I’m sure you mean well but no, thanks.

The workaround is to install an older version and then do a selfupdate, like so:

  1. Get version 1.3.2 from MacOSForge.org
  2. Unpack and place in /usr/local/src
  3. cd into the Darwinports directory
  4. Run [source:bash]./configure && make && sudo make install[/source]
  5. Edit your $PATH in ~/.bash_profile to include /opt/local/bin if it’s not there already
  6. Restart Terminal
  7. Run [source:bash]sudo port sync && sudo port selfupdate[/source]

That’s it. You should have the latest version of DarwinPorts/MacPorts. You may now “sudo port install” to your heart’s delight!

No It’s Not An Exit

Xanadu Star Theater, Cleveland, Ohio - Int.
Derek: No it’s not an exit. Not an exit.
David: We don’t want an exit.
Derek: No, that’s true.
David: Try this way.
Derek: I hope so. This way.
David: Wait, this looks familiar, though…it really does.

After stumbling around in the dark for the last several years I’ve decided to learn the fascinating Science of Computers from MIT’s OpenCourseWare. Up first, 6.001.

David: I don’t know, it’s in Indiana or something.