Obie Fernandez

New Hashrocket Client Video: Todd Siegel

2009-09-30T22:35:16-04:00

One of the coolest things about shooting a lot of video around the office is that every so often we catch one of our clients on film (and they let us publish them.) In this episode, of what I hope to turn into a recurring season, meet Todd Siegel, who has proven to be one of our favorite clients.

We've done this type of interview before with Dave Cohn of Spot.us.

I'm Cuckoo for Chrome Frame

2009-09-23T21:42:05-04:00

Don't know what Google Chrome Frame is yet? Watch the following short video first...

This is such awesome news that I'm practically besides myself with joy. I think web app developers should make a concerted effort to push adoption of the Chrome Frame plugin, just like Adobe's flash player plugin.

I tried it today on an app that I'm working on which looks like hell on even modern versions of IE. Worked seamlessly.

I can see developers of wide-audience consumer facing sites still facing real resistance towards dropping support for IE6. However, corporate IT and web apps written for the "enterprise" should have little trouble getting this plugin adopted.

Put the following meta tag in your app to activate Chrome rendering on IE:

<meta http-equiv="X-UA-Compatible" content="chrome=1">

10 Reasons Pair Programming Is Not For the Masses

2009-09-22T01:27:37-04:00

Hashrocket, or more specifically our beloved "Big Tiger" Jim Remsik, was recently profiled in the New York Times in an article about pair programming. They titled it For Writing Software, a Buddy System and it's gotten a fair amount of attention on Twitter, Hacker News and Reddit. (If there are other big discussions going on about it, please let me know in the comments. Thanks.)

I think pair programming is one of our most important competitive advantages at Hashrocket. My teams produce some of the highest-quality code I've ever seen in 15 years in the biz. We are able to effectively leverage XP-style client acceptance in our process because our code is so defect-free.

I'm damn proud of what we do at Hashrocket and talk about it often, but usually while trying to stress the supreme importance of context and talent in making it work. My homepage still says "Helping to evolve the world of software into a more fun and productive place to live, work and play", but pair programming, especially all the time, is one of those things where increasingly I have to advise most Agile idealists that it probably won't work for them, and here are ten reasons why:

10. Most software managers don't want to invest in the necessary hardware

Either they don't want to invest in the appropriate equipment (for personal or political reasons), or they are not allowed to do so.

Our pairing workstations are fully-outfitted Mac Minis ($1049) with a $99 Dual-link DVI adapter connecting them to an Apple's 30" Cinema Display ($1800). Each pairing workstation also requires a pair of mice ($98), keyboards ($98) and elevators notebook stands ($80). Finally, we also buy a pair of MagSafe power adapters ($159) for developer's notebooks. Mind you, we don't invest in all this fancy Apple gear because it's cool. We do it because we care about having the best tools available, a sentiment that the masses usually have to live without.

Incidentally, each of Hashrocket's developers has their own MacBook Pro, that they are required to own and maintain, based partly on the philosophy that a craftsman has his own tools. That is a hard policy to pull off in mainstream software shops, because it can be seen as a turn-off for potential recruits, not to mention that most corporate IT shops suffer conniptions about not having control over machines that are connected to their networks. C'est la vie.

9. Most software shops are not configured for pair programming

Cubicles do not work for pair programming. Period.

Most office environments have cubicles and most software managers are stuck with the environment they have and lack the political or budgetary capital to do anything about it.

In order to effectively pair program all the time, you have to have the right furniture and workspace. Comfort is key. Big wide desks, comfortable chairs and elbow room. Our desks are 2 m x 1 m, cost about $600 each and are height-adjustable. There is enough room for the pairing workstation in the middle of the desk, plus dual notebook computers to each side.

There are no cubicles or private spaces available, because developers are not expected to work in private, nor are they supposed to be doing non-work tasks in the office. However, our office is partitioned into a number of "war rooms" and casual seating areas that can be appropriated depending on needs of the team. In particular, client calls are sometimes conducted in quieter areas.

8. Most software shops use traditional hiring practices

