The Downtempo Blog

As I begin full-scale development on a couple of new products, I’ve been casting an eye down the road towards potential funding sources. The biggest question from the angel community was “Where’s your technical co-founder?”

I’m a reasonably technical person, and I’ve scratched out some perl scripts, java, javascript, css, and html5 code in the past, but i hadn’t considered myself a “developer”.

But I’d seen that having a technical co-founder was a blocking issue, so I’ve decided to be my own technical co-founder for the time being.

For my fellow entrepreneurs looking at making the same transition, let me give you my development stack information. This material is targeted for people building Ruby web apps on OS X Snow Leopard:

Andy’s Simple Ruby Web Application Toolkit

1. Install the latest version of XCode (free) from http://developer.apple.com/technologies/tools/xcode.html
2. Install TextMate (free trial, $57 to buy) from http://macromates.com/
3. Setup Ruby and Rubygems as per the instructions on Hivelogic
4. Create a “Development” folder, like in your home directory, to have your projects live in.
5. I’m going to assume you want to start with simple projects, so go ahead and install the Sinatra framework with “gem install sinatra”.
6. Create an account on Heroku to deploy your new applications on, and install the heroku gem.
7. Install Homebrew as per their instructions.
8. Install git and any other unix goodies you want with the “brew install” command. at least load git with “brew install git”
9. You’re ready to build! Go knock out a simple Sintra app by following their 4-line “Hello World” exercise.
10. Now that you’ve got a working app, deploy it on Heroku using Heroku’s instructions for deploying Sinatra apps.

And you’re done! You’re building Ruby apps in Sinatra, staging them locally, and deploying them to the web via Heroku. Rock on, new developer and future technical co-founder!

iPhone N.B.: As I get more into iPhone development using languages that I already know, such as JavaScript, I’ll be giving more coverage to PhoneGap which is a really neat-looking solution for building iPhone apps in JavaScript and being able to compile for several other smartphone platforms as well. (And if you’re looking to get started with them before I have a chance to write that post, make the jump over to their setup instructions and get started!)

370No Comments.http%3A%2F%2Fwww.downtempo.net%2Fblog%2Fdevelopment%2Fbe-your-own-technical-co-founder%2FBe+Your+Own+Technical+Co-Founder2010-11-05+20%3A29%3A46Andy+Volkhttp%3A%2F%2Fwww.downtempo.net%2Fblog%2F%3Fp%3D370

I’ve been making some changes at Downtempo lately, and one of those was moving out our office over at 1890 Bryant and into the new I/O Ventures space on Valencia Street in the Mission.

Why did we leave our cushy office space on Bryant Street? To focus down on building the next big thing in consumer products. I’ve discovered that “20% time” wasn’t enough to really focus on building a great new independent product, although I’ve been happy with the results we’ve gotten with Is It Safe to Visit? and NiceTips.

By entering a community of people focused on building products, I/O Ventures has a great ecosystem and set of teams for us to exchange inspiration with. (and of course, having The Summit cafe in our building doesn’t hurt either!)

So it’s back to the serious basics: smart people, big ideas, lots of computers, and plenty of space to work in. Time to go build some products.

372No Comments.http%3A%2F%2Fwww.downtempo.net%2Fblog%2Fcompany%2Fweve-moved-to-io-ventures%2FWe+Have+Moved+to+I%2FO+Ventures%212010-11-01+17%3A23%3A23Andy+Volkhttp%3A%2F%2Fwww.downtempo.net%2Fblog%2F%3Fp%3D372

One of the things that i love to do is travel, and that usually ends up getting mixed with work in all kinds of delightful ways.

Whether it’s spending time on the mobyboat with Mathys from Mobypicture, building NiceTips with Kareem Mayan in one sunny Budapest week, or attending the Geekretreat in South Africa, I’ve been lucky enough to engage with works in ways ranging from an afternoon cup of coffee, to a weekend of looking at using technology to address social issues, to building a new product fro the ground up.

Just wanted to share some of those experiences with you. While it’s not always clear where these interactions are headed when they start, i’ve never regretted any of the connections I’ve made. (and yes, i’ll be glad to see my fellow American entrepreneurs and friends in San Francisco when i return home later this week!)

And for those of you visiting the Bay Area and San Francisco from other countries, feel free to drop me a line and see if we can meet up! I always enjoy sharing stories from the SF / Silicon Valley tech scene, and getting new perspectives on technology and entrepreneurial projects the world over.

