Switch to MySQL

After struggling with things for a few hours tonight, I’ve managed to succesfully convert the database backend for MovableType to MySQL.

What does this mean? Well…good question. For you, the end-user, not much, though as MySQL is supposed to be a bit faster, posting comments might be a bit more responsive than it was before. For me as the author/administrator, it should mean a bit more speed when creating/editing entries, and a lot more options as far as what I can do on a design/implementation level.

At least, that’s the theory. If nothing else, according to one of the moderators of the MovableType Support Forums, “If you have the choice, pick mysql. :) A little faster, more stable, easy to browse the database….” Good enough for me!

BlogFodder

Here’s an interesting idea — BlogFodder, a daily e-mail with a short snippet of text intended to (hopefully) inspire musings, thoughts, and possibly future weblog posts. Meg’s likening it to the old school exercises where a class was given a single topic or title and ended up creating umpteen different stories seems right on target. Worth keeping an eye on, at least.

Installing MT on OS X

While searching around for pointers on getting MovableType moved over to a MySQL backend rather than the DBD backend I’m currently using, I ran across a few good general resources for OS X MovableType installations.

There’s probably more out there, but these are a good start.

Comment preview upgrade

Hooray for people smarter than me! Or, at the very least, more knowledgable of all sorts of javascripty goodness and magic.

A couple days ago, Phillip found my ‘Live Comment Preview‘ and incorporated it into his blog. However, not satisfied with what I had, he improved the code so that it recognizes and inserts linebreaks correctly!

So, I’ve gone and snagged the improvement, and tossed it into the script on my site. Better and better all the time…thanks Phillip!

GeoURL

I’ve just signed on with GeoURL, a web service that ties a weblog to a location, so that you can find out who your blogging neighbors are in a true geographic sense. For a quick example, to see who’s close to me, just check GeoURL. Just another fun toy to play with.

(Found via Jeremy)

A call for help!

I’m using a fairly heavily adapted version of the Hide/Show Comments hack from Scriptygoddess to hide and show the clickable smileys I’ve added to my site. I simplified the javascript a lot, but in doing so, the ‘hide/show smileys’ links on any post in my blog only work under Internet Explorer, and fail in various ways in any other browser (Netscape/Mozilla/Chimera don’t seem to be recognizing the javascript, and just reload the page, and Safari (and therefore probably also Konqueror, since they both use the kHTML rendering engine) doesn’t even display the links!).

Could anyone possibly give me some help on getting these to at least work under both IE and Netscape/Mozilla/Chimera, if not Safari also? I don’t know enough about javascript to know how to fix this!

(This plea has also been posted on the MovableType support forum.)

Read more

Lots of categories

The category (or, in many cases, categories) that each post on my blog is assigned to is (are) now listed in each individual post, just underneath the time/datestamp at the end of the post. Might make finding older and/or related posts a bit easier than it was before. I’ve also added a lot of categories in order to even further (over-)organize my posts — new posts will get these added at creation, older posts will just have to live without until I get them all assigned.

Browser Daydreaming

A few days back, Phil asked what we’d like to see in a web browser. I initially responded in my usual semi-flippant fashion, but after running it through my head for a couple days, I’ve actually got some ideas.

To start with, I’ll look at web browsers as divided into two core components, as outlined by John Gruber on Daring Fireball:

It is essential to understand that there are two huge, almost completely separate tasks involved in producing a web browser. The first is the HTML rendering engine — the part of the browser that parses HTML and turns it into an on-screen graphical representation. The second is the browser application: the windows, menus, buttons, and dialog boxes.

I’ll start with the second part — the application itself. The things I’m most interested here are scattered across multiple browsers at the moment, and I do end up wishing that they were all in one package. Key things I’d like to have in my ‘ultimate browser’:

  • Safari’s clean, simple interface (without the ‘brushed metal’ look, though).
  • Safari’s speed.
  • Chimera’s tabbed browsing (unless someone can come up with something better).
  • Safari’s bookmark management.
  • Internet Explorer’s form autofill.
  • OmniWeb’s beauty.
  • The ability to tab among all page elements — links, form elements (text fields, buttons, and menus).
  • Full-featured contextual menus (Safari’s are pretty anemic at the moment).
  • And there’s probably more that I’m not coming up with at the moment.

When looking at the other side of the browser experience, I was kind of inspired by Jason Kottke’s browser integration musings and Mark Pilgrim’s wondering if Safari should be intentionally buggy (and for the record, no, I don’t believe it should, but that’s another post for another time).

Dreaming about the perfect UI for a browser is all well and good, but we’re still faced with the dilemma of which rendering engine to use. Each of the major engines out there (IE Mac, IE PC, kHTML [Safari, Konqueror], Gecko [Chimera, Mozilla, Netscape], Opera and OmniWeb] has its own collection of bugs to be worked around, causing frustration for both web designers trying to design sites that look equivalent under all browsers, and for end users who, depending on their level of expertise, may or may not understand why any given site doesn’t seem to work in whatever browser they use.

So, what I’d kind of like to see, would be a plug-in based interface for the rendering engine, easily changed via a menu choice somewhere. Find a way to wrap the latest build of any given rendering engine in a small piece of plug-in code, and drop it in an “engines” folder for the browser app. The app would come with one default engine (and as long as I’m living in a perfect fantasy world, let’s make that engine an as-yet mythical completely strict standards-based engine), but at any given point, you could go to a menu and switch to another rendering engine, which would then re-render the current page (or all pages — let’s add a preference option to select whether rendering engines would apply on a global basis or window-by-window) with whatever engine was chosen, which might be less strictly accurate, but might be more compatible with whatever mess of code the user is currently attempting to view.

I have no idea how feasible something like this might be, and I don’t think it’ll ever happen, but hey, I like the idea. Of course, in a perfect world, I’d much rather see standards-compliant websites that worked in standards-compliant, bug-free browsers, but I don’t expect that’ll be happening anytime soon. I can dream, though….

Abuse my taste in music

Being silly here. ;) Feel like harassing me about what I listen to? Here’s the place to do it….

The last ten tracks I’ve listened to in iTunes are:

This feature is no longer active, as a consequence of the move to TypePad. Sorry!

Feel free to use the comment form to praise or condemn me — or if you’re feeling rich and/or adventuresome, use the links to Amazon and pick up something new to listen to!

(This is inspired by the playlist comment feature on Phil Ringnalda’s site.)

Revamping the Archives

I’ve made some revamps to my archive listing pages, in an attempt to address some of the issues raised by Dave and Kirsten.

Monthly archives I’ve kept the same — I really like the calendar-style display that they use.

Clicking through to the main archive page should be much nicer now. Rather than the huge (and rapidly growing) table listing the title for every post I’ve ever made, you’ll now see a simple list of each category I use, with a short description of the category and the titles of the last ten posts within that category.

Heading into each category’s archive page (for instance, my Humor archive), I wanted to get away from listing the entirety of each post, as that lead to huge pages, but still include more info than just the title of each post. Nicely enough, MT includes an ‘excerpt’ field for each post, and if an exerpt isn’t written by hand, MT will auto-generate one using a snippet of the beginning of each post. So, the category archive pages list the title for each post, then the excerpt. I’m going to start trying to remember to create excerpts for any new posts from here on out, but the auto-generated excerpts will have to suffice for all the old posts — at least until I get really bored. ;)

Hopefully this makes things far easier to deal with. As always, questions, comments, and words of wisdom are always appreciated!

[Addendum: the main archive listing and all category listings validate as valid XHTML. Individual entry pages should, but may or may not, on a case-by-case basis. However, there’s lots of those, and I need to go to bed.]{.underline}