notes.husk.org. scribblings by Paul Mison.

Heroku, App Engine, and AppJet

When AppJet was still around, we had an edit button, a single page of a few dozen lines and a cross-domain AJAX API. This, surprisingly enough, was all you needed to apply some programmatic patching to a bunch of different use-cases

Jonathan Lister, from Joyent Smart Platform – a replacement for AppJet?

In it, he compares Joyent (nee Reasonably) Smart’s model, where you develop locally then deploy with git, to that of AppJet, where you edited online via a web form.

For a long time, I thought that the online-editing model was the right one, and I thought Heroku and App Engine suffered for not supporting it. However, when I was seriously working on my AppJet sites, I found that I ended up developing locally (with their .jar download), then wishing for an easier deployment method than copying and pasting between text files.

For any serious project (and most developers), I’m sure that pattern would be repeated. So why bother with the complex work required to put an editor into the browser (even if Bespin promises to be a drop-in component)? Better to concentrate on the deployment side, either building on a (D)VCS like git or using custom hooks, like GAE’s “appcfg.py update”.

He goes on to say:

I’ve said it before and I’ll say it again – I will pay for what AppJet were providing. People will pay for what AppJet were providing.

Unfortunately, this has a classic problem of having to build a market. Heroku can build on Rails programmers; GAE on Python and now Java developers. Smart has the harder job of getting people to write server-side JS, but at least there are people who think that way, and they can usually pick up git.

AppJet, on the other hand, was trying to persuade people who don’t think they can program that it’s really not that hard. This is a huge problem, and I can see why it’s far easier for their developers to sell real-time web based collaboration, since everyone knows how to write words.

I suppose this is a long winded way of saying that web-based server-side programming is still a way off.

Fix Yr Tumblr Template Titles

I’m a big fan of meaningful titles. Not only do they make your web browser’s history easier to navigate, but they also give bookmarks - both local and shared - meaningful, and they’re good for IRC and IM conversations too. I’m told they’re important for SEO, but I’m not exactly bothered about that one.

When I first published my custom theme for notes.husk.org, the title was fairly useful:

<title>notes.husk.org. 
     {block:PostSummary}{PostSummary}{/block:PostSummary}</title>
     

This gives the index page a title of notes.husk.org (yes, I should be using {Title}, but I don’t care to make this theme public- yet), and if it’s a single post (for example, my previous text post), it also puts the post’s name into the title, so you end up with “notes.husk.org. Irony in Stamps”.

I decided to add a full stop after the PostSummary, but then considered some other cases. For example, what about archive by date pages, like this one? Well, there’s a set of tags for use when you’re on such pages for pagination, and you can (ab)use them like so:

{block:DayPagination} noted on {block:Posts}
     {block:NewDayDate}{Year}-{MonthNumberWithZero}-{DayOfMonthWithZero}.
     {/block:NewDayDate}{/block:Posts}{/block:DayPagination}
     

It’s not terribly clean, because you need to loop over the posts to get the day out, but it is there. However, that still leaves the other sort of pagination, the straightforward 10-per-page sort. That’s easy enough to deal with, though:

{block:PreviousPage} archive page {CurrentPage} 
        of {TotalPages}.{/block:PreviousPage}
        

Here, PreviousPage is only invoked if you’re not on the newest (ie front) page, so the title there is kept short. Thankfully this is more straightforward than the date archive version, but I might end up tweaking the wording a bit (especially as Tumblr has its own concept of “archives”, which are very pretty but not templatable).

Finally, there’s tag pages, which I don’t expose (edit: now I do, on single-post pages only) but you can still get to anyway. These are pretty straightforward:

{block:TagPage}tagged {Tag}.{/block:TagPage}

So that’s it. All the pages on notes.husk.org now have a unique title, even the ones that don’t have exposed navigation. Nifty, huh? The full block, in case you want to work with it, is as follows. Have fun!

<title>notes.husk.org. 
    {block:PostSummary}{PostSummary}.{/block:PostSummary}
    {block:DayPagination} noted on {block:Posts}
      {block:NewDayDate}{Year}-{MonthNumberWithZero}-{DayOfMonthWithZero}.
      {/block:NewDayDate}{/block:Posts}
    {/block:DayPagination}
    {block:PreviousPage} archive page {CurrentPage} of {TotalPages}.
      {/block:PreviousPage}
    {block:TagPage}tagged {Tag}.{/block:TagPage}</title>
    

Google Chrome for developers?

In all the commentary about Google’s new browser, I haven’t seen any note of a feature that’s becoming central to many other browsers - development tools.

After all, Firefox has the pack-leading Firebug, and Safari’s (bundled) Web Inspector is getting more capable with every release. Given Chrome’s process manager, at least a profiler for developers (to make sure their web applications don’t kill it) wouldn’t go amiss. As it is, though, nothing’s been mentioned, and I haven’t seen any notes on extensibility, either (meaning a third party can’t write something like Firebug (although presumably the recently-improved Lite cousin will work)).

On the other hand, it’s not even out yet. Maybe I should give Google a little time.