Dear [Under-Capitalized Business-Guy who wants me to work on your site for 'equity'],

[Note: This was cut/pasted from an email response I sent an individual I had a meeting with. I did not enter into a business relationship with this person. I posted this here since it seemed to contain general advice that might be useful to others. - Kevin]

Dear [Under-Capitalized Business-Guy who wants me to work on your site for 'equity'],

Thanks for taking time to meet today. It was interesting to learn about what you’re doing.

I’ve put some thought to what you’re trying to do and I have to be honest, I have some reservations about it. The business model itself may work, though I don’t know that much about the kinds of businesses you’re hoping to get as customers. But the very rough proforma you’ve put together gave me a bit of pause.

I appreciated that you’ve had the foresight to put together some financial modeling — that was reassuring. But it concerns me that you felt you could somehow spend only $50,000 on developer salaries over a 5 year period. And while I understand that at this point the numbers are all pretty rough, it just seems way low for what you’re trying to do.

A single developer (one with the skills to handle all aspects of the site, build it and keep it running, backed up and responsive as your customer base grows) would cost a very minimum of $75-80K/year (plus benefits, etc.) For $10,000/year you might be able to hire a single person at far less than half-time. That’s to me just so unrealistic as to be almost impossible. I can’t imagine it. You can’t build a software-based company without software developers. To realistically handle what you’re trying to do would likely require an ongoing staff of 2 or more people once you got to 2-300 or more customers using the application.

And if you can’t find someone willing to work for free I’d recommend a budget of closer to $50K to have enough to get things live with a decent design and cushion for when things go wrong — which they will.

But given your current funding level you probably can’t afford that. So what I’d recommend is finding a ‘technical co-founder’ that you can partner with. The only appropriate thing to do, though, would be to be up front that you don’t have money and are looking for a co-founder — and provide co-founder-level equity participation for their efforts (meaning probably no less than 30% ownership). Otherwise you won’t likely find someone with the level of skill and experience to make this thing work. You have sales experience and the idea, and that’s worth a lot.

But either way, given your current unrealistic expectations regarding cost I don’t think I can in good conscience refer you to contacts of mine as a potential partner. I wouldn’t feel right about it.

Maybe we can get together in a couple weeks and talk about where you are. I’m happy to meet and provide what guidance I can over coffee periodically.

Best of luck,

Posted in career, leanstartup, management, personal_insight | 6 Comments

Basic Introduction to Mysql InnoDB Performance Tuning – What are the best resources?

I used to manage a couple very large MySQL Databases (like, 1TB+). They were huge, unforgiving beasts with an endless appetite to cause me stomach problems.

I read everything I could find on MySQL Performance Tuning and innodb. Here’s a summary of what helped me:

1. The book High Performance MySQL is good, but only gets you so far.

2. The blog MySQL Performance Blog (this link is to their posts tagged ‘innodb’) was the most useful overall resource I found on the net. They go into detail on a lot of innodb tuning issues. It gets ‘ranty’ at times, but overall it’s great. Here’s another link there on InnoDB Performance Optimization Basics that’s good.

3. The last main thing I did to learn it was to simply read the MySQL Docs themselves. I read how every last parameter works, changed them on my server and then did some basic profiling. After a while you figure out what works by running big queries and seeing what happens. Here’s a good place to start:
InnoDB Performance Tuning and Troubleshooting

In the end, it’s just experimenting and working through things until you gain enough knowledge to know what works.

Please share any other ideas, pointers or resources you know of in the comments — Thanks!

Posted in mysql, open source, programming | Tagged , , | 1 Comment

Securing Cloud-Based Ruby on Rails Applications: Why I like Engine Yard.

A customer of mine referred me to an article on Cloud Deployment on Amazon Web Services’ EC2 platform that discussed common security holes users are leaving in their instances. The article, Amazon’s Cloud is Full of Holes, warned that poor practices by AWS users were leaving their applications ripe for attack.

I completely understand the issues behind the story and I agree — it’s much easier to create a new instance on AWS than it is to understand how secure it is. A lot of people have the skills to create instances; fewer have the skills to ensure they’re secure.

This, by the way, is one of the reasons I really like deploying Rails applications on Engine Yard.

