Patents are in the news in the tech circle more and more these days. As trolls lurk under bridges and the portfolio cold war gets hotter and hotter, everyone is talking about the fact that something is wrong. What exactly that something is, however, is up for debate. Should the patent system be abolished? What about just software patents? Is the term too long? I don't know, maybe. But one of the primary issues, from my view as a web startup developer, is that what's obvious isn't really so obvious anymore.

A lot has been made in the talkosphere recently about the brewing "multi-Ruby version manager" war, namely RVM vs newcomer rbenv. I'm not here to discuss the relative merits of either software solution, mostly because I take things pretty simple and straightforward in command-line world and I've never run into problems with RVM. What I do think this little fracas displays, though, is a common thread in the Ruby community of having big, blown-up controversies when new things come along. In some ways, I think that such drama is one of the unique features of the Ruby community that make it so vibrant. It's also a feature of the community that can lead to community casualties.

There's been a lot of controversy surrounding the changes to Rails 3.1. It started with an epic GitHub commit thread and the discussion exploded again in the past few days after What the Hell is Hapenning to Rails and Yehuda's response thereto. I'm going to address the issue from a perspective that honestly hadn't even occurred to me until I just said it while in a conversation with some Kansas City Ruby folks after the last meetup: "What if Rails isn't for beginners anymore?"

Emacs vs Vim. iPhone vs Android. Of all of the nerd arguments, none hits closer to home for Ruby developers than HAML vs ERB. Proponents of HAML look at writing HTML as a dirty practice to be avoided at all costs and look down upon "mere" ERB authors. Meanwhile there's SASS, a language syntactically close kin to HAML and, until last week, one that even rode along inside the HAML gem. HAML abstracts HTML, SASS abstracts CSS. I'm not here to stop you from using HAML if you like it. Go for it. However, I'm tired of having an aesthetic choice that some developers make bandied about as if it were "the only way" to do things.

For a software developer there are essentially two paths to extremely enviable positions of respect in the community: either you can be the tech genius behind a multi-billion dollar startup or you can release open source projects that thousands (not millions) of developers find useful. Guess which one is easier to accomplish?

Companies have many ways to benefit from an open source culture. While many arguments can be made about the philisophical implications of choosing to contribute to the open source community, at the end of the day philosophy isn't going to persuade any CEO to adopt open source. The real reason that open source culture is important to a business is because it's a business decision that can bring many real-world advantages over the proprietary-focused alternatives.

It's hard to be "on" all the time as a developer. Despite its engineering aspects, I find software development to be a fundamentally creative act, and creativity requires inspiration

There's a problem in the software development world, a practice that breaks down the free and open exchange of information. This practice is widespread throughout the software development world and can lead to a lock-in mindset that is damaging for the advancement of the community as a whole. I'm talking, of course, about copyleft licenses such as the GPL.

In the past week I've jumped head-first into Android development for a new Intridea project. This is my first time doing any real Android development as well as my first jump back to Java since I graduated from college. I thought it might be interesting to catalog some of my experiences developing for the platform, so here they are:

I think that Android is a very important project that came along at just the right time. It has applications far beyond mobile handsets and we’ll begin seeing Android in cars, tablets, and more in the very near future. This will mean even more work will be poured into the Android ecosystem creating greater and greater benefits for everyone from consumers to handset manufacturers. All that needs to happen to take advantage of those benefits is for Google to help handset manufacturers free themselves of the idea that they need to “make it their own”.