If my changes worked, this post should have an IntenseDebate-style commenting feature instead of the default one provided by TypePad. You can give it a try or just ignore.

Updated: Testing slight template change

• Tax-Loss Harvesting For An Unsteady Market (Page 2 of 2)
  In summary, tax-loss harvesting is a way investors can take an active role in managing their portfolios with a strategy that is based on opportunity created by tax law, not market speculation. In some cases, after-tax returns could be greatly enhanced, putting the investor well on the road to quicker asset accumulation, so that next time the market turns downward you won't be feeling blue.

I'm super busy with my duties as technical chair and M.C. for the conference and I'm not getting the opportunity to live-blog the Professional Ruby Conference the way I would like to. Luckily Nick Quaranto is doing a great job documenting the proceedings in details here: Professional Ruby Conference Notes

Liana (with baby in tow sometimes) is also doing a great job of documenting the highlights of the sessions.

So far it's been a really great experience. Along with friends and familiar faces, I'm also meeting amazing people from all sorts of backgrounds and it's doing wonders for my reputation (heh!)

The single track, 30-minute format is wonderful and we've gotten ample praise about it. Everyone in the audience gets the same content at the same time and has plenty of opportunities to meet informally and discuss what was presented. We have quite a mix of experience levels in the audience -- keeping the talks short and sweet ensures that no single group is bored for an extended period of time. We've covered the gamut of topical ranges, from pure case study "this is what we did" in the New York Times newsroom to Philippe's detailed explanation of DTrace.

Our Tuesday morning keynoter, Giles Bowkett, canceled at the last minute, so I had to scramble. After some undecidedness, I opted to try a concept that I witnessed last week at Conferencia Rails in Madrid. Sebastian Delmont and I brainstormed the content over single-malts in the hotel bar last night.

Photo credit: Sebastian Delmont

We distributed two pieces of colored paper to each person, which they used to vote on their preferred choice from the two displayed on the screen. After most of the votes, I asked for the audience to chip in with an explanation (and occasionally apology) for their choice.

Photo credit: Sebastian Delmont

I was asked to post the results, so here is my list of the smackdown lineup:

vim vs emacs:  About half of the audience voted, skewed heavily to vim. I didn't want to start a "religious war" so I didn't ask for elaboration.

svn vs. git:  Heavy voting, with fairly even split (perhaps slightly skewed to svn). Will from

jQuery vs. Prototype  Apparently when I introduced this lineup I said "...still using Prototype" which I apologize for, since it was leading the audience and it got a laugh. I've been a fan of Prototype for a long time, but Hashrocket as a whole has switched over to jQuery in the last 6 months.

Chad Pytel told us that he's still using Prototype on existing projects because it doesn't make sense to switch over, essentially "if it's broke don't fix it".

Sinatra vs. Camping  A few people in the back of the room voted for Sinatra. Matt Bauer told us that it's good for very small standalone web apps and yes, it's ready for production-use.

Blueprint vs. YUI  About half the audience voted, skewed towards Blueprint. Someone pointed out that the 960 Grid System is cool, and then we spent at least 30 seconds trying to figure out the name and URL.

MySQL vs. Postgres  Heavy vote for MySQL. Consensus appears to be that if you come from big enterprise databases then you're going to prefer Postgres. Also, Postgres is more standards-compliant and

blank? vs. empty?  This one was a joke (pretty much) that Sebastian and I included in the smackdown to remind the audience to consider the semantic meaning of API methods. The correct vote would have been for both, since they are not used for the same purpose. The blank? method is for strings and returns true for strings consisting of purely space characters. The empty? method is primarily meant for arrays, but works on strings and returns false for strings consisting of purely space characters.

attachment_fu vs. paperclip  Evenly split audience, but consensus was that Paperclip is better than attachment_fu in terms of features and flexibility and its implementation code is very clean and easy to figure out. Also, paperclip allows for attaching more than one file to a single model.

system gems vs. frozen gems  Frozen gems won hands-down. Bryan Liles said that if anyone thinks system gems is the way to go then obviously they aren't doing production deployment. Sebastian chimed in that using system gems saves 10 seconds on his deploy time, which everyone took as a joke. Not sure if he meant it seriously. :)

Vlad vs. Capistrano  A handful of people voted for Vlad, but otherwise the audience favored Capistrano heavily. I asked Matt Bauer to defend Vlad. He mentioned some reasons about its simplicity and how bad early versions of Capistrano were, but in the end he said it's not worth switching at this point because the pain-points of Capistrano have been resolved.

Mocha vs. Flexmock  Mike Schwab was the only person who voted for Flexmock, but wasn't really able to defend the choice except to tell us that Chad Fowler and Marcel Molina suggested it once at a conference. (Comments welcome -- Is this reason still valid? Was it ever?)

FactoryGirl vs. ObjectDaddy  Not too many people voted and those that did went for FactoryGirl. Earlier in the conference we heard from the testing panel that ObjectDaddy has way too much magic to be useful.

resource_controller vs. make_resourceful  A couple of people voted for each. Got the impression that the audience was largely unfamiliar with these great plugins, so I asked Joe Fiorini to explain them. Bottom line, if you're writing your apps in a RESTful manner then you should check out and use one of these libraries because it'll spare you a bunch of boilerplate code.

