RubyRags, a Littlelines project
We’re really excited to announce today an exciting new initiative for RubyRags (a community-spirit-building project selling Ruby and Rails themed apparel to Rubyists across the globe).
We at Norbauer Inc created RubyRags a few years ago and it grew quite popular in that time, but our consulting work prevented us from giving the project the proper attention. As of today, however, our pals the brothers Matt and Josh Sears over at Littlelines are taking over the RubyRags reigns, and they have some truly awesome plans to improve the operation and give it the attention it truly deserves. We believe they’re the perfect fit for the project: not only are they huge supporters of the Ruby and Rails communities, but they also have a keen design sensibility and an enthusiasm for e-commerce.
We can only share a few of the new things in store for RubyRags with you publicly now. But, suffice it to say, Littlelines plans to restock all the popular designs that have run out of stock, and more importantly, they plan to start releasing new designs at a regular interval, similar to how PeepCode releases screencasts. RubyRags hasn’t introduced a design in years, so this is a particularly exciting development, and I’m really eager to see what they come up with (especially since Josh is an illustrator himself).
Join the RubyRags mailing list for to stay in touch with what RubyRags is up to in the coming months.
Congratulations to Littlelines, and to all of us who will get to benefit from what they have planned!
Ryan Norbauer's commonplace book
There are times when I have bits of text and other effluvia worth sharing that are somewhat extraneous to the world of web development and business and thus not quite appropriate for this space.
I’ve started a separate little notebook on the web for that purpose. For those of you who have enjoyed my writing in this space, perhaps you’ll enjoy what I’ll be collecting over there too. Or perhaps not. Maybe I won’t either. It’s an experiment. We’ll see how it goes.
Either way, I encourage you to read the introduction to my new Commonplace Book and decide for yourself.
The Psychology of OmniFocus: How to Wrap your Head Around the Finest (and Most Perplexing) GTD App on the Market
Though I have been hard-core enthusiast and sometime black belt of GTD since around the age of 20 (i.e., nearly a decade), I’ll admit to having had a certain initial reluctance and skepticism about OmniFocus. Perhaps this was due to the seeming eternity the notional app spent as vaporware, but I think it was mainly my bafflement at first opening the program shortly after its beta release. In its tiny default font and weird spacing, it presented the user with an empty list and almost no guidance on what the program does or how to use its amazingly complicated array of options for every conceivable combination and permutation of projects, lists, children, parents, siblings, start dates, dependencies, etc. I futzed with for a few minutes, realized I didn’t have a full week to spend learning a piece of software that seemed to make a simple task more complex and didn’t allow me to sync my data across computers, and I gave up.
As syncing and other improvements like increased clarity of features and flexibility of configuration options and the ability to customize the appearance of lists came along, OmniFocus was already dead to me. It wasn’t until much later when a chance frustration with the weight and drudgery of my own makeshift pen-and-paper GTD implementation drove me to give it another try that I learned precisely how amazing an implementation of David Allen’s system the folks at OmniGroup had ultimately come up with. It renders elegant and easy elements of the GTD workflow that were previously either cumbersome or completely impossible to do properly with a paper-based system (or, worse, a system based on a hack of an existing piece of software built for another purpose).
I will add, however, that it wasn’t until spending a few hours slogging through the manual that I finally “got” this about OmniFocus, and frankly I can’t imagine anyone else just downloading the software, playing around with it, and making it their primary productivity tool spontaneously. The learning curve for OmniFocus is honestly far steeper than with any other piece of desktop software I have ever used. What I have since learned, however, is that the payoff is very much worth the effort.
Read MoreDining on Charles St last night, overheard at the neighboring table
Interlocutor 1: I’m convinced that we’re going to have to do some vaporware in the mobile space by Q4.
Interlocutor 2: Yeah, I’ll divert a couple FTEs. We’ll put out a press release. It’ll be good.Design worth caring about.
Design should always be about the humans who will be dealing with the designed object—whether it be a building, a website, or a piece of furniture.
Interview on The Official Ruby on Rails podcast
If you’re interested in hearing me chat a bit about Rails consulting, social networks, and whatnot, give a listen.
Dueling
When they started off, it was all about delegates. Now that we have more delegates, it’s all about the popular vote. And if that does not work out, they will probably challenge us to a game of cribbage to choose the nominee.—David Axelrod (Obama Campaign Chief Strategist
I had occasion to partake in a brief chat with David Axelrod in Boston recently, the details of which gave me serious reason to believe he may be the awesomest political flack in the history of America, but this just makes it official.
Interview @ Slash7
My infinitely awesome friend and colleague Amy Hoy just published a fun conversation I had with her a while back. It’s pretty airy-fairy and theoretical, but that’s what makes most good conversations fun.
Mention in Wired piece on 37signals
I had a nice time chatting with Andrew Park of Wired recently about some of the subjects on which I have so frequently opined in this and other venues: simplicity in software, programmer happiness, and the role 37signals has played in promulgating those values in the tech world.
Park cited me as a source in the resulting article; (and graciously made a salutary reference to Lovetastic and my consulting firm.) It’s an interesting article, and I’m glad to see more journalists paying attention to the fact that Rails and 37signals applications are important as much for having shifted the contemporary discourse about software as they are for the technologies in question themselves. But I think if the article had any weakness, it was that it didn’t very thoroughly discuss something to which it only alluded in its closing sentence: “’I’m not designing software for other people,’ Hansson says. ’I’m designing it for me.’” Not enough attention has been paid to the growing movement in the software development community that suggests that programmer happiness is the most important factor in making quality software—the argument that code is meant to be read by humans first and computers only secondarily—that in order to write software that addresses real human needs we need to approach the problem of software development from a more human perspective. These “emo programmers” (if I may borrow Kathy Sierra’s coinage, which was originally intended as a joke) recognize that the most costly aspect of software today is the labor involved in making it. Performance is cheap. On the other hand, creating, customizing, and maintaining huge (and hugely complex) bases of inscrutable software code is very expensive. There is increasing sentiment in the software world that we should be happy to take performance hits if it means the process of software development can me made more sustainable, pleasant, and simple. That’s what Rails does. And in this it embodies a sweeping philosophy about the manner in which software development should proceed, which stands firmly in opposition to the prevailing view in much of the Fortune 500 world. I’d like to see us take up “emo programming” as a badge of pride to describe this nascent philosophy. Original terms of dismissiveness like “suffragette” and “tory” have subsequently been taken up as banners around which to rally movements, so there is no reason we shouldn’t do the same. Hopefully this article is an early sign that more people are paying attention to this movement and taking it seriously for what it is: an entirely new way of thinking about the how and whys of software development, and about the fundamental relationship between humans and their computers.