Relying on recruiters to source candidates and then hiring someone after a few phone calls and a day of interviews, you know, the way that most places do it, is one of the worst ways to bring on talent. You really don't know what you're getting. The savvy mainstream software manager might swing a contract-to-perm policy, but still has to recruit the contractor in traditional ways.

The best way to hire talent is to drop them in actual work situations for at least a week and see what happens. And that's the catch. Since most shops don't pair all the time, they don't have a built-in infrastructure to accommodate just "dropping someone into a real work situation". The poor candidate would be in over their head. Our candidates spend their interview week rotating on actual production code, pairing with the same people they'll be working with if they're hired. Everyone gets a say in whether to hire a new recruit, and hesitance from a developer that actually paired with them means they do not get hired.

7. Most software shops tolerate anti-social behavior (halitosis included)

At your average software shop, someone can be considered a "good programmer" even if they are a complete asshole. Nobody wants to pair all the time with assholes, even other assholes. Same thing goes for prima-donnas, chronic farters, people who don't bathe enough, people with halitosis, jerks, idiots, lazy bums. There are myriad conditions that could make pair programming a gruesome experience and it is absolutely management's job to make sure that those problems are kept under control or eliminated. As in censored. Or fired.

Face it, most software managers are under-staffed (see below), overworked and/or under-qualified. They would rather let the group deal with Asshole Architect, Mr. Stinky or Jimmy the office jerk than to go around provoking difficult conversations and making more work themselves. Besides, Stinky's code is pretty good, isn't it? Right... I've had to dismiss otherwise-qualified people for being assholes. People that I otherwise-needed. It wasn't easy, but it is crucial to do it anyway.

Full-time pairing requires strict implementation of the No-Asshole Rule. In the words of Robert Sutton, "enforcing the no-asshole rule isn't just management's job". The entire team has to feel empowered to call out and reject anti-social behavior. That kind of empowerment is extremely rare in corporate America. It's easier to take it during the day, rush out of the office at 5 pm on the dot and vent your frustration at happy hour.

6. Most software people don't understand pair productivity

Those of us that have seen it in action know that good full-time pair programmers consistently produce higher-quality code faster than individuals working alone.

To the average manager, with his average mindset, two people working on the same thing equals half the work done. To the average programmer, having to pair full-time means they won't get to waste time during the day on Reddit or Hacker News.

Full-time pair programming keeps developers focused and coding, all day, every day, week-in, week-out. The average developer spends maybe a few hours a day actually coding and finds all sorts of other activities to fill in the rest of his day. The difference in experience gained towards mastery of the craft adds up quickly.

I see pairing work so well every day that I consider my career prior to my current job to have consisted mostly of wasting time. When I think back to all the code I’ve written for a job, I’m annoyed at how much less efficient I was then since I wasn’t pairing, and how much better my code and my products would have been if I had paired on them full time.
When you have a second person working with you, you find that you try harder to code well. You’re far, far less likely to be willing to apply duct tape to a problem, because someone else is working with you and he or she is more likely to object to the duct tape. If two people approve a hack and implement it, it’s almost certainly because it’s the right approach given the time constraints. If one person sitting alone decides to pursue a hack, it’s more likely to be a situation where there is a better approach.
Two people attacking a design problem together is easier than one person doing it. Your partner will think of things you don’t, and vice versa. In a non-pairing environment, you can always call someone to a whiteboard to help you work through a design issue, but when you do that you’re only calling for help when you know you need it. The times when you need help and don’t know it go unaddressed – and yet despite the fact that you need help, I guarantee that you’re coding SOMETHING and checking it in. It’s almost certain to be shitty code. The amount of time you spend trying to figure out “what’s going on here” or “why isn’t this working the way I expect” is severely reduced. I’m talking hours of debugging that literally turn into seconds.

Rod Hilton in I Love Pair Programming

5. Most software shops employ under-qualified developers

