Dev411 Blog

Planet engines are applications that aggregate RSS/Atom feeds and generate composite feeds as well as a website. The generated feeds typically include RSS, Atom, FOAF and OPML. Two popular open source planet engines are Planet and Plagger. I've used both to create planet-style websites and here are my observations:

I just put together an online JavaScript Compressor interface to Dojo Toolkit's JavaScript Compressor, custom_rhino.jar. The JavaScript Compressor is used in the final stage of the Dojo Toolkit build process so gets a lot of use. Although there is already an online version, ShrinkSafe, I put another version together because:

• It would be nice to have a web app that makes custom Dojo builds people don't have to install the JDK and ant to get a custom Dojo build. This is the primary reason and the compressor is a first step in that direction.
• There have been some reports that the JS produced by ShrinkSafe doesn't work (maybe it's using an outdated custom_rhino.jar?). I want an Dojo-based online system to use myself.
• It's nice to have more Dojo, Prototype and Scriptaculous integration tests. I used the client code from ShrinkSafe which uses Dojo to add additional file and do Drag-and-Drop along with the Lucid theme which relies on Prototype and Scriptaculous. I learned that dojo.js 0.3.1 needs to be loaded before scriptaculous.js 1.6.1 or Scriptaculous will break Dojo (I updated the Dojo and Prototype Together article). My minimal use of the Lucid theme actually doesn't need scriptaculous.js so I can get away with loading just dojo.js 0.3.1, prototype.js 1.5.0 rc0, effects.js (part of Scriptaculous 1.6.1) and lucid.js. lucid.js is part of the Lucid theme.

The JavaScript compressor eats its own dogfood and uses prototype.js, effects.js and lucid.js compressed into a single-line, single file. Here are the compression sizes and ratios for the files. Generally you save about 30%.

A number of people are using JavaScriptCompressor.com which is running Dean Edwards' .NET JavaScript compression code. This can be used after Dojo's compressor for even more compression.

Often times you'll want to customize your response specific to the View being used, e.g. setting extra headers. This can be done directly in your View class by creating a process method. All View base classes have a process method defined in Catalyst::View that gets called at rendering time. By adding a process method in your subclass and redispatching to the parent you can do some preliminary processing.

Yahoo! provides a number of cheat sheets for their YUI library widgets however these are in PDF format and not usable as wallpaper. PDF is great as a transport format because you can provide one version for everyone, however transforming it makes it more appealing for actual use. I prefer cheat sheets in standard image formats that can used as wallpaper, espcially useful with virtual desktops.

Here are the YUI 0.11 cheat sheets converted to PNG images of various sizes. Let me know if any other sizes would be useful.

Jim Ley reports on the Google JSON XSS exploit with example code and screen shots of stealing information from the AdSense site. The moral of the story is don't use text/html for the MIME type when returning JSON, use application/json which is an IETF standard (RFC 4627) now. Most browsers should handle application/json fine, however Opera may have problems and you may want to use application/x-javascript for that. Something to remember even if your AJAX code/library doesn't care about the MIME type returned by the server, e.g. Dojo.

If you are using Catalyst and Catalyst::View::JSON, your JSON response will automatically be set to application/json for all user agents except Opera (which gets application/x-javascript) so you're already safe(r).

Two weeks ago, Scott Laird posted a Mongrel patch to the Typo list to make it work with non-root URIs. I'm particularly interested in this because Mongrel is getting more mindshare and my blog uses a non-root URI. The patch has been submitted to Zed Shaw for inclusion but, until it's in, here are some links since I don't think this is easy to find:

• archived email
• mongrel.diff patch

UPDATE: This is now included in Mongrel 0.3.13.4 pre-release.

One of the most valuable assets for a website is its domain name. Whenever I check to see if a new domain I want is available or not, part of me wonders if just the act of looking for domain name would make it unavailable, i.e. if someone is scanning domain name look ups. I've always written this off as being too paranoid but Larry Seltzer reports this is exactly what Chesterton Holdings is doing. Chesterton Holdings' webpage essentially admits they are using an automated shotgun approach to acquire domain names which may result in many names they don't have the rights to:

Larry checks for domain availability on the CNet Domain Search Page (the link provided doesn't seem to go there anymore) and within 30 hours, those domains were registered to Chesterton Holdings. There's some speculation as to how this is happening but it's clear there is a compromise somewhere. I urge everyone to treat domain search aggregators as (the equivalent of) phishing sites and go directly to a trusted registrar for domain availability checking. The other thing you can do is look up lots of worthless and nonsensical domain names to see if Chesterton registers them.

I've been looking for a program that will take full screen shots of web pages even when the web page is larger than the window size on my physical screen, requiring scrolling. This morning I found such a program in Petr Šmejkal's Win32::CaptureIE when it was mentioned by Displeaser on DevShed Forums in the "Screenshot of webpage" thread. It uses ImageMagick for image manipulation.

Many popular sites in the Typo community have chosen not to include www. in their domain name. I was curious about this because it isn't very common in websites overall. Then I ran across a Typo Forums thread saying dropping the www. with a 301 redirect would improve SEO. I wonder if this thread or something similar in the Typo community influenced many of the sites.

Doing a little more searching I found a Digital Point thread where the general concensus is that having www. or not doesn't really matter but you should pick one and do a 301 redirect from one to the other so they don't appear as different sites to search engines. I also checked some high traffic sites in Google to see how they are indexed, e.g. searching on [site:myspace.com] shows MySpace's domain indexed as www.myspace.com. Since dev411.com was indexed with www. already and responding to both dev411.com and www.dev411.com, I simply added a 301 redirect to www.dev411.com.

The following from the Digital Point thread adds a 301 redirect for Apache:

RewriteEngine on 
RewriteCond %{HTTP_HOST} ^yoursite.com [NC]
RewriteRule ^(.*)$ http://www.yoursite.com/$1 [L,R=301]

However, it seems that many sites do not do a redirect and serve content on both www.domain.com and domain.com. MySpace and Ruby on Rails (rubyonrails.org) are two such sites. Although one is preferred, both are responded to with HTTP 200 status. Perhaps the SEO issue isn't as important of a consideration for those sites.

The other consideration when using cookies. If you wish your users to access your website with no subdomain as well as multiple other subdomains, you will need cookies that can work across both uri styles. To set a cookie that will work without a subdomain, set without the Domain attribute. To set a cookie that will work with multiple subdomains set a cookie with a domain that starts with a dot. To cover both bases, i.e. if you wanted to set session cookies that work across different uri styles, set both cookies with the same name.

Edited 16 June 2007 to discuss non-redirecting sites and cookies.

The future of Prototype (the JavaScript AJAX library), both as a stand-alone library and as a part of Rails, is being discussed by the community on the rails-spinoffs list. The primary concerns appear to be: