Dev Platter

A Clojure Tutorial

2008-08-17T16:43:00.000-07:00

The more I learn about Clojure, the more excited I am about it.

Now that I've reached a less-steep part of the Clojure learning curve, it's time to go back and expand upon the Clojure tutorial I started a few months ago.

PHP Tags are Ugly

2007-11-02T09:25:00.001-07:00

(Or, "Why Are There So Many PHP Templating Engines?")

Remember when most PHP scripts used short tags?

<? $users = get_users(); ?>

Along with the short syntax came the quick and easy output syntax:

<?= $user['name'] ?>

Then, after XHTML hit the scene, the short tag syntax conflicted with the XML processing directive syntax. So the PHP coding standards changed to long tag syntax. This adds 3 characters to every tag:

<?php echo $user['name'] ?>

The tag syntax is not only longer, it forces the developer to use an 'echo' call when before, an equals sign was sufficient. This adds another 5 characters to tags that output something.

The long-tag syntax helped spawn a myriad of templating languages, which many developers consider silly, since PHP already is a templating language.

If you want your templates to be secure and logically correct, you have to escape those characters that HTML considers 'special':

<?php echo htmlspecialchars($user['name']) ?>

Consider the same statement in RHTML (a popular templating system for Ruby):

<%=h user['name'] %>

The RHTML version is vastly simpler.

With that kind of syntax, there's little incentive to use or create a separate templating language.

Firefox with Firebug

2007-07-02T11:09:00.000-07:00

No web developer should be using Internet Explorer as their primary testing browser. As a development and testing environment, Firefox with Firebug is miles ahead of anything based on Internet Explorer. It is beyond me why web developers who know about Firefox with Firebug still choose to use Internet Explorer as their primary testing platform. Somebody, please illuminate.

Note that when I say 'primary' testing browser, I'm not saying 'exclusive' testing browser. Of course web pages need to be tested in all browsers that the shareholders care to support. I'm talking about the first browser you reach for when you want to see what the page you are developing looks and acts like. When the developer is happy how the page looks and acts in one browser, then she tests it on the others.

For those who use Internet Explorer as their primary testing browser, and want to make an argument, have you tried Firefox with Firebug?

Rails Javascript integration

2007-06-19T11:11:00.000-07:00

I just started using the JavaScript integration features of Ruby on Rails.

This is my sixth month using Rails. It was difficult letting go of the tendency to hand-code the JavaScript. I had used Prototype and Scriptaculous at OCP, so hand-coding was a no-brainer. At first glance the Rails/Javascript integration didn't look like it would do much for what I needed. Looks were deceptive, though.

The integration features has its strengths and weaknesses. It's good at sprinkling dynamic behavior on HTML elements. Here's an example (formatted for readability):

<%= link_to 'Hide Comments', '#',
:id => 'hide_comments_link',
:style => 'display:none',
:onclick => visual_effect(
    :blind_up,
    'comments',
    :after_finish => "function() { $('comments').update(); }"
    ) +
    "$('hide_comments_link').hide();" +
    "$('show_comments_link').show();" +
    " return false;"
%>

Here's how it renders (again, highly formatted for readability):

<a href="#"
  id="hide_comments_link"
  onclick="
      new Effect.BlindUp(&quot;comments&quot;,{
          after_finish: function() {
              $('comments').update();
          }
      });
      $('hide_comments_link').hide();
      $('show_comments_link').show();
      return false;
  "
  style="display:none"
>Hide Comments</a>

The big advantage here is that the underlying JavaScript libraries, Prototype and Scriptaculous, can change their API over time, and Rails will adjust, saving the programmer from having to update code to the new APIs.

There are more advantages:

The developer can stick with the Ruby and ROR coding conventions and syntax. No need to switch from underscore naming to camel case. No need to switch to the quirky JavaScript syntax (e.g., new Effect.BlindUp('comments') becomes visual_effect(:blind_up, 'comments')
The syntax for adding the JavaScript code is the same syntax already used for creating HTML elements with Rails' helper methods.
No need to worry about escaping characters that could be mis-interpreted as HTML syntax characters (<, >, "). This is doubly helpful when an attribute such as onclick-"" contains JavaScript with double-quoted strings (see generated HTML above).

As you can see in the example, I had to hand-code some JavaScript, but it was kept down to simple little pieces.

Thunderbird 2.0

2007-06-13T09:26:00.000-07:00

I got sick of Apple Mail, and decided to give the new Thunderbird a trial run.

I had been pretty happy with Thunderbird as a Windows and Linux user, but the smooth experience Apple Mail provided made me switch about a year ago. The never-ending desire to make email management easier made me reconsider Thunderbird.

The reason I switched back is that Thunderbird supports tagging. Email messages can be tagged with keywords, and each tag can have a color associated with it. Combine tags with Search Folders, and the QuickFolders extension, and I'm a happy camper.