Note: I've reorganized this site to use tags; the category archive remains to support old links. Only posts prior to April, 2006 are categorized. Tag Archive »
This website finally has a homepage. Previously, http://jclark.org displayed only a “comming soon” message. I had planned to setup Apache to use 304 redirects to send such traffic straight to the weblog. Upon further consideration, I decided that it was better to allow search engines to index a home page as well as the weblog… after all, the weblog is at /weblog and not / just incase I ever want other content on my home page.
The RSS Feed for this weblog has been updated to RSS2.0. I‘m currently using a shortened
but my current aggregator (NetNewsWire Lite) is only showing the short description. I’d like to try NewsMonster, but the OS X version is not ready.
Feed & Validation badges and links added to the right hand area of the page… which needs a name. It’s more than just a navbar. Suggestions welcome.
This weblog is now published under a Creative Commons Attribution-ShareAlike Licence. Badge and link added to the right hand side of the page; auto-discovery RDF included in the XHTML source.
So here’s the nickel tour of the new site design. I’ve split it into two lists- general features and Blosxom-specific design features. Among the general features are:
In addition, there are a few things going on under the hood, based on this blog’s implementation via Blosxom.
blosxom http://www.blosxom.com The Blosxom Home PageThat’s about a nickel’s worth.
The new site look & features are finally up. Be sure to check out the style switcher on the right. Writebacks are now working, so please comment and share your thoughts on the updates. Oh, if you want, you can compare it to the old layout.
I’m done for tonite. I’ll post more soon about all that went into this update. For now, it’s published.
Woohoo!
I have a bad habit. We all have bad habits, but I should know better. After all, I’m a professional software developer. I really should know better. But then, to be a bad habit, it must be both bad, and habitual.
To what behavioral horror do I alude? I like to test in production. You know, make changes to a live system, just to see what happens. Instead of making changes the test system. That was designed for testing. Changes. Bad!
But the first step with any problem is admitting you have a problem. For me, it started innocently years ago, with a web site I built and maintain for my employer. It has a small, well-defined clientel (Less than 200 users), and processes anywhere from $10 to $15 Billion dollars a month in transactions. Yes, Billion with a “b”. And so what do I do when someone reports a minor issue? Do I set up the test system, try to reproduce the problem, fix it, regression test, and then release? Well, yes, sometimes. But for minor little problems, I’ve been known to save time (hush, I know) and make the changes directly on the production system. This is an example of what professionals call Bad Mojo. Do not mess with this stuff.
While I have learned over the years not to do this at work (thankfully not the hard way; I guess I just figured out that Karma is not exempt from the Law of Averages), I’ve been doing so lately here on my weblog. Maybe this isn’t so bad, after all I’m running a personal site. I wouldn’t be the first person to let readers watch “over the shoulder” at the evolution of a design. Nevertheless, I’ve knocked the blog off the air several times while working on plugins, and this is bad form; the whole practice sets my spider-senses to tingling.
The moral of the story is that I’ve setup a mirror of this site on my Powerbook, and I’ll be (working at) confining development work to my local platform.
Speaking of site development, a few notes. Posts will remain sparse for a few more days, as I am visiting family for the Labor Day weekend, and am stuck in a pre-millenial backwater of the web (i.e., dial-up. Gasp!). I am, however, working on the site on my local copy, and hope to have a number of changes published to the site within the next several days. The overall look hasn’t changed greatly, but has been much refined (I hope). I’ve finally gotten my very first Blosxom Plugin working, and will be announcing that (and putting it to work on the site) soon. Comments are also in the works. Stay Tuned.
So, now that I have a basic site up and running, what next? Things in my todo list (in no particular order):
1 Technically, I already have an RSS feed, thanks to the wonders of Blosxom’s flavour system, and the built in RSS flavour. I’ve even made a tweak so it will validate. But I intend to do more.
2 In fact, I want to go one better than preview mode. The idea is a ‘publish’ checkbox. If checked, works just like now. If not, the file is saved as something.txt~. Will have to do some tinkering so wikieditish can still display the ~ version.
Most of the above are just a plugin away. I just love Blosxom! Even gzip compression just became available today as a plugin.
The visual design I’ve already begun, and continue to play with. Todo’s here include:
I’ve reading up as well. I have Zeldman’s Book3 on order at Amazon. Meanwhile, I’ve been browsing such places as:
3 Full Disclosure: I have enrolled in the Amazon Associates Program. The provided link to Amazon.com includes reference to this site. I will get a kickback if you buy through this link.
Now that the weblog is up, albeit in very rudimentary form, I can begin to improve upon the design. My goal is to better learn XHTML and CSS, and to write about what I learn here. As part of this process, I intend to periodically review where I am and where I have been. To this end, I need a baseline.
The current (initial) design is that baseline. I have archived this design as the flavour rev0. You can view this post in the rev0 design, or view this site in the rev0 design.
Before looking at what I want to change, I want to review what I have. Rev0 features:
* Valid XMTL 1.0 strict and CSS
* Two column layout using CSS, not tables
* Post Calendar, Category Tree
* Badges for validation and attribution
Under the hood, the weblog is running the following plugins:
* timezone, v0.0.1
* calendar, v0+6i
* categories, v0+4i
* flavourdir, v2003-03-13
* metadir, v2.0b4 (required for textile2)
* textile2, v0+1i
* timestamp, v0+2i
* wikieditish, v2003-05-29
All of these plugins are available from the Blosxom Plugin Registry. Aside from configuration variables, they are all unmodified, except for a bug fix to wikieditsh. I did edit the default wikieditish templates a bit, to add textile help (like found on the Textile Demo Page).
It has taken longer than I anticipated (as does every project), but this weblog is underway. In this category I will document what goes into the creation, maintenance and growth of this site.
Although getting to this point has taken longer than I expected, it has still not taken very long. Although it has been nearly a week and I have only a couple of posts and a very meager layout, I have only been able to devote an hour or two here and there. Above all, the process has been educational.
There have been two sources of delay. The first is minor, and is a just a matter of bad timing. I began setting up this site using Blosxom 2.0 Beta RC5, which I thought was current. Several hours later, I learned that Blosxom 2.0 final had been released, along with a new website. I don’t know if I had followed an out of date link, or if the old site was not redirecting to the new site (which it does now). When I did learn of my mistake, I decided to replace blosxom.cgi and all of my plugins with new versions from the new site. Unfortunately, the plugin registry on the new site links to outdated versions of several plugins. More time lost, but more knowledge gained; I’ll call it an even trade. Perhaps this was just a case of growing pains.
The other source of delay has been a much bigger problem. The hosting firm I am using, iPowerWeb, does not offer shell access. I have used them previously, and found the provided web-based admin site they provide to be adequate. However, they have recently introduced a new admin interface, with which I have not fared as well. Again, I seem to be the victim of growing pains. The issue is that many of the functions (e.g. chmod, file rename, file delete) are implemented with client side javascript, which appears to contain bugs. The code will not run in Safari 1.0 or IE5.5/Mac. It does, of course work in IE/Win. So, much computer-hopping has been required. iPowerWeb support has escalated the issue to the development staff, and claim that they are working on it. In the meanwhile, they suggest using Mozilla Firebird. Perhaps I’ll try it.
But there is another issue with iPowerWeb’s admin interface, which I have not yet sent to support. The provided editor uses CR/LF for newlines, but my host runs Unix (i386-FreeBSD). The perl interpreter does not like finding
Having successfully passed these hurdles, I have begun posting to the weblog. In future posts I’ll detail where I hope to go from here.