HAML vs. ERB  One of my favorite topics! The split was maybe 33% HAML with surprisingly heavy voting. The reasons for sticking with ERB? Mostly to keep designers happy or based on what I detect as a resistance to change. I gave my typical impassioned explanation of how HAML lessens the amount of mental mapping needed to effectively think of your views as semantic markup and match them to your CSS.

Bluecloth vs. Redcloth  Meh...

RMagick vs. ImageScience  Meh...

TinyMCE vs. FCKEditor  Rich-text editor widgets in Javascript. They're not that different from each other and the audience was all like, "Meh.." :)

restful_authentication vs. clearance  This one was funny. A handful of votes went up for Clearance, which disturbed its author, Chad Pytel. He stood up and told us not to use it since it's not ready. The offshoot of Github's popularity, is that once public projects go up, they start getting used -- whether they're ready or not. :)

Test::Unit vs. RSpec  I was pretty much out of time at this point, so I skipped a bunch of slides to this matchup. Even distribution and some confusion about whether Shoulda belongs to TestUnit (yes) or RSpec. I think the consensus is that it doesn't matter as long as you're putting some effort into testing. I wondered to myself if the people that didn't vote weren't doing any testing. Things that make you go "hmm..."

If you're so inclined, take a moment to tell me your vote for the following smackdown matchups that I didn't have time to get to in the session...

Mongrel vs. Passenger

Sphinx vs. SOLR

ThinkingSphinx vs. UltraSphinx

exception_noti???er vs. hoptoad

Gruff vs. Google Charts

CouchDB vs. SimpleDB

I'm super busy with my duties as technical chair and M.C. for the conference and I'm not getting the opportunity to live-blog the Professional Ruby Conference the way I would like to. Luckily Nick Quaranto is doing a great job documenting the proceedings in details here: Professional Ruby Conference Notes

Liana (with baby in tow sometimes) is also doing a great job of documenting the highlights of the sessions.

So far it's been a really great experience. Along with friends and familiar faces, I'm also meeting amazing people from all sorts of backgrounds and it's doing wonders for my reputation (heh!)

The single track, 30-minute format is wonderful and we've gotten ample praise about it. Everyone in the audience gets the same content at the same time and has plenty of opportunities to meet informally and discuss what was presented. We have quite a mix of experience levels in the audience -- keeping the talks short and sweet ensures that no single group is bored for an extended period of time. We've covered the gamut of topical ranges, from pure case study "this is what we did" in the New York Times newsroom to Philippe's detailed explanation of DTrace.

Our Tuesday morning keynoter, Giles Bowkett, canceled at the last minute, so I had to scramble. After some undecidedness, I opted to try a concept that I witnessed last week at Conferencia Rails in Madrid. Sebastian Delmont and I brainstormed the content over single-malts in the hotel bar last night.

Photo credit: Sebastian Delmont

We distributed two pieces of colored paper to each person, which they used to vote on their preferred choice from the two displayed on the screen. After most of the votes, I asked for the audience to chip in with an explanation (and occasionally apology) for their choice.

Photo credit: Sebastian Delmont

I was asked to post the results, so here is my list of the smackdown lineup:

vim vs emacs:  About half of the audience voted, skewed heavily to vim. I didn't want to start a "religious war" so I didn't ask for elaboration.

svn vs. git:  Heavy voting, with fairly even split (perhaps slightly skewed to svn). Will from

jQuery vs. Prototype  Apparently when I introduced this lineup I said "...still using Prototype" which I apologize for, since it was leading the audience and it got a laugh. I've been a fan of Prototype for a long time, but Hashrocket as a whole has switched over to jQuery in the last 6 months.

Chad Pytel told us that he's still using Prototype on existing projects because it doesn't make sense to switch over, essentially "if it's broke don't fix it".

Sinatra vs. Camping  A few people in the back of the room voted for Sinatra. Matt Bauer told us that it's good for very small standalone web apps and yes, it's ready for production-use.

Blueprint vs. YUI  About half the audience voted, skewed towards Blueprint. Someone pointed out that the 960 Grid System is cool, and then we spent at least 30 seconds trying to figure out the name and URL.

MySQL vs. Postgres  Heavy vote for MySQL. Consensus appears to be that if you come from big enterprise databases then you're going to prefer Postgres. Also, Postgres is more standards-compliant and

blank? vs. empty?  This one was a joke (pretty much) that Sebastian and I included in the smackdown to remind the audience to consider the semantic meaning of API methods. The correct vote would have been for both, since they are not used for the same purpose. The blank? method is for strings and returns true for strings consisting of purely space characters. The empty? method is primarily meant for arrays, but works on strings and returns false for strings consisting of purely space characters.

attachment_fu vs. paperclip  Evenly split audience, but consensus was that Paperclip is better than attachment_fu in terms of features and flexibility and its implementation code is very clean and easy to figure out. Also, paperclip allows for attaching more than one file to a single model.

system gems vs. frozen gems  Frozen gems won hands-down. Bryan Liles said that if anyone thinks system gems is the way to go then obviously they aren't doing production deployment. Sebastian chimed in that using system gems saves 10 seconds on his deploy time, which everyone took as a joke. Not sure if he meant it seriously. :)

Vlad vs. Capistrano  A handful of people voted for Vlad, but otherwise the audience favored Capistrano heavily. I asked Matt Bauer to defend Vlad. He mentioned some reasons about its simplicity and how bad early versions of Capistrano were, but in the end he said it's not worth switching at this point because the pain-points of Capistrano have been resolved.

