MOO.com Announces Their API
Moo.com, purveyor of very cool business cards and other paper things, has announced their API. Looks like you could build some very neat stuff with that, and they will be sharing revenue. I love cool APIs like this.
Posts from Approaching Normal...
Moo.com, purveyor of very cool business cards and other paper things, has announced their API. Looks like you could build some very neat stuff with that, and they will be sharing revenue. I love cool APIs like this.
Twitter bashing has become a bit of a past-time for some people. I don’t think that the criticism leveled at Twitter is fair or accurate. It is generally based on a misunderstanding of the technical problems they are facing. In the case of TechCrunch, it’s a desire to drive traffic to the TechCrunch website by fabricating conflict and making personal attacks.
Twitter has had a hard time scaling. This is obvious to anyone that uses the service, and is readily admitted by the people behind Twitter. The present problems have brought out all of the Armchair Architects, and I’ve seen a lot of commentary stating “I don’t understand why this is so hard, all you need to do is [insert gross over-simplification of the problem here]”. It’s very easy to apply some 20/20 hindsight to this problem, but another thing entirely to be in the trenches day after day working to keep Twitter up and running while trying to make large-scale changes to fix the underlying problems.
Here’s the thing. Twitter was started as a side-project inside Odeo. It was developed in Ruby on Rails, the same tool that they had used successfully to build Odeo. While this choice is a major discussion point for their critics, it seems to me to have been a very reasonable decision. Ruby on Rails was what they were familiar with, and at first glance seems to be a good fit. I suspect most people would have made the same decision, given the same situation. The bottom line: They made the best decision they could, based on what they knew at the time. Keep in mind that nobody even knew whether Twitter would gain any traction – certainly none of them could have anticipated the warm reception it has been given.
Obviously their existing architecture isn’t working. The fine folks at Twitter have figured this out, and they are busy rebuilding the system to handle the current load and scale accordingly. This isn’t an overnight fix – it will take time to rebuild Twitter with all-new innards. Let’s be patient. Frankly, the internet needs to take a collective chill pill on this topic.
If you’re not following me on Twitter, you can remedy that here.

