The Devver Blog

A Boulder startup improving the way developers work.

Archive for August 2008

My Day Project: IMShoes

Inspired by two posts _Why’s ‘so create’ and GitHub’s Start a Side Project I decided that I needed to do a quick side project. After our demo day we were taking the weekend easy and I had some extra time on Sunday. I decided that I should find a really quick project something I could really just do in one day. Since I was partly inspired by _why, I decided to take some time to learn Shoes.

“Shoes is a very informal graphics and windowing toolkit. It’s for making regular old apps that run on Windows, Mac OS X and Linux. It’s a blend of my favorite things from the Web, some Ruby style, and a sprinkling of cross-platform widgets.”

I tried to think of a simple Shoes app that I could contribute to The Shoebox (a collection of Ruby Shoes apps). I saw a couple Shoe’s Twitter apps, but didn’t see any Shoes AIM apps. Since I knew a good AIM protocol library for Ruby existed (Net-Toc), I thought it would be a nice simple app.

I ran into a few problems with Shoes (getting it to work with Gems) and it seemed to have problems loading YAML files. Besides the mentioned problems it was a breeze to work with. I looked at a few different example apps from the Shoebox. I ended up using Gentle Reminder as a template of sorts for my app. So basically in couple hours on Sunday I read a bunch about Shoes, read the source code of a couple Shoes apps, and I created a very small but functional GUI for AIM. It was a great little side project that reminded me how much fun it can be to code little things once in awhile.

If you have a day off go try to write some code and contribute to one of your favorite projects. Or finally go learn a new library or framework that looks really cool and try to give something back to that community. Then write up a post and share your experience with others. The best way to learn is to go do something, quoting _why, “so create.”

So I proudly present my tiny day project IMShoes.

# A small gui for basic AIM messaging

# Author::    Dan Mayer (mailto:dan<@t>
# Site::
# Copyright:: Copyright (c) 2008 Dan Mayer
# License::   revised BSD license
# (
# Version::   0.0.1 (AKA a "alpha it sucks" version)
# Thanks::
# Ian Henderson for creating TOC, _why for Shoes, and
# Oliver for Gentle Reminder which I used to learn (as my template).

