The Devver Blog

A Boulder startup improving the way developers work.

Archive for the ‘Misc’ Category

Playing with Processing, Making Snow

What is Processing?

“Processing is an open source programming language and environment for people who want to program images, animation, and interactions.”

I wanted to play around with doing some visual programming and had played with Processing in the past. I recently had been reading about Ruby-Processing and wanted to give it a shot. First, I went to look for some Ruby-Processing tutorials, and I had recently heard about the presentation by Jeff Casimir about the ‘Art of Code‘ (slides and code), using Ruby-Processing. I went through those examples and decided I wanted to modify it to display snowflakes in the spirit of winter. After a bit of searching I found a project that generated a Penrose snow flake using Ruby-Processing. I figured I could modify the programs to get a nice snow flake screen saver type app. The result is my app Processing-Snow, and is shown in the screen shot below.


Playing around with Ruby-Processing is a lot of fun, I highly recommend spending a couple hours to make a tiny app. I built my Snow app in about an hour and a half. Then I spent a bit of time using Caliper to improve the metrics. For such a small project there wasn’t a lot to improve, but it still helped me to do some refactoring. To get an idea of the code you can view Processing-Snow’s Metrics.

Feel free to fork Processing-Snow on GitHub and read about how to run it with in the projectss README.

Written by DanM

December 23, 2009 at 8:16 pm

Posted in Hacking, Misc, Ruby

Improving Code using Metric_fu

Often, when people see code metrics they think, “that is interesting, I don’t know what to do with it.” I think metrics are great, but when you can really use them to improve your project’s code, that makes them even more valuable. metric_fu provides a bunch of great metric information, which can be very useful. But if you don’t know what parts of it are actionable it’s merely interesting instead of useful.

One thing when looking at code metrics to keep in mind is that a single metric may not be as interesting. If you look at a metric trends over time it might help give you more meaningful information. Showing this trending information is one of our goals with Caliper. Metrics can be your friend watching over the project and like having a second set of eyes on how the code is progressing, alerting you to problem areas before they get out of control. Working with code over time, it can be hard to keep everything in your head (I know I can’t). As the size of the code base increases it can be difficult to keep track of all the places where duplication or complexity is building up in the code. Addressing the problem areas as they are revealed by code metrics can keep them from getting out of hand, making future additions to the code easier.

I want to show how metrics can drive changes and improve the code base by working on a real project. I figured there was no better place to look than pointing metric_fu at our own website source and fixing up some of the most notable problem areas. We have had our backend code under metric_fu for awhile, but hadn’t been following the metrics on our Merb code. This, along with some spiked features that ended up turning into Caliper, led to some areas getting a little out of control.

Flay Score before cleanup

When going through metric_fu the first thing I wanted to start to work on was making the code a bit more DRY. The team and I were starting to notice a bit more duplication in the code than we liked. I brought up the Flay results for code duplication and found that four databases models shared some of the same methods.

Flay highlighted the duplication. Since we are planning on making some changes to how we handle timestamps soon, it seemed like a good place to start cleaning up. Below are the methods that existed in all four models. A third method ‘update_time’ existed in two of the four models.

 def self.pad_num(number, max_digits = 15)
    "%%0%di" % max_digits % number.to_i

  def get_time

Nearly all of our DB tables store time in a way that can be sorted with SimpleDB queries. We wanted to change our time to be stored as UTC in the ISO 8601 format. Before changing to the ISO format, it was easy to pull these methods into a helper module and include it in all the database models.

