Rendering emails locally is a pain. Rendering all the emails in your Rails app is even more of a headache.

I frequently get requests from clients to send them a complete set of the emails sent from their applications for copywriting review. I wrote a quick gem for you to incorporate that function into your ActionMailer tests. It will log all of your emails to a central location so that you can zip them up and send them to your clients and/or stakeholders.

I’ve called it postmaster_general.

Once installed (add it to your gemfile as specified in the README, set the log directory like so:

PostmasterGeneral.log_directory = "/some/arbitrary/path"

Then, you might have an ActionMailer spec like this:

After you run your suite or this particular spec, you’ll have a file with a path of /some/arbitrary/path/a_delivery.txt that contains the contents of your message. What’s neat is it works well with continuous integration - you could set up your CI to automatically prepare an up to date version of all the emails in your system.

I hope you find it helpful, and that it encourages you to write ActionMailer tests!

Every day starts the same. Open up iterm2, start up a tmux session and create 3 windows. One for working (generating models, opening up the Rails console, etc), one for the server, and one for running autotest in the background. Then, I name the Tmux session appropriately along with all the windows. It takes about 5-10 minutes to get this all set up nicely in the morning. I got kind of tired doing it and felt like it was wasted time. After some research and some honing, I’ve created the following script:

Hope you find it useful! For easy reference and forking I’ve created a gist.

Has Ruby on Rails been good to you? Has the framework helped you get a job or start your consulting career? If so, I challenge you to give 3 percent of your time for Rails 3 over the next few months. If you work 40 hours a week, 3 percent amounts to less than 5 hours a month! Could you donate half a Saturday a month to the framework that figuratively puts money in your bank account? I can, and that’s why I’m pledging three percent for Rails 3 over the next few months.

The Bugmashes have been great, but there’s still more to be done. The core team is dedicated and smart, but they can’t do it all. As of the time of this post, there are 1199 open tickets in Lighthouse, 898 open bugs, and 301 open patches. Oh yeah, and by the way, Rails has been basically overhauled and re-architected in its entirety (You might want to kick the tires a bit).

Stop whining about bundler. Stop complaining about the new routing DSL. Instead of taking the time to talk about everything that’s going wrong, put in the time to make it right. Here’s why you should pledge your three percent today:

It Makes a Better Framework

How confident are you in a framework that has 1199 open issues that aren’t going away? How much better would the framework be if developers like Jose, Wycats, and Koz were freed up to focus on the bigger picture? If you use Rails on a daily basis, your unique perspective matters, and you can help with the burden of all of these open issues.

It Makes a Better Community

Negativity is contagious. You can sit on the sidelines and complain about what’s coming, or you can get in the game and help make things happen. What stinks is that if there’s an obnoxious crowd heckling the players on the field, newcomers will be less inclined to jump in. Positivity can be a virus in the same way. If you truly love what you do and you’re grateful, exhibiting that makes the community as a whole better and it attracts newcomers to the project.

It Makes You a Better, More Marketable Developer

Knowing the internals of the framework you use on a day to day basis definitely makes you a better developer. There is no magic behind Rails, just smart design and Ruby. Consider pair programming with someone more experienced than you and how that impacts your performance. Now, imagine working with the leaders of the community on core functionality and how that can improve your skills.

Consider the benefits from a professional perspective as well. Do you think being a core contributor differentiates you in a hiring decision? If you’re a freelancer, does that provide you with something marketable over those still on the sidelines?

Get in the game. Pledge your 3 percent today and give back.

This post is for all the recruiters, hiring managers, and human resource professionals hiring developers today. At some point, someone decided that it would be cool or differentiating to post job listings asking for Rails Ninjas, Front End Hackers and Rockstar Web Developers. It’s an unfortunate practice to get your job advertisement noticed, and I urge you to stop.

For developers, words and names are important. From my personal perspective, here’s what these titles say:

• Rails Ninja - You want me to creep around the codebase late at night and inject transient bugs to foil my developer nemesis? Should I do everything on my own, or do I have an exclusive ninja clan that I hang out with? You want me to do everything my way, or the way that’s been handed down to me from centuries ago? So, basically, you want a lone wolf that goes about their business without any collaboration or direct engagement?
• Front End Hacker - Hacker? To hack a frontend project immediately resonates as short term fixes and solutions that aren’t elegant or user friendly. If you want to recruit hackers to do any type of coding beyond security and vulnerability detection, you’re in the wrong business.
• Rockstar Web Developer - This is probably the most prevalent and astonishing of titles - do you really want what this stereotype personifies working in your organization? I immediately associate this with someone that’s arrogant, self-serving, and apathetic. Besides, how effective can you be at solving problems at 9AM when you’ve been up until 4 the night before partying like a ‘Rock Star’? Please.

Some of these questions or perceptions may seem silly, but like I said, words matter. Stop using these titles! What value does this add to your job posting? What does it convey about how you perceive developers? Developers want to be respected and appreciated, not trivialized. Developers want to be understood and stimulated. Here’s three better titles that I guarantee will yield a better candidate pool:

• Pragmatic Programmers - (Note: this book is required reading for developers and anyone hiring developers) - Don’t you want to hire problem solvers? The best developers solve business problems with the simplest solution possible. They have a demonstrated history of making things work, and shipping. That’s what pragmatic programmers do.
• Motivated, Lifelong Learners - Technology changes. New platforms arise, and new languages and frameworks emerge. For the best developers, the technology doesn’t matter. As mentioned above, developers are problem solvers first and programmers second. Finding the best talent is all about finding people that can identify the best tools to solve problems, and they’re unintimidated when it comes to learning and evaluating them. These individuals are typically well informed and love to read. In almost all cases, they thrive on learning new things, inside and out of their industry.
• Social, Connected, Passionate Professionals - Books aren’t the only source of learning and discovery. For top notch developers, they realize the importance of community and engaging with peers. Exceptional talent will quickly get discouraged if they don’t have the challenge and stimulation of discourse with other stellar developers. Not to mention, connected individuals bring in more talent and great people. To solve problems, you have to communicate and collaborate. Sure, developers can tend to be introspective, but that doesn’t mean you shouldn’t like or connect with the people you work with.

Think about it from your own perspective for a moment. Can you picture yourself applying for a “CEO Rockstar”, “Recruitment Chef”, or “CTO Samurai” position? So, stop using silly titles. It only distinguishes you as someone who doesn’t regard software development as the art and science that it is.

Rails 3 is coming!

I’ve been doing a lot of thinking about how I can help clients get in a better position to upgrade to Rails 3 when it’s ready for prime time. There’s a few things you can do today with your 2.3.x application to give it more Rails 3 flava. Yeah boy!!!

Use Bundler instead of config.gem

Yehuda Katz has done a good job replacing config.gem with a more platform agnostic utility called Bundler. The API has changed around a bit with the latest 0.9 release, but he supplies a decent guide. For details on what’s changed since that writeup, check out this post from Yehuda

Use inherited_resources to get respond_with

respond_with will be a nice shortcut in Rails 3 for the rendering end of RESTful controller actions. Jose Valim’s inherited_resources actually gives you respond_with and respond_to methods for Rails 2.3.x applications. No more repetitive and un-DRY respond_to blocks

Use rails_xss

Unsafe strings will automatically be escaped by default in Rails 3. If you want this behavior in 2.3.x, all you have to do is install Koz’s rails_xss. It is surprisingly hard to break out of the habit of using h() calls in your markup, though! Additionally, be wary that you might have to hack some of your view related plugins to get them working with rails_xss.

Use More Named Scopes

Fortunately, ActiveRecord find() calls will soon be unfound in Rails applications. Pratik has done some really cool stuff with active_record. These changes are all pretty significant, but perhaps the largest deal is that the find() method and its relatives will be deprecated come Rails 3.1. One thing that is remaining a fairly consistent part of the API is named_scopes (despite a name change).

Developers should be encouraged to use named_scopes and association chains even more aggressively, now. It will certainly be easier to refactor a few named scopes around than it would be to refactor scattered find() calls all over your libraries. You should be doing this anyway, because it definitely helps with improving code and test quality

An excellent gem that can help you with this is Ben Johnson’s searchlogic. It gives you a bunch of very useful, canned scopes.

Replace references to RAILS_ENV, RAILS_ROOT, and RAILS_DEFAULT_LOGGER

Thankfully, these ugly constants have no place in a Rails 3 application. There are now methods to access these properties as part of the Rails module. So, for example, you would use Rails.env instead of RAILS_ENV

Nick Quaranto actually just wrote a solid article with the details on the Rails module.

The current system for developing conceptual applications is broken. Many early stage entrepreneurs clamor to find developers that can build their product on a tight budget so they can get it in front of venture of angel funds for further development and proof of concept. These entrepreneurs consistently seek out a pool of developers that are few and far between: those that are willing to work exclusively for equity. This search typically results in two unsuccessful outcomes. The entrepreneur encounters an incompetent team that fails to develop a quality product, or the entrepreneur becomes frustrated and abandons the project entirely.

Why Does This Suck?

As a developer, I love new and innovative concepts. As an entrepreneur, I love disruptive ideas that can change the landscape of business as we know it. How many of these ideas meet with either of the two fates above? In today’s world of abundant talent and money, why do good ideas die without a fair chance to prove themselves?

I meet early stage entrepreneurs with cool ideas all the time. I want to help them, but they very often can’t allocate the budget to turn their ideas into reality. What results is a chicken or egg problem: the entrepreneur needs a product to pitch for funding, and the product developer needs funds to develop the product. What ultimately results is a dead idea that was never given the chance to get off the ground.

And Now…For Something Completely Different

What if a term sheet wasn’t in dollars and cents, but in developer time? What if VC’s wrote two checks - one to the entrepreneur and one to a recommended product development firm?

There are many intelligent individuals that are emphasizing the importance of building great products. In my opinion, the best people to build products are those that have done it before. If that’s the case, then, how many first-time entrepreneurs know how to build a product? It’s my claim that it is an investor’s fiscal responsibility to ensure the entrepreneur is connected with the right resources to develop their product.

Ideas like TechStars, YCombinator, and small, localized incubators and organizations have done a ton for the online startup community. Good luck getting into an esteemed mentorship program like TechStars without a developer on your team, though. All of the people around these ideas recognize the need for sound, technical talent, but rely on the entrepreneur to supply it! It is my belief that the investors can provide entrepreneurs with this talent as part of their investment. Whether they staff engineers permanently or furnish a recommended list of vendors, I believe the investors are more qualified to discern between developers that can deliver results and the unfortunate bozos that pervade our industry.

Why This Works for Investors

I consider the investors I know to be wonderfully connected and resourceful. They usually have a demonstrated track record of building successful products and companies. If I’m a first time entrepreneur, why not rely on my investors to connect me with a team of capable and efficient developers? As an investor, wouldn’t I want to be connected to developers that can make my portfolio truly shine?

If you’re connected to the best and battle-hardened developers, that creates a lot of value for your firm. Having engineers at your disposal to assess the complexity and costs of doing business during due diligence would allow for investigators to help discern between the money pits and the lean, money-making machines. Additionally, having an elite team that can get the job done right and fiscally efficient would allow you to cheaply evaluate business concepts.

Why This Works for the Entrepreneur

To say it matter of factly, entrepreneurs without software development backgrounds simply do not know how to hire solid, technical talent. If investors are helping to recruit and screen candidates, that really can increase the efficacy of such crucial hires. Not to mention, investors can train and mentor entrepreneurs on what to look for in a sound, technical hire to sustain future growth.

When entrepreneurs get funding and can make hires, do they really know how to evaluate a potential engineering employee or contractor? Potentially, a seasoned entrepreneur with a product development background may have a list of contacts to reach out to when they become flush with cash. How many first-time entrepreneurs, however, waste valuable time and money on incompetent people that don’t bear any fruit for their clients?

In early stages, most business-oriented founders want to focus on strategic partnerships and sales, anyhow. While there’s an increasing and encouraging awareness of how important your first technical hire is, it’s not something a first-time founder is really equipped to do.

Why This Works for the Development Community

There are a lot of bad developers out there that sustain themselves on unsuspecting, first time ventures. In a world where investors help to build a sound framework for screening candidates, these bad apples fall out of our industry. This effectively would raise the bar for everyone in the field, which would make the most meritorious developers more valuable and respected. Good developers would no longer have to tolerate those that didn’t carry their weight because they simply wouldn’t be found on the same team together. This would result in higher job satisfaction and retention, in addition to better output and creativity.

Additionally, developers love new projects and business problems to solve. If the investment community could provide a capable and elite team with a continuous supply of cool concepts, I bet you’d have a happy team of developers.

The Grass is Always Greener

I’m not necessarily knocking the present state of affairs. I can certainly understand why investors don’t want to manage the hiring process to this extent, and why certain entrepreneurs would view this type of involvement as intrusive. My intent here, is to raise the point that investors usually have the know-how to assist entrepreneurs with their product development efforts, and that they should use that know-how to the benefit the value of their portfolio and benefactors.

That being said, there’s also the issue of observing how a team stands on its own, which is probably the strongest case against this model. The development team sponsored by the investor won’t always be there, so it would be important to recruit and phase in a technical cofounder at some point in the product’s development. An investor might not want to finance this endeavor, and they generally want to invest in a full-strength team from the onset.

In the end, we’re in unfamiliar territory. Perhaps all we need is a better way to match good developers with promising teams and ideas. Brain power and attention are becoming the scarcest of resources, and my desire is to create the most efficient economy to maximize the outlay of these resources. The idea, the founder’s passion, the developer’s capability, and the investor’s money are all necessary to create successful products, so let’s all work together to optimize what results.

Update: Nick Plante tipped me off to a company trying something like this named SproutBox.

I recently attended an excellent event put on by a few people from BetaHouse and TechStars. The premise was to meet and network with other entrepreneurs in the Boston area to potentially find cofounders for your next venture. I’m primarily a technical guy, and I’m not married to any particular idea. Finding and enticing great technical talent to join your startup is hard, which is a big reason why I started the consultancy. We help startups get the technology they need, but sometimes founders desire a technical partner in crime. So, if you’re looking to attract solid developers or designers in your venture, here’s some perspective from a technical person who’s on the venture “dating” scene.

What’s your name?

At the beginning of the event, everyone had an opportunity to introduce themselves, their business, and state who or what they were looking for. I was surprised at how many people with ventures did not introduce themselves. They jumped right to the idea. The idea is important, but free agents want to know just as much about you as your business. Briefly state your name and a little of your background - it won’t take away from the presentation of your idea, and it will definitely help people to get to know you better.

What’s your idea, again?

This goes beyond finding team members. If you cannot clearly articulate what your business is all about in one minute, you need to practice your pitch. After many pitches, I had to ask myself what problems the team members were trying to solve. Technical people are naturally problem solvers, so they want to know about what pains you’re setting out to remedy.

Great idea. Tell me more about your team

Any idea can sink or swim based on the team’s capability. I want to hear about your executive team and their background. I want to hear about your board of advisors or your board of directors. Who inspires you? Who keeps you accountable? If I’m going to jump in the water with you, I want to know that you’ll help keep us afloat by surrounding yourself with great people.

I lost you at “Revolutionary” or “Web 2.0”

You’re in a room with about fifty other entrepreneurs that are just beginning to conceptualize their idea. Is your idea really that revolutionary? These terms really don’t mean anything to me right now. What market are you going after, and why do you feel your company can be disruptive in that space? What’s the market cap, and how much market share do you project over a 1, 2, and 5 year period? How much revenue are you expecting in these years? At what point do you anticipate becoming profitable? Isn’t the social media hype all about Web 3.0 now?

Technical people like substance, and some like hard numbers. Throwing around hand waving terminology doesn’t instill confidence in your idea or you as a potential cofounder.

It’s a Slow Romance

Perhaps it was because the TechStars application deadline is fast approaching, but founders were a bit eager to get your commitment. So let me get this straight, I just met you and learned about your idea, but you want me to come on board next week?

Joining a startup is not something I want to decide on overnight. Finding team members that you jive well with is a time intensive process, and it shouldn’t be rushed for either party. Have coffee regularly, jump on a few calls, then maybe pursue a short or part-time contractual relationship before everyone commits. You’re going to be spending a lot of time together, so chemistry is vital. Enjoy the courting phase, and pop the question when you know it’s the real thing.

TechStars held a very enlightening information session at Andala Cafe this morning. Shawn Broderick did an excellent job conveying what TechStars is all about and what a TechStars startup looks like. Some other people involved with TechStars provided insight as well.

While I didn’t take notes directly (standing room only), here are a few, quick takeaways I gathered. I think these thoughts go beyond TechStars and really speak towards general entrepreneurship.

It’s about the team first, and the product second

Great ideas without a team to execute on it is about as useful as a car without an engine. Find enthusiastic, passionate people you like working with - you’re going to be spending a lot of time together. Refine the idea together. I’ve heard this quite a bit - investors weigh the team’s capability and dynamic heavily, perhaps even more than the product idea.

It’s common for the product’s vision to change

It’s common for the idea of your product to morph into something different. Perhaps the distribution channel won’t work, or the revenue model needs to be tweaked. Embrace these changes as your product matures and you learn more about your audience and yourselves.

Moonlighters need not apply

The expectation is that you’ll be dedicated to the business and present in the program. If you’re thinking you can work on this in your “free time”, you should have a lot of it! Just like split focus hinders daily productivity, split career focus can definitely hinder the progress of your business. In fact, most TechStars companies had prototypes or initial funding prior to entering the program.

Being a solo founder is difficult

It’s hard to do it alone, and TechStars recognizes that. If you’re a solo founder and you want to apply, recognize the problem and identify the resources you need to make your business a success. Seek those resources out actively. Personally, it was a clear message that I need to make connections with more entrepreneurs.

Apply or Start It Up anyway

Shawn said something really great towards the end of it. I’m paraphrasing, but he basically said the only thing definite is that if you don’t apply, you won’t get in. Don’t talk yourself out of applying - take the time to do it and see what happens. Even if you don’t get in, at least it was a good exercise in thinking about your business.

Even if your business fails, you’ll become a stronger and more experienced entrepreneur in result. Personally, I believe the largest asset of being a TechStars company is the access to those that have tried, failed, and succeeded in traveling on the roads you’re approaching.

One tenet of Getting Things Done is to always have a tool that you can use to capture thoughts and actions as they pop into your head. I get crazy ideas in the oddest places and times, so it’s important to have a tool at my disposal to quickly capture them. I always have my cell phone on me, so it’s a natural choice for a capture tool. I needed a service that I could dial into and leave a message which would be then transcribed and in my inbox when I returned to my computer. For a long time, I’ve been using Jott, but Google Voice has taken over as my tool of choice for capturing next actions and ideas.

Why the switch to Google Voice?

1. It’s free
2. It’s easily accessible - In addition to a great web client, GV has a great Blackberry application.
3. Better transcription quality - I’ve found the quality of voice transcription to be better. That means less corrections to make for me when adding actions to my GTD system.

Set up your Google Voice Account for Getting Things Done

1. Add your cell phone to your list of contacts if it’s not already present

1. Edit your google voice settings for the contact you just created. Select “Send to Voice Mail”

1. If this is a phone that you’ve connected to the account, you’ll need to navigate to settings and then the phone tab. Click edit and then show advance settings. Set voicemail direct access to “no”. Be sure to save your changes.

Calling your new capture tool for the first time

1. Dial your google voice number
2. Press 1 to go directly to voicemail once it starts ringing
3. Leave a message

Setting up more automation

• If you have a GMail account, you can set up filters to have a specific inbox for captured voicemails
• If you use Remember the Milk, You could also set up a rule to automatically forward the email notification to your inbox there.

Google Voice has become a vital part of my GTD workflow. Even if you’re on a low tech system like an excellent Moleskine, using Google Voice as a capture tool when you’re on the road is a safe and free alternative.

Last night I spoke @ Boston.rb about everything that happens around code.

Lately, I’ve been heavily interested in discussing the process behind software development. Our field is still very young, and I think there’s a lot we can do to improve the way in which we do our jobs.

Slides are below. I described the talk this way: We spend so much time focusing on conventional programming. Everyone focuses on standards, code clarity, testing, and what gems to use. Let’s chat about what’s done before your fingers hit the keys. Let’s talk about brainstorming, requirements, stakeholders, mock-ups, and writing solid user stories and acceptance tests with Cucumber. Every project has a story - how will your next one end?

If you attended the talk, I would love your feedback at SpeakerRate