Mocha vs. Flexmock  Mike Schwab was the only person who voted for Flexmock, but wasn't really able to defend the choice except to tell us that Chad Fowler and Marcel Molina suggested it once at a conference. (Comments welcome -- Is this reason still valid? Was it ever?)

FactoryGirl vs. ObjectDaddy  Not too many people voted and those that did went for FactoryGirl. Earlier in the conference we heard from the testing panel that ObjectDaddy has way too much magic to be useful.

resource_controller vs. make_resourceful  A couple of people voted for each. Got the impression that the audience was largely unfamiliar with these great plugins, so I asked Joe Fiorini to explain them. Bottom line, if you're writing your apps in a RESTful manner then you should check out and use one of these libraries because it'll spare you a bunch of boilerplate code.

HAML vs. ERB  One of my favorite topics! The split was maybe 33% HAML with surprisingly heavy voting. The reasons for sticking with ERB? Mostly to keep designers happy or based on what I detect as a resistance to change. I gave my typical impassioned explanation of how HAML lessens the amount of mental mapping needed to effectively think of your views as semantic markup and match them to your CSS.

Bluecloth vs. Redcloth  Meh...

RMagick vs. ImageScience  Meh...

TinyMCE vs. FCKEditor  Rich-text editor widgets in Javascript. They're not that different from each other and the audience was all like, "Meh.." :)

restful_authentication vs. clearance  This one was funny. A handful of votes went up for Clearance, which disturbed its author, Chad Pytel. He stood up and told us not to use it since it's not ready. The offshoot of Github's popularity, is that once public projects go up, they start getting used -- whether they're ready or not. :)

Test::Unit vs. RSpec  I was pretty much out of time at this point, so I skipped a bunch of slides to this matchup. Even distribution and some confusion about whether Shoulda belongs to TestUnit (yes) or RSpec. I think the consensus is that it doesn't matter as long as you're putting some effort into testing. I wondered to myself if the people that didn't vote weren't doing any testing. Things that make you go "hmm..."

If you're so inclined, take a moment to tell me your vote for the following smackdown matchups that I didn't have time to get to in the session...

Mongrel vs. Passenger

Sphinx vs. SOLR

ThinkingSphinx vs. UltraSphinx

exception_noti���er vs. hoptoad

Gruff vs. Google Charts

CouchDB vs. SimpleDB

• Polite in Public
  Interesting and fun concept in event photography. They come and setup a special "photobooth" with lots of bright colors. They also bring along costumes and props. Considering them for upcoming conferences.

This commentary about Palin was just too good to pass up (font emphasis mine):

Is there any way to break through and talk sense to those 46% of Americans or are they irredemable idiots? Depressing.

• Monroe Residence Club
  For next time I stay in San Francisco for a week or more. (Doesn't happen often, but oh well.)

In the months since delivering my Hustle talk at RubyFringe at least a few dozen people have emailed me asking for a copy of Hashrocket's Master Services Agreement (MSA). I consider it a competitive advantage to use a strong MSA and I'm not inclined to just give that document to anyone. However, based on the obvious interest level, I think it's worthwhile to discuss what goes into an MSA so that you can craft one for yourself with the help of your own legal counsel.

This is the first post in a probably-long series where I will go section by section into what I believe constitutes a strong MSA that protects the vital interests of both parties to a software consulting relationship.The intended audience of this series is people running their own Rails consultancies or working as independent contractors, although of course you could generalize the principles given in the series to software consultancy in general.

Why am I doing this? I strongly believe that it's good for the community to base their contracts on terms that are favorable to both parties while protecting consultants from abuse. I've found that the majority of clients act in good faith at all times, but ocassionally you will run into problems that send you scrambling for legal advice. The proper time to worry about whether your interests are protected are prior to entering into a contract, not when you run into trouble.

Just to be clear, I stress the following: I am not a lawyer and strongly advise you to engage your own legal counsel in a dialogue about the use of an MSA and how it specifically applies to your business, especially in countries other than the USA.

An MSA document lays the contractual groundwork for a consulting relationship that is expected to last for more than one engagement. You don't go ahead and do work based solely on an MSA; it requires addendum documents in the form of "Statement of Work" (SOW) exhibits that define the scope and term of a particular engagement. I prefer so-called "Time and Materials" (T&M) engagements, and with a good MSA you can usually fit your SOW onto one page. (Fixed-bid or scope-based SOWs will generally need to be quite a bit longer than one page, since they must detail the scope on which agreement is based. I'll go into the topic of SOWs in detail later in the series.)

As I mentioned in my Hustle talk, once you have a signed MSA in hand, you have created a client relationship where before there was none. And once you're in a client relationship, in my opinion you are in a much friendlier and more cooperative situation for negotiating contractual work. Later, the benefits of an MSA really start to shine brightly as you gain the client's trust and negotiate follow-on work, since they allow you to keep your SOWs small and easy to understand for all parties.

That said, let's proceed with how an MSA document is structured. I'll leave references to Hashrocket in place, but fields that should be filled for each client are identified like [this].

The MSA document should be drafted on company letterhead, so the first item on the first page is your company logo, followed by the title MASTER SERVICES AGREEMENT.

The first paragraph identifies the document and a few key terms, as follows:

