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!

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!

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).

As Joel has pointed out, the future of web applications is going to involve a standardized interface, providing UI-level features, interoperability, and a common platform for development. And there’s evidence of this happening. Several frameworks have come out recently that are generally very good: my favorites are YUI and prototype/scriptaculous. Very helpful, though the YUI is, I think, especially useful, as it provides a lot of very clean, useful interface-based functionality perfect for developing rich applications. But, it’s far from lightweight. And Joel’s point is: that’s okay.

I think we’re nearing a critical mass when more online software development will use an existing framework like YUI, so the common code between these sites will more likely be in users’ caches, therefore speeding up load times and reducing bandwidth costs. And, on top of that, there is likely to be further innovation to speed this up: building some amount of the framework code into browsers, say, or different, longer-lasting caching mechanisms strictly for Javascript framework files, or a whole number of other options.

Whatever happens, I think the biggest winners over the next several years will be with the developers who spend their time making the best applications, and let others (like browser developers) worry about keeping it fast. That’s not to say, “go out and make super-slow sites”, but rather to realize you shouldn’t spend all your time developing faster applications while neglecting features and other forward-looking progress.

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.

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.

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.

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.

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 txmt:// 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 “mate ." from Terminal.app in the application’s root. Then, open any file (I chose application.rb in the app/controllers 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 script/server and see the pretty links!

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

WordPress works in an interesting way: posts are displayed as query results, which means a list of posts that meet certain criteria (either as search results, or time-based, as specified in the URL) are displayed per-page. This can get tricky when you start to dig into the theme code for your site (especially if you’re not familiar with PHP). The solution is to learn a little about how WordPress works.

First, when displaying posts, WordPress works by looping through a list of posts that meet the criteria specified, and displaying each (The Loop). This is done by checking if any posts meet the criteria, and if so, to iterate through each and print the title, a blurb about the post, and any other information the designer decides to include. A simple example, from the WordPress Wiki, looks as follows:

[php]
if (have_posts()) :
while (have_posts()) :
the_post();
the_content();
endwhile;
endif;
[/php]

This loop can be used for both your index page, and for individual (single) pages. The only difference is the number of posts returned – your index page, for instance, may have dozens of posts come up when no criteria is specified, while an individual page, with enough criteria to select exactly one posting, will display the entire article. WordPress does all of this in your index.php template file.

For most themes, this is enough: the major difference between a list of posts and an individual page displaying all content for a given post is often that the content is either cut off (with a Read More… link included), or displayed in its entirety. But what if you want to get into further customization? In my case, I had just an index.php file and wasn’t quite sure how to add my “post to” buttons (I wanted them to only show up on a complete post page, and not on any list pages). Well, the solution is to copy your index.php file and name it single.php. The single.php temple file is used instead of index.php (when it exists) to display a single posting page.

Using the single.php file, you can customize how your individual story postings will appear without affecting the appearance of other pages (your index page, search results pages, special pages, etc). Hope you found this useful.