Adam @ Bitscribe

If you’ve just installed a fresh copy of Ubuntu 7.04 (Feisty Fawn), the following sequence of commands will give you everything you need to run Rails with MySQL or Postgres and Mongrel. This should be run as root (”sudo su -” will get you a root shell).

First, core packages through apt-get:

apt-get install ruby rubygems rake ruby1.8-dev irb rdoc libopenssl-ruby1.8 postgresql-8.2 libpgsql-ruby libmysql-ruby1.8 mysql-server gcc libc6-dev make subversion openssh-server

And your gems:

gem install -y rails mongrel --no-rdoc --nori

If it prompts you for which version of Mongrel (or other gems) to install, the first one on the list (type “1″ and press enter) is almost always right, unless it reads “win32″, in which case pick the first one that says “ruby”. (This silliness is definitely a major weak point of the gem package manager. I’ve created a patch that fixes this issue, which is being studiously ignored by the rubygems maintainers.)

Now, enable mod_rewrite and mod_proxy in your Apache modules (the latter is only necessary if you plan to proxy mongrel, but might as well have it):

a2enmod rewrite
a2enmod proxy
/etc/init.d/apache2 restart

For bonus points, you might want to install a few other useful developer tools:

apt-get install php5 php5-cli php5-pgsql php5-mysql vim-gtk vim-ruby

Here’s a source code editor I wrote in javascript, inspired by CodePress. Feel free to snag and use in your application or modify to your needs. Syntax highlighting and indenting for Ruby is hardcoded, but it could easily be modified by swapping out ruby_syntax.js with your own class. I used Prototype just out of habit, but it could be factored out very easily - I just use it for a couple of simple things like Event.observe.

One thing that really struck me working on this is just how powerful javascript and DHTML have become. I mean, writing a programmer’s editor is hard, right? But I cranked this out in a few evenings. And yeah, I know it’s far from full-featured; but it really blew me away just how easy this was. The only part that was even mildly challenging was handling selections.

I’ve worked with a number of different display paradigms over the years. Early on I was doing character-based output, drawing little boxes and menus and so forth using the upper 127 ASCII line drawing characters. This was great because it was so easy, mostly because everything fit onto a grid.

Later I started working with graphics by manipulating the raw pixels. It took a pretty massive amount of time to do something as simple as make a button, let alone something complicated like a scrolling panel or tabs.

A few more years passed and now there were various sorts of GUI toolkits. I started with hideous, barely usable ones like Motif and the raw Win32 libs. Later I moved on to more enlightened toolkits like Qt and GTK. The box model they offered for packing widgets, coupled with some good visual design tools, made the process of building the display portion of your app pretty reasonable.

Still, it was difficult to mix freeform drawing like lines or shapes with the box-model widgets. And either way, it was just nowhere near the ease of working with those simple character-based displays. That’s the price of progress though, right?

Nope. Somehow - and I’m not sure how or when it happened - DHTML managed to evolve into a combination of the box model (for auto-adjusting layouts) and the canvas model (for freeform drawing). And somehow, working with it, I had a strange sense of deja-vu: working with DHTML is very pleasantly reminiscent of the good ol’ fashioned character grid from my old 80×24 text mode programs.

Maybe because, at it’s core, HTML really is just a bunch of characters. But it’s divided into container nodes that can easily be positioned however, including using box model stuff to get them to line up neatly and dynamically resize with their content. And then it’s like a canvas in that you’re free to position things however, breaking them out of the grid if you want. And then when I see the amazing things you can now do with inline SVG, all I can say is: the sky’s the limit.

Through most of my career as an entrepreneur, my mornings have always been devoted to checking email. This has always seemed like a good way to dive into the day. But recently, I’ve come to the conclusion that this behavior is actually quite poor for productivity. Not because there’s anything wrong with checking email - it certainly needs to be done at some point (or many points) each day. No, the reason why I prefer to do things differently now is that I think a morning email-check starts you off at the wrong level of detail.

Email tends to be very zoomed in. Little notes, FYIs, and requests related to stuff you’ve already done, or may do in the future. But one of the biggest impediments to productivity is getting too caught up in the details, and thus missing out on the big picture.

There are always an infinite number of details, and you can run yourself ragged trying to keep up with them all. It’s easy to do so, because all of these details tend to be so demanding. They sit on a todo list looking terribly not-done, or worse yet, they come in attached to subtly demanding emails from your coworkers, clients, or partners.

The start of the day is a perfect time to look at the big picture. You’re rested, and your head is clear, since it’s been 12 hours or so since you last thought about work. The whole day is ahead of you, full of promise and potential. Now’s the time to ask: what is the absolute most valuable way I could spend the next eight hours?

I’ve been amazed at the insights this produces. I’m more productive - not from doing more work, but from working on things that matter more. Humans tend to get caught up in the details so easily. Once caught up, we rarely stop to question the comparative value of this here vs. anything else you could be doing with your time and energy. But the opportunity cost of that energy may be huge. Morning is a great time to stop and think about this; it’s the one time of day that you’re not already wrapped up in something.

Not surprisingly, I’m not the first to have this insight. Getting Things Done recommends setting aside two hours each week to look at the “50,000 foot view”, or the really big picture. This is one of those “But I don’t have time for that!” → “You don’t have time not to” things. My complaint with the specific method suggested by GTD - doing this review late on a Friday - is that you don’t want to think about the big picture much then. The events of the week are still fresh in your brain, demanding your attention. I find it much more effective to think about this at a time when I’m more distant from the details.