Draconis Software Blog

After updating my Mac to Leopard (MacOS X 10.5), I noticed I had a couple issues when updating Rubygems. For instance, when running “gem update mongrel_cluster”, I would constantly get build errors. After doing some digging, I found that you need to set ARCHFLAGS to your system type. Here’s how you would update all your rubygems on Leopard:

sudo su
[Enter your password]
bash
export ARCHFLAGS="-arch i386"
gem update

Note that you’ll want to change the i386 to the actual architecture you have (my MacBook, for instance, is an Intel processor, while you would want to use “ppc” for non-Intel Macs).

Once I had updated my gems, things started working fine again. For instance, mongrel_cluster was having issues configuring a new project, but after updating the gem using this method, it seemed to be working fine. Hope you find this useful!

Comments (2)

I wanted to point out a great article on ReadWriteWeb today, by Alex Iskold, about the history of Java and the missed opportunities the language has had over the years.  Even if you’re not a software developer, it’s still a great overview of a language that is both elegant and powerful, and the drama of free market competition.

Of course, don’t get the impression that Java is dead!  It’s anything but: kiosks and embedded devices run it, along with consumer-facing websites and plenty of enterprise software.  Many other technologies have been eating away at it over the years, and will continue to do so, unfortunately, for many of the reasons in the article.

Like Alex, I think the biggest issue Java faced (and got wrong) was with the web.  Before there was web 2.0 (and web 1.0 was still being explored), Java applets were the way to integrate interactivity inside web pages.  But applets were horribly slow, limited in their abilities, and complicated.  I think if Sun were able to do it all over again, they shouldn’t have focused on placing Java applets inside web pages, but focused more closely on making Java the core of web development.  Like Alex states, imagine how great it would be if we could manipulate the DOM using Java, say if it were an integrated part of the browser.

But, alas, that didn’t happen.  There’s still time to reinvent how Java and the web co-exist, but for the time being, it’s being edged out in favor of new technologies and languages.  So here’s to you, Java!

Comments (1)

There’s an interesting opinion up by Joel Spolsky, a software developer and founder of FogCreek Software, about where the direction AJAX-based web applications are headed. He makes an interesting, and I feel very apt, comparison with the olden days of mainframes and Lotus 1-2-3, and the current state of the interactive web. For instance, he likens the idea of sites like Google’s Gmail with Lotus 1-2-3, where the development team spent all of their time writing code and optimizing it for the current day’s limitations, rather than looking ahead and adding new wiz-bang features that would give them their “long-term competitive advantage.”

And I think Joel is completely right. Gmail, for one, has been stagnant for the last three years or so, and haven’t been preparing for the future. Check out this blog article from Lifehacker about a comparison between Gmail and Yahoo Mail. Their conclusion? Yahoo Mail has spent the last two years innovating and adding all sorts of new features, while Gmail has very little improvements (except, perhaps, incrementally increased storage levels).

(Read the article)

Just like every other techie in the world, we recently got our hands on some iPhones.  And, as software developers, our first thoughts were: what can we write for this thing?  Well, as everyone else has already pointed out, you’re pretty much limited to writing web apps for the iPhone only, but this doesn’t impact us as much: we’re doing web apps exclusively at the moment anyway!  I’ve been looking into creating an invotrak app for the iPhone recently, and believe I should have something available in the near future.

Craig Hunter has a good article up on his site that discusses some of the limitations of creating applications for the iPhone, though his standpoint is coming as a traditional Mac developer (and he makes great points: it doesn’t make any sense for a user to connect to a web app to input to-do list items):

Business aspects aside, the main issue I see as a traditional developer is that iPhone web app development is still very limited. Outside of some viewport settings, a couple special link types (really only the "tel:" link is new), and some new "-webkit" style attributes, there is little about making iPhone-specific web apps that differs from generic web apps. And that's possibly the most disappointing aspect of all from my standpoint. Apple's announcement states that "developers can create Web 2.0 applications which look and behave just like the applications built into iPhone", but that's not the case.