One of the most useful ideas I’ve seen in the past few years was Dashboard. Dashboard was an open source project launched by Nat Friedman of Ximian (since acquired by Novell). It’s aim was to provide a “dashboard” of information relevant to you while you were doing work. If you were having an IM conversation with your friend Bob, it would show you the last few emails Bob had sent you, previous IM conversations with Bob, Bob’s contact information from your address book, etc.
I had always thought that Dashboard was an intriguing concept, and one of the few examples of real innovation on the desktop that I have seen in a while. It was a bit dissapointing to see the project get sidelined, but these things happen.
A project emerged recently for OS X that is based on the same concepts, although implemented differently. It’s called Shelf and is written by Tom Insam who is a developer at Dopplr (though all indications are that this is an independant project and not supported or endorsed by Dopplr).
Shelf watches the applications you are using in OS X, and displays relevent information from applications local to your computer as well as web sites (like Dopplr, naturally). Here is Tom’s own description from the Shelf website:
Shelf is an app for MacOS that looks at the current foreground application, and tries to figure out if what you’re looking at corresponds to a person in your Address Book. Then it’ll tell you things about them. ... Just run it. It’ll sit in the background, and watch the foreground application. If it can tie something you’re looking at (the current url in your web browser, for instance, or the target of an open chat) to a person in your Address Book, it’ll open a window and show you their name and picture, and it’ll try to fetch RSS feeds for any URLs in their address card.
Although it’s a newer project (only at version .13), Shelf seems to be off to a promising start. It provides hooks into a number of different applications on OS X already (according to the Shelf site):
This is an idea whose time has come, I think. There are obviously some gaps here, for example if you use GMail as your email application (as I do), or Google Reader for RSS feeds. Integrating with all of these applications is a tricky problem, but it’s not insurmountable. I think it’s certainly worth solving though, as the benefits could be huge.
I hope this project doesn’t fall by the wayside, as it has too much of a potential impact on the way we work. It’s possible that Apple will implement something similar, it seems like the next logical progression of Spotlight.
Are there any other tools like this out there?
I’ve built up a big backlog of links. Here’s the first batch.
33 Pages of command line goodness. I’ve been rocking the command line for almost a decade, but there’s a ton of stuff here I didn’t know.
Update : Hal Pomeranz, who created this document, sent me an email with a link to the PDF version of the document. You can find it here. Thanks Hal!
I want to experiment with both of these languages.
The title is self-descriptive, and as you would expect from Ruby Inside there’s a lot of nice shortcuts here.
This has been pretty well publicized, but here it is in case you missed it. Community Engine allows you to add social networking capabilities (profiles, photos, blogs, forums, and more) to any application simply by adding this plugin. Extracted from live websites, so it is real-world tested.
Awaken is a slick little app for OS X that I picked up as part of the MacHeist bundle. I’ve used it as a timer for those occassions when I need to force myself to work on something for “Just 10 minutes”, but here are some other uses.
I stumbled across a great site tonight, chock full of the geekiest videos I’ve seen. The main sources seem to be university lectures. Very good stuff, and in a variety of disciplines such as Computer Science, Business, Chemistry, and Mathematics.
Check it out: Video Lectures.
This job posting from Nat Friedman got me to thinking, along the lines of my previous post. Here’s the bit that got my mind working:
Keep in mind that we’re not looking for specialists: we’re a small team, and we need people who are willing and happy to shift gears whenever necessary.
It was implied in my previous post, but I didn’t overtly state it: The worst thing that can happen to you as a programmer is to become a specialist. There are very few things you can do that will do more to damage your career potential than to only have expertise in a very narrow set of skills
Becoming a specialist could take many forms. It could mean being tied to a specific language, a framework, a part of the application stack, or a specific tool. I often see it in people who have only done the server component of web applications – they’ve never really coded a user interface. Sometimes it’s .NET developers, who know how to develop web applications, but only using the Microsoft “Drag and Drop” toolset. If you handed them Notepad and told them to code something, they would stare at you blankly.
One of the best things you can do for your career is to be a generalist. Develop a broad set of skills in a wide variety of tools. Become adept at picking up any technology you are handed and becoming proficient at it quickly. Learn as much about as many things as you can. This makes you rare, and very valuable.
In my time as a developer, and now managing a team of developers, I have come to realize that there are two kinds of programmers: the Journeyman and the Craftsman. These terms aren’t mine – I’ve seen them used other places – but they describe the developers I’ve worked with pretty well.
...knows one programming language.
...knows one operating system.
...can’t be bothered to learn something on their own.
...doesn’t know anything about the operating system or hardware their applications run on: “Someone else takes care of that”.
...never masters his tools. “I know my way around my IDE, that’s good enough”
...doesn’t refactor: “It’s ugly, but it works. Leave it alone!”
...only learns about the part of the system they are working on. No need to learn the rest of the system: “That’s not my job”.
...doesn’t want to take on an unfamiliar technology: “I haven’t had any training on x”.
...knows a handful of programming languages, and is always on the lookout for the next one he should learn. He knows that learning any new language will stretch his mind and make him a better programmer in the language he uses day to day.
...devotes time to learning about new technologies, and helps to make others aware of them.
...understands the platform and operating system his applications run on, because he knows that’s the only way to diagnose many problems.
...masters his tools. He can perform magic in his chosen editor, and is always looking for ways to make himself more efficient.
...rarely passes up an opportunity to broaden his knowledge of the system he is working on.
...is always willing to take on something he’s unfamiliar with. He can pick up most things pretty easily, and enjoys the challenge of learning something new.
One craftsman is worth three or four journeymen. Easily.
It’s the journeymen whose jobs often end up moving overseas (and rightfully so, they add little, if any, value).
The longer I manage development projects, the more I value the craftsmen I have around me.