Hashrocket is a boutique shop, so we can be very picky about who we hire. Candidates have to pair with us onsite for at least a week before the team decides whether to hire. We've hired qualified interns, but we don't hire apprentice or junior-level folks. Occasionally we do extended pairing matchups with client developers in our office, but they have to fit in culturally for it to work.

The bar for success in this industry is set very low. Most software shops have one or two great, productive hackers, offset by a boatload of net-negative producers:

"When doctors screw up (massively) they get sued. When (permanently employed) programmers screw up they get let-go, and they go find a new job, usually with more responsibility and a pay raise. There are no ramifications for software malpractice."
Jay Fields in The Cost of Net Negative Producing Programmers

Hiring only great people and compensating them very well is expensive. Most software managers don't even buy into the advantages of only hiring great people, thinking that a mix of talent levels is more advantageous.

4. Most software shops are overworked and under-staffed

This reason is related to #5 in the sense that most software shops don't have enough good people to take responsibility for the truckloads of work that they're expected to do. You can't put idiots in charge of important projects, therefore pair programming requires double the amount of "good" people as not pair programming.

Promiscuous pair programming, where there is a weekly, or even daily, rotation of pair partners, requires more people than discrete workstreams, so that pairs can switch without incurring big ramp-up penalties.

3. Most software developers don't like everyone they work with

Good luck putting together more than 15 people in any type of group without some of them hating each other's guts. Now limit your pool of resources to average programming geeks with anti-social tendencies and making your group get along just got a lot harder.

Lots of teams out there are simply too big for a happy group to even be possible. There is research on ideal group sizes for teams, with the consensus falling in the 8 to 14 member range. Unless you're committed to small teams of sociable people, you won't be able to get everyone working together happily.

Most software managers would rather pay 20 mediocre and/or anti-social developers $75k/year instead of hiring 10 great developers at $150k/year. (Why? I'd bet on they don't want to pay their developers more than what they make.)

2. Most software developers just don't want to work that hard

Laziness is a virtue for programmers, isn't it?

Laziness - The quality that makes you go to great effort to reduce overall energy expenditure. It makes you write labor-saving programs that other people will find useful, and document what you wrote so you don't have to answer so many questions about it. Hence, the first great virtue of a programmer.

Larry Wall in Programming Perl

Unfortunately, it seems like over the years as an industry we've simply reduced that advice to "go to great effort to reduce overall energy expenditure" and forgotten about the rest.

