neovintage

Being in business school is great. We get to learn about all sorts of topics like economics, marketing, and even organizational development. The one thing that not all students get to learn about is how to hire the right person for the job.

Since I love being a part of startups, especially software startups, I get a lot of people in the business school asking me for advice when it comes to hiring programmers and developers for their businesses. Outside of telling them that they should really have a technical co-founder on the team, I try to give them some advice based on my past experiences.

In one of my past experiences, I was brought on to a team to manage a couple of developers. Unfortunately, I was brought on to the process a little too late. When I was finally debriefed on what was going on, I found out that all of the developers had been hired, and without my input. The process for hiring developers was just a standard 1 hour interview. At first I didn't think anything of it but as the project progressed, cracks started to show in the team. For example, I had one individual who would always promise to do a set of tasks by the end of the day, but then at every status meeting the next day, without fail, some issue came up that prevented him from completing it. His excuses were alway very long winded and convoluted. After a week of this, I found out from other developers on the team that the individual in question kept pestering the other developers to help them solve very simple issues. Not only was this not productive for the other developers but for the project as a whole. Since the project was so short, I didn't have the time to let the person go and hire someone new. I had to just manage around the problem individual. It was at that point, I wished I was part of the hiring process.

Take aways:

• Don't think that an hour interview is going to tell you if the interviewee is a good candidate.
• You're gonna have to take the time to get to know someone.
• Have the person work on small tasks or projects before actually bringing them on. (On Interviewing Programmers)

As a Senior Project Manager at Sparkseed, my job encompasses managing our staff of interns, developing the company's long-term strategy, as well as mentoring any of the Sparkseed funded ventures. Recently, I was asked to mentor one venture, Capital Good Fund (CGF), on what software package to use to implement their back end systems. The team was struggling to determine what package could meet their needs now and into the future. It seemed like a very large task, but I was definitely up for it.

After a few initial emails to get a background on CGF and its mission, I jumped onto a call with one of the founders. One of the very first things that we did was talk about all of the software platforms that they were considering, like MIFOS, Salesforce.com, and Highrise, just to name a few. Almost immediately after identifying all of the software platforms that were up for consideration, the conversation turned into listing all sorts of features that CGF might need.

The key word to point out is "might." Just like with any software development project, I was finding feature creep. We'd discuss one feature and that would certainly lead into another. There were so many things that the team at CGF wanted the software to do that the platform was beginning to look over-complicated.

In terms of providing a solution for CGF, I recommended that we stop talking about technology all together and focus on the core process for the business. In this case, the core business function was the loan process. We then drilled into the loan cycle, how the loans are made, who has authority to make loans, and how the loan gets paid back. At this point, we had a clear understanding of how the business worked and who was involved.

Taking the current staff capabilities into consideration, I was able to recommended a system that had the bare minimum to meet the need of tracking the loan and the various touch points the loan officers would have with their customers.

Side Note: As with any software package, it should be robust enough that if you outgrow the software or want to manipulate it in other ways, the software should let you access the raw data.

Key Lessons learned:

• Always pull back. Ask the question "what operational problem am I trying to solve?"
• Only use as much software is needed to get the job done.

References:

• The Right Mind-set for Managing Information Technology
• Avoiding the Icebergs - Talks about software architecture but still pertinent
• Avoiding the Icebergs #2
• Scope Creep

Since playing around with MacRuby, I figured, to keep myself relevant in the programming space I should learn Objective-C / Cocoa. That and it seems every person that has touched Ruby is now hopping on the Objective-C bandwagon. EVERYONE WANTS TO BE AN IPHONE DEVELOPER! Just kidding.

My requirements for learning materials:

• I really didn't want to pay for anything, but I'll have to if I must.
• I wanted all my materials to be online or pdf.

Basically my requirements cut out things like classes and most screencasts.

This is what I ended up with (its also in order of operation):

• Peepcode Objective C Screencast: I have purchased a number of his screencasts in the past and have been pleased, so I figured why not get this one, it was only $9. It was a well put together screencast but I felt like something was lacking. That, or I was being lazy. Yet I found that I wanted more of an introduction to some of the major frameworks on Mac OS X and the iPhone. Uh oh, there's that word again, 'iPhone'. I think if you're just looking for an introduction into the semantics of the language, start here. Otherwise, like me you'll move on to the Stanford Class.
• CS193P - iPhone Application Programming: This class was great, and on top of it, it was free! Now I wasn't specifically looking for iPhone application development, but the topics covered were still very pertinent to developing on Mac OS X. I found the instruction to be be very good. I would recommend this course for anyone that has some programming background but finds the classroom setting a little easier to work with.
• Cocoa Dev Central: I wish I would have known about this before I started down the path of the Peepcode screencast. Yet since I purchased the Peepcode screencast, a reference was made to this site. I guess I wouldn't have known about it had I not gotten the screencast. Sounds like a paradox to me. Anyway, the site was great and you could find anything you needed to if you're learning about the intricacies of Objective-C and Cocoa.

