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