After just a few short week, we have gotten fed up with the limitations of having our blog hosted by wordpress.com and decided to host our own. Our new blog is at http://devver.net/blog. Please update your reader and sorry for the inconvenience.

This is part two of my TechStars Days series of posts.

Amazon Day

Mike Culver (Amazon AWS)

Mike did a great job presenting all of the various AWS offerings. The TechStars teams asked a ton of questions. It seemed after the presentation at least 4 of the teams were thinking about using some part of AWS. We found this whole session interesting as we had just made the decision to build Devver on top of some of the AWS offerings. Devver is currently working with EC2 and SQS, but we are strongly considering Amazon’s SimpleDB as well. Most of the topics our group discussed about AWS are publicly available. It was still worth hearing a talk and seeing demos which explore the possibilities as it helped sell us on the AWS solution.

Josh Hug (Shelfari)

Amazon Day continued with Shelfari, which Amazon ended up investing in. Josh gave a candid talk about the growth of his startup. Josh had a different beginning than the average startup. He wanted to start a company, but didn’t know what he should work on. He started looking at industry trends he could take advantage of, which eventually led him to Shelfari. He shared many tips about the early stages of a startup. Since my notes were just a list of bullet points I will share a few of the best.

• Focus on getting first version done
• Early focus in a startup has the largest impact
• Use A/B testing to really see what your users prefer
• Outsource a payroll service
• Do your own bookkeeping and have it checked once a month
• Actively engage in your own PR
• Keep initial costs really low
• A final great quote, “The grass is always greener on the other side of the technology fence.”

The first couple weeks, of TechStars has been flying by in a blur. The first weeks were filled with many meetings, introductions, contacts, and informal group meet-ups. I am pretty sure during the first two weeks each team gave their elevator pitch 45+ times, giving us all chances to refine our pitches. During these first weeks besides the regular meetings, there were some full meeting days, which I call “TechStars Days”.

The thought behind our initial meeting-packed schedule is that TS front loads many of the longer meetings at the beginning of the program. This allows us to try to absorb as much of the advice as possible before we get moving. If we came in the program and immediately started going as fast as possible we might find that we were running the wrong direction. Devver has slightly shifted the way we think of our business, and I think we are better off for it. At the heart of these full days there were four large, themed days: Google Day, Amazon Day, Microsoft Day, and Yahoo Day. We just finished the last of our so-called themed days, and I have far too many thoughts and notes to even try to turn them all into blog posts. So I will just try to cover some key points and notes from my experience.

Over the next four days I will post all of my TechStars Days thoughts, starting with Google Day below.

Google Day

Kevin Marks (OpenSocial)

Kevin talked about the “Social Cloud”, as he put it. The idea is that we don’t have to build new social networks and have our social graph data trapped inside any particular website (i.e. Facebook). We can use the existing web infrastructure of linking to establish our social circles. Using XFN (which apparently Kevin prefers) or FOAF you can link to websites and express your relationship to those sites. I could for example link from my blog to my girlfriend’s blog and use XFN to express that she is my girlfriend. As this metadata grows on the web, Google does what it does best, and crawls all this information and allows people to search and query against the data via an API (Google’s Social Graph API). Now the next time you sign up for a new service like Twitter, instead of finding all your friends again, it can query my social graph and recommend contacts that I have already expressed on the web. This is also far safer and better than many services asking for my Gmail password to find my contacts. The open social graph is a very cool and big idea, but it will really require a large adoption of XFN by many and preferably highly social sites.

Kevin also talked about Google providing a solution to the Gmail password problem. Google has a Contacts API which will get all of your contacts information from Gmail without you having to give a third party system their password. The contact API initially is entirely separate from the social API, but I am sure you can see the likely overlap.

Lastly Kevin got into Open Social, the large social initiative Google has been pushing to allow developers to write a single social app that should play nicely in any Open Social container. So a site like LinkedIn would run an Open Social container and apps that were developed for Open Social could run on this container and access my LinkedIn social graph so the app could use those relationships. The same social app could run on other Open Social containers as well like MySpace, iGoogle, or BeBo. Open Social sounds really promising to me if I was working in the social or viral space.

Kevin had interesting thoughts on viral growth and organic growth, the second of which he believes is the correct way to try to spread through a network. He also discussed limitations that social growth can run into, for example language or cultural barriers. He didn’t get into this topic as deep as he could have, but recommended that if we were interested, we should really read Danah Boyd, who has been working in the social space for a long time.

Dion Almaer (App Engine, Google Gears)

Google Gears isn’t just providing offline experiences, it is improving the speed and performance of websites. It also offers a unique way to offload work from the server to the client side. An interesting example of this is MySpace providing message searching to users via Google Gears. Utilizing SQLite DB, local caching, and local thread pools allows developers to perform many operations client side better and simpler than server side. Google Gears also allows full icon links, growl for the web, multiple file upload without flash, and a variety of other cool things.

Dion also talked briefly about Google’s location API which sounded pretty cool, being able to identify the users location based on Wi-Fi hotspots, cell towers, GPS, and a variety of other sources. Besides giving a location it will give accuracy ratings. I don’t know how much of this is live now, but it could be very useful if you are working in the location-based services.

Dion of course talked about Google App Engine last, which I really enjoyed hearing about, but pretty much everything we heard is publicly available. It seems to have some really nice benefits over Amazon like being free for up to 5 million page views, having a stronger DB offering, and seemingly better support. It also has some huge limitations which seemed to make most people, myself included, feel it isn’t ready for many real applications. If you want to build a sweet Python web app or Django-powered site, get on App Engine, but if you need any back end control App Engine just isn’t the way to go yet. It was great to hear this as we are currently very interested in cloud computing. Dion wasn’t allowed to discuss upcoming features or the widely discussed rumors of other languages and MapReduce support, admitting only that some big things are in the works.

