I’ve become a fan of definition lists as a layout tool. Here’s a snippet of HTML, using them to markup a form. You can make the input element label the definition term (dt) and the input element itself the definition data (dd), like so:
<dl>
<dt><label for="first_name">First Name<label></dt>
<dd><input type="text" name="first_name" id="first_name" size="20" /></dd>
<dt><label for="last_name">Last Name<label></dt>
<dd><input type="text" name="last_name" id="last_name" size="20" /></dd>
etc...
</dl>
What makes this better than using an HTML table is that with CSS you can specify whatever layout you want: you can style it so the dt is above, below, to the right, or to the left of its dd partner. This is particularly helpful when you’re writing re-usable code that might be needed in situations where you can’t predict the layout needs.
But tonight I discovered the limit of this approach, which is when you can’t predict whether the vertical height of the dt’s content will exceed the height of the dd’s. I’ve been working on the next version of Shashin, and what’s been driving the effort is the Boxing Dragons art gallery site, which I just finished working on. I’m using Shashin to display a list of albums (in this case artists) with the description of the album alongside the cover image of the album. For the next release of Shashin, I was originally planning to do this markup with definition lists (with the album cover as the dt and the description as the dd), giving users the flexibility to layout their album and description pairs any way they want, via CSS.
This approach to styling definition lists is fairly tidy, and works fine when the height of the dd is the same or greater than the dt. And in Firefox it also works when the height of the dt is greater, but not so in IE6 (I’ve been resisting upgrading so I haven’t tested with IE7). In IE6 the content of a dd will “flow up” into any available space above it, pushing a dd’s content higher than the position of its dt partner.
The clearfix solution for positioning floating divs doesn’t help here (believe me, I tried). I found several threads of people discussing this problem (or something quite similar to it) but no reliable solutions. The best I found was this admirable effort, but it entails about 70 lines of CSS code as well as some goofy markup. It’s also quite fragile - as soon as I started tweaking things like margins even slightly, it would start to fall apart. Although I probably could have gotten the layout I wanted if I kept at it, the CSS would have been so complex it would have defeated the purpose: to make it fairly easy for Shashin users to alter the stylesheet to get the layout they want.
So, at least for now, I’ve given up on using a definition list and have retreated to using a table. The upside is the markup and the CSS are straightforward and cross-browser compatible. The downside for Shashin is that there’s no flexibility: the album covers have to stay on the left, and the descriptions on the right.
In my announcement of Shashin 1.2 the other day, I said I didn’t have as much time for testing as I would have liked, for the sake of getting out a version that works with WordPress 2.3.3. Sure enough, there were several bugs in Shashin 1.2. Get the fixes in version 1.2.3 from wordpress.org.
It may fix the problem some people were reporting with adding and syncing albums (a problem I haven’t been able to reproduce, so I can’t say for sure). If you had this problem, please let me know if the new version fixes it for you.
I also took the opportunity to rewrite the algorithm for displaying random photos, and it works much more nicely now, so give it a try.
I believe I may have also found why some, but not all, Shashin users were having trouble with multibyte (e.g. Chinese) characters, so this upgrade may help with that as well.
If you have any questions or problems, please post a comment on this post.
Update: There were some bugs in this version, please see my post on version 1.2.3 for the latest update. Also go there for any comments or questions - I’ve turned off further comments on this post.
You can download the latest version of Shashin from wordpress.org. I had to rush this out the door, since Shashin 1.1 doesn’t work with Wordpress 2.3.3. That means I didn’t do all the testing I usually do before a release. If you have any problems, please post a comment here (note I turned off comments on the main Shashin page, as the page was just getting way too long).
The two big new features happen to be the two most requested features: displaying groups of album thumbnails, and the ability to add or sync all your Picasa albums at once. For the album thumbnails, they are displayed in a table with a number of columns you can specify, you can choose to display either only certain albums, or all your albums with your choice of sorting preference, and you can choose whether to display the album titles and locations (if you specified a location in Picasa, Shashin will include a Google Maps link as well). Syncing all your albums at once will make using Shashin easier for those who maintain a lot of Picasa albums.
Another feature I added is smarter album syncing. Now if you move a photo from one album to another in Picasa, Shashin will preserve its original photo key when it syncs the albums. Before I made this change, the old photo key would be deleted and the picture would get a new photo key, thus breaking any Shashin tags that referred to the old key. That problem won’t happen anymore.
The biggest piece of work in this release wasn’t the new features though. It was writing a parser for the Picasa feed from scratch. I got tired of Shashin breaking every time WordPress changed its RSS tools (which seems to happen with almost every new version - that’s what broke Shashin 1.1 when WordPress 2.3.3 was released). Instead of using something big like Magpie, I instead wrote a very lean XML parser - not counting comments, the whole thing is less than 60 lines of code. It uses Snoopy to load the feed, since I can’t rely on PHP functions like fopen being configured across different servers for URL fetching (Snoopy comes with WordPress, so Shashin loads it from there). I would have loved to write the parser in PHP 5, which has a great new set of tools for XML, but a lot of sites out there are still on PHP 4 (including mine), so the parser is PHP 4 friendly.
I’ve noticed my old rss-functions-mod.php file being re-used by folks in other WordPress plugins. That code doesn’t work with the new version of WordPress (I didn’t bother to investigate why, since I was done working on the new parser anyway). If you’re someone who’s used that file in your plugin, you may want to switch to the parser that’s included with Shashin 1.2. But you’ll need to make some adjustments to your plugin, as the data that comes out of the new parser is in a different structure.
Stay tuned for version 1.3, probably in a few weeks. I’m planning to include Highslide integration! 
Wordpress 2.3.3 was released about a week ago. I haven’t upgraded yet, but I just heard from a Shashin user that Shashin isn’t working with the new version. It sounds like it actually breaks the whole site - that you’ll only get a blank page until you deactivate Shashin. I will install the new Wordpress version today so I can start investigating what the problem is.
I actually have version 1.2 of Shashin almost ready. One major change is that I completely rewrote the parser for the Picasa RSS feed (so it’s no longer relying on my hacked version of the old WordPress rss-functions.php file). If I’m lucky, whatever the problem is with 1.1’s compatibility is already gone in my 1.2 code. But I’m not counting on it 
.
Now that I’m working at home, and at my computer all day, I’m trying to create a good ergonomic desk setup for myself (especially with my ongoing back problems). If you spend your time day in and day out working with the same set of tools, you need them to be quality tools. So I started today by shopping online for a good keyboard, and ended up taking a journey through history and language. But first, the keyboard…
An old Royal portable typewriter
A keyboard with fancy lights or extra multimedia keys holds no attraction for me. The currently popular flat, laptop style keyboards drive me crazy, as there’s hardly any tactile feedback. By learning to type as a child on my mother’s 1960s Royal portable typewriter, it’s been imprinted in some primal corner of my brain that the sensation of a nice mechanical whack when hitting (not tapping) the keys is really satisfying. Before the mouse became a common computer input device, computers were expensive, and people were used to the feel of typewriters. A keyboard that was popular then, and apparently still has a small but devoted following today, was the IBM Model M:
[Back then] the keyboard was the only day-to-day input device for almost all computers, and most users were tapping away at the things a great deal. Keyboards mattered. People cared. There were actually advertisements in computer magazines in which manufacturers bragged about how kick-ass their keyboards were.
The boasts were justified. There have been various technologies dreamt up over the years for keyboards, all trying to make the ‘board feel nice to use, last well, and not cost a million dollars. The “buckling spring” keyswitches in this IBM ‘board and some other old-style units are widely acknowledged to be the best ever developed in every regard, except cost.
They’ve got not-too-light but not-too-heavy key weighting, they’ve got the kind of positive click that I imagine you’d feel on the firing button for the Death Star’s primary armament, and their demonstrated service life, despite extraordinary abuse, is preposterously long. Essentially, if you don’t take to one of these things with a hammer, it’ll probably outlast you, even if you spend all day, every day, typing.
…The attractiveness of Real Keyboards faded with the arrival of mouse-based user interfaces. Suddenly all of that basic housekeeping typing became unnecessary. Programmers and data enterers and writers still typed like crazy, but everyone else could point and click their way through many tasks.
And when you don’t need to use the keyboard all day, you don’t really care how good the ‘board is, as long as it doesn’t stop working. Big heavy indestructible keyboards like the [Model M] became an unsupportable expense for the average personal computer, and they died out…
In addition to all that, apparently the Model M also makes you a better typist:
With the Model M, I type faster than on other keyboards - much faster. My personal best on a laptop was 50 words per minute on my old 12″ PowerBook. I’ve hit about the same speed on my various ThinkPads, MacBooks, and Toshibas, but the 12″ PowerBook was, in my opinion, the fastest laptop keyboard.
I just took a typing test using my old Model M and hit 64 words per minute - and I had fewer typos in the process. There’s just something right about the design; I really can’t describe it other than saying that my finger always presses hard enough and never too hard on a Model M - are two of the many reasons for typos on lesser keyboards.
Of course you still have to hit the right key, but even that seems easier on this most magical of keyboards. The new one I just bought cost almost $70 for something made well over a decade ago, and I consider it a bargain.
…while noisy and intrusive to your neighbors, there’s one very good reason why the buckling spring keyboard remained in production for so many years and why it’s something of a specialty item today. Those switches are very expensive compared to the cheap rubber domes in use today, and it’s those switches that give this keyboard its legendary feel (and make it too expensive for this age of made-in-China mass-production).
After reading all that I was hooked, and I ordered one. Unicomp now has the rights to the Model M and they still make them (but they’ve renamed it the “Customizer”).
A World War II recruiting poster for women stenographers
My keyboard quest got me thinking about that old Royal typewriter, so I did a quick Google image search and found a picture that looks just like it. I also came across a World War II poster for recruiting women to be stenographers. But that’s not all they did - many women worked as “computers” and after the war some went on to become the world’s first programmers:
Before the invention of electronic computers, “computer” was a job description, not a machine. Both men and women were employed as computers, but women were more prominent in the field. This was a matter of practicality more than equality. Women were hired because there was a large pool of women with training in mathematics, but they could be hired for much less money than men with comparable training. Despite this bias, some women overcame their inferior status and contributed to the invention of the first electronic computers.
In 1942, just after the United States entered World War II, hundreds of women were employed around the country as computers. Their job consisted of using mechanical desk calculators to solve long lists of equations. The results of these calculations were compiled into tables and published for use on the battlefields by gunnery officers. The tables allowed soldiers in the field to aim artillery or other weapons, taking into account variable conditions such as temperature and air density. Today, such calculations are done instantly in the battlefield with microcomputers.
…When the ENIAC was nearing completion, six women were chosen from among the human computers to be trained as programmers. …[They] devised the very first computer program, which was demonstrated when the ENIAC was unveiled in early 1946.
Before World War II, the term “computer” also referred to mechanical calculating devices (the Greek Antikythera mechanism, from about 150BC, being the earliest known example). ENIAC, unveiled soon after the end of World War II, was one of the first electronic, digital computers. As such computers came to replace all their human and mechanical counterparts, the descriptor “digital” was eventually dropped.
“Digital” is a word that has evolved into something almost antithetical to its origin. Digits originally referred only to fingers and toes. People use their hands to create and manipulate physical objects - to do things manually. Digits came to be synonymous with numbers, since you can count them with your digits. And computers are digital because they are essentially glorified calculators, and we rely on computers to do things for us automatically.
Sitting between the manual world and automated world, between the analog and the digital, is the keyboard. I’m looking forward to the arrival of my Model M, and feeling something akin to the satisfying whack of an old Royal typewriter as I type my programs - putting in the manual labor that ultimately lies behind all automation.
My Shashin plugin recently made the 20+ WordPress Plugins that Rock list by Jayson Akers. I have a slew of new features I want to add, but unfortunately I’m wrapped up in other projects right now (i.e. projects that can pay the bills). But an update will be coming - give me about another month.
If you’re not familiar with PHP sessions and how to use session variables, getting up to speed isn’t easy. What makes it difficult to learn is that it’s hard to make sense of the online resources. That includes php.net, which has a ton of little pink and yellow boxes on its pages about sessions, with caveats about important changes between PHP versions. The “right way” to use sessions has changed with successive releases of PHP, and many of the old ways are now either more trouble than they’re worth, or simply may not work at all anymore. Throw in the changes with PHP classes (if you want to store objects in sessions), and the multiple possible ways your server can be configured for handling sessions, and it gets even more confusing. So any tutorial you read that’s more than a couple years old may lead you astray.
I’m not going to try covering all the possible variations, but here’s what works for PHP 4.3.9 with a default session configuration (see the Runtime Configuration section of that page if you want to see the details), using MySQL and Apache. I’m fairly certain this all works in PHP 5 as well, but I haven’t tested it.
- session_start: you need to call session_start() on every page (you can save yourself from repetitive coding by putting this and other page startup code in an include file). Note that by default it stays with the session id that’s automatically set when the user first starts his session - you don’t need to pass in the session id (the php.net documentation could be clearer on that point).
- Requiring your class files: for any objects stored in session variables that you use in a page, you will need to call require_once() on their class files before your call to session_start(). This is necessary for PHP to know how to map the data in the session variable to the class (another good candidate for reuse in an include file).
- session_register: you don’t need to use session_register() anymore. Just use the $_SESSION array to store your variables. I found a lot of online discussions from a few years ago about session_register being essential when putting objects in sessions - that doesn’t apply anymore.
- serialize: if you just want to store your objects in sessions (not in files or database tables), you don’t need to serialize() them yourself, and you don’t have to worry about losing the object type or access to its methods.
- mysql_connect: at first I tried putting a call to mysql_connect() in a startSession method of a database class I created, thinking I’d only need to call it once for the user’s session. That doesn’t work: the connection is lost after the http response for the page is complete. Trying to store the connection in a session variable does not magically persist it for the user. mysql_pconnect() is not the answer either, for reasons outlined in the php.net Persistent Databaase Connection page. The answer is to simply make connections as needed for each page - old connections will be reused if they’re available, so this doesn’t necessarily lead to an unnecessary proliferation of connections. You can even call mysql_connect() repeatedly on a page and it will by default re-use the connection that was initially opened on the page. This is nice if, like me, you’ve written a database class and you have a generic query method in it: you can call mysql_connect() in your query method, and not worry about how many times it’s being called by a particular page.
I should point out all of the foregoing is for garden variety purposes: managing connections for high traffic sites, security, scalability, and dealing with users who don’t accept cookies, are all beyond the scope of this post.
So, in my code I have no calls to session_register() or serialize() (as they’re not needed for storing objects in session variables), and in my database class’s query method, I call mysql_connect(). The main things to remember are requiring your class files before calling session_start(), and doing so on every page.
My blog has been sadly quiet for the past month, but I’m now ready to resume my blogging duties. Today I’ve just a got a brief announcement though: Shashin 1.1 is now available for download at wordpress.org. I’ve added the most requested feature - widgets. Shashin now has a widget available for each of its main functions (displaying single photos, album thumbnails, random photos, newest photos, and tables of thumbnails). And for those not using widgets, I simplified the code needed for adding Shashin to your sidebar manually.
I don’t use widgets myself - since my sidebar is just a thin sliver of nav elements across the top - but it was fun learning how they work. The widget admin forms are great because I can include things like a drop down menu listing the possible image sizes, so you don’t have to keep referring back to the FAQ. The one thing that struck me as weird while studying other widgets is that all the other widget authors seem to have something against including a submit button in their widget admin forms. That’s just bizarre and not user friendly at all - they’re just counting on you hitting “enter” after filling out the last field in form. It’s probably because the couple of tutorials that are out there have just a single text input field (where a submit button is arguably less important), so everyone just blindly followed them, even when making a longer form. I’m happy to say that my forms include nice, friendly submit buttons
Last month I looked at my site stats and was all starry-eyed about the traffic I was getting. But a closer look at the numbers revealed the vast majority of it is just spammers and bots (spammers trying to flood my comment form, and search bots indexing my site). Instead of the 68,000 monthly visits listed in my site stats, the number of visits by actual humans is about 6,000 a month (not counting my visits, if you want to assume I’m human). That’s still a very nice number though . My most popular posts are ones about programming, travel in Japan, and pho. Time to write more pho reviews!
I just changed my permalinks to use the blog post titles rather than the post ID numbers in the URL, as I’ve learned that Google very heavily weights the words in the URL. AdSense does this too - my “technobabble” category, where I mainly discuss programming, keeps showing ads for DJ gear, presumably because of the word “techno” in the URL. I may drop the ads - I’m earning only about $1/month, which is a joke. I figured I’d keep them if they at least covered my monthly hosting fee, but it’s not even close.
I was nice and put in 301 redirects for my popular posts, and spiffed up my 404 page for anyone who gets lost. The very funny 404 Error Pages: Reloaded collection inspired me to create my own 404 page, giving a new purpose to a great drawing by my brother John.
I’ve been battling with the spammers using various techniques over the years, and I’ve finally settled on reCAPTCHA. I’d resisted using a captcha (as I don’t think non-spammers should have to bear the burden of my spam problem), but reCAPTCHA is nice because it’s actually productive work: the results of the captcha are used to help digitize books.
Shashin 1.0 is now available. New features include an options menu (so you don’t have to touch the code to change settings), improved random image and thumbnail display features, the ability to show the latest uploads to your albums, and UTF-8 support. Thanks to everyone who helped with the beta testing (the beta version was downloaded exactly 100 times).
Shashin is available at the WordPress plugin repository now, so you can get it there as well. The plugin repository requires a readme.txt file with an FAQ section. To avoid maintaining two sets of documentation, I rewrote my Shashin page to also follow the FAQ format.
If you’re crazy for code, you can read the PHPDoc documentation.
[tags]WordPress, Wordpress plugin, Picasa[/tags]