This Master Services Agreement (???Agreement???) dated [date of the agreement] is made between Hashrocket, Inc., a Florida corporation with its principal place of business at 60 Ocean Boulevard, Suite 11, Atlantic Beach FL, 32233 (???Hashrocket???) and [Client Company Name] a [State] [company type, i.e. LLC], having offices at [Address] (???Client???).

Simple enough so far. The next few paragraphs go under a heading of RECITALS:

RECITALS

WHEREAS, Hashrocket is in the business of computer software consulting and development services.

WHEREAS, Client desires to engage Hashrocket to provide software consulting and development services, and Hashrocket agrees to perform such services, on the terms and conditions set forth herein.

WHEREAS, Hashrocket and Client agree that this Agreement shall apply to all such future services.

Again, simple stuff, although we start getting into some legalese with this "whereas" stuff. The terminology "Computer software consulting and development services" is probably something that you should think about customizing to communicate exactly what you see your firm as providing.

Finally, you finish off with a paragraph under the heading of AGREEMENT, where the legalese starts to get a bit heavier:

AGREEMENT

THEREFORE, in consideration of the mutual covenants contained herein and other good and valuable consideration, the receipt and sufficiency of which is hereby acknowledged, the parties agree as follows:

As I said before, the MSA doesn't specify the work to be performed, that's what SOW documents are for. Therefore, Section 1 lays out the rules for describing the services in SOW documents. Since the identity of your client is established in the beginning of the preamble, it is sufficient to refer to them as Client in the rest of the document.

Hashrocket agrees to perform services for Client as described in one or more Statements of Work, the form of which is attached hereto as Exhibit A (the ???Services???). Any conflict or inconsistency between the provisions of this Agreement and any executed Statement of Work shall be resolved by giving precedence to the executed Statement of Work under which the Services are to be performed and then to this Agreement.

Note that precedence is given to the SOW over the MSA. The reason is that the MSA is considered the more general document. Although you'll put information in it about things like invoicing and payment schedules, there are usually items in the SOW that are more specific or outright changes from the general rules of the MSA.

That's it for now. If you're not already subscribed to my blog, now might be a good time to do so. I will publish the remainder of the series over the course of the next couple of months.

One of the promises of our new President-elect Obama is to establish a role of CTO in his new administration. A lot of blogger and media attention has focused on potential candidates for this position, among them Eric Schmidt of Google and Lawrence Lessig of Creative Commons. However, I think it is more important at this point to participate in a dialogue about the initiatives that will be tackled by our new CTO.

ObamaCTO.org (built on the UserVoice platform) was launched yesterday and garnered a bunch of attention on Twitter and the likes of Dan Farber, BoingBoing and the New York Times Bits Blog. I created two priority entries:

1. encourage adoption of Agile software development practices
2. standardize on Ruby on Rails for custom web app development

The first one about adoption of Agile is totally serious and I believe it's one of the only ways to reduce costs and improve effectiveness and success rates of government-sponsored IT projects. For example, the Department of Homeland Security (DHS) Directorate of Science and Technology has an annual budget of $830 million. It has 250 projects in process and 50 percent of them are expected to fail, according to Jay Cohen, Under Secretary for Science and Technology for the DHS.

Breaking that status quo is going to be a ridiculous challenge and will require radical and idealistic thinking from the top.

The second priority suggestion, to "standardize on Ruby on Rails" is just one of my (unabashedly self-serving) pet causes that I'm not 100% serious about, but I think merits some debate. Does it make sense for the government to standardize on any particular technology? My fear is that the normal way that government agencies go about making technology decisions is skewed towards big vendors with money and influence and without a degree of activism on our part, projects will continue to be based on proprietary and brain-dead old technology.

By the way, the Obama transition team also announced its internet outreach staff yesterday, but as far as I can tell everyone named so far comes from the existing group of insiders already involved with Obama via campaign operations. I will be much happier if/when I begin to see Web 2.0 thought-leaders such as Lawrence Lessig drafted for those jobs. Frankly, I'm still somewhat dazzled that Obama actually won and that we're having this conversation with any degree of seriousness.

This commentary about Palin was just too good to pass up (font emphasis mine):

Is there any way to break through and talk sense to those 46% of Americans or are they irredemable idiots? Depressing.

One of the promises of our new President-elect Obama is to establish a role of CTO in his new administration. A lot of blogger and media attention has focused on potential candidates for this position, among them Eric Schmidt of Google and Lawrence Lessig of Creative Commons. However, I think it is more important at this point to participate in a dialogue about the initiatives that will be tackled by our new CTO.

ObamaCTO.org (built on the UserVoice platform) was launched yesterday and garnered a bunch of attention on Twitter and the likes of Dan Farber, BoingBoing and the New York Times Bits Blog. I created two priority entries:

1. encourage adoption of Agile software development practices
2. standardize on Ruby on Rails for custom web app development

The first one about adoption of Agile is totally serious and I believe it's one of the only ways to reduce costs and improve effectiveness and success rates of government-sponsored IT projects. For example, the Department of Homeland Security (DHS) Directorate of Science and Technology has an annual budget of $830 million. It has 250 projects in process and 50 percent of them are expected to fail, according to Jay Cohen, Under Secretary for Science and Technology for the DHS.

Breaking that status quo is going to be a ridiculous challenge and will require radical and idealistic thinking from the top.