After thoroughly going through all of the material I've mentioned above, I actually did decide to write an iPhone app. I decided against releasing it to the App Store because, well, I think it wasn't the best quality. Anyway, I don't claim to be a master at Objective-C, but I know enough to be dangerous. I believe that going through the above references will make you just as dangerous!

If you're an absolute beginner, I would recommend starting with the Stanford class first, and then going over to the Cocoa Dev Central site and skipping the Peepcode screencast all together. Now if that's still too much for you, well you need to start all the way at the beginning by learning C. At least you haven't burned any money on education.

If you do decide to write an app for the iPhone here are some posts that I found useful:

• iPhone Development: OpenGL ES from the Ground Up: Table of Contents
• Displaying Variably-Sized Text Cells in a UITableView
• SQLite Persistent Objects
• Persisting Dates to SQLite3 in an iPhone Application
• More links can be found @ my delicious account

Plain and simple, your web app sucks because it doesn't have good metrics. Now I'm not talking about code coverage or anything internal to your operation. I'm talking about summary statistics for the end users of the application relative to how they interact with it. My case is this, developers hold themselves up to a very high standard when developing their apps using frameworks like Test Driven Development (TDD) and Extreme Programming (XP). If you can take some of the philosophies from those frameworks, TDD and XP, and provide measures for your users, we'll see much happier users in the end who will reap large benefits from your application.

Why Metrics Make Sense

• Your Users' Standpoint:Why wouldn't users of your site want the same procedures that developers use to build quality sites?! Continuous feedback, communication, and simplicity. All three are values within XP and are targeted toward increasing productivity. By having a measure to gauge how you're doing, as a user, I can get more value out of using your application and react to any changing conditions.
• The web app owner's standpoint: Let's face it, the whole reason you're writing web apps is to get something back. Whether its money or a learning experience. Let's take the money side of that argument. Analytics and metrics can be a boon for your bottom line. Take Twitter for example. With recent articles floating on the web about it's new BizDev guy, Kevin Thau has said that they'll sell analytics to enterprises to make money. That's a lot of money to make to cover the cost of running Twitter.

General steps that you can take to generate good analytics for your data:

• Define your core user experience. The important part of defining the user experience is understanding the reason why they're using your service in the first place. Are they trying to manage projects, track their finances, or connect with friends? This part may take some research on your end because despite all of our best efforts sometimes the users of our web apps have totally different goals than what we expect. That being said, consider sending out surveys to a sample population of your users or analyze your Apache web logs for usage patterns. If you're still not sure where to start, try holding a focus group on Skype to at least get you going in the right direction for the surveys.
• When trying to summarize multiple observations, consider using nonaveraging metrics (maximums, variance, counts). According to recent research from Shugan and Mitra @ the University of Florida, they found that although averaging metrics may sound great theoretically (like sales per user, or cost per user), most uses of metrics (benchmarking, monitoring, allocating resources, diagnosing problems, etc) require that the metrics provide information (explained variance) about all of the outcomes that you're measuring. For example, a simple count of the number of new products from a company might convey information about a firm's ability to innovate.
• Keep the number of metrics relevant and to a minimum. Although I'm advocating for including some type of metric within your application, I also want to caution against providing too many. A danger exists whereby you can give your users too much information. Users can spend too much time trying to absorb everything that you're throwing at them instead of getting what they need and then reacting to it. Another part of that argument is that the information needs to be relevant, which goes back to defining your core user experience. For example, if I had a project management application, a metric to track how many times all of the people on the team logged into the application is not really a useful statistic when you're trying to finish a project. For further reading on this point, check out Russell Ackoff's article about "Management Information Systems." It's an old article, but still relevant to this day.

If you have an opinion on this subject, I'd love to hear about it! Leave a comment.

I had originally submitted a request to the DataMapper team to include an option to allow MySQL database users the ability to specify table options in their DataMapper models. My needs were around data warehousing and I wanted to use a different storage engine like Infobright. Unfortunately this request was denied because dm-core could have ended up looking like spaghetti if my request were approved. Mind you I'm oversimplifying the argument, but I understood where they were coming from. As a result, I bring you dm-mysql!

Overview

• Plugin Name: dm-mysql

• Summary: Plugin that allows MySQL DataMapper user the ability to specify MySQL table options when DataMapper creates database tables.

• Requirements: Your DataMapper version must be > 0.9.10