358No Comments.http%3A%2F%2Fwww.downtempo.net%2Fblog%2Fcommunity%2Fhave-iphone-and-macbook-air-will-travel%2FHave+iPhone+and+MacBook+Air%2C+Will+Travel2010-10-05+11%3A06%3A00Andy+Volkhttp%3A%2F%2Fwww.downtempo.net%2Fblog%2F%3Fp%3D358

As software increasingly moves into the cloud, we’ve gotten used to upgrades being rolled out invisibly on our favorite web-based applications ranging from Gmail to the New York Times, and receiving notifications after the fact of functionality which has been added or changed.

If this approach works, then why is so much of our time still being wasted on manually installing or confirming updates on my laptop computer, smartphone, and blog software?

Why not have all our application upgrades installed silently in the background one week after release (or whatever point the app can be reasonably declared “stable”). Have a user preference setting to opt out of the upgrades for people that need to have a static operating environment, and allow early adopters to upgrade instantly for every new release. Otherwise, no notifications, questions, prompting, or anything else. Just update the application when the user quits out of it, or the system finds a quiet time to run the update.

In other words, take software updates from from a 1+ click process to a zero-click process.

Just think of the amount of productive time reclaimed globally, in addition to the reduction in calls to tech support along the lines of “An upgrade dialog box appeared. What do I do? Is it malware or real?”. (And the security advantage of not having users getting fooled by malicious/fake software update dialog boxes)

In addition, there’s a tremendous opportunity for Apple to have a simple, centralized Software Update manager in OS X that developers could use to push their updates through, so you wouldn’t need each application to individually check for updates through their own solution.

Let’s look at a few of the painful software update “user experiences” that we have today in OS X and iPhone:

1.) Apple Software Update: A multi-step process, complete with admin password requests, system restarts, and multiple update “scans”.

2.) iPhone App Updates: A two-click process involving entering my iTunes password (and why am I entering my password to download free software?)

3.) WordPress updates, both for the CMS system itself and its many plugins.

4.) Firefox’s update process, both for the application and keeping its many extensions current. (I appreciate Mike Morgan’s drive to simplify the update process in Firefox)

5.) Adobe Flash’s update process, which on OS X with Chrome still involves mounting a disk image and running an installer app. For EVERY release.

While a software update process that silently updates your computer’s software in the background has its own potential issues, I’d posit that it beats all of the experiences listed above. (With the caveat that iPhone firmware updates and similar major changes should get user approval before they occur.)

It seems like Google has already taken this lesson to heart with their Chrome web browser. Their concept of “channels” for stable versus beta releases, and their automatic update system within the browser, has that “just works” feeling which is the hallmark of a great user experience.

For the rest of the apps out there, I’d love to use a stopwatch to time exactly how many minutes of my time in a month is spent on the feeling of false productivity that comes with your software updates. If you multiply that time by the number of members of a user community, say OS X and iPhone users in the US, and you’d see some serious potential time gains.

279No Comments.http%3A%2F%2Fwww.downtempo.net%2Fblog%2Fdevelopment%2Fsoftware-updates-a-waste-of-our-time%2FSoftware+Updates%3A+A+Waste+of+Our+Time%3F2010-09-30+18%3A16%3A59Andy+Volkhttp%3A%2F%2Fwww.downtempo.net%2Fblog%2F%3Fp%3D279

I’ve been happily using MacPorts for many years here at Downtempo for our package management system on our OS X development machines. It’s easy, the defacto standard when I moved to OS X several years ago, and reminds me of the FreeBSD ports tree enough that using it was already second nature from my FreeBSD admin days.

However, I’d been hearing an increasing amount of comments about the ease of use of the brew package management system (including this ebullient article from Engine Yard), so I decided to try out brew instead of MacPorts on a new OS X machine I was setting up.

Bam. It took all of 5 minutes before I was completely sold on it, and about a day before I started converting my other machines over to brew instead of MacPorts as well. Besides the slightly quirky setup process with permissions (although it looks like their latest installation instructions have resolved this), it was ridiculously fast, took up far less space than the MacPorts tree, and gave me all the packages I needed to get things done.

If you’re on OS X and haven’t tried brew yet, check it out. MacPorts, it’s been a wonderful 3-year affair, but I’ve switched my loyalty over to brew.

346No Comments.http%3A%2F%2Fwww.downtempo.net%2Fblog%2Fdevelopment%2Fmoving-from-macports-to-brew-for-os-x-packages%2FMoving+from+MacPorts+to+Brew+for+OS+X+packages2010-09-28+07%3A54%3A01Andy+Volkhttp%3A%2F%2Fwww.downtempo.net%2Fblog%2F%3Fp%3D346