I’d heard (first from Joel Spolsky, I believe) about a cool new travel planning site called Tripit. I’m making arrangements for a trip to St. Louis later this month, and so I thought this would be a good opportunity to try it out. To say the least, I’m impressed.
The first thing that I noticed was the registration process: there isn’t one. All you have to do is take any travel-related email (hotel confirmation, airline itinerary, etc) and forward it to plans@tripit.com. If the email account you sent it from isn’t already registered with Tripit, they create an account for you and send you your registration details. Most sites would have you create an account first, filling out a lengthy form before you could use it. Tripit’s strategy on this is brilliant as it removes all barriers to entry to their service, making it completely painless.
Tripit then takes that email and creates an itinerary. I emailed it a hotel confirmation, and it was able to extract out the hotel name, arrival and departure dates, the city I was staying in and more. It builds a nice itinerary out of this data, and adds some useful information to it like weather and maps.
Tripit also allows you to collaborate, sharing your trip information with others in your party. There’s also a social networking component. If you add contacts who also use Tripit, you can see who else might be close to you on an upcoming trip. I don’t really travel enough to probably get much use out of that, but I can certainly imagine that it will be useful to a lot of people.
One other nice feature is that it can publish your itinerary in iCalendar format, for consumption by Google Calendar, Outlook 2007, or Apple’s ICal. It also appears to have good support for mobile devices, though I haven’t had a chance to try that out. One other nerdy item to note is that they’ve marked up many of their pages with Microformats.
All in all, Tripit is an impressive service so far. I would definitely recommend giving it a try – it’s as easy as it gets.
A list of random and assorted things I have found lately
“A blog about open source technology at The New York Times, written by and primarily for developers. This includes our own projects, our work with open-source technologies at nytimes.com, and other interesting topics in the open source and Web 2.0 worlds.”
There are a lot of nice posts in there, including one on how they used EC2 to convert their archives to PDF.
Desert is a component framework for Rails that allows you to seamlessly define in your plugins:
- Models
- Controllers
- Views
- Helpers
- Routes
- Migrations
- Plugin Dependencies
I’m going to check this out for something I’m about to start on.
Five Runs is conducting a series of 5-question interviews. So far they have interviewed Chad Fowler, Michael Cote and Peter Cooper.
Paul Graham has released Arc, his long-awaited Lisp dialect.
Arc is designed above all for exploratory programming: the kind where you decide what to write by writing it. A good medium for exploratory programming is one that makes programs brief and malleable, so that’s what we’ve aimed for. This is a medium for sketching software.
‘nuff said.
I’ve owned the Macbook Pro for a little while now, and am getting comfortable with OS X. I think it’s time to dig a little deeper though, so I’m going to buy a book or two.
I’m a long time computer user, and have a lot of *NIX experience, so I’m not looking for something too basic. I’d like something that will teach me the ins and outs of the whole operating system, and let me go from being “comfortable” to “power user”. I’m leaning towards Mac OS X Leopard: The Missing Manual, but I thought I would ask here if anyone else has any other recommendations.
Peter Cooper (who I interviewed recently ) has just announced SwitchPipe, which aims to make deploying and hosting Rails (and other frameworks, such as Django) applications easy. From the site:
Introduction / Overview
SwitchPipe is a proof of concept “Web application server” developed in Ruby. More accurately, it’s a Web application process manager and request dispatcher / proxy. Backend HTTP-speaking applications (Web applications) do not run directly within SwitchPipe, but are loaded into their own processes making SwitchPipe language and framework agnostic.
SwitchPipe takes control of, and manages, the backend application processes, including loading and proxying to multiple instances of each application in a round-robin style configuration. As an administrator, you can define the maximum number of backend processes to run for each app, along with other settings so that you do not exceeded preferred resource limits. SwitchPipe quickly removes processes that “break” or otherwise outlive their welcome. For example, you can let SwitchPipe kill any backend processes that have not been accessed for, say, 20 seconds. This makes hosting many multiple Rails applications, for example, a quick and non-memory demanding process, ideal for shared hosting environments.
...
SwitchPipe’s goal is to be:
- super easy to configure
- the easiest way to deploy multiple HTTP-talking backend applications
- painless in terms of management; no hand-holding of different applications is needed
- a permanent daemon that can handle configuration changes in backend apps “on the fly”
- a reliable solution on Linux and OS/X (and anything POSIX compatible, ideally)
I haven’t spent much time with SwitchPipe yet, but if it lives up to Peter’s claims this will dramatically simplify hosting Rails/Django/Camping/whatever applications.
What’s interesting to note is that this originated with Peter’s widely read article on why such a thing was needed. Unlike a lot of other people who have complained loudly about the state of Rails on shared hosting environments, Peter put his time and talents towards creating a solution which he then released within 3 weeks. This is definitely something we need more of.
So what are your thoughts? Is this the solution we’ve been waiting for?
A list of random and assorted things I have found lately
“A blog about open source technology at The New York Times, written by and primarily for developers. This includes our own projects, our work with open-source technologies at nytimes.com, and other interesting topics in the open source and Web 2.0 worlds.”
There are a lot of nice posts in there, including one on how they used EC2 to convert their archives to PDF.
Desert is a component framework for Rails that allows you to seamlessly define in your plugins:
- Models
- Controllers
- Views
- Helpers
- Routes
- Migrations
- Plugin Dependencies
I’m going to check this out for something I’m about to start on.
Five Runs is conducting a series of 5-question interviews. So far they have interviewed Chad Fowler, Michael Cote and Peter Cooper.
Paul Graham has released Arc, his long-awaited Lisp dialect.
Arc is designed above all for exploratory programming: the kind where you decide what to write by writing it. A good medium for exploratory programming is one that makes programs brief and malleable, so that’s what we’ve aimed for. This is a medium for sketching software.
Monday Questions is a recurring series on Approaching Normal. For more questions like this, please visit the archives.
The text editor is the programmer’s main tool. The best programmers I know are masters of their chosen editor, whatever that might be. Knowing how to be productive with your editor can make the difference between a good developer and a great developer. So today, I’m asking you to share with us what your favorite text editor is and why.
My editor of choice is Emacs. It’s the first “real” editor that I ever bothered to learn well. I started learning it right after reading The Pragmatic Programmer for the first time. I have a love/hate relationship with Emacs. It’s an amazingly powerful editor – there’s very little that it can’t do. Unfortunately, it’s as ugly as they come and a pain to customize. Lisp is cool in the same sense that Latin is cool. Beautiful language, but hardly anyone speaks it. I had hoped that when I made the move to OS X, I would switch to TextMate. I tried it, and even bought the Peepcode screencast on Textmate. In the end though, I couldn’t give up Emacs. It has too many features that I rely on that Textmate just doesn’t have, like split buffer windows and dired mode.
As always, post your answer in the comments below.
Monday Questions is a recurring series on Approaching Normal. For more questions like this, please visit the archives.
Most people, it seems, listen to music while they work. Whether it’s to aid concentration or drown out their coworkers, I see most people do it. So today’s question is:
What music do you prefer to code/design/whatever by?
I have very diverse musical tastes and listen to just about everything, but I find that lyrics are distracting when I need to concentrate. So I prefer Jazz like Miles Davis and John Coltrane, or classical like Yo Yo Ma when I need to focus.
Monday Questions is a recurring series on Approaching Normal. For more questions like this, please visit the archives.
As previously noted I recently switched my development environment from a Linux laptop to a Mac. This Monday’s Question is: What is your development machine? Tell us your OS, hardware specs, etc.
This article is the second in a series of interviews that I will be conducting over the next few months. For the other interviews, please visit the archives

