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.
Some random observations on Mozilla Firebird v0.6.1, for Mac OS X and Windows:
- Warning: In the Mac version, holding CMD while clicking a tab closes the tab. Even if you’re working on a post via wikieditish in that tab. Even if you have alot of time invested in said post. You’ve been warned.
- Finally got the Windows version to work on my work pc (Win2k). As noted previously, my clean install was crashing on startup. Consistantly. Even after some fairly thorough cleaning of old Mozilla install bits. Turns out it was crashing while trying to import IE favorites, and the IE Favorites tree has circular shortcuts. The solution is to move all Favs to another location (or delete them if you are feeling pyromaniacal towards your bridges), then start up Firebird. Once the import succeeds, it won’t try again, and you can restore your IE Favs if you kept them.
- On the Mac, closing all browser windows has a curious effect. The menu bar reverts to Mozilla layout, including acces to the full Mozilla Preferences dialog and various debugging options. No parallel found yet in the Windows version.
- The magic url about:config lets you edit many settings right in the browser window (but doesn’t work as a link in a page).
- Scroll bars are not yet ready for prime time, at least in relation to themes. I’m currently using the theme Pinball, which does not appear to come with scroll bars. Instead, it depends on the default scroll bar implementation ( I think ). On my Windows install, switching to Pinball from another theme initially leaves the prior scrollers in place, but they break (i.e., look funky) when you scroll. A fresh restart of the app fixes the problem (assuming the theme is picked prior to restart). On the Mac, this theme never has working scrollers. This could be a bug in the theme’s chrome/rdf/other-mozilla-voodoo, but I’d hope the fallback behavior would, um, work.
- Pop-up blockage belongs in the browser. Period. +1 for the good guys.
- There’s a nifty extension available named StyleSelector that lets you choose alternate CSS stylesheets (or turn off all styles) right from the status bar. It needs an option to disable userStyle.css (the user stylesheet, see above) for those times when you think your ad-blocker may have whacked a non-ad.
- To run Preference Manager in the Windows version, run
MozillaFirebird.exe -p (as stated all over the Mozilla Site). This doesn’t work in the OS X version. Instead, use the trick from above in the list - close all Firebird windows. One of the menus revealed in the Menu bar will include the option to ’switch profiles’. The resulting dialog provides access to the Preference Manager.
- My Mac version won’t launch links from other apps… even after making a new profile, which is supposed to cure many ills. If I try (for example, clicking a link in Mail.app or NetNewsWire Lite) I get the cryptic error “Error launching browser window:no XBL binding for browser”. Update: This seems to be fixed as of version 0.7.1, more info here.
Conclusion: Firebird, thoroughly unpolished at version 0.6.1, utterly rocks. It is now my default browser at work, on my (personal) Mac, and on one of my three home WinPC’s (the other two will fall as soon as I have time).
Once again, it’s been a few days since my last post. It’s time to remedy the situation.
One of the things I was worried about when I decided to begin this weblog was content… specifically, having the discipline to post my content on a regular basis. I’ve never been a good journaler. I ran a practice blog a few months ago, and quickly found that I spent more time working on the infrastructure than on the content. Much more.
I have started writing new entries several times over the past few days. Each time I seem to get distracted or obstructed by something different. I am quickly finding a fundamental difference between writing prose and writing code - the way in which difficulty affects my desire to complete the task. When writing code, a more difficult problem tends to spark my interest, and draw me into working harder at solving the task. Technical difficulties add to the challenge. When writing prose, however, technical difficulties tend to turn me away from the task at hand. I attribute this to the differences in my perceptions of these tasks - I enjoy coding much more than writing.
For example, when writing blog entries, I often cite topics which should contain links to other resources (e.g., Blosxom). Even using textile to compose my entries, I still find the task of looking up and typing in URLs to be tedious. Late last week, I began a post, only to quickly tire of including the links for Blosxom, the plugins page, etc., yet again. So I stopped what I was doing and went looking for a better way. I recalled seeing something in Dean Allen’s Textile 2 Announcement post regarding storing of URLs in an external file, to avoid embedding them in the text. As well as I can tell, this feature is not (yet?) a part of the perl port of Textile 2.
This led me to attempt my first ever Blosxom Plugin. After many hours of hacking (and still no post), I decided that: A) my perl is rustier than I thought, and B) My original concept for the plugin might be flawed. Eventually I gave up, but the post didn’t get done.
A day or two later, I started on another post. Again, I got distracted by the need to look up (and type) URLs, and again, I got sidetracked by the desire to come up with a strategy. I spent some time carefully combing through the Blosxom Plugins Registry looking for something applicable. Eventually, I thought of a refinement of my original idea, and returned to the failed plugin. Much hackery later, I still had no plugin (and no post). I am very close, but still sans cigar. I plan to post about it on here soon, and to seek help on the Blosxom mailing list and/or PerlMonks.com.
Another hurdle to writing blog entries is the difficulty in formatting posts for my subject area. When trying to include sample code, I’m finding the interaction between wikieditish and textile to be a problem. Escaped markup in the original post gets un-escaped in the wikieditish edit box. Another enhancement for later, but one I plan not to address at the expense of site content.
This is a test of a new plugin for blosxom. More info to follow.
Update At least this used to be. Now it’s my testing sandbox. Never know what you might see.
Iñtërnâtiônàlizætiøn
It’s been quiet here for a couple days. Besides being out of town for a few days, I’ve been doing some reading/surfing/learning about CSS, site design, etc. Posting frequency should pick up again soon.
I did take a stab last nite at my first Blosxom Plugin. My perl seems rustier than I thought, however, and it’s still not working. More reading ahead….
As noted previously, the administrative interface provided by my hosting service does not play nicely with Safari or IE/Mac. They suggested Mozilla Firebird. I finally decided to cave, and give it a try.
I think I like it. That’s really saying something, considering I’ve never seen a Mozilla browser I liked. From the early Netscapes onward, I’ve always thought they were ugly and slow. Mozilla 1.0 became usable, but not really comfortable. Firebird (I’m using the 0.6.1 build) feels alot different.
It’s still rough around the edges. Scratch too hard and you will see the mozilla underpinnings. In the Mac OS X version, if you close all windows, the menus all change… to what look like Mozilla menus. Even the Mozilla properties dialog, which Firebird normally replaces with a much slimmer version, returns when all the windows are closed. And when I tried to install the Windows version on my office PC (Win2K), it crashed. Repeatedly. I finally gave that up.
But this is only a 0.6x build… its supposed to be rough. It’s got some very nice features. Tabbed browsing is on par with Safari. The ‘extensions’ feature reminds me of Blosxom… There seem to be lots of extensions available already (this may be a general Mozilla feature). And of course, the CSS rendering is great.
All in all, so far so good. I might even make it my default browser. If I can ever figure out how to customize the keyboard shortcuts, I will. For some unknown reason ‘Backspace’ is only a shortcut for ‘Back’ in the Windows version. Why not make the Mac ‘Delete’ key do the same thing? Until then, I still find myself in Safari less and less.
While writing the previous entry, I used Textile’s footnote feature to note that my site’s RSS feed validates. I even made the word “validate” a hyperlink to the Feed Validator with an url that will autocheck my feed. Since I always check my links as soon as I post a story, I clicked the validator link. Only to find that my feed no longer validates.
Why does my feed no longer validate? Because of the footnote. Specifically, because Textile’s footnote feature makes relative url hyperlinks to anchors within the page. And relative urls are not valid in the element.
My feed will remain invalid for a short period of time while I ponder a solution. So far my options seem to be:
- Remove the footnotes
- Live with a non-validating feed
- Tinker with the textile2 plugin and/or textile.pm, and get it to emit full (not relative) URLs for footnotes.
- Tinker with the RSS flavour to fix up such urls automagically.
- Find/build a plugin that rewrites all relative urls to fixed urls. This will be tricky for the RSS feed, since the url is not relative to the feed being created.
Option 1 is admitting defeat, and besides, I like the footnotes. Option 2 I will accept only as temporary, to keep from having to take down the offending post. Options 3, 4, and 5 mean learning more about Blosxom’s plugin model, and/or the guts of textile; both things are already on my mental list of Todo’s. I’ll post the resolution when I find it.
So, now that I have a basic site up and running, what next? Things in my todo list (in no particular order):
- Visual design (see separate list below)
- Comments/trackback
- Blogroll
- RSS feed
- Setup a logfile analyis tool
- gzip compression
- Write!
- improve the wikieditish flavour. I want to add links to insert em dashes, en dashes, etc., add a preview mode, and clean up the textile help I copied from the Textile homepage.
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:
- Fonts (!)
- Fix IE rendering (ugh)
- Tweak right-side ‘panelets’ color scheme, sizing
- Improve rendering of story titles and panelet titles
- Overall negative space tweaking
I’ve reading up as well. I have Zeldman’s Book on order at Amazon. Meanwhile, I’ve been browsing such places as:
One of my stated goals with this weblog is to better learn web standards, such as XHTML and CSS. So each time I make a change to the design, or post a new story, I use the validation badges (see the right hand column) to check that everything is still copascetic. Yesterday, it was not.
The error message from the XHTML validator, in all its yellow-highlighted glory, was:
Sorry, I am unable to validate this document because on lines 52, 56-58, 62-66, 68-70, 73, 76-81, 83-84, 86 it contained one or more bytes that I cannot interpret as utf-8 (in other words, the bytes found are not valid values in the specified Character Encoding). Please check both the content of the file and the character encoding indication.
Now, this is clear (invalid characters), and yet not so helpful (what characters? Where in the line?) I didn’t see anything in the view source, or opening the original file in an wikieditish. And of course, I’m using textile, so that could be a culprit as well.
After some experimentation (by which I mean to say, several hours of searching Google, threatening the Validator, and banging my head against the wall), I found that by saving the XHTML from my browser, and running it through less, I could see the bad characters. They were all 0xA0, which is 160 decimal, a.k.a. . Of course, is valid in XHTML, as is . But utf-8 does not encode single byte values above 0×7F as single byte values, so 0xA0 is not the utf-8 encoding for nbsp.
The thing is, I’m not sure how they got there. The seemed to mostly appear inside blocks, in place of the original indent spacing. So I suspect it was a combination of textile2 trying to format the code, and wikieditish saving the document. I'm going to have to do some experimenting to make sure I understand how they interact.
I tried to fix the problem my adding some filtering to wikieditish, in the form of:
$_ = $body;
s/\xA0/ /; #non-breaking space
snip! more translations in here,
like emdash, soft hyphen, etc.
$body = $_;
I then re-edited the file, but this didn’t seem to fix it either. I eventually downloaded the story to my local system, cleaned it up with a perl one-liner (perl -pi -e 's/\0xA0//;' filename.txt), chosing to just eliminate the nbsp’s entirely for now until I better understand them.
And the best part of all? My host is running perl 5.8.0, with PerlIO enabled; which if I read perluniintro correctly is supposed to automagically take care of all that utf-8 madness for me, so I don’t have to.
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).