Pair programming makes developers work harder than they've ever worked before in their lives. You constantly have someone making sure that you're not distracted or wasting time running down dead ends. Unless you're an asshole who just doesn't care (see #7) you're not going to abandon your pair while you endlessly do non-work-related stuff. Pairing keeps you honest. Being honestly hard-working is still one of the best ways to earn accolades and raises. Accolades and raises usually bring some measure of added happiness.

All that hard work really pays off in terms of success for everyone involved as well as personal growth, but why bother trying? Most software developers are happy to skate along doing the least amount of real work possible without getting in trouble. In other words, they're lazy.

1. Most software shops don't really care about excellence

There are so many things to worry about at your average shop that have nothing to do with excellence. Corporate America cares about lines of code, the bottom line, toeing the line, and whether Joe in Accounting is doing lines in the bathroom during his breaks.

Truly caring about excellence means considering your work to be more than just a job or a paycheck. You have to treat is as a craft. You have to have passion for the success of your clients, company and co-workers. You have to be justly rewarded for that passion and encouraged. You have to care. And frankly, that is just way too much to ask of most people.

Links for 2009-09-12 [del.icio.us]

2009-09-13T00:00:00-07:00

teehan+lax » Blog Archive » iPhone GUI PSD 3.0

BizConf Update

2009-07-31T10:00:17-04:00

BizConf is an exclusive conference focusing on the business of software development in a Web 2.0 world. I originally conceived it to be a gathering of owners and managers of Rails shops from around the world, but once the idea started taking shape, our target audience got a little wider.

As I'm writing this, we have 3 weeks left before the conference and just hit an important milestone. From the beginning, my budget has called for a minimum of 50 attendees and a maximum of 75. Well, we hit 52 registrations today! The event is definitely on and we're ramping up our outreach to individuals that we think should attend in an effort to sell out.

Money Matters

I realize the economy is putting a damper on registration, which is why I've tweeted that people who want to attend but are having trouble affording the trip to get in contact with me for special consideration. In future years, we are definitely going to try budgeting the conference around a lower registration price.

I have to mention that BizConf would not be possible without the generous support of Hashrocket and 11 other awesome sponsors including, nGenWorks, New Relic and Engine Yard. Half of the sponsors are providing attendees with awesome free packages of their services.

Presenter News

We added a couple of internet celebrities to the program recently: Andrew Warner and Alex De Carvalho.

In his twenties and with no outside funding, Andrew co-founded a business that reached $30+ mil in annual sales. He is now the host of Mixergy.com, a video podcast that interviews "doers and thinkers whose ideas and stories are so powerful that just hearing them will change you."

Andrew will present Bootstrap Like a Missionary, based on his true life experiences doing just that.

Alex is a co-founder of StartPR, an online tracking service for reputation management, blogger relations, and brand monitoring. He's an advisor to businesses and organizations on their use of social networks and social media to build community relationships and brand. He also designs and manages social networks, including business planning, technology selection, wireframing, development, and community management.

Alex's presentation topic will be announced soon.

Blog Highlights

We just posted an informative interview with noted author and consultant Esther Derby, who is presenting three talks at BizConf!

Good Idea, But How Do We Do It? Finding and Using Your Sources of Power
What Does Your Customer Want?
Beyond the Organization Chart: What Really Drives Behavior at Work

We also have quite a few video interviews with presenters. I think my favorite might be the one with Jessie Shternshus of the Improv Effect talking about her session at Bizconf.

Agile Design, O RLY?

2009-06-02T23:50:04-04:00

We had a great Hashrocket Book Club discussion today about a Cennydd Bowles article on A List Apart: Getting Real About Agile Design. Our discussion revolved around the integration of our very XP-like process with traditional and so-called "Agile Design", the evolution of design activities that traditionally have been very waterfall-like and involving heavy research phases.

Les made a pretty bold statement that design people are stuck where developers were 10 years ago, prior to wide adoption of Agile.

Here are the rest of my rough bullet point notes, in the hopes of getting a discussion started about this important topic.

There is a trichotomy* when discussing "design": Experience, Application and Graphic. Or sometimes you say "design" and you mean all three. That makes it difficult for everyone I know to talk about "design" without getting really confused.
User experience design involves the entire interaction of a user with a business and its technology, which makes it different than application and interaction design, which has more to do with the design of screen interactions and forms and pages.
Projects should have mini-milestones that represent "user journeys" as described in the article -- stories chained together to represent a path through the application -- and different than the concept of an "epic story".
The meaning of iterations still presents issues (even to us) in terms of thinking that they constitute weekly milestones. I say that iterations are nothing except dumb timeslices that enable tracking of velocity, but I realize that is far from a universal view in Agile circles. See The Story is The Iteration as practiced by Hashrocket, Pivotal Labs and others.
It's hard to envision experience and application design as happening after storycarding, since the storycarding process is dependent on having that design already done.
There are ways to start intertwining design with Agile the way that we're practicing it, but not like in the Bowles blog post, because Hashrocket usually acquires clients that have their application design done. Except that's not actually the case now, because since Andrew came on board we're participating in the earlier stages of the project, even starting at the concept phase.
There is value in developers championing the user experience throughout the project, being more than just programming robots. This implies that our developers have design savvy.
Customers are not experts in experience and application design and they cannot replace designers on XP projects.
The comparison in the Bowles blog post between software and the movie industry is flawed, because movie projects don't do small or often releases.

* Yes, I know that trichotomy is not really a word. But "dichotomy" implies two things, not three. Update: As pointed out by Thufir in the comments, it is a word. (I originally checked and didn't find it in my dashboard dictionary.)

BizConf Venue Teaser

2009-05-20T16:38:22-04:00

BizConf Venue Teaser from Hashrocket on Vimeo

IP and Non-Competes for Employees

2009-05-19T22:47:58-04:00

Got the following email the other day, concerning intellectual property issues and non-compete agreements:

I was wondering how Hashrocket handles intellectual property and non-competes with its employees. Is it something that your developers are required to sign as a new employee?

I ask because I got into a deep discussion with my boss about this. The employee agreement he came up with basically says that he owns any software / web related intellectual property that I work on (on and OFF the clock). The non-compete section says that I can't start my own business or work for another firm in the same or surrounding states.

I have an issue with him owning the intellectual property for work I do off the clock. It makes me less motivated to learn and be innovative when I'm tinkering around on my own. I have my pet projects that I don't want him to have any part in. His argument is that he doesn't want his employees using company resources (software and laptops) to start their own business... which gets into the non-compete.

The answer is an emphatic "NO!" I do not require non-compete agreements to be signed by new hires at Hashrocket. Neither do I try to claim ownership of work that they do off the clock (open or closed source), a practice I learned from and admired at my former employer, ThoughtWorks.

Work done on the clock is a different story. We have the notion of chartered projects, internal initiatives which you are paid to work on for at most 5 hours per week or when paying client work is not available. If I'm paying someone to work on something then Hashrocket owns it, end of story. Actually, there could be some gray areas there, like bringing interesting outside projects in-house in order to make more progress on them, but in that case reasonableness is key.

Anyway, a non-compete agreement (or non-compete clause in a larger contract) restricts employees from engaging in similar work after leaving your firm. I didn't like them as an employee and I don't like them as an employer either, because I think they're fundamentally unfair. If as the owner of the firm I'm insecure about my people leaving and competing with me, then I'm doing it wrong. Keeping my people from being innovative on and off the job is exactly the opposite of what I need to be doing.

The rationale that your boss used with you, that he "doesn't want his employees using company resources (software and laptops) to start their own business", is IMO such a cynical asshole thing to say to anyone. I've heard it before, and it always pisses me off. The thought process doesn't come up at Hashrocket because I require my people to buy and maintain their own computers. Professional craftsmen have their own tools, yada, yada... that's the subject for a different blog post.

And paid software? Really? What do we actually use for Rails development that costs money? Texmate? (Use vim to solve that problem.) I guess Adobe products are a notable exception there, but I still can't bring myself to look at the situation with such shortsightedness as to try and prevent someone from using tools that I purchased for them to further their career. I just realized why that is -- I see my mission as their "boss" to help further their career! (The rewards from treating your employees this way are immeasurable.)

Incidentally, non-compete agreements are not enforceable in California, but elsewhere in the USA they are legally binding, so you should be very careful signing anything with a non-compete clause.

My suggestion to people presented with non-compete clauses in their offer letters or as part of agreements signed post-hiring, is to strike the offending clause from the contract and initial the change. Do that or refuse to sign the agreement altogether. Yes, it takes chutzpah to do what I'm suggesting, but c'mon now... you shouldn't kick off your new job by bending over and taking the corporate shafting from day one. Given the time and expense needed to find qualified hires nowadays, after some initial fussiness from HR or the hiring manager, the whole matter will be forgotten. If they try to force you to sign under threat of termination then you really should be evaluating whether you wanted the job in the first place. Seriously.

I do believe in a particular type of informal non-compete agreement, which I make verbally with all my people. I ask my people to refrain from "moonlighting" (doing side work) of the same type that they do during the day at Hashrocket. As an employer, you should do that too, but only if you pay competitively!

I can't forcefully prevent my people from moonlighting, but I discourage it strongly for one simple reason: burnout risk. Rocketeers work very hard every single day of every single week, putting in 35-40 hours per week doing intense pair-programming. I want them to go home and relax, so that they're fresh the next morning. Think that's an unreasonable request? Don't come work for me.

On a final note, I think it's a good idea, as a company that sponsors open-source projects and encourages open-source work on the clock, to have signed contributor agreements from all employees. I haven't done this at Hashrocket but I'm going to look into it soon.

Announcing BizConf

2009-05-17T17:52:07-04:00

BizConf is a one-of-a-kind, exclusive event that I am hosting about 3 months from now at the Ritz-Carlton Amelia Island Resort in northern Florida. It's a 2-day conference specifically crafted for independent consultants and owners/managers of small to mid-sized web consultancies.

Conference Website: http://bizconf.org

Summary

The conference program is on Thursday and Friday (Aug 20-21, 2009) and the Ritz-Carlton is offering steep discounts on their room rates for up to 3 days before and after the conference. This is a perfect opportunity to turn a "business" trip into a vacation (or golf) getaway with friends and family. I selected the venue particularly because of the luxurious rooms, restaurants and spa, and its location on some of Florida's finest white-powder beachfront and warm, sparkling blue ocean. Amelia Island is conveniently about 30 minutes drive east of Jacksonville airport (JAX) and local transportation can be arranged through the conference.

Check out some more photos of the Ritz-Carlton Amelia Island by Josh Hallett. It is a beautiful and luxurious hotel and we're making the most of it. All meals are included in your conference registration, from special catered breakfasts in SALT Restaurant to the Friday night private dinner and pool party at the Spa.

Registration is limited to 75 people in order to keep the event intimate and maximize interaction between our presenters and attendees. We have over 20 compelling presenters confirmed so far, with additional announcements happening soon. The program is divided into plenary sessions for everyone in the main room and three breakout session tracks in small conference rooms. Some have questioned the decision to do 4 tracks for such a small conference. The answer is that we will be covering a wide variety of topics, from marketing, to team building, to legal/finance issues, to product development and client services. Attendees will be able to select a mix of topics that suits their exact needs and receive personal attention from the presenters, while still having ample opportunities for networking and creating new friendships in our industry niche.

Presenters

The following list only skims the surface of who you can expect to meet and learn from at BizConf:

Jerry Weinberg is one of my heroes. He has over 30 years of consulting experience and has written many notable books including "The Secrets of Consulting" and "The Psychology of Computer Programming". He will be presenting small group experiential sessions including "Learning to Say No" and "Great Client Expectations".

Roy Singham, my friend and mentor, will be keynoting and spending one-on-one time with attendees. Roy famously grew his tiny Chicago-based consultancy into world-class software consulting powerhouse ThoughtWorks, admirably working to make positive change in the world every step of the way. Martin Fowler has written about Roy on his blog.

Esther Derby and Johanna Rothman are esteemed trainers and co-authors of the Pragmatic's Behind Closed Doors: Secrets of Great Management among other titles. They will be very busy at BizConf with sessions topics including:

Recruiting and Keeping Talent Happy
Leveraging Personal Sources of Power
Levers for Change
Interviewing Customers

Don Gray coaches software development organizations to higher levels of productivity. His background in machine and process automation provides the foundation for working with organizational systems and change. His workshops at BizConf will focus on personality types and teamwork, team productivity, and retrospectives.
Ian McFarland, Principal at the esteemed San Francisco-based consultancy Pivotal Labs will present a new model for selling a potent mix of Agile, Ruby on Rails and cloud-computing to CIOs and CTOs in the enterprise world. Ian was a special guest on the Rails Podcast last year.
Corey Haines is one of the warmest, most genuine voices of the Software Craftmanship movement. He is rapidly gaining friends and notoriety from his travel around the world as the wandering journeyman software craftman, sharing programming language with technology professionals in exchange for room and board.
James Duncan Davidson will provide attendees that bring their own DSLRs with a unique opportunity to learn photography from a master of the craft. Learn how to maximize your marketing with candid shots of your people in action.
Jessie Shternshus is founder and owner of The Improv Effect and has worked with companies such as CBS, Paramount Pictures, MTV and Sesame Workshop. Jessie merges her lifelong passion and expertise of improvisational acting with the fast paced demands of the corporate world. In her classes and workshops she helps people become better listeners, team players, leaders and communicators. Her physically engaging and playful workshops are relevant to all facets of life and are sure to be a fun highlight for BizConf participants.

The complete list of speakers is here, although I expect to add a few more to it in the coming weeks. This conference is very personal to me -- I am handcrafting the program to maximize the interest to other people like myself: entrepreneurs in the web development space, particularly my peers running successful Rails consultancy shops.

Price

If you register before July 17th you can take advantage of the early-bird pricing of $1995. After that, the price goes up to $2495. Yes, I know very well that the cost is out of reach of some of you reading this. However, it's an upscale and exclusive event on purpose and I decided on that price based on market research. Also, running a conference like BizConf is quite expensive and entails a great deal of financial risk for the organizers. The venue and food is very expensive, as well as travel expenses for all of the speakers.

Inverted Sensibilities

2009-04-29T10:04:27-04:00

nextangler: I certainly have a line as well
nextangler: And it goes at violence
obie: LOL you certainly are a european
nextangler: Which, funny enough, seems to be the inverse of a lot of people here
obie: americans have hangups about sex, but not violence
nextangler: And that's some fucked up shit
obie: yep
nextangler: That needs to be attacked at any given opportunity
obie: violently?
obie: :)
nextangler: By arguments and pictures of mating!!

Links for 2009-04-25 [del.icio.us]

2009-04-26T00:00:00-07:00

Rails Devs for Foreign Keys
Interesting commentary and plugin from Rails guys who believe in using database constraints.

Heroku and GoDaddy CNAME

2009-04-24T17:51:16-04:00

If you're trying to get Heroku working with your GoDaddy-hosted DNS, you're going to have problems adding a CNAME record for "@". The system will complain and ask for a valid hostname, even though GoDaddy's own documentation says that "@" is okay.

The solution is to use the name of your domain instead. A trailing period after the TLD seems to be optional. An A record for @ is not needed with this configuration.

Links for 2009-03-01 [del.icio.us]

2009-03-02T00:00:00-08:00

Ereblog » Blog Archive » Telling stories in Nashville
Fawesome story about guest-pairing with the OGC guys. I think the guest-pairing meme is catching on.

Links for 2009-02-18 [del.icio.us]

2009-02-19T00:00:00-08:00

DigiDave | Communication is Key: A Journo-Entrepreneur's Important Relationships
Today one of the most important relationships I have is with my developers. The joke goes "developers are the new teamsters."

Links for 2009-02-17 [del.icio.us]

2009-02-18T00:00:00-08:00

We Vouch For...
Interesting take on a "network of excellence" concept by Brian Marick
Sparkboxx - Wilco van Duinkerken: Rails Maturity Model, Certification and the Rails Ecosystem
%w(Akita On Rails) * 2.0 / Rails (Im)maturity Model?
Fabio's take on the subject of RMM and CMMi in general. He seems to know what he's talking about based on experience.

Links for 2009-02-05 [del.icio.us]

2009-02-06T00:00:00-08:00

Agile Testing: Load Balancing in Amazon EC2 with HAProxy

Links for 2009-02-04 [del.icio.us]

2009-02-05T00:00:00-08:00

Rabbits and warrens. - Jason’s .plan
AMQP and RabbitMQ Primer
Write-Through Cacheing is an Essential Part of a Healthy Scaling Strategy « Magic Scaling Sprinkles
Nick Kallen explains why write-through cacheing is necessary prior to debuting cache-money.
DIY: How to write a book - Boing Boing
Interesting approach that sounds kind of like what I did for The Rails Way. Aggregate content for a long-time and then organize and synthesize your own content from it. Similar to an approach advocated by Gerald Williams.
AMQP from Rails, crashing intermittently - AMQP | Google Groups
Thread.new{ AMQP.start(:host => 'localhost') }
Thin Web Server Benchmarks | Webficient
Thin uses the Mongrel parser and Event Machine I/O library. In addition, it uses the Rack interface, allowing you to run other frameworks besides Ruby on Rails.