Nothing To See Here

This is a test of the gnome-blog client

Posted by tibbetts Fri, 20 Jan 2006 01:01:46 GMT

I'm just testing the gnome-blog client.

Posted in Tools | no comments | no trackbacks

Subversion greater than CVS

Posted by tibbetts Sun, 29 May 2005 15:20:00 GMT

I recently finished upgrading Typo (the software that runs Nothing To See Here) from 1.6.8 to 2.0.x, and at the same time moved my local changes into Subversion. Subversion is a definite improvement over CVS. Being able to rearrange my repository (I did this twice before I was happy with it) was really nice. Once I was used to it, I gained the ability to just add things anywhere I want and figure I could sort them out later. The write-once nature of the directory structure in CVS had always created a lot of anxiety whenever I was starting a project. I think I will shortly be transitioning all of my personal projects to Subversion. All the cool kids are doing it. Of course, if I was a really cool kid I'd be using SVK, but I think I'm not cool enough for that yet.

Posted in Tools, Software Development | no comments | no trackbacks

Book Review: Defensive Design for the Web

Posted by tibbetts Sun, 29 May 2005 15:17:00 GMT

37 signal is one of the neatest companies out there in terms of advancing the state of the art in web design. It seems like they do almost as much as Google, presumably without spending such embarrassing amounts of money. If you haven't check out some of their projects, like Basecamp, Ta-da Lists, and Backpack, you really should. They build really nice web apps. Not only that, but they give back to the community with things like the yellow fade technique and a presentation on How to make big things happen with a small team (slides) (summary).

Jesse Vincent just shared with me a copy of their book De fensive Design for the Web: How to Improve Error Messages, Help, Forms, and Other Crisis Points. It was a very quick read this morning before breakfast, and I think also worthwhile, even though I am not currently a builder of real webapps. I find well designed web applications interesting, and like learning more techniques for doing it. This book is mostly about user-level guidelines, rather than technical detail. But that is important too, since when building technical frameworks it is important to enable the right kinds of user interaction.

The book is pretty good. It gives a set of 40 guidelines with real examples of sites that break and sites that follow the guideline. The guidelines mostly focus on what to do when something goes wrong or how to keep something from going wrong. The core idea is that when looking at the usability of your website, the error cases are as important as the non-error cases.

One area in which I disagree is their support of restrictive forms. They encourage sites to prevent users from entering incorrect data through the use of drop down lists (for things like states or dates) and client-side validation with JavaScript. The principle is that if you keep users from ever entering bad data, then you are sure they won't have a confusing experience fixing errors. I tend to find that these restrictive forms harm my user experience more than they help though. I'd rather type a free-form address, or phone number, or date, and be corrected, than have to mouse- or arrow-around in 6 drop down lists to enter two dates.

Combining client- and server-side validation of form data is an interesting challenge for framework development. Is it possible to easily combine these so that site developers don't have two divergent code bases (most likely in different languages) to maintain? Consolidating this functionality probably requires JavaScript code generation, so that the server-side encoding of the validation rules can be pushed down to the client. I'm not aware of any JavaScript code generation that really makes for a usable system, so maybe this idea would be doomed anyway.

Because it ignores technical details and focuses on user experience, De fensive Design for the Web is a quick read. It's guidelines are not perfect, but they are reasonable. It presents you with a helpful checklist which can be used to improve your crisis points, and thus to improve your sites whole user experience. And it is lightweight enough you can throw it at a coworker without be charged with assault. I recommend it for people doing webapp development.

Posted in Books, Web | no comments | no trackbacks

Setting up Typo: RubyOnRails, lighttpd, FastCGI and being a bad sysadmin

Posted by tibbetts Fri, 15 Apr 2005 13:10:00 GMT

I took most of my evening last night to set up FastCGI and lighttpd. My goal was to serve a Typo, a blog engine based on RubyOnRails. I was thwarted by not knowing RubyOnRails very well, and by knowing FastCGI and lighttpd not at all. The first issue was that Typo doesn't like to run in a subdirectory on a webserver. That is, it wanted to be at ntsh.innocuous.org/, not innocuous.org/ntsh. This offended my sensibilities somewhat, so I decided to beat it into submisssion. This involved tracking down a bunch of places where paths were hard coded, which included a few places in the templates and the CSS. The second issue was that FastCGI on lighttpd seems to have been designed for php. You can easily tell it to delegate *.php to FastCGI. You can tell it to delegate /ntsh/* to FastCGI, but that has the problem that /ntsh/stylesheets/base.css doesn't work, because the RubyOnRails dispatcher doesn't know how to serve static pages. You also have the problem, and this is the showstopper, that for some reason the AbstractRequest.request_url_base function helpfully strips off the directory of your request path when you use it this way. That is, it turns xml/rss/feed.xml intofeed.xml. As you might imagine, losing the xml/rss part confuses the cool new routing feature of Ruby on Rails. So this was unacceptable. I had to give up my delusions of configuring lighttpd in some clean way, and instead use the trick that a bunch of web pages recommended: server.error-handler-404. This configuration file setting tells the server to delegate 404 errors somewhere, and that somewhere can be the Typo dispatcher. Combined with the conditional configuration functionality of lighttpd, this is actually quite sufficient to get Typo up and running. But it still feels like a hack for some reason. The conclusion I'm coming to, as I've come to many times before, is that I'm a bad sysadmin. I expect to be able to bend software to my will, and make it work the way I want, which should be elegant and conform to my expectations. When doing sysadmin work, it is important to use the software you are given, the way someone else designed it to be used. But it always has to get to be 1am before I remember this principle. For anyone who is interested, here is the relevant chunk of lighttpd.conf:


$HTTP["host"] =~ "\.innocuous\.org$" {
    server.document-root = "/var/www/vhost/innocuous.org/pages"

    $HTTP["url"] =~ "^/ntsh/" {
        server.error-handler-404   = "/ntsh/dispatch.fcgi"
    }

    fastcgi.debug = 0
    fastcgi.server = ( 
                "/ntsh/dispatch.fcgi" =>
                    ( "ntsh" =>
                        (
                            "socket" => "/tmp/ntsh.socket",
                            "bin-path" =>
                              "/var/www/vhost/innocuous.org/ntsh/public/dispatch.fcgi",
                            "min-procs" => 1,
                            "max-procs" => 5,
                            "max-load-per-proc" => 4,
                            "idle-timeout" => 20,
                            "bin-environment" =>
                              ( "RAILS_ENV" => "production",
                                "RAILS_ROOT" => "/var/www/vhost/innocuous.org/ntsh"),
                            "check-local" => "disable"
                        )
                    )
        )
}

Posted in Tools | no comments | no trackbacks