When you create an instance on Engine Yard, here are some of the security features you get:

  • It’s impossible to ‘ssh’ directly into a system with a username/password. ‘ssh keys’ are required.
  • You can only connect to the machines as the ‘deploy’ user — not as root or any other user.
  • Once you login, you have sudo access and can swith user to root, but only after you’re on the machine already.
  • To enable ‘ssh’ connection for a particular user, you have to log into the Engine Yard admin panel and upload the user’s public key then specifically authorize them on a particular instance.
  • The apps in the stack (passenger, rails, mysql, postgresql, etc) are run under accounts with restricted access.
  • The database passwords only exist on the instance and are generated random strings.

This isn’t to say that they’re perfect, but I think it does say that a good deal of care has been taken to make sure the instances are secure. Most of the examples in the article were from users who were inexperienced or lacked the knowledge to secure their instances.

I once worked with another customer who deployed their applications using a different (yet commonly used) deployment tool. It created their instances using one of the popular Ubuntu-based AMI’s.

There were a number of security issues with the implementation — primary access to the instances was done using ‘ssh’ with ‘root’ as the login, the database accounts were setup with no passwords, etc. Not that the tool they used didn’t allow these things, but they took extra time to implement and the person who’d set it up hadn’t done so.

Posted in aws-ec2, cloud, code, leanstartup, programming, rails, ruby on rails | Tagged , , , , | 2 Comments

JQuery-UI verus SimpleForm for Rails Forms processing

Recently, I had a conversation with a colleague about using JQuery UI to layout form processing for a Ruby on Rails application. I cautioned them against it.

In general, I’ve found more success using the simple_form library for generating form processing. I’m a huge fan of JQuery itself and use it a lot, but I find JQuery UI to be less valuable. It seems over-engineered for what people use it for.

What I’ve found with JQuery UI sometimes is that people use it because it promises a lot of capability with not very much coding effort. But the challenge comes when there is debugging to do or when you want functionality that is not ‘out of the box’.

I had a customer very recently that brought me in to address some issues getting a complicated form to work on a project that used a lot of JQuery UI components. They had used these components and then tried to extend them because the functionality they wanted wasn’t exactly ‘out of the box’. It ended up being very complicated to debug and it took me close to a day to trace one of the defects back into the JQuery UI component itself — it was placing random extra elements in the DOM on the browser and causing some things to not work.

Debugging complicated JavaScript issues in the browser is more complicated than tracing rails exceptions on the server side.

simple_form, on the other hand, is a much simpler framework to use. Basically the views are very simple and styling and layout is determined through css. If you need any dynamic features on the form you can implement them using straight JQuery — which gives you a wealth of capability. Trying to add JQuery functions on top of JQuery UI components is much more complicated to debug.

Here’s a railscast on ‘simple_form’ – that’s a good place to start. It’s getting to become the most widely accepted way to do form processing for rails.

All this being said, using JQuery UI for to implement components of a view that aren’t related to forms processing may be the best way to go.

Posted in code, jquery, open source, programming, rails, ruby on rails | 2 Comments

How To Get Started with Ruby on Rails — Where should you start?

A friend of mine is beginning an effort to learn Ruby on Rails. He asked me where to start and I sent him a few links that I felt covered some of the key components of Rails that were critical to learn first. Not everyone will agree with my choices, but nevertheless this is what I thought.

I figured I’d share them here since there may be other people around asking the same questions.

These links are references to the ‘guides’ that were developed as documentation by the Rails community. They’re ‘reference guides’, so they’re deeper in places than you’ll need. But I think they’re useful and I refer to them often.

1. Getting Started. To get started, the first thing is to just build a simple app and get it running. This, if nothing else, verifies that you have everything installed correctly and introduces you to the basics of building a rails application.

link: Getting Started with Ruby on Rails.

2. ActiveRecord. The first thing you need to understand with Ruby and Rails is how ActiveRecord works. It’s more than just the interface layer to the database, it’s the foundation of all your ‘Model’ code including data validation and relationships between objects.

Link: Active Record Query Interface

3. Rails routing. Understanding the routing in Rails is something that a lot of beginners miss — and it makes their first applications sub-optimal. Also, understanding the routing rules makes things so much easier. And it’s core to understanding the ‘restful’ concepts behind rails.

Link: Rails: Routing from the outside in.

