So I’ve been having some problems with http://nouri.sh … a free service that converts the blog into an email newsletter. This is great for those of you that haven’t gotten into rss (which seems to be most everyone), and for those that check email more than various web sites.
Anyway, this is a test. I’m switching over to something else, and right now MailChimp is looking like a good candidate. Thanks for your patience.
Started re-reading the latest version of Agile Web Development with Rails, Third Edition. I know this’ll bore many (most?) of my readers, but this kind of stuff excites me. I can’t help it.
Talking about how Rails has taken the world by storm:
But easy on its own doesn’t cut it. We’re talking about professional developers writing real-world websites. They wanted to feel that the applications they were developing would stand the test of time—that they were designed and implemented using modern, professional techniques. So, these developers dug into Rails and discovered it wasn’t just a tool for hacking out sites.
For example, all Rails applications are implemented using the Model-View-Controller (MVC) architecture. Java developers are used to frameworks such as Tapestry and Struts, which are based on MVC. But Rails takes MVC further: when you develop in Rails, there’s a place for each piece of code, and all the pieces of your application interact in a standard way. It’s as if you start with the skeleton of an application already prepared.
Yum.
It’s amazing that people have so much time to fret about today’s emergency but almost no time at all to avoid tomorrow’s.
Agreed. I’ve got a number of emergencies just waiting to happen … and I’m not doing anything about it today, because it won’t be a problem till tomorrow. This is not good planning at all.
So the trend seems to be favoring purchasing software over building it. But I think Buy vs. Build is a slippery slope, and more so, should be more clearly named: Buy and Configure vs. Build on a Framework.
In my mind, the difficulty of configuring down a complex piece of software is really just as difficult as building up a piece of software from pre-built frameworks, plug-ins, and templates.
The intent with Buy is not necessarily to spend money (though I do know people that value software strictly on its price tag), but to follow a basic principle: don’t reinvent the wheel. If someone has already done it, use that first. The question for me is: when does configuration cost more than building?
| Buy or Build | Where you spend your time | Considerations |
| Buy the enterprise tool that does everything | comparing and contrasting various products, learning how to use the proprietary product you select, and a lot of configuring | does more than you want, pay a company for support |
| Build with pre-built frameworks, plug-ins, and templates | understanding your business need, learning how to use general-purpose components, and program what you want | does exactly what you want, pay a consultant for support |
In my experience, configuring is very expensive. I think about my Java programming days when it felt like half of my time was simply spent figuring out how to configure the fancy and expensive server.
From a learning perspective, I’m all about the build. I would much rather have knowledge about a general-purpose framework than knowledge about a proprietary system. General-purpose knowledge has much longer-term value, and can be re-used over and over and over again.
What do you think?
monthly email
RSS 2.0