I live in Seattle, home of the world’s most pretentious Ruby brigade. I’ve been doing professional development for almost 10 years.
Definitely a developer first. I love solving problems and reading about other people’s approaches to software development.
However, I’ve worked for many startups and it was probably inevitable that I would eventually ask the question “Could I run a business of my own?”
I had wanted to start my own business since high school but didn’t pursue it until recently. In 2002, I wrote a shareware RSS reader and started selling it for $15 online. Cory Doctorow even bought a copy and gave me some feedback, which I unfortunately never implemented.
I only sold a couple hundred copies, but it was a good lesson in developing a product, getting feedback, and advertising. One lesson I should have learned is that there are no overnight successes. Even a good idea often needs 6 months or a year of development and promotion to get off the ground. Unfortunately, I promoted the RSS reader for only a few months and then let it slowly die.
I also started an online todo list that has accidentally resulted in almost 10,000 signups. I haven’t figured out what to do with it yet, but it taught me a lot about deploying Rails applications.
I started working with it in January, 2005. There weren’t any books, so I started by reading the entire online documentation, method by method. Everything just seemed to fit together and I loved the way that common web development tasks were wrapped up into simple methods.
I still recommend reading through the entire API documentation. It’s the most thorough source available.
At first, I appreciated the high-level completeness of the API. Most of the common things that a web developer would need to do were all there, from database relationship definition to form building. While reading through the documentation, I kept thinking “Yes…I could use that feature!” or “That’s so useful…why didn’t I think of that?”
I had built my own MVC framework in Perl, but it was a chore to keep it consistent and bug-free. With Rails, I found a framework that was already capable and was also being constantly improved.
Currently, I appreciate the inventiveness of the Ruby community. Most of the software I rely on day to day isn’t part of the Rails framework at all. I use Haml templates exclusively (I hate having to type all those angle brackets and end tags!), Haml’s Sass templates for my CSS, and make_resourceful whenever I need a REST controller.
I received a copy of the Django book earlier this month (which was very well written), but I cringe at the thought of doing web development without Haml. I’ll probably need to write a few demo projects just to become familiar with it.

