Linkstew

Imagine if iCal and iPhoto were more tightly integrated: If you kept your iCal very up to date, you could search for "snowboarding pictures," and iPhoto would know that since the picture was taken on date N, and your iCal said you were snowboarding on date N, then that iPhoto could assume that that picture is probably snowboarding related.

This all started because I was getting violently sick of my old background color (#ffffcc, for those of you playing along at home), and I figured I could change it to white (#ffffff =p) without disrupting things too much.

But when I made the background white, everything started to blur together, because the backgrounds on my posts were white to contrast against the formerly creamy color of the page... So I decided I needed a vertical stripe to separate the posts from the sidebar.

Now, I've always been a big fan of vertical stripes, but with html it's easier said than done. So I grabbed the first site I could think of with a vertical stripe (which happened to have been AJ's) and pulled the code and images straight from there, which explains the dotted line as opposed to a solid line.

But then I felt off balance, and I've been toying with the idea of adding another column for a long time anyway (because that damn date navigation is *really* long), so I added it, and now the whole thing is nice and symmetrical, and for the moment, I like it.

I actually really like the dotted lines, and assuming AJ doesn't object, I'm going to leave them there for now. However, I'm also thinking about changing the green soon, because I don't even know how old that color is or why I have that green.

Later: So I decided that with the symmetry the lines provided, I wanted the green bars to come closer to being evenly spaced on each side, which meant I had to alter the comment links some. And that got into issues of having the colored dot load on a background the future color of which I'm not certain...

So I just made the comment widget text yellow and extended the green background, but changed the permalink/recency indicator to be a colored arrow at the beginning of the text. I like the way it looks, but I'm not entirely happy with the implementation at the moment. First of all, I was having some CSS issues so I had to give up and wrap the arrows in colored font tags. And the second problem is that posts that don't start with a <P> tag at the beginning (Of which there are 58, according to a quick check via SQL) won't get arrows put in correctly. But aside from those implementational issues, and the still standing puke green issue, I like it.

Oh, I also made the title bar truncate seconds from the post date, since they're useless. Hopefully the dates will be a little easier to read now that there are two fewer numbers there in that bar.

I've been working insane hours at work, and I needed a break from all the coding I've been doing, so tonight I rebuilt Linkstew using Kevin's Furynodes. Yes, coding this site actually is a break from coding for work. I pretty much threw away all of the old Linkstew code, which is kind of depressing, but also huge a relief. Cricky, the old Linkstew was so broken.

Yes, some features from the old version are still missing. But with Furynodes, they'll be real easy for me to add back in at a later date, and they'll work better than before. And I've got plans to display even more metadata for The Stew, including related categories when viewing a category. But in place of the temporarily missing features, you get comments! Woohoo!

I know it doesn't look shiny and new, but it really is. But I basically just recreated the old look and feel, so I'm definitely open to suggestions on how to make the page more usable.

Also, it seems to me like the whole page is running slowly. But I've been having net issues all night, so could y'all tell me if the page feels slow(er)? Or is it just me?

Warning: Annoying geek rant ahead. Read at your own risk.

This sure is a chickles micken. Every ounce of database experience and knowledge and training in me tells me to minimize the number of queries I perform. So, on that note, I can either spend at least 2 seconds performing one query to fetch all of my data, or performing 11 queries, where each query takes less than a fifth of a second, on average. Unfortunately, my database is on another machine, so every one of those fetches has to travel back and forth across TCP. Tradeoffs.

Ugh. What's a database snob like me to do?

If I had my choice, I would not use MySQL, but that just isn't an option.

In the meantime, I've chosen to perform all the little transactions. Why? Well, because a lot of repeated executions of the queries in a script I wrote to test it showed that no caching happens at all, and with the single query I get at best two seconds, and at worst up to 10 seconds, with an average of about 3.5 seconds. The little queries hit one second total, at worst. Stupid MySQL. I blame the speed differences on database load from other Dreamhost customers.

What's the query, you might ask? It's just a stupid little "select a.aid, count(b.bid) from table_a a, table_b b where a.aid=b.bid and a.thingx<>'y' and a.thingx<>'z' group by a.aid order by a.created desc limit 10". In other words, I want a list of the ten most recent entries in table_a that aren't y or z, along with a count of how many items from table_b are associated with that given entry from table_a. This is not a complicated query. table_a only has like 500 entries, and table_b only 10,000. There isn't enough data there to bog it down that much. For shits and giggles, I replicated this situation on both PostGreSQL and Oracle (on significantly slower hardware, mind you), and, at worst, they both performed the query faster than the best my MySQL could muster up. I tried rebuilding my table on MySQL. I recreated all my MySQL indexes (though the oracle and postgres tests didn't even have indexes). It's just MySQL that sucks. Instead, I have to do "select a.aid from table_a a where a.thingx<>'y' and a.thingx<>'z' group by a.aid order by a.created desc limit 10" and then for every aid returned I have to do "select count(b.bid) from table_b b where b.aid=$aid". How on earth did MySQL get a reputation for being a "fast relational database management system" with performance like this? Yes, I'm very grumpy about this. I told you not to read this.

I guess it's vaguely possible that it's the dreamhost configuration that sucks, but with as many users as dreamhost has, I expect that it's at least a little tuned. However, I'm not in the mood to set up MySQL on my own machine just to verify my resuls, because as far as I'm concerned, if MySQL's speed doesn't scale, the tradeoffs they made to get that speed were not worth it in the first place.

"We can't decide where we're going to eat dinner, let alone whether to use PostGreSQL or Oracle."
--Me, about work.

For the record, we chose PostGreSQL, for a number of reasons, the least quantifiable but most important of which was "it's neater."

Today while reading use Perl; I noticed that there was a new module named DBIx::XML_RDB. Now, as my job is composed almost entirely of XML and Database work right now, this module sounded interesting enough for me to check it out.

And check it out I did, and interesting it looks, but I'd still dig something on the level of Oracle's XML Tools in an open source package, because what this particular Oracle document describes sounds like a very well integrated and robust package. Too bad I don't have it to play with. Maybe I'll get a chance to work with real XML/Database tools some day, and not be stuck with Perl's half assed implementations. (They're not all bad, but the best ones I've found are the ones that are simply perl bindings onto libraries in other languages.

It's partially my fault for not paying more attention, but it's also partially mysqls fault for not having transactions. Anyway, while working on adding the display by date feature (look at the right column), I accidentally issued an "update noids set newdate=moddate" instead of "update noids set moddate=newdate". What this means is that a lot of nodes are now going to look at lot newer than they really are, because when I changed my tables in early september, a lot of nodes ended up with a pretty new moddate despite retaining the correct newdate. What's this mean for you? Nothing really, except that if you see a node mentioning it being March that is dated September, now you know why. Oh, and the "By Date" feature mostly works at this point.

The content lives in a mySQL database, and I use PHP to retrieve the data and make the page. Any page you look at in here is all done using one web page, for now. Pretty cool, eh? I remember when I first started making web pages way back when, and I had no idea how to do something like that... Now, doing anything else strikes me as positively stupid.