The second priority suggestion, to "standardize on Ruby on Rails" is just one of my (unabashedly self-serving) pet causes that I'm not 100% serious about, but I think merits some debate. Does it make sense for the government to standardize on any particular technology? My fear is that the normal way that government agencies go about making technology decisions is skewed towards big vendors with money and influence and without a degree of activism on our part, projects will continue to be based on proprietary and brain-dead old technology.

By the way, the Obama transition team also announced its internet outreach staff yesterday, but as far as I can tell everyone named so far comes from the existing group of insiders already involved with Obama via campaign operations. I will be much happier if/when I begin to see Web 2.0 thought-leaders such as Lawrence Lessig drafted for those jobs. Frankly, I'm still somewhat dazzled that Obama actually won and that we're having this conversation with any degree of seriousness.

Here's a quick list of my favorites parts of the conference...

• The Brazilian (and Argentinian) "Raileros"... Simply awesome and super-enthusiastic bunch of people and I was so glad to be part of their special conference.
• The reception that my keynote talk about the "Hashrocket Way" got. I had a ton of attendees tell me afterward that they were very excited about adopting some of our Agile techniques and practices in their own operations.
• Pounding the tables, clapping and singing "We Will Rock You" along with what felt like another 100 conference attendees packed into a sushi restaurant in downtown Sao Paolo.
• Getting to spend quality time getting to know Dr. Nic and Chad Fowler, whoops I mean Chad Erik
• The look on my lovely Desi's face when she saw my presentation slide promoting DevChix at the end of the keynote. :)

I'm going to give this talk again this year, so I'm not posting the slides (which were mostly pics of the Hashrocket crew anyway). My 60 minute talk spanned the range of Agile practices that we use at Hashrocket, organized by the principles of the Agile Manifesto.

Individuals and interactions over processes and tools.

Among several other core practices, Hashrocket is a pair-programming shop primarily because we believe that pairing is a key way of emphasizing and leveraging the productivity of our people in effective ways. I spent a lot of time explaining how pairing works and its benefits.

Working software over comprehensive documentation

As Bryan says, "Test all the f*cking time!" There are other ways to put this principle into practice too, having to do with the test technology that we use.

Customer Collaboration over contract negotiation

Onsite customer is important, and our location on the beach in Florida plays into our ability to attract people to come work at our office. I also introduced some ideas about visual design, and when you should do design work on a project, that isn't necessarily what you would expect from a believer in extreme programming.

Responding to change over following a plan

I showed off Pivotal Tracker and spoke about how we use it. I also talked about the importance of standup meetings and how to do those effectively.

I can't recommend Pivotal Tracker enough for Agile teams. You should go sign up and try it for free.

It's hard to believe, but the US presidential election is only 14 days away, which means that the Addison-Wesley Professional Ruby conference is coming up in less than 4 weeks. Continuing my series about the conference, I'm going to blog about some of the speakers I have lined up for you. First up are a few guys that I highly respect, am lucky to count as friends and unflinchingly call "Rails Heroes" because of their longstanding contributions to the Ruby world.

Ezra is famous for being the creator of Merb and founder of Rails hosting superheroes Engine Yard. He is a production systems expert and widely acclaimed speaker within the Ruby on Rails world.

Ezra's talk will explore the history and current state of the art in deploying and maintaining scalable Ruby applications. Over the last four years we've gone through countless web servers and deployment scenarios on the path to the ultimate deployment environment. Ezra will do a brief history of where we've been, where we are now, and where we are headed for the future, including his groundbreaking ideas with regards to backend messaging design and a world of services pattern.

Josh is without a doubt one of the most beloved characters in the Ruby scene. His blog has_many :through boasts over 8000 readers and he is a key player for Rails powerhouse Pivotal Labs, for whom he is spearheading an expansion into New York City.

Josh will be premiering a special talk titled "Ruby: Fragile or Agile". As a former Smalltalker, Josh lived through the experience of C++ eating Smalltalk's lunch, and will tell us what we should be on the lookout for as Rubyists so that the same thing doesn't happen to us. He will broach vital topics about the disciplines we need to exercise in using Ruby so that it can take over the Agile mindshare from mainstream languages.

Matt's firm, Eastmedia, was one of the earliest professional design agencies to do heavy Rails work, including the first Ruby on Rails-based implementation of OpenID for Verisign and the official site of NFL football team The New York Jets. He gave me plenty of technical review help and contributed the production deployment chapter to The Rails Way, for which his name graces the cover of my book.

Matt is also very good friends with Zed Shaw and was the primary author of our book about Mongrel. His talk at the conference will show you why Mongrel is still relevant, how it works, how it fits into your deployment stack, and how it can be easily extended to serve custom requirements. You can get a taste of the subject matter in this InfoQ interview that I recorded with them last year.

It's hard to believe, but the US presidential election is only 14 days away, which means that the Addison-Wesley Professional Ruby conference is coming up in less than 4 weeks. Continuing my series about the conference, I'm going to blog about some of the speakers I have lined up for you. First up are a few guys that I highly respect, am lucky to count as friends and unflinchingly call "Rails Heroes" because of their longstanding contributions to the Ruby world.

Ezra is famous for being the creator of Merb and founder of Rails hosting superheroes Engine Yard. He is a production systems expert and widely acclaimed speaker within the Ruby on Rails world.

Ezra's talk will explore the history and current state of the art in deploying and maintaining scalable Ruby applications. Over the last four years we've gone through countless web servers and deployment scenarios on the path to the ultimate deployment environment. Ezra will do a brief history of where we've been, where we are now, and where we are headed for the future, including his groundbreaking ideas with regards to backend messaging design and a world of services pattern.