I have a pretty standard Rails setup with a Mac, TextMate, FireFox with the web developer and FireBug plugins. For everyday browsing, I find Camino to be a bit faster.
I use the tcsh and the standard Apple terminal. MailPlane for email, though I’m probably going to switch back to mutt now that Gmail offers IMAP.
I try to reduce distractions, so I run with a solid black desktop picture and the MenuShade utility to hide the menubar. Sometimes I also use Spirited Away to hide background applications.
I’ve got a great desk from Anthro Cart that can be used sitting down or standing up. Plus, there are attachments for all my audio gear, speakers, etc. A comfortable keyboard from TypeMatrix and the Freedom chair.
autotest and rstakeout for running tests or other commands automatically.
In addition to the Rails plugins mentioned above, I use memcached and acts_as_state_machine in most of my web applications. The Hodel logger is a must for viewing the real-world performance of a web application.
I’ve been experimenting with dtrace and hope to learn how to use it.
I had wanted to do something with teaching and digital distribution. I read many books and they are often out of date by the time they hit the shelf.
I saw how popular the original 10-minute Rails blog screencast was and I also noticed that many other people were doing screencasts. However, they often had distracting quirks, such as being shot fullscreen and delivered at gigantic resolutions.
So I figured that I could do a really polished screencast that would be more informative than many books and cover timely topics. It started with one and has turned into a full time business not only for me, but also for a few other authors who are writing PDF books.
I’m currently using Final Cut Pro for editing and iShowU for screen capture. I also use OmniGraffle for diagrams and other utilities such as XScope and OmniDazzle.
In fact, I’m working on a screencast right now that shows how I create a screencast.
Technically, it only takes about a week to film, dub, edit, and release. But often, I’ll do a few weeks of research about a new topic, or I’ll re-film a screencast after receiving feedback.
For the git screencast, I created an entire hour-long screencast and then started again from scratch after receiving technical feedback from Junio Hamano, the maintainer of git.
The information that developers need is increasingly time sensitive. I don’t scale very well as a single author, so I was looking for ways to work with other authors to produce relevant content on topics that developers want to learn about. PDFs are a great way to do that, and are even preferred by developers because of the ability to search the text or copy and paste code snippets.
A printed book usually takes 9 months or more to write, and authors often end up exhausted, discouraged, and poorly compensated.
So I built a system that works with standard Textile-formatted text. So far, authors have responded very favorably and it has even made translation very easy. I have a half-dozen authors working on some great topics that will be released over the next few months.
There are many important topics that aren’t very well documented. I want to make those topics accessible to developers at an affordable price.
Rails developers have supported my business from the beginning, so I’ll definitely continue to publish Rails-related content.
But I hope to branch out into other topics, especially where it’s of interest to the Rails community as well as the greater web development community. The Prototype.js Javascript screencasts were quite popular but didn’t require knowledge of Ruby code. I’m hoping to do a series on CSS that will be useful to developers, no matter what framework they are using.
I’ve been fortunate to have been working on PeepCode full-time since May, 2007. It was a big decision to make, but it has definitely been the right decision. Overall business has more than doubled since then and I’ve been able to collaborate with many intelligent developers.
Scott Barron started it, thanks to encouragement from David Heinemeier Hansson. I contributed a few shaky interviews starting in July of 2005 and have done almost all of the subsequent 60+ shows.
I just bought a ticket to San Francisco for the sole purpose of interviewing Rails startups for the podcast. It will be right around the time of the MacWorld expo, and I hope to post the first interview almost as soon as it is recorded.
Right now it’s all PeepCode! There will be a book on ActiveMerchant that I’m excited to see published this spring. I also have an idea for a series that will compare Rails to other popular web frameworks.
Monday Questions is a recurring series on Approaching Normal. For more questions like this, please visit the archives.
It’s New Year’s eve, so we’ll suspend the geekery for another week. Today’s question is What are you doing New Year’s Eve?4
In the Wright household, we’re unsure. We may go out, we may stay in. When you have three young children, New Years Eve isn’t all that interesting anymore.
Monday Questions is a recurring series on Approaching Normal. For more questions like this, please visit the archives.
Since it’s Christmas Eve and all, I’m taking a break from the usual geekery that goes on here. Today’s Monday Question is: What is your favorite Christmas tradition?
I’ll start with mine. For as long as I can remember, on Christmas Eve, my mom took my sister and I on a drive to look at the lights on the houses. It’s simple, but it’s a great memory. My wife and I have done this now every year since we’ve been married.
What’s yours?
Note: This is the first in a series of interviews I will be doing over the coming months.

