photo credit: threedots

A couple of weeks ago, Antonio Lupetti shared a list of 10 "handwritten" fonts that he uses in his design projects. He also does a brilliant job of integrating that stuff into the diagrams in his posts, which is why I paid attention when he put out a list (just take a look at his archives and you'll see what I mean).

As I was looking at those fonts and downloading them, I was thinking about sIFR, which I've mentioned before. It's a way to replace text in web pages with Flash on the fly, using fonts that aren't on a user's computer. I've wanted to include that on this site and on several others for quite a while.
Read the rest of this entry »

Photo: Seamus Murray

Lots of the web applications I build or work on are replacements for desktop (often terminal-based). A few years ago, one of my clients asked if it would be possible to wrap their suite of intranet applications in something other than the standard browser.

They wanted a regular Windows menu with links to the individual pieces, like: Time Entry, Address Book, Order Queue, etc.  Many of those apps were written at different times and that approach gave them an integrated application that had its own place in the Windows menu. For them, we built a C# application that wrapped Internet Explorer to accomplish it and they were pretty happy.

I re-used that wrapper several times, including as a way to give clients a way to test sites that were in progress without having to deliver URL's that were likely to change as well as a custom sidebar to help them go through the site.

Fast forward to more recent days and you'll find me frustrated with how long it was taking Firefox to launch a new tab or switch between them. Shortly after killing the tab containing Google Reader everything became snappy again. The next time Firefox was sluggish, I checked the memory during the problem and killed Google Reader again with the same results.

That's when I flashed back to my browser wrapper as well as several articles I'd bookmarked over the last year or so regarding "single site browsers". Since my RSS reading is usually just a background activity, but is nearly always open, I don't really like taking a performance hit during things like web testing as a result of a background activity.

While I could have resurrected the old application to make a Google Reader-specific app, I have no idea where the code is at this point. I thought this might be a perfect task for trying out Adobe AIR. I'd installed the tools and tried a basic test run back in August. I figured this could also serve as an example of how to build a quick and easy single site browser that runs on Windows and Mac (at this point, with Linux in the works).

Read the rest of this entry »

Photo: Geraint Otis Warlow

For quite a few years now, I've used Microsoft's HTA setup for doing quick, standalone applications in HTML and Javascript. Most of those have been for my own use, in large part due to the fact that changes in the Windows security policies mean that if you distribute them, you don't really have a great chance of them working on other people's machines.

Along the way, a few other solutions in this vein have shown up as well. Webrunner is based on the Mozilla platform and works particularly well if your application will reside on a web server and you just want to provide a custom client for it. Webrunner is cross-platform (which HTA's aren't), but doesn't provide much access to the local machine. The "sandbox" that it is able to operate in is pretty much exactly the same as a regular browser.

However, when I saw Adobe AIR (with Linux support planned) being reannounced after the recent renaming from Apollo, I gave it a closer look. Adobe's AIR gives you that same build-it-in-JS-and-HTML approach, with installable final applications. Further, it provides some additional API's to things like the local filesystem.

That feature leverages both sides of the technology. You've got all of the web and the best of the desktop all in one. If you look at the samples page, you'll see a variety of stuff that just doesn't work in a regular browser. I'm messing with ScreenPlay for use in screencasts to do that play-by-play highlighting of what's going on on the screen.

Now, when Apollo was announced, one of the reasons I didn't do much with it was the same reason I have a love/hate relationship with XUL: creating projects was a major pain. I'm perfectly OK with writing code by hand (it's usually what I prefer), but I hate having to stub in dozens of files just to get a "Hello World" project up and running.

So, Aptana's, recent addition of AIR support in their IDE caught my attention and I gave it a spin.

I have to say, I'm impressed so far. It was really easy to set up a basic project, run it from the IDE and build an installable AIR file. In short, their support for this framework lets you focus on writing your application instead of setting up the project and environment. Very nice.

This offers some real possibilities for some of my project ideas, particularly where the client side of the client-server equation needs to be a bit richer or should really be a dedicated client instead of sharing the web browser.

For instance, I really prefer to use a dedicated application to do the writing on this site. All too often, something can go wrong when you just type into a web browser's text box and you lose a bunch of content. However, a nice desktop application, with local saving of drafts fixes that. If I can whip something up that also uses SVN to version and share those drafts, I think I'll have my writing environment. And, AIR with Aptana looks like it might make that easy.

As I've been using Twitter to post frivolous things that aren't worth posting as real posts here on the site, it becomes clear pretty quickly that if you want to post a URL, the 140 character limit gets in the way. The typical solution the people go to is to use something like TinyURL to get a shorter version.

While I could use that service, I decided I'd rather have my own version on my server, so this afternoon, I coded up a quick solution. It consists of an .htaccess file to route everything in a directory called "lnk" to a PHP script. That PHP script either creates a new link or redirects you to an existing one. I also made a quick bookmarklet to make creating links quick and easy.
Read the rest of this entry »

I'm still oscillating between several text editors, unable to find *all* of the features I like in any one place. That's not new territory for me. After all, my ideal OS is a stone soup combination of Linux, Windows and Mac. They all offer things worth having that the others don't have. However, given that I *do* use all 3 platforms, and do much of my work (and play) in a text editor, finding a new contender that's cross-platform is a good thing. I don't care how great Textmate is, if I'm sitting at a Linux machine, it doesn't do me any good.

ActiveState (if you've done any Perl on Windows, you've bumped into these guys) have had an IDE product for a while, priced in that $300 range. A couple of weeks ago, I got a product announcement that they'd released a free programmer's text editor, with the typical goodies: syntax highlighting, autocomplete, custom keybindings, all the "normal" stuff.

Komodo Edit has support (including auto-complete for most) for Perl, PHP, Python, Ruby, Tcl, HTML, CSS, XML, Javascript, RHTML, Template-Toolkit, HTML-Smarty and Django out f the box. The auto-complete works much better out of the box for PHP here than in many of the other options. Theoretically, there can be lots of other support added as well. That's because Komodo Edit is written in XUL (like Firefox and Thunderbird) and it can be extended just like those other platforms: with Javascript and XML. There aren't many extensions yet, but that's the case with any new platform, so I'll be watching for developments in that area.

Overall, I think they struck a nice balance of features in the free editor vs. the $295 full IDE. You can see a comparison of the feature differences, but it basically boils down to things like a full debugger, regular expression toolkit, and a code browser. They're the kind of features that most individual developers can do without. And, if you *do* need them, you are probably in a position to justify the price tag.

Definitely worth a look, especially if you don't want to fiddle with settings to get lots of good functionality. Besides, it's free. So, if you don't like it, delete it and move on.