4. Rendering views. A lot of the magic in rails happens in how easy and flexible it is to build, change and rearrange the actual pages you’re building — the ‘view’ part of the Mode-View-Controller model that Rails is based on. This guide gives you an introduction to how all that works and what the options are. Notice also how it builds on what you learned in ‘Rails Routing’.

Link: Rails Views: Layouts and Rendering.

Don’t get discouraged and don’t underestimate — this is a bit of work. But the value is great.

These guides are build to some extent as ‘reference guides’, so don’t worry about understanding every line. But scan and read some portions deeply — and you’ll come away with a great foundation in what Ruby on Rails is and how it works its magic.

Posted in agile, open source, rails, ruby on rails | 2 Comments

Interview with Eric S. Raymond – “Who Owns Unix?”

[This is a reprint of an interview I did with Eric Raymond a number of years ago that originally appeared in LinuxWorld Magazine (LWM, the initials you see in the article). I was Editor-in-Chief of the magazine at the time. Some of it is a bit dated now, but I think it's valuable in respect to the historical perspective it provides. Eric Raymond is referred to in the article by his initials, 'esr'. -Kevin]

In response to the SCO lawsuit, Eric (with consultant Rob Landley) wrote the “OSI Position Paper on the SCO-vs.-IBM Complaint.” This position paper addresses in detail SCO’s claims of intellectual property ownership over Linux. The paper has been widely read and is considered by many to be the best analysis of the topic available. In short, the paper addresses the question, “Who owns Unix?”.

LWM was able to catch up with Eric on the day of the Novell announcement that SCO did not own the patents or copyrights to Unix.

LWM: In a nutshell, what exactly is SCO trying to do?

esr: What they were trying to do, I think, was shake IBM down for a payoff or a buyout offer. That has blown up in their face, especially now that Novell has made a public statement that all but accuses SCO of lying about the disposition of the IP. But now they have to play this losing hand out to the end – because admitting that they knew they didn’t have a real case to begin with might land their management in jail for fraud and harassment.

LWM: So tell me about the position paper you developed. Why did you and Rob Landley write it?

esr: I was trying to do two things really. One, I was trying to give IBM ammunition. Two, I knew the open source community would have to respond to SCO’s attack sooner or later, and that it would be better if it was sooner – before SCO’s propaganda (if any) had time to take hold.

But part of why I was upset didn’t have anything to do with Linux. I’m actually an old Unix developer – back to 1982. I wasn’t one of the original developers of Unix (though I’ve contributed code to Linux and the BSD Unixes), but I know those guys and they know me. The SCO complaint was insulting. It was SCO claiming that they owned all the code that we wrote – and then using that claim to harm Linux.

LWM: What’s happening with your “No Secrets” effort?

esr: I’m trying to prove that the proprietary Unix vendors don’t have any trade secrets. Right now I have enough people willing to sign affidavits about having uncontrolled read access to Unix source code that I can show there’s been a pervasive failure to enforce even the minimum level of nondisclosure required to maintain trade secrecy. Thousands of people who have seen the Unix source code were never under nondisclosure. This is the kind of evidence that destroys trade-secrecy status.

If SCO continues, I’ll get enough signed affidavits to prove that they have no trade secrets.

This is also an attempt to send a powerful message to potential future litigants: it’s not safe to mess with the open source community because we can bite back.

LWM: And what is IBM’s position on all this?

esr: You’ll have to ask IBM that. I’m their ally in this, not their spokesperson.

LWM: For readers who may be unfamiliar with your work in this area, can you share some of your background with open source and Linux?

esr: I wrote the foundational paper on open source development, ran the meeting where the term “open source” was invented, and have been one of the community’s principal ambassadors to the rest of the world for the last five years. I am the president of the Open Source Initiative, one of the community’s two leading advocacy organizations.

LWM: What is the position of the Open Source Initiative on this issue?

esr: We believe SCO’s claims are utterly without merit. In much of their complaint they seem to be, plainly and simply, lying through their teeth. We have published a detailed rebuttal at [no longer available - ed.]. It looks even stronger than it did in light of Novell publicly announcing that they, not SCO, own the Unix patents.

LWM: So, who owns Unix?

esr: Legally, it’s very unclear. Novell holds the patents. The OpenGroup owns the trademark. The copyrights are in some weird limbo – first Novell came out and said they owned them, but SCO now claims to own them under the terms of Caldera’s deal with Novell and Novell is keeping mum. The one thing we do know is that the transfer of the copyrights (if any) was never recorded with the U.S. Patent and Trademark Office. That has interesting legal implications, and may be the reason SCO hasn’t come out and made an explicit copyright-infringement claim in the lawsuit.

Ethically, OSI’s position is that Unix belongs to the distributed development community that wrote it. SCO’s threats broke the tacit understanding that kept us from asserting this for 30 years. It used to be that we agreed not to fuss over the fact that AT&T or Unix Systems Labs or Novell or SCO were claiming to own the code as long as they agreed not to fuss over the fact that every senior Unix developer had a technically illicit copy of the source code in his hip pocket.

Everybody took code from everybody. AT&T used Berkeley and Xenix code and got called on it during a 1993 lawsuit. Truth is, the rights picture is so tangled that nobody’s theory of ownership would stand close scrutiny of the source code’s history. The law of intellectual property doesn’t handle this kind of situation well. The equitable thing to do would be to just give up, throw it open, and admit it belongs to the hackers.

LWM: What do you see as the potential downside risk for companies using Linux? Will SCO try to sue everybody?

esr: The risk dropped to zero last May 28 with Novell’s announcements. SCO’s response basically admitted they’ve got no grounds to sue anybody but IBM.

SCO have since changed their minds, but I think this is just bluster. Furthermore, the various lawyers I’ve talked with agree that it’s just bluster. When you think you have a strong case in court, you don’t fight it in the media. SCO would scare me worse of they weren’t huffing and puffing.

LWM: If you were a manager in a company considering using Linux for a first project, would this lawsuit impact your decision to give Linux a try?

esr: Not at all. Ignoring the occasional FUD storm is part of the job.

LWM: In your book The Cathedral and the Bazaar you describe the Linux development process as being like a bazaar, where all kinds of people with all kinds of interests are developing different pieces. Is Linux development still that way? How has it changed?

esr: If it has changed, it has changed by becoming more conscious and better organized. I played a part in that by giving people language with which to reflect on what they’re doing.

LWM: What do you think will happen with this suit? Any idea how long it might be before it becomes clear what’s going to happen?

esr: They can’t win, not in front of a judge with any brain cells operating – and the word on His Honor Dale Kimball is that he’s a sharp guy. Timeframe? Who knows. These things can drag on for years.

LWM: How can the Linux community ensure that Linux stays free of IP claims in the future? Can there be a process instituted that ensures this doesn’t happen again?

esr: See my “No Secrets” page for an example of what network activism can do. I’ve collected nearly 100 responses, with at least 40 people willing to sign affidavits. I think we can prove that there are no trade secrets in Linux. I think we can use the same methods to turn up prior art in patents cases.

LWM: Switching gears a bit, in the IBM -v- SCO analysis on the OSI Web site (, you referred to a “seismic shift” occuring right now in the software industry. Can you explain what you meant?

esr: I already have. Readers should go to for the story.

LWM: Will all applications eventually be open sourced? Which kinds might not?

esr: I don’t think it will be all – there are economic circumstances in which closed source makes sense, though they’re not common. I think “most” is a fairly safe bet, though. I’ve discussed this at length in my paper “The Magic Cauldron.”

LWM: What will the software industry look like in five years?

esr: A lot like the legal profession does now, I think. Independent software firms will be like law firms, partnership organizations of professionals. Other programmers will work in-house at corporations the way that corporate lawyers do now. Programmers in general will be operating from a common open source base; secrecy will be a feature mainly of legacy software.

Regarding outsourcing and offshore development – one thing you can’t outsource is getting inside a customer’s mind. You can’t move face-to-face, person-to-person communications and design offshore. You can outsource cookie-cutter code, but I predict a lot of companies are going to discover they’re paying for large portions of code that don’t match their requirements.

One of the things we know is that the most effective ways of writing software involve a series of interactions – a succession of prototypes – using continuous feedback. You can’t do that if your customer’s in Teaneck, New Jersey, and your developers are in Bangalore.

About Eric S. Raymond

Eric S. Raymond is an observer-participant anthropologist in the Internet hacker culture. His research has helped explain the decentralized open source model of software development that has proven so effective in the evolution of the Internet. His own software projects include one of the Internet’s most widely used e-mail transport programs.

Posted in interview, open source, programming | Tagged , , , | 1 Comment

Interview with David Heinemeier Hansson (DHH), Creator of Ruby on Rails.

[This article originally appeared as the cover story Linux Journal Issue #147, published in July of 2006 -- back when I was still just learning Ruby on Rails. -- Kevin Bedell]

Kevin: For our readers who are unfamiliar with Ruby and Rails, can you give us a short description of what they are and what makes them different from other development environments?

DHH: Ruby is a dynamic and object-oriented programming language created in 1995 by Yukihiro Matsumoto. It has been described as a cross between Smalltalk and Perl, but I don’t think that juxtaposition does it justice. Ruby is, more than anything else, a language for writing beautiful code that makes programmers happy.

Rails, then, is an attempt to mold the beauty and productiveness of Ruby into a solution for Web applications. We’ve sought to adhere to the same core principle that guided the development of Ruby: make the programmer happy!

This might all sound mighty fluffy, but only until you recognize that the single-most important factor in programmer productivity is motivation. And, happy programmers are certainly motivated programmers. Thus, if you optimize for happiness, you’re optimizing for motivation, which ultimately leads to an optimization for productivity.

Kevin: What is Rails? Why was it developed?

DHH: Rails is an extraction from a solution to a real problem. It’s not a science project. It’s not something clever men sat down and designed in the highest of ivory towers. It’s simply the generic pieces that were left after I tried to use Ruby to create Basecamp—the Web-based project management system from 37signals.

That means it’s a very pragmatic, very targeted framework with a strong sense of direction. You might not share its vision, but it undeniably has one. I like to call that opinionated software. And Rails sure has a lot of opinions.

From one point of view, it could be said to be the collection of opinions I have about how Web applications should be constructed. Surely you can use Ruby on Rails without sharing all my opinions on how to create Web applications, but the more opinions you share, the less work is put upon you.

And, these opinions are surprisingly simple. They aim to give most people most of what they want, most of the time. It’s a strong disagreement with the conventional wisdom that everything should be configurable, that the framework should be impartial and objective. In my mind, that’s the same as saying that everything should be equally hard.

Kevin: I’ve been reading about Active Record and the ORM (Object-Relational Mapping) capabilitites (or how the application interfaces with databases) that are available using Ruby on Rails. Can you comment on this?

DHH: Active Record has, by many, been called the crown of Rails. Its core mission is to make relational data mesh seamlessly with an object-oriented domain model. And to do so with a minimum of explicit configuration.

So, you’ll have a Person class that’s automatically mapped to a people table (notice the cases and pluralization that Rails automatically figures out). This Person class will then have a first_name method if the people table has a first_name column. So, we’re using reflection and conventions to escape the XML situps that plague frameworks of the old world.

Although the lack of explicit configuration scores high points with the Enterprise crowd used to Hibernate, EJBs and other Java frameworks, it’s the mere notion of ORM that wins big with the PHP/.NET crowd. Active Record relieves you from the vast majority of all SQL writing. It’s automatically constructed on the fly. No more three-line INSERTs, no more repetitive, tedious UPDATEs. The only SQL left is the bottleneck-clearing work where actual brainpower is involved on how to make this query go really fast.

Kevin: For many of our readers to adopt Ruby and Rails (or convince their management to let them), they need real success stories. Where has Ruby and Rails been used to build scalable, production applications?

DHH: Ruby on Rails has been a huge hit inside a lot of organizations. We have some 400 people signed up as working either partially or completely in a Rails-related job. So, like an iceberg, the bulk of the action happens below the surface.

But, we do have a good number of public success stories too. My own company, 37signals, has four widely popular applications used by hundreds of thousands to manage their projects (Basecamp), their personal life (Backpack), their to-do lists (Ta-Da List) and their collaborative writing (Writeboard). That suite has been the number-one poster child for Ruby on Rails and has helped win over a lot of doubters.

But 37signals is by no means the only small team doing big things with Ruby on Rails. The Robot Co-op has a suite of social networks that includes 43things, 43places and 43people. Together, these networks push more than two and a half million dynamic page views a day across their three-machine setup.

Odeo is running Ruby on Rails to power its podcasting portal in front of thousands of subscribers. Evan Williams created Blogger and knows a thing or two about running a huge, public site. He’s at the wheel at Odeo.

Strongspace is just one of several Rails applications in the making from TextDrive. They provide gigabytes of secure hosting in the sky. It’s a really cool and smooth site by the same guys that carry the title of being the official Rails hosting firm.

And, that’s just a small taste. We have major applications in everything from e-commerce to productivity to content—you name it. There are very few kinds of Web applications left that Rails hasn’t been used to create.

Kevin: By the way, I’ve been a Backpack user for a while and I love it. Was it completely developed using Rails?

DHH: Backpack is indeed 100% Ruby on Rails. When it launched, it was a mere 2,000 lines of code.

Kevin: Java had been around for a while before it really penetrated the enterprise. It took the development of J2EE for it to establish itself as a true “enterprise development platform”. The addition of transactional management, flexible deployment strategies and so on seemed required for it to mature into that role. Could you see Ruby and Rails eventually following a similar path, or do you think its role will be something different?

DHH: We have a wide enterprise audience that uses Rails simply because it gets the job done, faster. I think we’ve seen the peak of Java in the enterprise. I’m sensing an understanding that while Java and the J2EE gang certainly has its uses in legacy integration, huge distributed setups that require two-phase commits and so on, it’s way overkill for the majority of applications created in the enterprise.

Dave Thomas from the Pragmatic Programmers recently expressed this as “cracking nuts with a sledgehammer”. Yes, a few special jobs do need sledgehammers. But you don’t need to use it [a sledgehammer] for all the other jobs that need to get done.

That’s why having a company standard on something like Java and J2EE seems so nonsensical. Why would you use the heaviest and slowest machinery to solve the 80% of the business that would rather have its valuable software two, three, five or ten times faster? Or, whatever the multiplier is in your environment. So, keep the big guns in store for that last 20% that actually requires it.

Kevin: Is there anything else you think is important to tell our readers about Ruby and Rails?

DHH: Give it a try! We’ve fought hard to make Ruby on Rails the easiest Web-application framework to try out. Get Ruby, get RubyGems (the apt-get of Ruby libraries), gem install rails, rails my_application, and you have your application skeleton running and ready to produce.

It’s hard to relay in words just how fast and easy it is to get started. So, I would invite your readers to check out the 15-minute video on the Rails Web site where we build a complete, if simple, blogging engine.

Posted in interview, programming, rails, ruby on rails | Tagged , , , | 3 Comments

Open Source Developers Are Rock Stars!

When I was a kid, all I wanted to be was a rock star. I wanted to play guitar, get up on stage, and have everyone scream while I cranked out some hard rockin’ tune. I wanted to see lighters held up in the crowd as I finished my last set – dripping with sweat, completely tired, and no energy left. Leave it all on the stage – that’s what I wanted. My friends all felt the same – we talked about it all the time.

Well, that never happened. Instead I went to college and spent more time in the computer center than I did at parties. The only thing I cranked out was code. Later, I got a job writing software and I’ve been working with computers ever since.

While I still listen to a lot of music and have Gigs of tunes on my iPod, my dreams of being a rock star have faded. I still think about them once in a while, but more than that, I now think about open source. So do a bunch of my friends – we talk about it all the time.

I met a guy at the Softpro computer book store off Route 128 in Burlington, MA, a while ago. (I hang out there now instead of the record shop.) He writes financial applications for a mutual fund company in Boston. All he wanted to talk about was JBoss. He’d spent some time working on the JMS implementation but had gotten too busy to continue. He wanted to get back involved as soon as he could. All those people who were building the latest JBoss – he wanted to be one of them.

In his eyes I saw the same stars I used to have. I used to think that way about Robert Plant and Jimmy Page. I wanted to be one of them. When I was younger, I ran out to buy the latest Led Zeppelin album – now I run out to get the latest build of Gentoo or Hula.

Open source developers are the rock stars of the software world. The parallels actually go pretty far. You can say they don’t get the money and fame, but I think you’re wrong. The average open source developer probably makes more at his or her job than most local musicians make. I’ve met open source developers who have founded software companies and are doing pretty well financially. As far as fame goes, they may not do quite as well as real rock stars but some do pretty well; Linus Torvalds is fairly famous, but I guess not like Kurt Cobain.

They’re also usually the most talented developers. Rock stars get where they are in the music world by being great musicians; open source rock stars get where they are by writing great code.

Naming their projects is a lot like naming their bands. When you hear people talking about Subversion, Ethereal, or Excalibur (all open source projects), it’s hard to tell if they mean software projects or rock bands.

A good friend of mine called me once and went on for 30 minutes about how he was submitting a patch to the Jakarta Struts project (a JSP framework from the Apache Software Foundation). His patch would allow you to define validations for one input field based on the value of some other field (e.g., if you fill in a last name, make sure you fill out a first name…). He was totally excited about it and went into all the details of how he built it.

After he was done telling me about it, he was almost out of breath. I reached in my pocket, pulled out a lighter, and stood there holding it lit in the air.

Leave it all on the stage.

Posted in code, personal_insight, programming | Tagged , , | 7 Comments

BarCamp Boston 6, April 9-10, 2011 Cambridge, MA

Make sure you don’t miss one of the best tech events of the year in the Boston Area: Barcamp Boston 6, April 9-10 in Cambridge, MA.

From the site:

“BarCamp Boston is Boston’s geek unconference, organized on the fly by attendees, for attendees. Visit the website and wiki at There is no registration fee, and all attendees are equal… but you don’t just attend a BarCamp — you can participate in discussions, host a session of your own, or join in another cooperative event (startup founder match, programming contest, design competition, and more…).”

Link:  BarCamp Boston 6 at 1 Memorial Drive, Cambridge, MA – Conferences,seminars on Plancast.

Posted in career, leanstartup, mysql, programming, ruby on rails | Leave a comment

Example code for storing environment-specific configuration variables in rails

Here’s some example code I’ve used for storing configuration variables using Ruby on Rails. This code allows for defaults as well, so you only have to specify variables per environment if they override the default value.

This first file should be put in /lib/app_config.rb.

# This singleton class stores configuration options.
# It makes use of Ruby's method_missing method
# Any option added to the application's config file
# is automatically available as a method of the same name.
class AppConfig
  include Singleton

  # This file is used to set the configuration options for the application.
  CONFIG_FILE = "#{RAILS_ROOT}/config/application.yml"

  def initialize
    @parser =

  def method_missing(methId)
    instance_sym = ("@" + methId.id2name).to_sym
    instance_variable_set(instance_sym, @parser.send(methId)) unless     instance_variable_get(instance_sym)

The above code uses method_missing to create methods on the fly that correspond to different configuration variables. Add the config variable, and it automatically becomes available as a method on the AppConfig singleton class.

You need this class to load and parse the yaml file that the data is stored in. It should be in /lib/yaml_app_config_parser.rb.

# This class parses /config/application.yml
# It supports both default and environment options.
# Environment options override the default options.
class YamlAppConfigParser

  def initialize(yaml_file)
    @yaml = YAML.load_file(yaml_file)

  def method_missing(methId)
    if @yaml[RAILS_ENV] && @yaml[RAILS_ENV][methId.id2name]

The above 2 files you just put in your project and forget about. Then, you just add config values to the /config/application.yml file, and they become available config variables that vary by environment.

Here’s what a basic/config/application.yml might look like.

  facebook_app_id: adsf78yadfkjasdf807y
  facebook_secret: adsf78yadfkjasdf807y
  path_to_file_foo: /mnt/files/

  path_to_file_foo: /User/MyUser/tmp/files/

  facebook_app_id: my_prod_fb_app_id
  facebook_secret: my_prod_secret

Notice that the production environment has its own facebook_app_id and facebook_secret values, while the development environment just uses the default values. That’s how this approach works – you override only what you need.

Now to access these values from your code is simple, you just call:

  @facebook_app_id = AppConfig.instance.facebook_app_id
  @facebook_secret = AppConfig.instance.facebook_secret
  @path_to_file_foo = AppConfig.instance.path_to_file_foo

Then the variables you’ve set as above contain the configuration values specific to their environment.

Posted in code, programming, rails, ruby on rails | Tagged , , | 1 Comment