• Options: For available MySQL table options see the MySQL documentation. Note that this plugin was created against MySQL 5.1.

• To Install: Make sure you have github listed as one of your sources.

sudo gem install neovintage-dm-mysql

Example

require 'dm-core'
require 'dm-mysql'

# Shows available options
class HasAllOption
  include DataMapper::Resource

  property :id, Serial
  property :name, String

  table_opts :engine => 'MyISAM',
    :avg_row_length => 7,
    :checksum => 1,
    :comment => "Best Comment EVER!!",
    :connection => 'another_connection',
    :data_directory => '/dude/wheres/my/dictionary',
    :delay_key_write => 0,
    :index_directory => '/index/this',
    :insert_method => 'FIRST',
    :key_block_size => 256,
    :max_rows => 5,
    :min_rows => 0,
    :pack_keys => 0,
    :password => 'secret',
    :row_format => 'COMPRESSED',
    :tablespace => 'DUDE',
    :union => 'has_its, not_includeds'

end

As always, I appreciate any feedback on the code or any features that you'd like to see implemented as part of this.

I recommend that you check out the Startonomics blog for details on the conference as well as all of the video. I learned quite a bit and met many interesting people who were at various stages within their ventures. Yet if you want to get the quick gist of the conference, I bring you my top 10 themes of Startonomics:

In my last post, I had briefly talked about how I ran a rake task in the background to accomplish the twitter worker functionality. After the course of a couple of weeks, I've got a couple of updates to that process, so that hopefully, you'll have an easier time of running a rake task continuously in the background.

Use Monit instead of god for monitoring

I started with god to monitor my rake task. It was very easy to setup, almost too easy. After a couple of weeks, I started to notice that the god process was starting to leak memory all over the place. I'll qualify this by saying that I use slicehost for hosting tweetrics. I've seen some messages on the slicehost boards that talk about how god doesn't work well on the VMs. That being said, I had to switch to something else. Enter Monit. I didn't have that much experience using Monit so, I had a learning experience in front me. I found some instructions on the web on how to install Monit, which were fairly painless. Within a few minutes, I had everything installed. Now onto getting the rake tasks setup.

Setup the monitrc file

The next step in setting up monit to handle my background task was setting up the monit control file. This is analogous to setting up the configuration file that you'd use with god to handle the monitoring of your processes. I have to admit that the syntax for the monit control file was relatively straight forward. To make things even easier, I found this post from Ilya Grigorik. I copied the monitrc file and put it in my config directory of my merb project. Although Ilya's post was directed toward using mongrel with monit, all I needed to do was change the start and stop program lines to something like this:

start program = "/path/to/bash/script start"
stop program  = "/path/to/bash/script stop"

The purpose of these lines are to start an stop the rake tasks, which leads us to the next step.

Create the bash script to handle the startup of your rake task

Since rake tasks are not daemonized and do not create their own pid files, we'll have to set that up. Time to setup a bash script. I couldn't do this part without looking through the FAQs on the Monit site, more specifically what to do to set up a script for processes that don't create pid files. I'm not the best person when it comes to creating bash scripts, so finding this information in the FAQ was a big help. Now came the part for creating the rake specific parts:

#!/bin/bash
export PATH=$PATH:/usr/local/lib/site_ruby/1.8/rubygems

case $1 in
   start)
      cd /path/to/merb/root/directory;
      echo $$ > /path/to/log/metrics_gen_master.pid
      /path/to/rake twitter:metrics_gen MERB_ENV=production
      ;;
    stop)
      kill `cat /path/to/file/metrics_gen.ppid`
      kill `cat /path/to/file/metrics_gen.pid`
      kill `cat /path/to/file/metrics_gen_master.pid`
      rm -rf /path/to/pid/files
      ;;
    *)
      echo "usage: twitter_worker {start|stop}" ;;
esac
exit 0

Important notes:

• In your rake task, make sure that you save the pid and the ppid to a file.

  `echo "#{Process.pid}" > #{Merb.root}/log/metrics_gen.pid`
  `echo "#{Process.ppid}" > #{Merb.root}/log/metrics_gen.ppid`
  

  This is important because we'll need to stop the rake processes.

• If you're running monit using init be careful of permissions.

  Since my rake task loaded the merb environment, it would be running as root and would write to merb.main.pid. If I restarted apache, passenger could not write to the file merb.main.pid and would throw errors instead of running the app.

• Don't use & when invoking your rake task!

  By using & in the bash script, the rake task will get forked and and the incorrect pid will get written to file. Trust me, I spent a lot of time on this one.

Run it!

Not much I can say here other than take the time to really extensively test your monit script. The log output can be found at /var/log/monit.log. Also, make sure you run it with sudo if you are going to use init.