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.

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.

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.

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.

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.

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.

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

   

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

   

3. 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.

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

Here’s a few reasons why we like it:

• SCRUM can get you the highest business value in the shortest amount of time, assuming your priorities are right.
• It makes the release of your software less of a technical problem and more of a business decision
• It helps to project the amount of value your development team can deliver over a finite period of time
• It helps keep your development team and your product flexible so that it can change with the long-term needs of the business

We try to help all of our clients refine their product development process, so we’ve seen a few roadblocks that get in their way when adopting SCRUM. These are the top 5 ways to cause a SCRUM misfire:

1. Too Much, Too Soon

   Traditional development shops sometimes try to change their ways overnight. If you overwhelm developers with sweeping changes, it’s unlikely that everything will stick. There are many aspects to SCRUM and Agile, so why not take it one step at a time? First, you could start writing user stories. Second, you could start time-boxing your release plan. You can spread out the adoption and sell each facet of SCRUM on its own merit. Being a curmudgeon myself, I respond to change much better when it is spread out over time.

2. Being dogmatic and following the procedures to the letter

   SCRUM is a framework, not a dogma. It annoys me to no end when people criticize others for not having an “up to the letter” implementation of SCRUM. If you’re not changing your ways from iteration to iteration, you’re missing a lot of the benefit that SCRUM provides. During your retrospective, discuss what’s working and what isn’t. Change your ways for the next iteration, and see if things improve. Every company’s culture and operations are different, so why should you try to fit a round peg into a square hole? Bend SCRUM to your team’s will, and find what works for your organization.

   That being said, a lot of people think SCRUM is about having an open floor plan or rapidly changing requirements and development priorities without forethought. If you do only these things, you’re not practicing SCRUM or reaping any of its benefits.

3. No executive buy-in

   We’re getting warmer. It is so important to have C-level support for the long-term adoption of SCRUM and Agile methods. Take considerable time and effort with getting your executive team on board. When you miss your last few stories in a sprint (it will happen), your management team needs to understand the complexity and uncertainty around sprint planning, and how you already have a plan in place to address it.

4. A Bad Product Owner

   I’ve unfortunately seen this more times than I’d like to admit. Bad product owners mean bad user stories and priorities, which translates to sprints that miss the mark in terms of business value. Naturally, if stakeholders and board members aren’t seeing the results you’ve been promising, SCRUM will be forgotten as quickly as what they had for lunch two weeks ago. In the early stages of trying SCRUM out, work with your product owner intensively to make sure he or she is doing a good job of getting the right stories and priorities from stakeholders. If they can’t get make it work within a few sprints, you’ve got to respond quickly and find someone else to fulfill this important role.

5. Split Focus

   So you’ve got this great idea for implementing a framework where you can demonstrate predictable and reasonable estimates of what your team can do in a given slot of time. Your team members, though, are on about 4 different project teams and have their quarterly TPS reports due somewhere towards the end of the sprint. In my opinion, resources that are spread across multiple projects is the #1 cause of SCRUM death in an organization. Fight for your resources! If you can’t get a predictable and dedicated amount of time from your SCRUM team, how can you get can you accurately gauge velocity? If everyone has to work on multiple projects (which is a horrible idea), see if you can get them for dedicated times for every sprint. This will be really hard to do as the project priorities shift and fires need to be put out, so this should be a last resort. If you have some pull in the company, see if you can try restructuring project teams to be more dedicated. Nothing is more important for the successful adoption of SCRUM than protecting your team from distractions and the ever popular “Can you do me a favor?”. As a technical leader or someone that wants to see your product and SCRUM succeed, this is the battle you want to pick.

Are you struggling to get SCRUM working for you? What’s killing the adoption of SCRUM in your organization? We’d love to hear from you in the comments.

The Amazon Advertising API allows you to retrieve Amazon catalog data and use it in your application. It can be really handy if you’re participating in the Amazon Associate’s Program

There are a few users of Amazon Associate that might want to know that I’m deprecating the library in favor of ramazon_advertising. Amazon Associate was an older library that I was maintaining. It uses HPricot and really doesn’t jive well from a design standpoint, so amazon_associate is deprecated in favor of ramazon_advertising

Ramazon Advertising uses John Nunemaker’s awesome library happymapper along with nokogiri selectors. It’s much more object oriented and cleaner, so I hope you’ll enjoy using this library.

Right now, it supports product data acquisition via the ItemLookup request. Here’s a simple example where you can find the product data for a given asin:

@products = Ramazon::Product.find(:item_id => "B000NU2CY4", :response_group => "Medium")
@products[0].title
@products[0].asin
@products[0].upc
@products[0].large_image.url
@products[0].url
#you can also use a nokogiri search string to get elements that don't have built-in accessors
@products[0].get("ItemAttributes Actor").collect{|a| a.content}

The ruby gem is available on Gemcutter and the documentation is available at rdoc.info. Patches and feature requests are welcomed!