Josh is without a doubt one of the most beloved characters in the Ruby scene. His blog has_many :through boasts over 8000 readers and he is a key player for Rails powerhouse Pivotal Labs, for whom he is spearheading an expansion into New York City.

Josh will be premiering a special talk titled "Ruby: Fragile or Agile". As a former Smalltalker, Josh lived through the experience of C++ eating Smalltalk's lunch, and will tell us what we should be on the lookout for as Rubyists so that the same thing doesn't happen to us. He will broach vital topics about the disciplines we need to exercise in using Ruby so that it can take over the Agile mindshare from mainstream languages.

Matt's firm, Eastmedia, was one of the earliest professional design agencies to do heavy Rails work, including the first Ruby on Rails-based implementation of OpenID for Verisign and the official site of NFL football team The New York Jets. He gave me plenty of technical review help and contributed the production deployment chapter to The Rails Way, for which his name graces the cover of my book.

Matt is also very good friends with Zed Shaw and was the primary author of our book about Mongrel. His talk at the conference will show you why Mongrel is still relevant, how it works, how it fits into your deployment stack, and how it can be easily extended to serve custom requirements. You can get a taste of the subject matter in this InfoQ interview that I recorded with them last year.

Here's a quick list of my favorites parts of the conference...

• The Brazilian (and Argentinian) "Raileros"... Simply awesome and super-enthusiastic bunch of people and I was so glad to be part of their special conference.
• The reception that my keynote talk about the "Hashrocket Way" got. I had a ton of attendees tell me afterward that they were very excited about adopting some of our Agile techniques and practices in their own operations.
• Pounding the tables, clapping and singing "We Will Rock You" along with what felt like another 100 conference attendees packed into a sushi restaurant in downtown Sao Paolo.
• Getting to spend quality time getting to know Dr. Nic and Chad Fowler, whoops I mean Chad Erik
• The look on my lovely Desi's face when she saw my presentation slide promoting DevChix at the end of the keynote. :)

I'm going to give this talk again this year, so I'm not posting the slides (which were mostly pics of the Hashrocket crew anyway). My 60 minute talk spanned the range of Agile practices that we use at Hashrocket, organized by the principles of the Agile Manifesto.

Individuals and interactions over processes and tools.

Among several other core practices, Hashrocket is a pair-programming shop primarily because we believe that pairing is a key way of emphasizing and leveraging the productivity of our people in effective ways. I spent a lot of time explaining how pairing works and its benefits.

Working software over comprehensive documentation

As Bryan says, "Test all the f*cking time!" There are other ways to put this principle into practice too, having to do with the test technology that we use.

Customer Collaboration over contract negotiation

Onsite customer is important, and our location on the beach in Florida plays into our ability to attract people to come work at our office. I also introduced some ideas about visual design, and when you should do design work on a project, that isn't necessarily what you would expect from a believer in extreme programming.

Responding to change over following a plan

I showed off Pivotal Tracker and spoke about how we use it. I also talked about the importance of standup meetings and how to do those effectively.

I can't recommend Pivotal Tracker enough for Agile teams. You should go sign up and try it for free.

• YouTube Video Download Tool
  Recommended to me by Chad Fowler when I asked him how he put so many videos into his Rails Summit keynote.

• The Chris O Show: A peek at the inner workings of Hashrocket
  Recently the folk over at Hashrocket had another one of their famed 3-2-1 Launches - this time inviting as guest stars Tammer Saleh and Joe Ferris of another renowned Rails shop Thoughtbot.

The following two sections of our Master Services Agreement establishes who (as in, a specific person) is responsible for managing the relationship on behalf of your client. This is a critically-important bit of information to establish on a contractual basis when more than one stakeholder is involved in decision-making. Once the work has begun, make sure that important decisions are communicated back and forth through this person.

The Client's Representative should be a party to all important decisions and project communications. If they are not directly the person involved in a decision or communicating it to you, make sure they are at least CC'd (assuming email). These clauses are your protection from accusations of having acted in a reckless or otherwise unauthorized manner.

Make sure to make an amendment to the agreement if the identity of the Client's Representative changes during the term of the agreement. At no point in time do you want it to become vague or unclear who it is that should be giving you definitive directions.

I'm working on another installment of the MSA series, but in the meantime I took a break and did the following silly blog meme.

Via Marc Fleury

1.Take a picture of yourself right now.
2. Don’t change your clothes, don’t fix your hair…just take a picture. (should be super-easy with Photobooth)
3. Post that picture with NO editing.
4 Post these instructions with your picture. 

• “Why Don’t You Do Some Work?” | The Home of Peter Shankman - Shankman.com
  Holy crap, this guy is my hero!

As Dan Croak of Thoughtbot pointed out in the comments of my last post, there's also one major attraction to the Professional Ruby Conference that I didn't mention: Boston

The conference is at a killer location at the Sheraton downtown. It's right in the center of action, is close to a ton of great stuff in a great city. Boston's extremely walkable, and the subway is cheap ($1.25 a ride). Even cabs aren't bad because the city is so compact.

I'll be there and willing to play hometown host to any visitors looking to experience the city. Looking forward to this conference a lot.

Register now for Voices That Matter: Professional Ruby Conference and use discount code PRNOBIE for a $200 discount!