I believe there’s a lot that can still be done with the tools we’re given, and I look forward to Apple creating more tools in the future.

Comments (1)

A friend alerted me to an article he put together recently regarding deployments in a custom build environment.  It’s intriguing, as my own software company has a similarly-setup system.  The idea is to keep logs of deployments on a MediaWiki-powered internal wiki automatically, allowing developers to see what repository revision was rolled out, the build version number, along with other salient information.

For our internal processes, we wanted to keep a running list of the code release version (such as "0.9.1"), the SVN repository revision that was deployed, the timestamp Capistrano used as the folder name in the Releases directory, and a more human-readable date and time of deployment. The first field, the release version, is an arbitrary string given by the person making the deployment; Capistrano prompts the deployer for this string as the first step in the deployment. The repository revision and release timestamp are both provided by Capistrano, and the human-readable date is provided by Media Wiki.

Some additional coolness: automatically linking to BugZilla bug numbers whenever they’re referenced in the commit messages, and automatically creating “readme” files containing commit messages for each new build.  Check out the article here.

This is a programming quickie, but can be one of those gotchas if you don't know what to look for. As I mentioned recently, I had to temporarily switch back to the Windows side of things when my MacBook died, and in doing, had to learn new tools for getting my work done. One of those tools was to replace Cyberduck, which I used to open a remote connection (via SFTP) to edit files live. Well, I was recently working on a Ruby on Rails project, and I noticed a strange side effect: whenever I would edit a file (a view, controller, etc), and hit reload in my browser, I never noticed the change. It could be the simplest or most complex, but it never seemed to appear unless I restarted Mongrel.

Turns out the problem was actually quite simple: WinSCP, the replacement I was using for Cyberduck, was set to preserve timestamps on files by default. Mongrel checks timestamps of files to determine whether to reload them live (in development mode, mind you, where I wasn't doing any caching), and these timestamps need to be changed by WinSCP in order to show up to Mongrel.

To fix the problem, just click the Preferences icon in WinSCP, click the Transfer selection on the left, then uncheck the "Preserve timestamp" option under Common options. This should now update timetamps correctly and your changes should appear to Mongrel. Enjoy.

I was thinking I'd start a new thread on this blog about some of the things I do on a regular basis to get work done. Lately (like since the release of the new Safari beta), I've been trying out different web browsers to find one that really fits. For a long time, I was using Firefox on my Mac and was doing just fine, until I really gave Safari a chance and realized how much FASTER Safari is over Firefox (and how much that really makes a difference for me).

Using Safari was good for some time, though my biggest issues were the plugins (I really need a good ad-blocking program, and SafariBlock seemed buggy and missing some features), and site support. Since many sites are setup to allow only the most popular browsers, certain features weren't available within Safari. With Apple's latest version of the browser being released for Windows as well (most likely in a ploy to get more developers on board for the iPhone), this will probably change. But for now, I found Firefox was still a better choice for me over Safari.

I then tried out Camino (which is what I'm using currently). Camino is different from Safari in that it uses the same rendering engine as Firefox (so pages that work in Firefox should also work in Camino), though has a much more MacOS-friendly interface than Firefox (and seems a bit faster). So far, I've been very happy with Camino, and I like the built-in ad-blocking feature. One downside, however, is the lack of a Javascript console. Since I do a lot of web development, I've come to rely on Firefox's Javascript console (and the Firebug plugin), so unfortunately, I still need to use Firefox to do this.

Hope you found this useful. I'd like to turn this into a regular thing: discussing what tools I use in my work, why I choose to use that tool, etc.

Comments (2)

As a Rails developer on OS X, I spent a lot of time bouncing back and forth between my web browser and the incredible editor TextMate. Often times, I will complete my latest modification to the source and I'll load it up in Firefox only to find an ambiguous page with the title "Action Controller: Exception Caught". Usually, a quick look through the stack trace reveals the line that is causing the problems. Then, it is back to TextMate to open the offending file, find the mistake and reload the web browser.

This can get tedious rather quickly. I have found that the Footnotes plugin for Rails does wonders and increases my productivity dramatically. It turns all of the lines in the stack trace into clickable [

] links. TextMate registers itself with the OS X so that it receives all clicks of this type - a quick click on the stack trace will open the relevant file and place the cursor at the correct line. In addition, Footnotes adds some extremely useful debug information (and more TextMate links!) to the bottom of every view when the application is launched in the debug environment.

Footnotes is incredibly easy to install directly from within TextMate. To do it, just follow these instructions:

1. Open up your application as a TextMate project by issuing "[
   PLAIN TEXT
   CODE:

   1. ]bWF0ZSAuIg==[

   ] from Terminal.app in the application's root. Then, open any file (I chose [

   PLAIN TEXT
   CODE:

   1. ]YXBwbGljYXRpb24ucmI=[

   ] in the [

   PLAIN TEXT
   CODE:

   1. ]YXBwL2NvbnRyb2xsZXJz[

   ] directory).