I’m Peter Cooper, a Ruby developer and author from the wild, barren north of England. I’m probably best known in the Ruby community for being the author of Beginning Ruby, published by Apress, as well as the editor of Ruby Inside, the most popular Ruby related weblog.
It tends to vary year by year! I’ll go through periods where I’ll happen to be developing more for other people, and others when I focus on my own projects. Having made a successful exit with two businesses in 2007, however, I’ve been leaning towards doing more for myself. I’m likely to drop the “enterpreneur” stick soon though, as it tends to be that I merely follow my nose and the business side of it just falls into place by itself. I’m more of a curious bumbler by nature.
Rails first came onto my radar in October 2004. It was reasonably primitive then but will still appealing. As such a nascent technology based on a relatively unheard-of language, I was more interested in poaching the ideas for my favorite language of the time, Perl, and began developing my own equivalent. I developed a whole application on my framework, but it was shaky and I decided to give Rails a try, while promising not to get too bothered about learning Ruby itself.
My first Rails application was for a client and I developed a whole photography site for them in perhaps a quarter of the time it would have taken me with Perl. At that point I was hooked, and I also began to venture into the Ruby on Rails IRC channel on irc.freenode.net which, at the time, was great fun. What was it about Rails that appealed to you?
The biggest selling points were the abstraction and the speed / ease of development. I pride simplicity and economy above all, so developing Web applications in Rails was an eye opener compared to the clumsiness of Perl (I mean, take a look at mod_perl sometime!).
Up till now, my development environment has been under OS X. I’ve stuck with MySQL for a database engine throughout, merely because I know it so well by now. Firefox was my browser of choice on OS X until Leopard, but now I mostly use Safari as it’s come on in leaps and bounds. I use Textmate as my primary editor, although I don’t know how to use any of the macro / snippet features.. it’s really just a text editor with syntax coloring and a file list down the side for me. I like to keep things really simple with little to remember.
At the deployment end of the chain, I use Linux, nearly always Red Hat Enterprise or CentOS.
As with most Ruby and Rails developers, my applications all end up deployed on Linux machines. While open source technologies make it easy to jump between different flavors of UNIX, something about OS X’s “everything for everyone” approach irks me when it comes to doing development work. It’d be like taking my city car on the track or putting a race car on the streets.. you can do it, but it feels better to have separate cars for different situations. While I don’t find Linux particularly useful for graphics work and general day to day use, it feels like a more natural operating system for developing on at the command line level. With the minimalist dwm window manager, you can even get all of the GUI control at keyboard level, meaning you can focus on work rather than moving pretty windows about.
I’m also attracted by the ability to run a single X11 server in my house, then be able to access the same development environment from different machines around the house without needing to sync up. OS X can be used as an X client quite easily, so I can be developing in the same environment anywhere and on any machine. I’m still in the process of setting all of this up though and working out the pros and cons for day to day use.
I don’t tend to have many libraries or tools installed. I’m a big fan of the command line clients for things like MySQL, Subversion, and Git, and I don’t run my IRB with any elaborations. The only gems I tend to install are Rails, Mongrel, Daemons, Hpricot, and RMagick, although installing OS X Leopard has updated this somewhat. Mongrel and Daemons are my “favorite” gems. Mongrel because it makes building super-fast HTTP daemons so easy, and Daemons because it means I can forget all of the dull process involved in daemonizing and controlling applications and services I build.
There’s no escaping the fact that big businesses move slowly. Their technology departments can be frighteningly conservative and there’s often only one “approved” way to do things. This is especially true of deployment. Even medium sized companies freak out when you talk about installing Linux and putting your own Ruby / Rails stack on top. They need everything documented, centralized, and consistent. As such, the Java platform has become a real bedrock for servers and application deployment in the enterprise, and JRuby gives us the opportunity to target all of those established enterprise ecosystems by making Rails applications easy to deploy on JBoss, Tomcat, and other Java application servers.
JRuby is definitely the key to getting Ruby and Rails applications deployed inside most major companies whose ecosystems have no time for alternatives just yet. JRuby is definitely the direction you should be heading for these sorts of deployments, and I think this area is going to become significant to most profit-driven Rails developers very soon.
My book is for people who either have a reasonable understanding of programming, even if they’re not that good at it, or people who have experience with languages other than Ruby and want to move across. For people with absolutely zero programming experience I’d recommend Chris Pine’s Learn to Program. For already experienced Ruby developers who want to become real hotshots and delve into the deeper mechanics of the language, I’d recommend Hal Fulton’s The Ruby Way. Both of these books cover totally different ground than Beginning Ruby and even complement it, depending on your skill level.
I’m an opportunist developer who tries to use the right tool for the job in order to quickly capitalize on some untapped market or niche. As such, I don’t tend to learn languages for fun, at least not to a deep level. I’ve taken a look at languages like Erlang, Haskell, Io, and even written a little Lisp, but don’t see any immediate reasons to learn these languages to a professional level. It’s certainly worth understanding their paradigms and styles, however, to take something useful back to your more productive environments. Lisp has certainly given me a big appreciation for a lot of oblique programming techniques.
Opportunistic sales. In the first case, with Code Snippets, I was approached by a friend who was interested in buying the site, but after checking with my network of contacts it turned out Rick Ross of DZone was also interested and the site made a great fit with DZone, the “Digg for developers” as I call it.
Ay, there’s the rub! Most of the projects I’ve had success with have been tools or services that I’ve desperately wanted to use myself, so I’ve had a lot of motivation to see them through. When you don’t have any nagging wants, however, you have to really dig deep to come up with the ideas. I’m currently in a bit of a low gear, with it being the end of the year, as well as having sold two businesses this year, but I hope to get back on the saddle really soon and release some more projects next year. For the meantime, however, I’m keeping Ruby Inside updated as best I can and keeping my nose to the ground!
Beginning tomorrow, I’m going to be publishing a series of interviews. I’m going to start with notable people from the Rails community, but over time I would like to branch out into other areas. The first interview will be with Peter Cooper, whose book Beginning Ruby I reviewed recently.
In the coming weeks I will be publishing interviews with Geoffrey Grosenbach and Robby Russell, with more to follow.
If you have suggestions for other people I should interview, please leave a comment or send me an email (my email address can be found in the “About” section of my homepage).