In the months since delivering my Hustle talk at RubyFringe at least a few dozen people have emailed me asking for a copy of Hashrocket's Master Services Agreement (MSA). I consider it a competitive advantage to use a strong MSA and I'm not inclined to just give that document to anyone. However, based on the obvious interest level, I think it's worthwhile to discuss what goes into an MSA so that you can craft one for yourself with the help of your own legal counsel.

This is the first post in a probably-long series where I will go section by section into what I believe constitutes a strong MSA that protects the vital interests of both parties to a software consulting relationship.The intended audience of this series is people running their own Rails consultancies or working as independent contractors, although of course you could generalize the principles given in the series to software consultancy in general.

Why am I doing this? I strongly believe that it's good for the community to base their contracts on terms that are favorable to both parties while protecting consultants from abuse. I've found that the majority of clients act in good faith at all times, but ocassionally you will run into problems that send you scrambling for legal advice. The proper time to worry about whether your interests are protected are prior to entering into a contract, not when you run into trouble.

Just to be clear, I stress the following: I am not a lawyer and strongly advise you to engage your own legal counsel in a dialogue about the use of an MSA and how it specifically applies to your business, especially in countries other than the USA.

An MSA document lays the contractual groundwork for a consulting relationship that is expected to last for more than one engagement. You don't go ahead and do work based solely on an MSA; it requires addendum documents in the form of "Statement of Work" (SOW) exhibits that define the scope and term of a particular engagement. I prefer so-called "Time and Materials" (T&M) engagements, and with a good MSA you can usually fit your SOW onto one page. (Fixed-bid or scope-based SOWs will generally need to be quite a bit longer than one page, since they must detail the scope on which agreement is based. I'll go into the topic of SOWs in detail later in the series.)

As I mentioned in my Hustle talk, once you have a signed MSA in hand, you have created a client relationship where before there was none. And once you're in a client relationship, in my opinion you are in a much friendlier and more cooperative situation for negotiating contractual work. Later, the benefits of an MSA really start to shine brightly as you gain the client's trust and negotiate follow-on work, since they allow you to keep your SOWs small and easy to understand for all parties.

That said, let's proceed with how an MSA document is structured. I'll leave references to Hashrocket in place, but fields that should be filled for each client are identified like [this].

The MSA document should be drafted on company letterhead, so the first item on the first page is your company logo, followed by the title MASTER SERVICES AGREEMENT.

The first paragraph identifies the document and a few key terms, as follows:

This Master Services Agreement (“Agreement”) dated [date of the agreement] is made between Hashrocket, Inc., a Florida corporation with its principal place of business at 60 Ocean Boulevard, Suite 11, Atlantic Beach FL, 32233 (“Hashrocket”) and [Client Company Name] a [State] [company type, i.e. LLC], having offices at [Address] (“Client”).

Simple enough so far. The next few paragraphs go under a heading of RECITALS:

RECITALS

WHEREAS, Hashrocket is in the business of computer software consulting and development services.

WHEREAS, Client desires to engage Hashrocket to provide software consulting and development services, and Hashrocket agrees to perform such services, on the terms and conditions set forth herein.

WHEREAS, Hashrocket and Client agree that this Agreement shall apply to all such future services.

Again, simple stuff, although we start getting into some legalese with this "whereas" stuff. The terminology "Computer software consulting and development services" is probably something that you should think about customizing to communicate exactly what you see your firm as providing.

Finally, you finish off with a paragraph under the heading of AGREEMENT, where the legalese starts to get a bit heavier:

AGREEMENT

THEREFORE, in consideration of the mutual covenants contained herein and other good and valuable consideration, the receipt and sufficiency of which is hereby acknowledged, the parties agree as follows:

As I said before, the MSA doesn't specify the work to be performed, that's what SOW documents are for. Therefore, Section 1 lays out the rules for describing the services in SOW documents. Since the identity of your client is established in the beginning of the preamble, it is sufficient to refer to them as Client in the rest of the document.

Hashrocket agrees to perform services for Client as described in one or more Statements of Work, the form of which is attached hereto as Exhibit A (the “Services”). Any conflict or inconsistency between the provisions of this Agreement and any executed Statement of Work shall be resolved by giving precedence to the executed Statement of Work under which the Services are to be performed and then to this Agreement.

Note that precedence is given to the SOW over the MSA. The reason is that the MSA is considered the more general document. Although you'll put information in it about things like invoicing and payment schedules, there are usually items in the SOW that are more specific or outright changes from the general rules of the MSA.

That's it for now. If you're not already subscribed to my blog, now might be a good time to do so. I will publish the remainder of the series over the course of the next couple of months.

I heard the song quoted below on my drive into work the other day, and it crystallized one of the key philosophies behind the way I run Hashrocket.

That philosophy is love every minute of every day. I have plenty of stress in my job, keeping business flowing smoothly and making clients happy. The key is to enjoy it, even when it's difficult. Knowing that it's worthwhile, that I'm building something special is very important.

I told Durran about wanting to write this blog post, and he rolled his eyes. It's corny, I know. Still, it's so true and goes beyond "work hard, play hard". Just because the work is hard doesn't mean it can't be fun also, and if you're working the right way you should be able to love it too.

The spot.us team during storycarding. (Desi, JB, David Cohn, and Lark)

