A buffer overflow… is… uh… this is hard to explain without a whiteboard and 8 boxes - whenever you see this sort of thing in a book there’s always 8 boxes, you know? Well, it’s like… when you allocate some memory… and then you assign something that’s… too big. Like you assign 256 characters to a … char star, and somebody puts 300 characters in there. Other languages will… you know… stop you, but C won’t, and when you… uh … write the data it … uh… it goes into space that’s being used by data, or other programs, and that’s… you know… bad.

CodeIgniter is right for you if…

• You want a framework with a small footprint. - Wouldn’t necessarily say that’s my top priority, but hey, it’s not bad, either..
• You need exceptional performance. - I don’t need exceptional performance, but I wouldn’t turn my nose up at it, either.
• You need broad compatibility with standard hosting accounts that run a variety of PHP versions and configurations. - Okay, I definitely don’t need this. I like to always have at least enough control over my server to be running PHP5.
• You want a framework that requires nearly zero configuration. - I’m pretty comfortable configuring things.
• You want a framework that does not require you to use the command line. - What’s wrong with the command line? I like the command line.
• You want a framework that does not require you to adhere to restrictive coding rules. - What’s wrong with restrictive coding rules? I like restrictive coding rules.
• You are not interested in large-scale monolithic libraries like PEAR. - Is PEAR really that monolithic?
• You do not want to be forced to learn a templating language (although a template parser is optionally available if you desire one). - I can see why one might avoid template languages (see: performance) - but I don’t avoid frameworks based on whether or not they enforce template usage.
• You eschew complexity, favoring simple solutions. - Well, I like to imagine that I do.
• You need clear, thorough documentation. - I like clear, thorough documentation, I’ll admit.

So, I’m having trouble finding a reasonable gallery software.

Honestly, what I want is a service that allows me to export seamlessly from iPhoto, not worry about storage space or download limits, share with arbitrary people, allow for posted comments, look nice, run fast, and be free.

I know, that’s a tall order.

flickr limits you to 100Mb / month, which is a bit of a pain if you take more than a few pictures a month. Google Picasaweb limits you to 1 gigabyte forever, which seems almost worse. flickr pro costs money, SmugMug costs more money, and MobileMe costs the most of all.

That pretty much leaves “Gallery”, but the last time I tried running it on my DreamHost account, it was so slow as to be not even worthwhile. Yeah, DreamHost may allow you to install a wiki or a gallery, but if you want to USE them, you’re up slow creek without a paddle.

So, what that leaves, then, is iPhoto’s “Web Export” function. Now, I’m not sure about iPhoto ‘09, but iPhoto ‘08 produces HTML that’s lightweight, but… well… there’s no way to style it. Would it be so hard to include a couple of hooks so that one could toss a CSS stylesheet on the pages?

So now, my solution is to just post iPhoto galleries (here), and then, in the FAR OFF FUTURE, I plan to write a script that iterates through them and adds a CSS-stylesheet link to each page- and maybe wraps all of the ‘descriptions’ in a <small> tag. Maybe a link to some external Javascript for special effects. Who knows?

Yes, through the magic of JSON, Yahoo! Pipes, Python, Beautiful Soup, and a variety of other things, AutoBoose the handy IRC-logging robot is now a feed-reader.

Not a mind-reader. That would be much more difficult, and there probably aren’t enough third-party libraries to make it happen.

So, I recently discovered Yahoo Pipes.

Yahoo Pipes is a staggeringly useful platform for performing various server-side transformations on tree-shaped data. It’s designed to work especially well with RSS feeds, although it works with JSON, as well.

It’s built entirely with a slick (albeit buggy) YUI interface that allows you to link transformations together, piping the output from one into another, in a chain.

The JSON from the site is set up in such a way as to allow JSONP pulls, but its own data-access is server-side, so it’s a quick way to noodle around Javascript’s restrictive-but-secure Same Origin Policy.

I’ve built three pipes so far — a reddit pipe, which pulls all of your most recent links and comments from reddit, and posts them to http://pipes.yahoo.com/lassam/reddit

A twitter pipe, which pulls all of your recent twitter posts from your Twitter RSS feed, available at http://pipes.yahoo.com/lassam/twitter

And a #sfucsss pipe, which uses my PieRC IRC logger, from http://curtis.lassam.net/pierc/, to pull a feed of the most recent things you have said on the IRC channel #sfucsss on irc.freenode.net, available at http://pipes.yahoo.com/lassam/sfucsss.

Then, I piped all of these things together, to create the “Social Megapipe” — ( http://pipes.yahoo.com/lassam/social_megapipe ) and am now using is as an all-purpose social-tracking widget thang (see ‘twitter++’ on my sidebar) - and it can be targeted on people who use reddit, twitter, and #sfucsss. Like Allen, or Dan.

After processing, these pipes can be consumed as RSS data, JSON data, as a site widget, or in a number of other useful formats.

I’ve been playing around with the new font-embedding features in Firefox and Webkit recently, just out of curiosity — and I’ve discovered once again that I am absolutely in hate with Microsoft’s font rendering.

Despite, say, Jeff Atwood’s impassioned preference for Cleartype, when I’m displaying an OpenType font in Windows, it looks bad. Ugly. Fugly. I suspect that this is because the fonts were designed for print, not for display on a monitor, so when Windows’s font renderer ham-handedly tries to cram them into a pixel grid, the end result ends up being uglier than a bad analogy. I’d also guess that font-hinting at low resolutions is only peripherally included in nicer print fonts. In order to make any embedded fonts look even remotely okay in Windows, I had to increase the size of all website text by 110% — which I actually prefer, for readability’s sake, so long as none of my website users like to browse the page on ancient, tiny screens.

On the Macbook, the fonts look pristine, pure, and proper, comparatively.

One of the longest-to-load elements of my page is the external call to Twitter. That wouldn’t be a problem, except the Javascript UI elements running the left-side of the page wait for the site to load completely before they kick in- so new visitors get a few seconds of ugly UI-less page while waiting for the Twitter feed to load, then the whole thing folds up into a tidy accordion.

Hum.