Rick Klau, Dick Costolo (FeedBurner)

As part of Google Day, we got to hear from a company that was acquired by Google. My cofounder did a great post about the talk, FeedBurner get all the feeds, so I will leave that to him.

On Tuesday, we had Mike Culver from Amazon give a great talk about Amazon’s web services. We had pretty much decided on using AWS for Devver, but Mike’s talk convinced us even more.

So for the past few days we’ve been porting our code to work with EC2 . We’ve also been building scripts that will configure the machine instances on boot.

When you’re using EC2, you can store custom machine images, but you really don’t really want to be saving a new image for every tweak you make to the machine. It’s a lot more flexible to just save a basic image and give the instance a script to run when it boots, like this:

ec2-run-instances [some-image-name] -f config.rb

In this example, I’m passing a Ruby script, but you can pass any type of file at all.

I found a couple of great tutorials, but unfortunately they didn’t do quite what I wanted, so I hacked up my own solution. It’s just a few lines in the /etc/rc.local file (which runs after the machine boots) that grabs the config.rb file and runs it.

Unfortunately, for some reason, my Ruby script was not getting run. After a painfully long debugging session, I figured out that the environment had not been configured for RubyGems when my script was run, so my ‘require’ statements were breaking the code. The key lesson is that no matter what language you’re using, /etc/rc.local is running in a different environment than a logged-in user, so environment variables like PATH (and in this case, RUBY_OPT) will not be set up the same way.

Anyway, here’s the code I added to my /etc/rc.local file:

# AMI configuration code, based on code from
#http://developer.amazonwebservices.com/connect/entry.jspa?externalID=1085&categoryID=100 

# grab the file from Amazon's web service. Yes, this IP address is always the same
/usr/bin/wget http://169.254.169.254/latest/user-data -O /tmp/payload.rb

# if wget error code is 0, there was no error
if [ $? -eq 0 ]; then
  if [ -e /tmp/payload.rb ]; then
    # DON'T forget the -rubygems option! You need it if you call 'require' in your config code
    /usr/bin/ruby -rubygems /tmp/payload.rb
  else
    echo "rc.local : No payload.rb script to run"
  fi
else
  echo "rc.local : error retrieving user data"
fi

I hope that helps anyone out there starting to play with EC2…

Last night, Dick Costolo and Rick Klau from Feedburner stopped by the TechStars office to give a fascinating (and often hilarious) talk about their experiences -starting with just four guys with a tiny market and no revenue through getting acquired by Google.

There was a lot of great advice in the talk, but I want to touch on two points that really got me thinking.

First, Dick and Rick mentioned that from the beginning, Feedburner understood what Feedburner was about: they were going to provide value by sitting between publishers and their audience. Furthermore, they were going to interact with publishers and be virtually invisible to the audience.

The interesting result of this is that they turned down several lucrative revenue streams because they didn’t fit with their vision. For instance, some companies offered them money to install Feedburner on corporate intranets. Although this would have been a source of revenue at a time when they didn’t have any, they had the confidence to stick with their vision and say “no, that’s not what we do.”

Secondly, they had a core goal/metric they executed on: “get all the feeds”. Notice that this isn’t the same as their business model, slogan, or investor pitch. Rather, it was used internally as a simple goal that got everyone working towards the same thing. Dick was apparently famous for saying stuff like (and I’m paraphrasing here), “Do you have all the feeds? No? OK, then get back out there and get more feeds”. Jim Collins goes into this more (he calls it “The Hedgehog Concept”) in Good to Great.

These points got me thinking: what is our vision for Devver? And what is our our core goal/metric? I’ll save the answers for another post after I’ve had some time to really think about it.

Since we are working on development tools initially focused on Ruby developers, we wanted to get a better picture of what is normal in Ruby development. We thought it would be good to make a short informal survey and collect the results, which we plan to share back with the Ruby community (aggregated and anonymous). We are hoping to learn a little bit more about the average size of a project, testing practices, web frameworks, and development environments.

Feel free to pass the survey link on to other Ruby hackers you know in the community. We would appreciate any additional feedback so feel free to contact us. We hope that what we learn can help us to build some tools that will help make Ruby hackers lives a little bit easier (as if it isn’t already made easy enough by comparison to some languages… ha).

So if you have some time, please take the Devver Ruby Developer Survey. Feel free to take this even if Ruby isn’t your primary language as we hope to be able to bring our tools to other languages in the future.

* Note: this phrase only applies if you’re like us and consider writing code all day “fun”

We’ve survived our first week of TechStars. So far, so good. We’ve had the opportunity to meet tons of great founders and mentors this week. The only problem is that with sessions and meetings every day, we haven’t had as much time as we’d like to actually write code. We wanted to do more Saturday, but got caught up with errands and a friends birthday in Denver. Luckily, we’ve got nothing going on today, so we’re going to crank out a lot of code. So much for that “day of rest” stuff.

One of the first things we’re working on the in the TechStars program is our elevator pitch: both improving the content and the delivery. In the first two days, we’ve been asked to present it to three different mentors and all of the pitches have improved dramatically.

Here’s our latest version (it’s sure to change):

“Devver provides web-based tools that allow developers to easily understand and improve their code. Our tools analyze and recommend changes to code with almost zero setup costs for the developer. For example, using Devver, developers can quickly and easily analyze the performance, complexity, and compatibility of their project, saving them time and money.”