• First look at Spot.Us in Action « “Community Funded Reporting” Spot.Us
  This blog post is by David Cohn, founder of non-profit startup Spot.Us, and client of Hashrocket. It has a video that David captured of our demo after completion of our 3-2-1 Launch "sprint", which are the first three days of development on a project. Really gives you a sense of what Hashrocket can accomplish with a good client and a great site design.

• Kiss of Death – Contract Provisions Entrepreneurs Should Avoid at All Costs | infoChachkie
  Really great advice about contract terms and negotiation

Antonio's post about good job listings reminded me that I promised to keep up with the comment thread on my blog post about open developer positions at Hashrocket. Just wanted to make a quick blog post to let readers know that I replied to a number of comments this morning, including salary range information.

Also, for the record, the company supplies 30" Apple widescreen monitors, mice, keyboards and extra power supplies in the office for all developers, although you are expected to provide your own Macbook Pro. Occasionally we end up pairing with dual-30s (as shown in the picture above). It's a bit overkill, kinda like the developer equivalent of a "hoopdy" ride.

I'm headed up to Boston in mid-November to do something I've never done before: chair a technical conference! The event is hosted by my publisher, Addison-Wesley as part of their support and promotion of my Professional Ruby Series.

Before going any further, I have to address something that some of my friends have given me flack for, both privately and on twitter: the name of the conference sounds snotty.

Voices that matter? SRSLY? Does that mean people not speaking at the conference don't matter? (Actually, that name is used for more than just this Ruby conference.)

My publisher might kill me for this, but I have to admit that I had reservations about the name at first also. It might not always come across online, but in person I'm actually a pretty humble guy about my accomplishments and outlook. SRSLY! So plainly put, it was only once we started getting our speakers lined up that I was able to put my concerns aside and start getting enthusiastic about the conference and what we're going to accomplish with it. I hope you will also, which is a big part of why I'm writing this now.

First of all, I have to tell you about the format of the conference, which I take responsibility for defining. Normally, the AW conferences are multi-track, with 45 to 60 minute talks. I said: "No way. That sounds awful!".

RubyFringe sealed the deal for me on one-track conferences. Technical conferences should be kept small in attendance, have just a single-track, and short talks. Short talks are especially important, since all topics are not equally interesting to everyone in attendance (or god forbid I fuck up and invite a boring speaker) as long as talks don't go beyond 30 minutes then we're safe from completely going off the rails.

In fact, we're following as much of the advice given by Pete Forde in this blog post as possible, starting with the following:

• 30 minute talks are superior, and questions should be discouraged
• 150 attendees, 20 speakers, and 30 volunteers is the perfect intersection between big and small
• you do not need sponsors!
• you should charge real money for your event, your attendees will thank you because it will be worth going to
• make sure women play a leading role in organization and speaking
• single track is totally the way to go, because it keeps people together and allows an ongoing narrative

Women are definitely playing a leading role in organizing the conference. The inimitable Barbara Gavin is the conference organizer. She's got a huge spirit and is very experienced with this stuff. Debra Williams, my editor and familiar face at Ruby conferences, has a prominent role in hosting the conference too.

I hope you join me in Boston for what promises to be an exciting conference. The registration information is here and in the following installments of this little blog post series I'll start covering some of the exciting speakers and topics that we have lined up for you.

• Paired Programming’s Benefits | Programmer’s Paradox
  Glad to see that “pair all the fucking time“ is catching on.

Here's a short and sweet version of a listing I'm going to start posting on various job boards tomorrow. I'm looking to hire up to four experienced web developers in the next couple of months, bringing our billable consultant headcount up to 20 people:

Qualified candidates will:

• Have at least 5 years of serious web development experience (experience with Ruby and Rails is of course a big plus, but not absolutely necessary for the right person).
• Be "true believers" in Agile methods, including story carding, pair-programming and test-driven development.
• Relocate to sunny Jacksonville Beach, FL where Hashrocket is headquartered and currently building out brand-new, kick-ass office space. We do provide generous relocation assistance.

Besides working in an awesome location with some of the best Ruby programmers in the world on cool, progressive projects with the best clients, some of the benefits of working for Hashrocket include:

• Competitive salary
• Company-paid medical/dental coverage
• Full 401k matching up to legal limits with immediate vesting!
• Three weeks vacation, plus paid time off for conference attendance (Rubyconf, Railsconf, etc)
• Up to 8 hours paid time per week allotted to "other activities" including open-source hacking, writing books and blogs, education and other internal initiatives
• Strong emphasis on culture and lifestyle, overtime/weekend work strongly discouraged, frequent team outings and social events
• Regular opportunities to work with some of the most experienced Rails experts in the world via our 3-2-1 Guest Star program
• All our work is done on-site, so no travel requirements (great for road-warriors wanting a break)

I encourage you to ask questions and I'll keep a close eye and participate on the comment trail for this post.

• How To Sell Agile To Fixed Bid Contract Clients
  Interesting write-up with ideas on creating contracts that adjust according to scope movement.
• Stevey's Blog Rants: Programming's Dirtiest Little Secret
  If you are a programmer, or an IT professional working with computers in any capacity, you need to learn to type! I don't know how to put it any more clearly than that.
• Agile: Fixed Price Bids - Greg Young [MVP]
  I am not a lawyer but I would love to hear some legal thoughts on just how to put teeth into these contracts without providing explicit criteria for completion of the contract. Until I see successfully litigated cases (which there may already be) I am reluctant to even attempt being agile on a fixed price bid.