2. Make sure that the editor has focus and then press Ctrl-| to bring up the Rails bundle's context menu. Select item #2 (Install plugin) from this menu.
3. In the Plugin Search dialog that appears, type "Footnotes" and then press Go. This should bring up the Textmate Footnotes plugin as the only result. To install it, click the down arrow button on the right. If all is well, the Footnotes plugin should now be installed.
4. Start up [
   PLAIN TEXT
   CODE:

   1. ]c2NyaXB0L3NlcnZlcg==[

   ] and see the pretty links!

Normally if I'm going to write a script to automate a task via cron, I'll use Perl (or lately, Ruby). Recently though I needed to use PHP in order to take advantage of common code from a web application. I was expecting this to be an unpleasant experience, using PHP outside of web programming, its raison d'être. However I ended up being pleasantly surprised with the results.

There are a few cases where it may make sense to write scripts in PHP:

1. Code reuse. This was my reason for going with PHP. If a script is related to a web application written in PHP, it's good practice to avoid reinventing as much functionality as possible. This also makes it easier to write tests directly in PHP.
2. Availability. PHP tends to be widely installed on most machines, especially those with a web server. If you're not sure what type of system the script may be running on, PHP might be safest bet.
3. Widely known. There are a lot of languages out there nowadays, but PHP tends to a common denominator among developers due to its age and ease of learning. This is useful if the code is being written in a team that doesn't have the same knowledge base. Even if someone doesn't know PHP, it's usually pretty easy to pick up given it's similarity to languages like C, Java and Perl.

Luckily, PHP makes it very easy to move out of the web area into scripting. Recent versions of PHP include a Command Line Interface (CLI) which allows code to be run outside of a web server. The CLI also provides for parsing of command-line arguments and easy access to stdin/stdout/stderr. I had never used the PHP CLI before but was able to pick it up very quickly.

My foray into PHP scripting was also made a lot easier though various helper functions. PHP includes quite a few functions that can come in handy when writing a script or doing administration. For file I/O, the file_get_contents()/file_put_contents() pair of functions can be used to read or write the contents of a file in a single line of code, and I found them to be particularly useful. PHP's functions for dealing with the filesystem, image parsing, string manipulation, and database processing are also helpful and may come in handy for the system administrator.

So the next time you need to write a script, consider using PHP, especially if it relates to a web application that's written in the language. And if the decision to use PHP is forced upon you, don't despair, as it might be a lot easier than you think.

Additional Reading:
Using PHP from the command line
SysAdmin to SysAdmin: Scripting admin tasks with PHP
System Administration with PHP

Comments (2)

There are a lot of people out there using WordPress to run their blog (this one does), and understanding a bit of how it works can go a long way to wrangling it to meet your needs. Recently, I wanted to add several buttons to the bottom of my post pages: buttons to submit the pages to digg, Reddit, and other sites. The trick is, I didn't know how to make changes to just the post pages (read: singles) and not to my index page. This article outlines the basics of how WordPress handles displaying pages, and how you can start customizing it a bit beyond just pluggable themes.

(Read the article)