module TimeHelper

  module ClassMethods
    def pad_num(number, max_digits = 15)
      "%%0%di" % max_digits % number.to_i

  def get_time

  def update_time
    self.time = self.class.pad_num(


Besides reducing the duplication across the DB models, it also made it much easier to include another time method update_time, which was in two of the DB models. This consolidated all the DB time logic into one file, so changing the time format to UTC ISO 8601 will be a snap. While this is a trivial example of a obvious refactoring it is easy to see how helper methods can often end up duplicated across classes. Flay can come in really handy at pointing out duplication that over time that can occur.

Flog gives a score showing how complex the measured code is. The higher the score the greater the complexity. The more complex code is the harder it is to read and it likely contains higher defect density. After removing some duplication from the DB models I found our worst database model based on Flog scores was our MetricsData model. It included an incredibly bad high flog score of 149 for a single method.

File Total score Methods Average score Highest score
/lib/sdb/metrics_data.rb 327 12 27 149

The method in question was extract_data_from_yaml, and after a little refactoring it was easy to make extract_data_from_yaml drop from a score of 149 to a series of smaller methods with the largest score being extract_flog_data! (33.6). The method was doing too much work and was frequently being changed. The method was extracting the data from 6 different metric tools and creating summary of the data.

The method went from a sprawling 42 lines of code to a cleaner and smaller method of 10 lines and a collection of helper methods that look something like the below code:

  def self.extract_data_from_yaml(yml_metrics_data)
    metrics_data = {|hash, key| hash[key] = {}}
    extract_flog_data!(metrics_data, yml_metrics_data)
    extract_flay_data!(metrics_data, yml_metrics_data)
    extract_reek_data!(metrics_data, yml_metrics_data)
    extract_roodi_data!(metrics_data, yml_metrics_data)
    extract_saikuro_data!(metrics_data, yml_metrics_data)
    extract_churn_data!(metrics_data, yml_metrics_data)

  def self.extract_flog_data!(metrics_data, yml_metrics_data)
    metrics_data[:flog][:description] = 'measures code complexity'
    metrics_data[:flog]["average method score"] = Devver::Maybe(yml_metrics_data)[:flog][:average].value(N_A)
    metrics_data[:flog]["total score"]   = Devver::Maybe(yml_metrics_data)[:flog][:total].value(N_A)
    metrics_data[:flog]["worst file"] = Devver::Maybe(yml_metrics_data)[:flog][:pages].first[:path].fmap {|x|}.value(N_A)

Churn gives you an idea of files that might be in need of a refactoring. Often if a file is changing a lot it means that the code is doing too much, and would be more stable and reliable if broken up into smaller components. Looking through our churn results, it looks like we might need another layout to accommodate some of the different styles on the site. Another thing that jumps out is that both the TestStats and Caliper controller have fairly high churn. The Caliper controller has been growing fairly large as it has been doing double duty for user facing features and admin features, which should be split up. TestStats is admin controller code that also has been growing in size and should be split up into more isolated cases.

churn results

Churn gave me an idea of where might be worth focusing my effort. Diving in to the other metrics made it clear that the Caliper controller needed some attention.

The Flog, Reek, and Roodi Scores for Caliper Controller:

File Total score Methods Average score Highest score
/app/controllers/caliper.rb 214 14 15 42

reek before cleanup

Roodi Report
app/controllers/caliper.rb:34 - Method name "index" has a cyclomatic complexity is 14.  It should be 8 or less.
app/controllers/caliper.rb:38 - Rescue block should not be empty.
app/controllers/caliper.rb:51 - Rescue block should not be empty.
app/controllers/caliper.rb:77 - Rescue block should not be empty.
app/controllers/caliper.rb:113 - Rescue block should not be empty.
app/controllers/caliper.rb:149 - Rescue block should not be empty.
app/controllers/caliper.rb:34 - Method name "index" has 36 lines.  It should have 20 or less.

Found 7 errors.

Roodi and Reek both tell you about design and readability problems in your code. The screenshot of our Reek ‘code smells’ in the Caliper controller should show how it had gotten out of hand. The code smells filled an entire browser page! Roodi similarly had many complaints about the Caliper controller. Flog was also showing the file was getting a bit more complex than it should be. After picking off some of the worst Roodi and Reek complaints and splitting up methods with high Flog scores, the code had become easily readable and understandable at a glance. In fact I nearly cut the Reek complaints in half for the controller.

Reek after cleanup

Refactoring one controller, which had been quickly hacked together and growing out of control, brought it from a dizzying 203 LOC to 138 LOC. The metrics drove me to refactor long methods (52 LOC => 3 methods the largest being 23 LOC), rename unclear variable names (s => stat, p => project), move some helpers methods out of the controller into the helper class where they belong. Yes, all these refactorings and good code designs can be done without metrics, but it can be easy to overlook bad code smells when they start small, metrics can give you an early warning that a section of code is becoming unmanageable and likely prone to higher defect rates. The smaller file was a huge improvement in terms of cyclomatic complexity, LOC, code duplication, and more importantly, readability.

Obviously I think code metrics are cool, and that your projects can be improved by paying attention to them as part of the development lifecycle. I wrote about metric_fu so that anyone can try these metrics out on their projects. I think metric_fu is awesome, and my interest in Ruby tools is part of what drove us to build Caliper, which is really the easiest way try out metrics for your project. Currently, you can think of it as hosted metric_fu, but we are hoping to go even further and make the metrics clearly actionable to users.

In the end, yep, this is a bit of a plug for a product I helped build, but it is really because I think code metrics can be a great tool to help anyone with their development. So submit your repo in and give Caliper hosted Ruby metrics a shot. We are trying to make metrics more actionable and useful for all Ruby developers out, so we would love to here from you with any ideas about how to improve Caliper, please contact us.

Written by DanM

October 27, 2009 at 10:30 pm

Lone Star Ruby Conf 2009 Wrapup Review

I recently went to the Lone Star Ruby Conference (LSRC), in Austin TX. It was great to be able to put faces to many people I had interacted with in the Ruby community via blogs and twitter. I also got to meet Matz and briefly talk with him, which was cool. Meeting someone who created a language which is such a large part of your day to day life is just an interesting experience. I enjoyed LSRC, and just wanted to give a quick summary of some of the talks that I saw and enjoyed. This is by no means full coverage of the event, but hopefully sharing my experience with others is worth something. If you are interested in seeing any of the talks keep an eye out for Confreaks, they taped the event and many of the talks should be coming online soon.

Dave Thomas
Dave was the first speaker for LSRC, and it was a great way to kick off the event. Dave gave a talk about Ruby not being perfect and that is why he likes it. I have heard Dave speak before, and I always enjoy his talks. It isn’t like you learn anything specific about Ruby development, but you learn about the Ruby community. Actually, Dave would say we are a collection of Ruby communities, and that having a collection of communities is a good thing. It was also interesting to hear Dave speak about the entire Zed, “Rails is a Ghetto” incident. Sometimes when you are angrily ranting around online, it is easy to forget that there are real people attached to things. Feelings can get hurt, and while Dave agrees there is some valid points in the post, I think it shows that it probably isn’t a good way to go about fixing them. Dave really loves Ruby and the weird things you can do with the language and it shows.

Glenn Vanderburg, Programming Intuition
Glenn talked about phyical emotions tied to code, such as a sense of touch or smell. The talk generally just evoked memories of Paul Graham’s “Hackers and Painters” in my head, in fact Glenn talked about PG during his talk. The best programmers talk about code as if they can see it. The talk explored ways to feel the code and react to it. It tried to promote the idea that it is OK to just have a gut reaction that some code is a bad way to do things, because we should sense the code. Glenn also played a video showing Bobby McFerrin teaching the audience the Pentatonic scale, which I really enjoyed.

James Edward Gray II, Module Magic
James visited Japan recently and went to a Ruby conference, and he really enjoyed it. About half his talk was why Japan is awesome… He then found little ways to tie this back into his talk about Ruby and Modules. It covered some interesting topics like load order that many people just don’t know enough about, but use every day. Examples of the differences between include and extend. Modules are terrific at limiting scope, limit the scope of scary magic and keep it hidden away. I enjoyed talking with James a good amount through out the conference. I had never met him before LSRC, but I used to practice Ruby working on Ruby Quiz which he ran for a long time.

James has his slides are up, Module Magic

Fernand Galiana, R-House
Fernand gave a really cool and demo heavy talk about home automation. He has a web front end that lets him interact with all his technology. His house tweets most of the events that it runs. The web interface has a iPhone front in, so he can, on the go, change the temperature or turn off lights. I have always been a real home automation geek. When I was growing up, my dad loved playing with an X-10 system that we had in the house. I am really interested in playing with some of this stuff when I have my own place, mostly looking at ways I could use it to cut waste on my energy usage.

Mike Subelsky, Ruby for Startups: Battle Scars and Lessons Learned
* You Ain’t Gonna Need It (YAGNI), don’t worry about being super scaling at the beginning…
* Early days focus on learning more data about what your building and what your customers want concentrate on the first 80% solution.
* Don’t over build, over design, or over engineer.
* Eventually plan to move everything out of your web request, build it so that it will be easy to do in the future, but it isn’t worth doing at first. (delayed job, EM, etc)
* Make careful use of concurrency, prefer processes communicating via messages (SQS etc…) If you are doing threading in your software EM is your friend.
* Avoid touching your RDBMS when you are storing not critical data:
– Storing large text blogs in S3, message across SQS, tons of logging SDB
* Don’t test all the time at the beginning, it gets in the way of exploration… Things that is mission critical maybe should be BDD as it will be the most stable and least likely to change part of your code

Mike posted his slides on his blog, Ruby for Startups.

Jeremy Hinegardner, Playing nice with others. — Tools for mixed language environments

Jeremy wanted to show how easy it is to use some code to make it easy to work with a system that uses multiple languages. He brought up that most projects in the room utilize more than one language. That it will be more common as systems grow in complexity. He looked at a lot of queues, key value stores, and cache-like layers that can be talked to by a variety of language. He then showed some code that would quickly demonstrate how easy it was to work with some of these tools. Extra points because he talked about Beanstalkd, which I personally think is really cool. I think nearly everyone is starting to look at work queues, messaging systems, and non standard databases for their project and this was a good overview of options that are out there.

Yukihiro Matsumoto (Matz), Keynote and Q&A
Matz gave a talk about why we, as a community, love Ruby. In this talk there weren’t really any takeaways that were specifically about Ruby code but more about the community and why Ruby is fun. He spent a good amount of time talking about Quality Without A Name, QWAN. More interesting than the talk was the Q&A session. I thought the most interesting question was why Ruby isn’t on Git yet. He said the teams doesn’t have time to convert all the tools they use from SVN to git. He also mentioned that the git project tracking SVN is very close to the SVN master and is a good way to work on the Ruby code.

Evan Light, TDD: More than just “testing”
Evan first covered that the tools we as a community keep getting excited about aren’t really what matters. What matters is TDD technique. After discussing why tools aren’t as important for awhile, Evan began live coding with the audience. Something I thought was pretty impressive as it would be difficult to do. It made for a weird pair programming exercise with the entire audience trying to drive. Which sometimes worked well and sometimes lead to conflicting ideas / discussion (which made for interesting debate). It was over all a really interesting session, but it is hard to pull out specific tidbits of wisdom from the talk.

Jake Scruggs, What’s the Right Level of Testing?
I have known of Jake for awhile from his work on the excellent Metric Fu gem. Jake explored what the right level of testing for a project is, from his experience on his last nine projects over the years. He explored what worked, what didn’t and what sometimes works but only depending on the people and the project. I think it comes to this conclusion: what works for one project won’t work for all projects. Having some testing and getting the team on a similar testing goal will make things much better. He also stressed the importance of metrics along with testing (really? From the metric-fu guy? Haha). If testing is old and broken, causing team backlash, low morale, and gridlock, it might be better to lessen the testing burden or throw away difficult to maintain tests. Getting rid of them and getting them out of the way, might be worth more than the value the tests were providing. In general he isn’t big into view testing, he likes to avoid slow testing. He likes to have a small ‘smoke screen’ of integration tests, to help verify the system is all working together. In the end, what is the right level of testing for a project? The answer: what level of assurance does the given project really need? In a start-up you probably don’t need a huge level of assurance, speed matters and market feedback matter more. If your building parts for a rocket or medical devices it is entirely different.

I enjoyed this talk quite a bit, and it inspired me to fix our broken metric_fu setup and start tracking on projects metrics again. Jake also wrote a good roundup of LSRC

Corey Donohoe @atmos, think simple
Corey gave interesting quick little thoughts and ideas about how to stay productive, happy, learn more, do more, fail less, and keep things simple and interesting… Honestly with something like 120+ slides, I can’t even begin to summarize this talk. I checked around and couldn’t find his slides online, but they couldn’t really do the talk justice anyways. Keep your eyes peeled for the video as it was a fun talk, which I enjoyed. Until then here is a post he made about heading to LSRC.

Joseph Wilk, Outside-in development with Cucumber
Cucumber is something I keep hearing and reading about, but haven’t really gotten a chance to play with it myself. Joseph’s talk was a good split between a quick intro to Cucumber, and diving in deeper to actually show testing examples and how it worked. From the talk it sounded to me like Cucumber was mostly a DSL to talk between the customer and the developer/tester. I don’t know if that is how others would describe it. I thought Cucumber was an odd mix of English and and Ruby, but it helps effectively tell a story. Since returning form LSRC, I have started working on my first Cucumber test.

Yehuda Katz, Bundler
This was just a lightening talk about Bundler, which I had read about briefly online. Seeing the work that was done for this blew me away. I can honestly say I hope this takes over the Ruby world. We have been dealing with so many problems related to gems at Devver, and if Bundler becomes a standard, it would make the Ruby community a better place. I am really excited about this so go check out the Bundler project now.

Rich Kilmer, Encoding Domains
The final keynote of the event was about encoding domains. I didn’t really know what to expect going into this talk, but I was happily surprised. Rich talked about really encapsulating a domain in Ruby and then being able to make the entire programming logic much simpler. He gave compelling examples of working with knowledge workers in the field and just writing code with them to express their domain of knowledge in Ruby code. Live coding with the domain with experts he jokingly called “syntax driven development” – you write code with them until it doesn’t raise syntax errors. Rich spoke energetically and keep a tiring audience paying attention to his stories about projects he has worked on through out the years. Just hearing about people who have created successful projects who have been working with Ruby in the industry this long is interesting. I thought it had great little pieces of knowledge that were shared during the talk, but again this was a talk where it was to hard to pull out tiny bits of information, so I recommend looking for the video when it is released.

Final Thoughts
LSRC was a good time besides hearing all the speakers. In fact like most conferences some of the best knowledge sharing happened during breaks, at dinner, and in the evenings. It also gave me a chance to get to know some of the community better than just faceless Twitter avatars. It was fun to talk with Ruby people about things that had nothing to do with Ruby. I also am interested in possibly living in Austin at some point in my life so it was great to check it out a bit. Friday night after the conference I went out with a large group of Rubyists to Ruby’s BBQ, which was delicious. We ate outside with good food, good conversation, and live music playing next door. As we were leaving someone pointed out that the guitarist playing next door was Jimmy Vaughn, brother of the even more famous Stevie Ray Vaughan. We went over to listen to the show and have a beer, which quickly changed into political speeches and cheers. Suddenly I realized we were at a libertarian political rally. I never expected to end up at a Texan political rally with a bunch of Rubyists, but I had a good time.

Hopefully the next Ruby conference I attend with be as enjoyable as LSRC was, congrats to everyone who helped put the conference together and all those that attended the event and made it worth while.

Written by DanM

September 3, 2009 at 3:58 pm

Boulder CTO January Lunch with Jud Valeski

The Boulder CTO Lunch meets once a month with a guest speaker and covers topics and questions that startup CTOs should find interesting. This month, the group had Jud Valeski, who is currently the CTO at Gnip. Prior to Gnip, Jud started his professional career in technology at IBM as a software developer. In the past ten years he has spent about five of them coding (primarily C/C++), and about five of them in technical team management/director capacities. The bulk of his experience comes from Netscape Communications (acquired by AOL), with varying durations at IBM, Microsoft, and (acquired by OpenWave).

I will share highlights of the discussion, but since this was a open, free-formed discussion, I am sure I couldn’t capture everything and not all my notes are completely accurate. Some of the notes also come from participants in the conversation and are not necessarily held by the discussion leader.

A question we ask each visitor, every month, What is a CTO? we do this because every CTO has a different answer.
“The title is pretty much irrelevant to me.” At a small company it doesn’t matter. It means something, it means a lot, at larger companies.

CEO is pure fantasy
Dev is pure reality
CTO is the bridge

Jud is a developer turned CTO, he explains this can be hard for some because a CTO brings some management responsibilities, which doesn’t always come naturally to all developers.

If you come from only management experience you can have a hard time with the CTO role because they don’t have the technical depth to make these decisions.

Important qualities of a CTO
* Technical Management
* Technical Direction (choose the tech to use, the approach, the design)

CTO role embodies the sense of leadership.

As CTO, you need a complete understanding of the business.

If the CTO is scattered that can be fatal. Be clear with prioritization and direction. If a person in the leadership position is confused it leads to a lack of confidence.

CTOs need to always be able to draw the system architecture. If you can’t, you are too detached.

To show those around you that you know what you are doing, you have to get down in the trenches and make some low level decisions with them. Backing up the decisions by explaining the technical merit of those choices.

Defining his role at Gnip
Push technical discussions along. Don’t let a topic be discussed too long when a decision needs to be made. Also, don’t cut off the discussion before exploring enough opportunities or you can make the wrong decisions.

At Gnip, defining the technical direction involved setting expectations that Gnip is an agile shop, uses pair programming, and uses lots of testing

One thing Jud measures the most is how well the team is going. If it isn’t going well, it is his fault.

A personal metric of Jud’s: if Gnip disbands tomorrow, every employee should be better and more knowledgeable than they were before they worked at Gnip.

* Only hire people that are smarter than you.
* If you think you are the smartest in the room, there is an ego problem and it is hurting the business.
* The downside to this is it takes a long time to hire.
* Gnip might hire 1 out of every 120 resumes it takes the time to seriously consider.
* It is important to sit down and write code with someone, plenty of people can talk a good talk
* Hire generalist because they can learn and do anything
* Don’t just hire for the tech need, the team personality and fit are just as important.
* Everyone on the team has to be great people, not just in the office, but out of the office.

The Gnip hiring process:
Resume Screen -> 30 minute call -> group tech conversation -> half/full day pair programming

Jud was once a part of a team that went from 15-50 in 4 months, which was too fast of growth and it was a mistake.

As a CTO do you have to manage your CEO?
“Yeah, all the time, absolutely.”

Like any job you need to be careful about what you escalate to the boss. The CEO doesn’t want to hear about every little thing.

What can a CTO do to foster engineering growth?
* Let employees buy as many books as they want on the companies dime.
* If you can afford it do the same for training
* Encourage participation in users groups
* Churn what people are working on
* Force developers out of their comfort zones.

What do you do about slipping schedules?
“Anyone suggesting software stays on schedule is in fantasy land”

If you pin motivation, success, or failure to a schedule you are doomed.

Wins have to come from someplace, if you set a schedule and meet it celebrate.

Reconciling schedules with business realities is probably one of the toughest CTO jobs.

If you have shrink wrapped software schedules has a whole different meaning.

Don’t inflate dates just to make the schedule, any dishonesty anywhere in the chain is bad.

You need to be able to release internally all the time. Internally always try to release early and release often.

When falling behind schedule, you have to evaluate the severity of each bug and feature. If there is a known workaround, that changes everything. If there is a workaround then it doesn’t have to block a release. If there isn’t a workaround, then you have to decide if it makes sense to have a release missing that feature.

Thanks a bunch to Jud for sharing his thoughts with our CTO group. I also want to thank Tom Chikoore from Filtrbox for organizing the meetings, and Jon Fox and David Cohen who originally started our CTO lunches.

Written by DanM

February 16, 2009 at 10:40 am

Boulder CTO January Lunch with Sanjiv Bhargava

The Boulder CTO Lunch meets once a month with a guest speaker and covers topics and questions that startup CTOs should find interesting. This month, the group had Sanjiv Bhargava from StillSecure come talk with our group. Before becoming VP of product development at StillSecure, Sanjiv was VP of Technology at Symantec Corporation. Sanjiv was also involved in some startups that failed and others that succeeded (selling a consulting company he founded). I will share highlights of the discussion, but since this was a open, free-formed discussion, I am sure I couldn’t capture everything and not all my notes are completely accurate.

Remote vs. Local employees
Sanjiv has worked with geographically dispersed teams in the past, but recommends working with everyone under the same roof if possible. He said that for small teams it is very helpful, as you build teams you need to build relationships.

Corporate Culture
“One of the best parts of starting a company is you get to create the company culture”

A team is a reflection of the leader, or you can switch it around, a leader is a reflection of a team because the leader builds that team.

The first hire to a small team has a huge impact on corporate culture, which can be good, but be aware of it.

What makes a good team?
* getting the right team chemistry
* sometimes make a compromise on technical knowledge but not on culture and team chemistry.

As a small startup, you don’t have time for team building exercises, if you need those at this level you have the wrong people in the company

The corporate culture is set by who you are. For example, if your office has a ping pong table and you never play ping pong that sets a culture to never play – focus on work. To play or never play: either is OK, but your actions as a leader set it.

Problem Employees
Have an open dialog with a problem employee to figure out what is going on. Maybe things can be turned around.

In small startups you need to cut your losses on employees fast and early.

There is never an easy or easier time to get rid of someone.

Think of the other employees you have. Good startup employees know the bad hire isn’t working out, and they don’t like having to carry their dead weight.

Employee Training
“Sometimes it would take you 2 hours to do something, or it take 1 hour of training and 4 hours for the new employee the first time. You have to take the trade off.”

Everyone chimed in on evaluations from the group, some of the thoughts are below.
* Every 6 weeks have a quick meeting. “Here is what you did awesome, here is what you could improve”
* Discuss as part of a team. What can I change? What can we improve on as a team? Have them evaluate you as a leader as well.
* A quick weekly meeting. What is not going right? What is going well? Go over what goals were met from the previous week. Have a meeting to set goals for the week and the year.
* It isn’t about management recognition, it is about team recognition. Group support and group recognition.
* Don’t have meetings. Do it on the fly, why wait to tell someone something is awesome or something wasn’t up to par?

The CTOs Role
* Ask ten different people what is the role of a CTO and you will get ten different answers.
* The CTO role is decided by what fits the company.
* It is a role that is a combination of business and technology.
* Two types of visionary CTOs, “How do I grow the business?”, or “How do I scale the technology or broaden the feature set?”
* One of the biggest mistakes we make is we try to pigeon hole people into boxes and defined roles.

Thanks everyone for attending our January CTO lunch. Thanks to Sanjiv for helping lead a great discussion. Also, thanks as always for TechStars for hosting our group. If you are interested in joining our CTO lunch shoot me an email dan, and I can get you on the email list.

Written by DanM

January 23, 2009 at 2:24 pm

Posted in Boulder, Misc, TechStars

Ruby people on Twitter

The Ruby community is always quickly moving, changing, and adopting new things. It is good to keep your ear to the ground so you can learn and adopt things that the community is finding really useful. There are a number of ways to do this, like watching the most popular Ruby projects on GitHub, most active projects on RubyForge, Ruby Reddit, or listening to the Rails podcast. The way I have found most effective is following a good collection of the Ruby community on Twitter, many of the most active Ruby community members and companies are on Twitter. It is where I have first heard of many things going on in Ruby like the recent Merb/Rails merge.

You can find a great list of 50+ (now 100+) Rubyists to follow on Twitter from RubyLearning. I thought we might as well give out a list of some of the Ruby people is following on twitter.

jamis / Jamis Buck
obie / Obie Fernandez
chadfowler / Chad Fowler
engineyard / Engine Yard
d2h / DHH
rjs / Ryan Singer
jasonfried / Jason Fried
_why / why the lucky stiff
gilesgoatboy / Giles Bowkett
dlsspy / Dustin Sallings
julien51 / julien
rbates / Ryan Bates
defunkt / Chris Wanstrath
chrismatthieu / Chris Matthieu
littleidea / Andrew Clay Shafer
headius / Charles Nutter
bascule / Tony Arcieri
atmos / Corey Donohoe
ubermajestix / Tyler Montgomery
raganwald / Reg Braithwaite

of course I have to give a special shout to ourselves:

danmayer / Dan Mayer
bbrinck / Ben Brinckerhoff

If we should be following you also send us an email at, and we can hook up on Twitter as well.

Written by DanM

January 8, 2009 at 2:08 pm

Posted in Misc, Ruby, Tips & Tricks

Boulder CTO December Lunch with Tim Wolters

The Boulder CTO Lunch meets once a month with a guest speaker and covers topics and questions that startup CTOs should find interesting. This month, the group had Tim Wolters from Collective Intellect come lead the discussion. Tim is a serial entrepreneur currently working on using artificial intelligence and semantic analysis to extract knowledge from unstructured text found in social media. Collective Intellect’s customers use this analysis to inform and measure the effectiveness of their PR and marketing strategy.

Tim is considering working on a book, a startup survival guide for CTOs. Some of his ideas for the book helped lead our discussion during our meeting. I will try to present my notes under topic headings that Tim mentioned, but since this was a open free formed discussion, I am sure I couldn’t capture everything and not all my notes are completely accurate.

The Idea
People should keep a journal of ideas. Tim keeps a journal which he updates, tags, and adds ideas. On any idea, keep track of what is near term, what resources are needed, what is the cost, and what does the related market look like. (I highly recommend this! Ben and I keep a wiki, which has grown to be an incredibly useful resource and was the initial starting point for our last two companies)

Ideas should have an “Aha!” factor that makes you wonder why someone else isn’t already doing it (or some emotional appeal that makes lives better).

During the first few years of a startup you can’t work on all the ideas that come to mind, that is why it is best to keep a journal, just add little notes to the idea to keep them in the back burner.

Talk to others about ideas and perhaps have a group move on an idea and lay the groundwork while leading as an adviser.

Don’t be worried about people taking ideas. After starting a few companies you know how hard it is to really bring something to market.

What about brainstorming for ideas with a group?
Brainstorming groups have never worked for Tim, it just hasn’t worked out. If you have the right people around the table (people that can make things happen), it could work, but Tim hasn’t seen it.

Ideas depend a lot on timing in the marketplace. If the market is moving slow you can slowly look at an idea. If the market it really moving fast you need to spin it up quick and get a lot of people working on it to really make a move on the idea.

Look over your ideas once in awhile and see what still really interest you.

The Role
As a CTO, you paint a landscape of the product and market.

There are two kinds of CTOs: tactical and visionary. Tactical CTOs are internally focused, manages the team, makes the day-to-day tactics so the product gets out there. The visionary CTO sees where the product could go in the market place, signs early deals and customers, looks for features that lead towards or away from markets/competitors/partnerships. The visionary isn’t working on architecture but the market landscape, what partners will benefit the product or get it out sooner.

CTO should be thinking about things such as the three hardest problems that the company faces, so they know what will also be affecting their competitors.

People who liked architectural purity but learned it isn’t as import at winning at the business end up making great CTOs.

CTOs need to stay involved with customers to make decisions about the project innovation and development. Stay active on sales calls, talk with sales people, read all the RFPs.

Becoming the CTO vs VP of engineering?
Are you good at managing or not? VP of engineering is a managing role. If not, divide off the management as soon as possible (in his case that wasn’t possible until the company was about 20 people).

Good sales people leverage a CTO as a company evangelist. If you are a CTO you have to be comfortable with presenting and publicity. You will be at conferences, sales calls, giving presentations, and fund raising. If you aren’t comfortable with these things, get comfortable with it.

time spent:

  • 10% guiding research
  • 30% Sales
  • 30% Partnerships
  • 30% Biz Dev Dealings

After some startups, successes, and expanding your network things like getting a team, funding, and getting a startup off the ground are much easier the next time.

It will take 3 to 5 times longer than you think to get a project going if you are an unknown entrepreneur with no reputation.

Don’t solve the big unsolvable problems first, the first time start with smaller problems and develop a reputation while solving them. Angels and VCs aren’t funding research efforts, don’t just chase after big impossible goals.

After a company is bought, it makes sense to make the purchaser successful. It builds on your reputation.

Become a big fish in a small pond and then move to a bigger pond.

Putting together the team
The ideal size for an engineering team is 6-8 people, bigger teams have difficulties maintaining the right amount of communication.

For hiring, Tim personally sits down with the key hires, and if it is research he does interviews with applicants as well.

The Traps and Pitfalls of Startup Companies
3 things that companies get stuck on that can kill the company.

  • Problem with getting over enamored with their original idea, startups must be able to adapt
  • Getting enamored with the research technology, for technology’s sake
  • Getting emotionally tied to architecturally purity. Working on layers of abstraction on abstraction to avoid some possible future problem.

Other things that kill companies (which are kind of like a marriage)

  • Not the right chemistry
  • Bad culture or losing company culture
  • Employees need some sense of allegiance. If they don’t have it cut them immediately
  • Lacks a culture of adaptability
  • Not thinking about how to quickly get to the market and solve problems

Continual code death march. Sometimes companies go on code marches to get something to the marketplace. This can’t be done many nights or it will start taking a toll on other aspects of your life. Strive for balance.

During a startup, you continually are hitting false summits, you think that if you could just get that contact, solve that roadblock, pass this milestone, or make this key hire then everything will fall into place. While these are important as milestones and you should celebrate them you are not done. Or rather, it typically doesn’t get any easier. What it does is takes more risk out allowing you to go solve bigger/other problems.

When founders or others in a company argue, which they need to do sometimes, don’t do it in front of everyone. Discuss disputes offline, reach agreement and present a unified front to the company.

Thanks so much to Tim for sharing some of his thoughts with our group. I will leave you with a final question and quote. Someone once asked why Tim likes to start companies?
“I like to pick where I work and who I work with.”

Written by DanM

December 11, 2008 at 9:50 am

Installing and running git-svn on Mac OSX 10.4 Tiger

I am shocked at how much time it took me to get git-svn working on my mac. I use MacPorts, which works well most of the time. Sometimes it has problems which makes me really wish for apt-get on OS X. apt-get normally has worked much nicer for me, but can have its issues too. I even occasionally wish for Windows and a simple install.exe which works 95% of the time out of the box. Really I wish Apple would throw some engineer support to MacPorts and make the service rock solid.

I have had git installed and working for awhile, but preparing to switch our main project from Subversion (svn) to git, I thought I should start using git-svn. It seemed smart to use git-svn for awhile to get used to git, before a full switch so I could fall back on svn in a crunch. I decided to start using git-svn, but the first run of the git-svn command caused this error, and I had no idea how much of my night was about to be wasted…

Can't locate SVN/ in @INC

Searching led to a couple of webpages, but the most useful was getting git to work on OS X Tiger. It had a quick fix that might work or the long route fix. For some lucky people it is just a path problem. I checked if that was the case for me, by the following command

PATH=/opt/local/bin:$PATH; git svn

unfortunately for me I got the same error, OK I need to reinstall SVN with additional bindings…

> sudo port uninstall -f subversion-perlbindings
> sudo port install -f subversion-perlbindings

leading to this error:

--->  Building serf with target all
Error: Target returned: shell command " cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_www_serf/work/serf-0.2.0" && make all " returned error 2
Command output: /opt/local/share/apr-1/build/libtool --silent --mode=compile /usr/bin/gcc-4.0 -O2 -I/opt/local/include -DDARWIN -DSIGPROCMASK_SETS_THREAD_MASK -no-cpp-precomp -I. -I/opt/local/include/apr-1 -I/opt/local/include/apr-1  -c -o buckets/aggregate_buckets.lo buckets/aggregate_buckets.c && touch buckets/aggregate_buckets.lo
libtool: compile: unable to infer tagged configuration
libtool: compile: specify a tag with `--tag'
make: *** [buckets/aggregate_buckets.lo] Error 1

I spent some time searching and eventually I find the solution to the serf error. I couldn’t read the blog because it wasn’t in English, but I could read enough to solve my MacPorts serf install problem. I followed these few lines from the blog

cd /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_www_serf/work/serf-0.2.0
$ sudo ./configure --prefix=/opt/local --with-apr=/opt/local --with-apr-util=/opt/local
$ sudo make all
$ sudo port install serf

Awesome, I have serf. Now what is next? Back to building svn with perl bindings, that works. Now, let’s build git again since svn with perl bindings is finally installed.

sudo port install git-core +svn

Which fails because of p5-svn-simple

dyld: lazy symbol binding failed: Symbol not found: _Perl_Gthr_key_ptr
Referenced from: /usr/local/lib/libsvn_swig_perl-1.0.dylib
Expected in: flat namespace
dyld: Symbol not found: _Perl_Gthr_key_ptr
Referenced from: /usr/local/lib/libsvn_swig_perl-1.0.dylib
Expected in: flat namespace
Error: Status 1 encountered during processing.

OK, I need to get p5-svn-simple working. Searching leads to this thread MacPort errors related to git. Here you will find the amazingly useful comment by Orestis:

“As mentioned move your libsvn_swig_perl* out of /usr/local/lib AND out of /usr/lib into temporary folders.

Uninstall and reinstall subversion-perlbindings

Install p5-svn-simple (and git-core +svn which is what lead me here)

Move the libsvn_swig_perl files back in /usr/lib and /usr/local/lib (or else git svn won’t work).

> cd /usr/local
> mv ./lib/libsvn_swig_perl* ./bak/
> sudo port install p5-svn-simple

Sweet that works now

> sudo port install git-core +svn
> cd /usr/local
> mv ./bak/libsvn_swig_perl* ./lib/

Finally I try to run git-svn, only to see the same ERROR I had from the very beginning! I am about to lose it but decide that I should try the quick fix again to see if it is the path issue…

PATH=/opt/local/bin:$PATH; git svn

It works! Alright now it is just a path problem. So I open up my .bash_profile, and notice I already have that path included

# Setting the path for MacPorts.
export PATH=/opt/local/bin:/opt/local/sbin:/Applications/MzScheme\ v352/bin:$PATH

But I also have an additional path added from when I originally built git from source, and it looks like I was running my old broken version of git-svn. So I just had to remove this one line from my .bash_profile

export PATH=~/projects/git-$PATH

and hours later and with a ton of frustration I have a fully functioning git-svn.

Now that it is working, you can move on to learning git-svn in 5 minutes.

Written by DanM

December 9, 2008 at 11:16 am

Revisiting additional Ruby Tools

I have heard about new Ruby tools since I did my Ruby Tools Roundup. I am always interested in tools that can help improve our code, so I had to check some of them out. Similar to my last tools post, I will be trying out a tool and writing my general impressions along with the basic usage.


I have to start with reek, since it has been the most requested and searched on our site since I originally wrote about tools. reek will help identify code smells, allowing you to fix up your code. Instead of looking at cyclomatic complexity or other metrics, reek looks at patterns to warn you about bad code. Reek currently detects a few code smells (Long Method, Large Class, Feature Envy, Uncommunicative Name, Long Parameter List, Utility Function, Nested Iterators, Control Couple, Duplication) but more are on the way.

I think this project is useful but would need to be more customized before a nightly run would yield very useful results. The biggest problem I have is the signal to noise ratio seemed pretty high. Reek was warning me about “long methods” that were only 7 statements long, which just isn’t something I am concerned about. The warnings on duplicate methods calls can be useful, after running reek on a few files I found a couple places where duplicate method calls were wasting time. Many of the other smells are interesting like ‘Feature Envy’, and ‘Utility Function’. I will need to use reek more before I know if these smells are good indicators or often false positives.

Below reek finds a utility function next_tick which is definitely a helper function that actually exists in two of our files, which probably should be moved into a helper mixin.

def next_tick
      EM.next_tick do

I am really looking forward to see how the tool progresses. If the project allows for a simple config customization to change the thresholds as well as ignore some files/smells, this could become a very useful tool to help keep a team maintain a high expectation of code quality. It would be useful to get nightly reports about any code that might not meet expectations, so a quick group code review could decide if it is an exception (which can be quickly added to the config) or if the code should be refactored and cleaned up.

dmayer$ sudo gem install reek
dmayer$ reek ./lib/client/client.rb
[Utility Function] Client#next_tick doesn't depend on instance state
[Long Method] Client#process_done has approx 7 statements
[Duplication] Client#process_ready calls @buffer.create_reload_msg more than once
[Long Method] Client#process_ready has approx 10 statements
[Duplication] Client#report_system_message calls result.msg more than once
[Feature Envy] Client#report_system_message refers to result more than self
[Duplication] Client#send_tests calls more than once
[Long Method] Client#send_tests has approx 24 statements
[Feature Envy] Client#send_tests refers to tests more than self
#check a whole directory
dmayer$ reek ./lib/client/*


Towelie helps discover duplication in Ruby code, it will help keep your code DRY. It doesn’t have a nice interface at the moment and it is pretty young code. That being said, it can still be a really useful tool to help guide refactoring and code cleanup.

~/projects dmayer$ git clone git://
dmayer$ cd ~/projects/devver/
dmayer$ irb -r ~/projects/towelie/lib/towelie.rb
irb(main):001:0> @t =
=> #, @model=#>
irb(main):002:0> @t.parse "lib/client"
(string):24: warning: useless use of a variable in void context
=> nil
irb(main):003:0> puts @t.duplicates
found in:

def nl

... 2 more dupes in the reporters ...

found in:

def report(str)

found in:

def quit

found in:

def send_quit

=> nil

There are currently many duplications because we are maintaining two clients while deciding what route to eventually take. We have also moved a lot of our shared client code into a mixin, and Towelie finds some methods that really should be moved there as well such as the methods “quit” and “send_quit”, which is currently duped in 4 files. Towelie also points to the fact that we should refactor our reporters because they both duplicate code.

I have always been annoyed with copied and pasted functions accidentally working its way in code, this could be a useful nightly run to keep a team DRY. Sometimes two team members implement the same functionality without even knowing a solution already exists in the code base. If you want to go a bit more in depth, check out Giles Bowkett’s (creator of Towelie) How to use Towelie


Flay is another great tool by Ryan Davis who also works on Heckle and Flog which I covered in the past. Flay, like Towelie, helps keep your code DRY, it detects exact and similar code throughout a project. It seems to be more powerful than Towelie, as seen in this Towelie and Flay comparison. My biggest complaint is the current release has some pretty basic output that you see below. The output I got from Towelie was immediately more recognizable and useful, while Flay currently requires you to dig in a bit deeper on your own into its suggestions. An improvement is already being worked on and a verbose output mode should be in the release soon. Once better output is included I think Flay will be immediately useful out of the box even with small amounts of developer effort.

I like that Flay has weight system, which should make it easy to set some threshold to ignore, high level weights are more likely to be worth your time and attention. One piece of code Flay tagged with a low weight was code that rescued and logged different errors thrown, which while similar actually served a purpose.

rescue Errno::EISDIR => ed
      @stderr.puts "Error: #{ed.message}" if @stderr
      @stderr.puts "You can't pass a directory to devver only test files. Quitting." if @stderr
    rescue LoadError => le
      @stderr.puts "Error: #{le.message}" if @stderr
      @stderr.puts "Not all of the files can be found. Quitting." if @stderr
    rescue SyntaxError, NameError => se
      @stderr.puts "Error: #{se.message}" if @stderr
      @stderr.puts "This file doesn't appear to be a valid Ruby file. Quitting." if @stderr

Digging into the Flay results turned up some duplicate code that Towelie had missed. Since Towelie also caught a method that was duped in 4 client files that Flay missed (I was expecting Towelie’s results to be a subset of what Flay found), perhaps there is room for both of the tools and learning to work with both a little bit is worth the time. After a little bit of work perhaps one of the projects will become a clearly better option. Until then I will be following both of these projects.

sudo gem install flay
dmayer$ flay lib/client/*.rb
Processing lib/client/client.rb...
Processing lib/client/mod_client.rb...
Processing lib/client/syncer.rb...

Matches found in :defn (mass = 84)

Matches found in :block (mass = 57)

... 6 more results ...

Matches found in :if (mass = 34)

Matches found in :defn (mass = 32)


That should cover it for this Ruby tools post, but I am really enjoying checking out the tools showing up in the Ruby scene. So as always let me know if I missed something, or if there is a tool you would like to see a full write up on. After some of the tools mature a little bit I will have to revisit a few of the tools which are currently in the early stages. I hope the Ruby tools scene keeps as active as it has been lately because there are some interesting projects being worked on.

honorable mentions (things I didn’t think really needed a full write up)

  • metric-fu a great gem to give quick access to a bunch of tools and metrics about your code (RCov, Saikuro, Flog, SCM Churn, and Rails Stats)
  • CruiseControl.rb when you start using all of these tools, continuous integration starts to become more important (or doing nightly runs). CruiseControl.rb is dead simple continuous integration.
  • Simian another code duplication tool, which is mentioned in 3 tools for drying your Ruby code (free for OSS, $99 for a license)
  • Ruby Tidy a tool for cleaning up HTML (I haven’t used this in Ruby, but loved the Java version in my Java days)
  • Watir is an open-source library for automating web browsers. It allows you to write tests that are easy to read and maintain. It is simple and flexible.
  • Autotest, if you haven’t heard of autotest, check it out, continuously run your tests every time you save a file in your project.
  • Rufus a tool that checks if code you are about to load is safe. Allows you to look for custom patterns that you don’t want to run.
  • I wrote about a couple benchmarking tools last time and here is a great article / tutorial on Ruby benchmarking

Written by DanM

December 3, 2008 at 10:01 am

Notes from the Boulder CTO lunch (11/3/2008)

Although I’m not actually the CTO of Devver, I had the pleasure of attending the Boulder CTO lunch this past Monday since Dan was out of town.

This week, the group had Todd Vernon from Lijit come lead the discussion. Although Todd is currently CEO of Lijit, he was CTO at his former company, Raindance.

The group that was assembled was small but awesome – I had the opportunity to learn not only from Todd, but also from the CTOs of a few of last years TechStars companies.

The discussion touched on a ton of topics, but two (related) themes that were heavily discussed were the role of the CTO and how a company grows from a technology perspective. I’ve organized my notes below. Keep in mind that these are the collected thoughts from a number of different participants and I may not have captured their ideas with 100% accuracy.

The Role of a CTO

What is the difference between a CTO and a VP of Engineering?

CTO is about leadership for technical issues, interfacing with the business side, guiding the product, get people excited about product from a technical point of view.

VPoE is almost one step above Chief Architect, more on a management side, getting product delivered.

1st time CTOs need to figure out their exact role. It’s a very amorphous role, depending on the company.

CTO needs to be able to tell the whole business story, understand the good parts and bad.

Early on, CTO should insert themselves into the sales process as much as possible (especially right after you hire the sales person). You need to be able to hear what customers say they want, so you can translate that into what they really need.

The Technology Onion

There is a technology onion – make sure the core of the onion is owned by company (the outer layers, not as important). The CTO needs to figure out the relationship between the technologies and the company’s partnerships. The closer a technology is to the core of the onion, the more important it is to own it and to make sure it scales.

For instance, if you’re depending on Google for search, you’re powerless to change features if things don’t work as your customers want/expect. If search is core to your business (near the core of the onion), consider building it internally. It’s the CTOs role to make that case, because business people will never understand the need to spend money to get “the same thing.”

Having to re-architect a core component of a company can really hurt growth. Assume you’re going to be successful, so plan for that.

Along the same lines, one concern about using EC2 is that you get tied to the platform and your business is dependent on an outside force you can’t control. Hosting on EC2 can be quite different than hosting your own boxes.

Acceptable Failures

What is acceptable downtime? It depends on when – between midnight to 1-2 AM, it might be OK to be down for a few minutes. CTOs need to determine what acceptable downtime is and tell that the to the rest of management and have people agree.

CTOs need to make decisions (for instance, what is the acceptable down time, acceptable data loss, or acceptable time for page load) and then tell the entire organization. That way, when something bad happens, you can explain that everyone agreed on the specific numbers. It’s unlikely your business will need to be (or can be) 100% perfect on all metrics, but people need to understand what the goal is and why it’s realistic.


If at least one person is using your service, you should have two web servers. It gives you ton of flexibility. Having two boxes forces you to work out most of the issues early (it’s a lot different getting to 2 boxes than 3 or 4). It’s not about load, it’s about reliability.

No matter how useful you are, if you are not reliable, someone will blog, “it’s cool, but it doesn’t work reliably.”

Downtime spreads very fast across Twitter. Consider tweeting about upcoming service interruptions ahead of time so customers are aware.

After more than 15 people, you need a dedicated operations person. Get some basic monitoring services early – after a server is under load, it’s really hard to diagnose. Try to detect stuff early, it’s easier to debug.

With startups, generally the problem tends to be slow requests rather than complete service downtime. Make sure your monitoring service will alert you with slow requests.

Get app specific stuff – a warning like “High CPU load,” is harder to understand (it might be a problem, or maybe the machine is just handling a lot of requests successfully), but “Page X takes 80 sec to load” is more obvious.

As you grow, try to measure more and more. Things often degrade slowly, and one day you just notice its too slow and it’s hard to go back and find the root of the problem.

Make two lists: a) the most catastrophic things that could happen and b) the most likely things that could happen. Where those lists overlap, you need to fix something. But there will be some risks that you decide are reasonable risks for the business (revisit these risks regularly as things change).

Regarding backup – always make sure you try to restore some data (before you really need it). You need to make sure it works and make sure its fast enough.

You should always be able to describe at a high level how the service will scale infinitely (it doesn’t have to be technically perfect, but it has to be believable). When someone wants to purchase, that’ll be a huge help – the business guy on the other side of the table will want to buy, but the technical guy doesn’t want to buy (he wants to build it in-house).

I hope those notes make some sense and give you a good feel for the discussion we had. I’m looking forward to attending more of these lunches (I hope they’ll continue to let a few CEOs sneak in…)

Written by Ben

November 7, 2008 at 10:21 am

Posted in Devver, Misc, TechStars