#You need to install net-toc with gem install net-toc
#then copy toc.rb into shoes/contents/ruby/lib/net for this to work in shoes
require 'net/toc' :title => "Shoes AIM",
  :width => 370, :height => 560, :resizable => false do

  #ADD your own user and password here, should allow you to do this via GUI
  @user = 'urUser'
  @password = 'urPass'

  background green, :height => 40

  caption "IM Shoes", :margin => 8, :stroke => white

  stack :margin => 10, :margin_top => 10 do
    para "Buddies", :stroke => red, :fill => yellow

    stack :margin_left => 5, :width => 1.0, :height => 200 do
      background white
      border white, :strokewidth => 3
      @gui_buddies = para

     flow :margin_top => 10 do
       para "To"
       @send_to = edit_line(:margin_left => 10, :width => 180)

     flow :margin_top => 10 do
       para "Message"
       @add = edit_line(:margin_left => 10, :width => 180)
       button("Send", :margin_left => 5)  do
         send_msg(@send_to.text, @add.text);
         @send_to.text = '';
         @add.text = '';

  stack :margin_top => 10 do
    background darkgray
    para strong('Messages'), :stroke => white

  @gui_messages = stack :width => 1.0, :height => 207

  def refresh_buddies
     @buddies = []
     @client.buddy_list.each_group { |g, b| @buddies = @buddies + b }

     @gui_buddies.replace *(
                { |buddy|
                           [ buddy.screen_name, '  ' ] +
                           [ link('Message') { set_to buddy.screen_name } ] +
                           [ '  ' ] + [ "\n" ]

  def refresh

  def refresh_msgs

    @gui_messages.append do
      background white

      @messages.keys.sort.reverse.each { |day|
        stack do
          background lightgrey
          para strong(day.strftime('%B %d, %Y')), :stroke => white

        stack do
          inscription *(
                         [" "]+
                         [" "]+
                         [link('Reply') { set_to(@messages[day][0].to_s) }]).flatten



  def set_to(screen_name)
    @send_to.text = screen_name;


  def send_msg(to_name, msg)
    msg = msg.strip
    to_name = to_name.strip

    return if msg == ''
    return if to_name == ''

    to_buddy = @client.buddy_list.buddy_named(to_name )

    if to_buddy.available?


  def load
    @client =, @password)
    sleep 3
    @messages = {}

    @buddies = []
    @client.buddy_list.each_group { |g, b| @buddies = @buddies + b }

    @client.on_im() do |message, buddy, auto_response|
      @messages[]=[buddy.screen_name, message.gsub(/<\/?[^>]*>/, "")]
      #buddy.send_im("#{message} responce")




IM Shoes Screenshot

Written by DanM

August 29, 2008 at 6:29 pm

Posted in Development, Hacking, Ruby

Yeah, that’s my cofounder

Behold my favorite picture of this awesome TechStars summer

Dan\'s backflip

Considering you can clearly see the Devver logo on Dan’s shirt, I think this needs to be in all our future marketing material. Nothing says “developers love Devver” like a developer doing a backflip in excitement. Awesome stuff.

Written by Ben

August 28, 2008 at 8:59 am

Posted in Devver, TechStars

TechStars Completed

TechStars has been an amazing group to be a part of. We have frequently been asked about the program and “what is the best part of the TechStars program?” It is really hard to break it down to any single point, but all the benefits come back to being all about the people.

We have received a ton of help from everyone in the program. We want to thank all of the mentors and sponsors involved with the program. TechStars really brings an amazing group of people together. We of course want to thank the original founders of TechStars – you have helped to build a really unique and engaged tech community in Boulder.

We want to give mad props to all of the other TechStars 08 teams. Some of the best advice we got came from the other teams. So thanks goes out to Occipital, Gyminee, App-X, TravelFli, Ignighter, People’s Software Company, Foodzie, BuyPlayWin, and of course The Highway Girl.

We also got some great advice and feedback from some of last year’s teams. Thank you to Ari from Filtrbox, Rob and Josh from EventVue, and the entire team with Socialthing!.

Last, but not least, we wanted to give a final thanks to some of the mentors that we spent additional time with. We really appreciate the advice, feedback, and laughs… thanks to David Cohen, Tom Higley, and Seth Levine.

Congrats to everyone for making TechStars such an amazing ride. We know that even though the program is over we will still be getting advice from many of you and still be working with the kind of determination that TechStars helps foster.

Written by DanM

August 22, 2008 at 4:56 pm

Posted in Devver, TechStars

Looking for your first CS job? Be sure to own your ideas

During my search for my first “real” computer science job during my senior year of college, I compared a lot of factors for various jobs including city, company, project, salary, and benefits. The salary stuff was fun to think about (especially after four years of being a poor college student) and I was looking to move to a bigger city somewhere outside of the Midwest (after growing up and going to college there). But mostly I thought about the company and project. Which companies would I want to work for? What project would interest me the most? Where would I learn the coolest stuff?

In hindsight, I realize I’d overlooked the single most important question – is this company going to own my ideas?

I never even thought to ask my prospective employers about their policies on IP and moonlighting. It wasn’t until I’d accepted an offer and received their legal documents that it dawned on me. And even then, I didn’t mind. I thought it was just standard practice and I really didn’t have much of choice*.

For those of you that don’t know, many large software companies technically own everything you think of while you’re working for them. No, not just the stuff that you do at work. They also own the stuff that you do at home, after hours. There is no clean separation of “work” and “personal” projects.

This manifests itself in a few ways. First of all, you may notice that the company explicitly bans working on open-source projects. Or they may require you get explicit permission for “moonlighting” i.e. working on non-work-related projects after hours.

At the very least, you should ask any potential employer about their IP policy before you accept a job. You may be able to get them to loosen their restrictions, especially if they really want you (I haven’t personally done this and I’m not sure if the bigger companies would go for it, but it’s worth a shot).

In fact, I’d argue that you should not accept any job that claims ownership over your outside-of-work ideas – even if that means compromising salary, benefits, project, company, or location. The benefits of owning your ideas are just too numerous and important.

Side projects make you a better programmer. I don’t care if you’re contributing to open-source projects, building a for-profit website, or just toying with a personal project in your own time, writing code that doesn’t relate to work will expand your skills and make you a better programmer at work.

Side projects help your career. Working on projects that anyone can examine are much more valuable than a good resume or recommendation.

As Paul Graham writes in Hackers and Painters:

It seems surprising to me that any employer would be reluctant to let hackers work on open-source projects. At Viaweb, we would have been reluctant to hire anyone who didn’t. When we interviewed programmers, the main thing we cared about was what kind of software they wrote in their spare time. You can’t do anything really well unless you love it, and if you love to hack you’ll inevitably be working on projects of your own.

Your side projects won’t just help you during your next active job search. They form a sort of passive job search in which you’re letting the outside world know how awesome you are. If a better offer comes along, great. Even if you’re happy where you are, you can use external offers as leverage with your current employer (and not just for salary, either. A higher profile outside the company may convince your boss to give you more responsibility at work, publish whitepapers, or attend more conferences).

You can start your own company. If you own your own ideas, then when that little site you built in a weekend starts getting a bajillion visitors a day – you’re free to pursue it. Hello, no boss/early retirement**.

Even if you quit and your startup fails, your career will probably be better off anyway. In Hiring is Obsolete, Paul Graham writes:

Even if your startup does tank, you won’t harm your prospects with employers. To make sure I asked some friends who work for big companies. I asked managers at Yahoo, Google, Amazon, Cisco and Microsoft how they’d feel about two candidates, both 24, with equal ability, one who’d tried to start a startup that tanked, and another who’d spent the two years since college working as a developer at a big company. Every one responded that they’d prefer the guy who’d tried to start his own company.

If you’re trying to rationalize taking that more restrictive job anyway (I mean, they’ve give you free soda at work!), you might be thinking:

“I don’t want to do a startup anyway.” Well, OK. But are you sure you’ll feel the same way in a year? In any case, working on side projects is good for your career, even if you never do a startup.

“No one will know.” Maybe you’re thinking that when you have that good idea for a startup, you’ll just keep it in your head until you quit. There’s a couple of problems with that.  First, you won’t really understand your idea until you start working on it. Secondly, some of the best startup ideas come from projects that didn’t initially have any commercial value (and therefore wouldn’t appear to be worth quitting to pursue)

“They won’t be able to enforce it.” You mileage may vary by state (I’m no lawyer, but I vaguely understand the California courts may be ruling against companies in these kinds of disputes), but it probably won’t matter anyway. Since you don’t want to spend time tied up in court, just the threat that your company could come after you will prevent you from working on most ideas. And even if you have a great idea and decide to go for it – do you really think future business partners and investors will want to hear that your old company might own the core IP of your company?

“My new employer lets me list the IP I own before I joined the company, so what’s the big deal?” The big deal is that you’re almost certainly going to think of new (and likely better) ideas during the time you’re employed at the company. Do you really think all your future ideas will fall into the narrow set of things you’ve thought of before you join? Doubtful.

If you feel you like have to take the job (or you’ve already done so), make sure to get permission in writing before starting to work on your new idea. But of course, just the hassle of getting permission is a strong disincentive to not work on your idea at all.

“All CS jobs are going to require me to sign away my IP” On the contrary, many jobs will let you keep your IP – especially if you are doing programming for a company that doesn’t consider delivering software to be it’s core business. Clearly some jobs let you do other stuff – or no one would be contributing to open source. For instance, Matt Mullenweg got to hack on WordPress while he was working on blogs and new media for CNET (in fact, working on WordPress was part of his job, which is extra cool but probably harder to accomplish).

In order to own your ideas, you may have to sacrifice other aspects of your job (not work at a “brand name” company, work on more mundane projects at work***, make less money), but I’d argue that it’s worth it, especially at the beginning of your career. It’s just too limiting to give away that much of your potential – because you never know where the next idea will take you.

*I ended up accepting the job at Microsoft. For the record, I really loved parts of the job (but also wish I could have worked on open source). I hear they have relaxed their policies since I left, which is definitely a good thing.

** For the record, I am not advocating taking ideas from work (the stuff you are being paid to work on) and starting a company based on that (or, for that matter, putting those ideas into open-source code). That’s illegal and immoral. I’m referring to the case where you’re working on X at work – but you want to keep your options open to do a startup that does Y.

*** Being less satisfied at work might actually be a good thing if you are interested in eventually doing a startup, since it will increase the chance that you’ll work on something really cool in your free time.

Written by Ben

August 19, 2008 at 1:48 pm

Posted in Misc

New Devver Blog Design

We finally have our new blog theme up! Thanks goes to Andrew Hyde for the amazing design and to Ryan Imel for the WordPress theme. We think the new theme helps complete our look, and provides a seamless transition from our Devver homepage. Let us know your thoughts.

Written by DanM

August 17, 2008 at 8:59 am

Posted in Devver

Leaving NetBeans for Emacs as my Ruby Editor

When I first started working with Ruby I used RadRails (which still has the best integrated test runner I have used). Various problems and crashes with RadRails along with exciting features being added to Ruby NetBeans enticed me to switch. I enjoyed NetBeans and some of its features, but the weight of my IDE began slowing me down. I didn’t have the control to tell it not to do some things that annoyed me.

My cofounder Ben had been using Emacs since learning Ruby. The quick speed that he could work with code, made me wonder what features I was actually using in my bloated IDE. It turned out that I had been getting annoyed with most of the advanced features because they stalled my system, crashed occasionally, or really weren’t that useful. An example of a cool feature that I hardly found useful would be Netbean’s Ruby code completion. In the past I had used Emacs to develop all my C and C++ code and I always liked it, so I decided to switch away from NetBeans and see how Emacs would hold up as my editor.

I have enjoyed using Emacs and think that I can more quickly work with code with far less hassle and frustration. I don’t expect to move back to a large IDE anytime soon. That being said there are definitely pros and cons to working with a full IDE vs an editor, and I find myself missing features sometimes. So I thought I would list out some of the pros and cons so others can weigh these issues themselves.

Reasons I miss NetBeans:

  • Graphical test integration linking to the lines of code in the stack trace
  • Navigate -> ‘Go to Declaration’, ‘Go to Test’, ‘Go to Action or View’
  • Easy code refactoring and renaming
  • Code completion, occasionally (e.g. was the Array function called include? or includes?)
  • File browsing with folder tree view
  • Graphical SVN browsing, easy branch, merge, get version, diff
  • Easy project file search (Yes, you can do, ‘grep -Ri ‘Logger’ lib/* bin/* app/* | grep -v .svn’, but that is a pain to type)
  • Easy code commenting (Apple-/ which toggles, is much nicer than Ctrl-x, Ctrl-m comment-region / uncomment-region which has to be added to your Emacs configuration)
  • Easy code formatting (Apple-shift-f, is easier than Ctrl-x, Ctrl-m indent-buffer / indent-region)

Reasons I hate NetBeans:

  • Frequently stalls (Especially if you have been out of the application for awhile)
  • Crashes (At least every couple days)
  • Not enough user control (stop indexing everything)
  • Magic behind the scenes (constantly connecting to SVN every time I saved a file)
  • Debugger didn’t work well (ended up running on the command line to get debugging)
  • Ruby Console didn’t work well (ended up using irb on the command line instead)
  • All tasks that NetBeans handles nicely for you like testing or migrations were slower (ended up running all rake task and tests on the command line)
  • Resource hog, making everything else I am running far slower
  • NetBeans ignores canceling tasks and continues trying to run them
  • Booting up takes a few minute before NetBeans completes its various start-up tasks (You can work during some of the start-up tasks, but it is slow and unresponsive until it has completed the tasks)

Things I like about Emacs:

  • Better/more key commands (I love kill/yank – the ability to kill until the end of line is incredibly useful)
  • Incredibly fast, if I am working live with someone I can jump in make an edit and be back live showing them the change on the project (Imagine having to boot NetBeans to do this)
  • Multiple copy and paste buffers. This is something you get with GNU Emacs on an X system. I can use both kill/yank from Emacs while also using my normal copy and paste to maintain two independent copy and paste buffers, very handy
  • Complete control over the editor, no longer do I have to deal with auto closing brackets or any other ‘helpful’ defaults the editor includes (You can turn them all off, but I get annoyed having to go change a bunch of settings)
  • An unexplainable feeling of being closer to the system and the code.

Written by DanM

August 8, 2008 at 3:27 pm

Posted in Development, Hacking, Misc, Ruby

Miško Hevery on Writing Testable Code

Miško Hevery has written up a nice collection of tips on writing testable code on his blog. Some of the tips are a bit hard to understand and apply, but it sounds like he will be going into many of them in more detail in the weeks to come (or you can use this list as a starting point and search for more details on individual tips).

While I don’t agree that there are no tricks to writing good tests, I whole-heartedly agree that a huge part of testing is making your application code testable. This is one of the biggest reasons that unit testing has a low ROI when you start (but that ROI increases as you learn to write testable code).

Written by Ben

August 7, 2008 at 9:04 am

Posted in Testing

New site!

Thanks to talents of the one and only Andrew Hyde, now looks awesome. The text I supplied is far from perfect and we still need to integrate the blog, but it’s a huge improvement. Thanks Andrew – you rule.

Written by Ben

August 4, 2008 at 10:23 pm

Posted in Devver

Jason Fried (of 37signals) on building great companies and products

Last Thursday, we had the opportunity to hear a talk from Jason Fried, CEO of 37signals. I had already read some of the 37signals philosophy in Getting Real (although it’s about time for a re-read), but the talk was still totally fascinating. Although in many ways they are similar to the Web 2.0 startups (they emphasize releasing early, focusing on the customer, and avoid detailed long-term planning), in other ways they are totally different (notably, they don’t work an insane number of hours a week).

Jason repeatedly said that their process was not the only way to successfully run a company – just the way that works really well for them. While I don’t think every piece of advice will be useful for every startup, I’m betting that everyone can learn at least a few very useful things from Jason. I know it got my mind spinning about ways we could improve how we work at Devver.

Without further ado, here are some nuggets of wisdom from Jason, split roughly into two categories: Running a Company and Building a Product.

Running a Company

Focus on things that don’t change

  • first-mover advantage is overrated
  • the leaders today sat back, watched, and did it better
  • invest in the things that won’t change (example: in ten years, people will still like simple software, so focus on simplicity)
  • don’t try to chase the next big thing

Don’t plan

  • 37signals just wants to build a great products that people love
  • they don’t have a five year plan
  • they know they want to be profitable, but they don’t have a plan to get X users by Y date

Use ‘less’ to your advantage

  • use your constraints to focus your attention on the most important things you can possibly do instead of everything you can possibly do
  • less money is an advantage (you have to be creative to get the word out, which is more effective)
  • less time is an advantage (focus on important stuff)
  • fewer people is a good thing (less coordination necessary)

Work less

  • 37signals don’t work on Fridays
  • now Monday-Thursday people work extra hard, they waste less time
  • they don’t make them cram in more hours (around 8 hours a day, four days a week)
  • the output has been better, they are more refreshed
  • great for employee retention
  • they pay for employees to pursue hobbies outside of work
  • if they pay for hobbies, the person has to teach everyone else the stuff they are learning

Share knowledge

  • they don’t spend money on advertising
  • the most famous chefs are famous because they teach others
  • out-teach, out-share, out-contribute your competitors
  • don’t be afraid of competition stealing your ideas
  • if you teach, you have people’s mind even if you don’t have them as a customer
  • amass an audience, then you can sell them something

Avoid interruption

  • it’s the biggest enemy of productivity
  • look to minimize interruption
  • they don’t talk to each other
  • at 37signals, everyone usually works from home
  • there might be 4 months where they don’t see each other, but they collaborate passively via Campfire
  • there is no such thing as a rock star developer, only rock star environments (those that make developers productive)

Don’t hold meetings

  • no meetings at 37signals
  • they are a huge waste of time
  • they last too long
  • information per minute is really small
  • think about the total cost (10 people attending a one-hour meeting == 10 hours of lost productivity)

Be transparent

  • if you make a mistake, come out immediately, admit it, move on
  • don’t try to hide mistakes
  • be part of the conversation about you screwing up (because the conversation is happening anyway)
  • the more you admit you are wrong, the more people like you

Avoid these words: “Need”, “can’t” and “easy”

  • these are the words that cause things to be late, to be difficult, to be contentious
  • people use the word “easy'” to describe other people’s work (e.g. “That feature should be easy to implement, so let’s have it by tomorrow”)
  • you don’t need most things you say you “need”
  • “can’t” is also unnecessarily strong

Don’t scar on the first cut

  • don’t institute a policy every time one little thing go wrong
  • if problems arise, deal with problem on individual basis
  • treat people with respect, not rules
  • small companies should not try to be big companies (big companies are wishing they could be like small companies)
  • if employees know you trust them, they won’t abuse that trust
  • example: everyone at 37signals has a company credit card they can use for anything they want (not necessarily work related)

Don’t only hire on specific skills

  • curiosity is the most important trait. Curious people want to learn new things and appreciate other people’s work
  • if you want to know how curious someone is, just ask them the last (non-work related) thing they learned
  • always hire good writers, that’s more important than specific skills

Pick your clients carefully [this was targeted at service companies]

  • you can choose the work you do
  • find the right kind of clients
  • you don’t need every customer
  • you can’t make everyone happy
  • if you take on everything you can at first, you’ll never stop, and after 10 years all your projects will suck

Let customers pay right away

  • don’t pester users to get them to upgrade
  • most of their paying customers started w/ paid version (as opposed to using the free version for awhile and then upgrading)
  • ask people for money right away if you want it from them

Don’t worry about the competition

  • they will change
  • you can’t control them

Building a Product

Don’t plan

  • it’s vastly overrated
  • just build the thing
  • don’t let planning scare you into not doing something
  • spend 95% of the time on the real thing
  • you always know more about the project after you’ve started working on it

Eliminate abstractions

  • diagrams, wireframes, proposals aren’t real
  • just work w/ the real thing
  • fake things create an illusion of agreement (if you think you are all agreeing to the proposal, you aren’t. Everyone interprets it differently)
  • get rid of documents, artifacts – anything that you file in the cabinet after you complete them
  • don’t represent the thing you are building, just build it

Error on the side of simple

  • every mistake they have made is because they tried to do too much
  • do the simplest possible thing for any problem
  • get it out, let people try it out, then iterate
  • always do the easier/faster/simpler thing

Don’t focus on details early on

  • it’s a waste of time
  • the things that are done early will probably be redone anyway
  • polish is important, just do it later

Solve atomic problems/make tiny decisions

  • people try to solve problems that are too big
  • break down big problems down to the atomic level
  • you can easily solve small problems (and if you do it wrong, you can go fix it easily)
  • if you solve a big problem incorrectly, you won’t go back to fix it, because you invested so much in it
  • 37signals doesn’t work on anything more than a week
  • they often just solve a quarter of a bug
  • morale is killed by people working on big problems that never get solved

Give up on hard problems

  • they aren’t worth solving
  • let your competition solve hard problems
  • there are so many easy problems that need really good solutions
  • take a step back, figure out what the core problem is
  • take a few days off, look at it again, there may be a simple problem instead

Say “No” much more than “Yes”

  • say no to everything (to customers requests, to features you yourself want)
  • you think you need to give everyone everything they want, but you don’t
  • make a feature/request really fight to be in the product
  • as a product designer, you are the curator, you are the editor, you have to say no
  • once you start hiding stuff in your product, it’s too complicated (if users have to turn stuff off, that’s a bad sign)
  • it’s really hard to take away features from people (even if they are bad)

Be careful when adding features

  • they read every feature request, then throw them away
  • they used to keep a huge list, but no one looked at it because it was too long
  • now they just notice the stuff that gets asked over and over
  • look out for the “bananas in the lasagna” (even if everyone asks for something, if it doesn’t fit w/ the product, don’t add it)
  • think very deeply about requests, even simple features have a lot of implications
  • customers talk in solutions, you need to look for problems and solve those
  • improve things for the majority, not the vocal minority (vocal minority can destroy a product)

Eliminate product management

  • if you have a product manager, the product is too big and complicated
  • the builders should be able to manage the product

Written by Ben

August 4, 2008 at 8:13 am

Posted in Misc