Or maybe I’ve been working too much and my mind is a bit melted.  Still, SQL is about as conversational as code can get.  SELECT name FROM people; is a bit of a snippet of a conversation, and at this point, MySQL and I have been talking for years.

MyISAM and InnoDB

Until recently, most projects I’ve worked on have dealt with rather small numbers.  No table has had many more than a thousand rows, and everything rather fits neatly in memory.  I’m now scaling up a bit, and am paying better attention between the differences between MySQL’s different storage engine options.  Namely, the two sides are MyISAM, the default storage system, and InnoDB.  By “storage engine,” I mean it’s the method by which MySQL actually puts the data onto the disk, and subsequently does its reads and so on with the resulting information.

MyISAM is sort of simple and out in the open.  CREATE TABLE countries ?  That’ll generate a countries.MYD, which is the data, and a countries.MYI, which holds the indexes.

InnoDB, on the other hand, is a bit more sneaky.  By default, InnoDB puts all its data, index and column information  in a single place, for all databases, tables, etc., in a file named, by default, ibdata1.

ibdata1 gets obese

I like a lot of aspects of InnoDB, though one thing I don’t particularly like is that this ibdata1 file can get rather large, without many options to reduce its size.  There aren’t many solutions to this, though the one I found which I’m currently employing is to enable Per-Table Tablespaces.  Essentially, I just add one line into the system my.cnf which reads: innodb_file_per_table.

How to be silly and mangle your MySQL system

So, armed with the single additional line in my configuration file, I decide to go wild.  I shut down the MySQL service, after checking that I indeed have no data whatsoever in any InnoDB tables in any databases.  I change the config option, and I move the ibdata1 to a temp location.

The server rises once, and then later decides it has lost its will to live.  Luckily, I can see the error messages in the syslog, which includes a lot of scary data and a message which reads “The log sequence number in ibdata files does not match.”

I realize at this point that I’ve been playing around a bit too much, and that I should have been a bit more careful.  Alas, I then move away the ib_logfile0 and ib_logfile1 files which were in the same directory as the ibdata1, restart MySQL, and the system starts these files off again at a base, zero level.

.ibd reigns

After my heart rate came back down to a reasonable level, I then started to play with my new config, innodb_file_per_table. Indeed, now ibdata1 stays at its current level, and manipulating a table which has ENGINE=INNODB modifies a file in the database directory named tablename.ibd.

By default, the .ibd file is going to act in the same way as the single InnoDB store, ibdata1.  It’s going to get large and out of control.  A single table which was less around 2MB in MyISAM quickly took up 10MB as the .ibd file.  DELETE FROM tablename; and the .ibd is still 10MB.  However, DELETE FROM tablename; ALTER TABLE tablename ENGINE=INNODB; and then the .idb falls back to a much more reasonable size, as it started without any data.

Indeed, this type of ALTER TABLE command essentially drops the table and then regenerates itself from a temporary copy.  This is obviously a terrible idea for a production system.  It’s also always a good idea to back up before doing anything drastic.  Even so, with the given precautions and some good system downtime, this method comes out with what I consider to be a reasonable result.

As with anything I write here, if there’s anyone out there that can verify any further dangers or caveats, please leave me a comment so I may correct my ways.  Otherwise, hopefully these tips will allow for an extra few converts to the InnoDB system who may have been scared away when visiting the disk DB stores.

On the technical side, this is a huge step up.  Many sites are non-trivial, requiring a number of steps, and, more importantly, some reasonably obscure structures.  The tweet button also looks very nice: subtle, and entirely functional.

Twitter’s scope

The first competitor that comes to mind is Digg; yes, Facebook is also in the mix with its Like count, though the Digg count has been around for years now, and was, in my mind, the starter of the second run of website counters.   Furthermore, Digg launched its own shortening service more than a year ago; and as of today we now have t.co, Twitter’s crazy short domain name.

I’m not sure where Digg is headed, though they seem to be having a lot of trouble this past year.  I’m currently in the alpha, and I can’t say it either gets me excited or gets me to visit the page any more than I had.  I do hope they can pull it together, though with Tweets superseding Diggs, the future seems to be headed for the.. bird.

Then there’s Facebook, which has had its Like Button for months now.  Realistically, the Tweet Button is more in conversation with this particular element, albeit with JavaScript and HTML5 rather than a single URL with GET variables.  I’ve gotten less fond of Facebook by the year, and that Twitter is now again taking over this realm I’m much happier to teh bookface.

Future reach

This particular story is about aggregation, and about integration.  To me, the next step seems to be going back towards Digg: having some function whereby a URL can be prepended by t.co, for instance, which would start a Tweet with the appropriate URL link and title.

More importantly, being able to share content from mobile devices has to get easier, one way or another.  These systems tend towards that, though still depend on the particular site to implement the button.  Blogger had a “Blog this” toolbar button, and it seems we’ve forgotten this type of functionality in the mobile space.  There must be some web-standard way, too, which does not depend on a platform-dependent app/toolbar/addon/etc.  It’s rather meaningless without widespread adoption, which is why it’s more sensible to have this in the hands of an established community with a large userbase.. though I suppose we’ll just have to wait and see where this all leads.

O’Reilly’s High Performance MySQL has been an unbelievably helpful resource, given me tons of ideas in terms of schema, indexing, and general strategies.  It’s a long book, though even the first few chapters are very helpful, and it’s very well written.

As a short cool-down, I played a few rounds of Team Fortress 2.  It’s a great game, and it looks quite stunning since I upgraded to an ATI HD5670.  My stats aren’t all that wonderful, and I mostly play with a wired 360 controller over keyboard and mouse.. but it’s fun and has a great cartoon-y aesthetic.  I also played a bit of GRID a few nights ago, which I’ve been enjoying a lot.  It’s much on the arcade side of simulators, though the instant flashback feature is great and the sound design and graphics work really well.

I heard it was beautiful outside the past few days, though I didn’t exit the door even to go into the hallway of my building.  I certainly have been more of a typical nerd recently; not exercising as much, skirting away from the sun.. though these work projects have been really interesting, and the idea that I’m creating something for a larger base of users is exciting.

I’m also coming into my sixth year of PHP development, and my code is getting tighter by the month.  It really is so much easier to write a lot of lines of code, yet condensing the logic and finding more efficient paths to the same solution is always worth the experience.  In my head, I think of it as the difference between writing scripts: small procedures to do a particular task; compared with programming: creating some kind of robotic life form which is beautiful and can speak for itself.

Overwrote my php.ini

For those who don’t know what a php.ini file is, it’s a very important configuration file for PHP.  If you want to set whether errors get displayed, which directories you want in your include path, etc.  These are both options that I set in my php.ini:

I’ve put my custom libraries outside of the web-accessible path, in the odd case that there’s a system problem and the code gets exposed.  More importantly, however, I can have a single require_once(‘library.php’), and regardless of the path I’ll be able to get the file within that include directory.

I also changed the default error behavior, to disallow PHP errors to be displayed on the page itself.  This again is a security measure, since otherwise there’s a reasonable amount of information about the system that can get leaked out by these error messages.  They should be in a private log, not searchable via Google.

Imagine my dismay, then, when I find that my site has been broken since this past Sunday (Friday, today) because both of these directives were completely overwritten by Bluehost.  I never received an email, nor any sort of communication before or after the fact.   I was on the support line for 27 minutes and 53 seconds, after which I received a suggestion that not all users are quite as picky as myself, and that I can send an email to their feedback line if I wanted to voice my opinion.

I’m opting for this instead.

My only real evidence of any sort of problem was, and is, the modification time of the php.ini file, and another file titled “php.ini.NEWCONFIGPOSSIBLYBROKEN”.  Oh, and masses of error logs; and the site showing PHP errors rather than content.

Passwords in the clear?

So of course, that wasn’t the whole story.  There’s also Bluehost’s support contact page, which is a gem in of itself.  In order to see the nasty bits, you’ll have to click one of the various support options and hit the button at the bottom of the form.  In there lies a rather special field:

Last 4 Characters of Password (not credit card):

Really? ! Upon mentioning this to the tech on the support line, he assured me that the system is entirely safe.  No one can read your passwords; they have a script which takes your input and then gives an answer.  He wasn’t sure how it worked, though he claimed to know it was not a security problem.

It is possible that the system is storing two independent hashes, one for the entire password and secondly for what’d be substr($password,-4);.  I seriously hope that’s the case, because any other alternatives that I can dream up seem to point to storing the system passwords in plain text.  I do hope that they are not that stupid.  My confidence is just a little bit shaken, however, by their inability to forsee other problems, such as described in the upper half of this post.

Taking a deep breath

Aside from today, I’ve never had a problem with Bluehost.  I know they have a huge number of clients, and that alone is not an easy job to undertake.  Their MySQL performance and support for multiple domains make me want to stick with them; on top of the fact that I already bought three years of service from them, of which I have two left..

With that said, systems are incredibly important, and these kinds of mistakes are not representative of a company which knows what its doing.  Luckily they had backups of my old php.ini — and because I knew where to find it, I was able to get my site running again.  Sans that, however, there was no trace of my configuration.  That simply is not cool.  I sincerely hope that they, along with all other providers, take the proper steps to help developers; not those which send them up a creek without a paddle.

Previously, I had a rather simple PHP script on my site which looked at the browser string from the client; if it seemed from that as though the current user was on a mobile device, I then either loaded a mobile-overrides CSS file, or modified the statements inline (in the case that my CSS was served up via PHP).

Smashing Magazine recently posted an article titled Modern CSS Layouts: The Essential Techniques which came up on Digg.  I’ve heard of a number of the other sections, though what really caught my eye was the large amount of discussion about media queries.  What particularly caught my eye was the article titled Safe media queries from dev.opera.com.

This is why, if you’re using Internet Explorer to visit this site, all my pages look a bit messed up in their current state.  I’m being liberal with the “safe” part of the article, and tending towards more what’s in the Dev.Opera tagline: “follow the standards, break the rule.”

General idea

So the idea here is that within a single CSS file, it’s possible to section out certain rules such that they apply only to certain types of devices or screens.  The main players are min-width and max-width; the general syntax goes something like: @media all and (max-width:800px) {/* rules */}.

My approach

There are loads of way to attack this.  One major concern is that Internet Explorer and other non-supported browsers don’t understand whatever it is you put inside these rules, as defined in the way of the previous paragraph.  The Dev.Opera article breaks this down quite well.

As long as the site is readable and easily navigable, I’m not too worried about making sure the page looks exactly the same on each system and browser.  Obviously, I have a much looser set of criteria than most designers out there; so if you’re more restricted you’ll have to think about your other options.

Rethinking set widths

In my case, I thought I’d rethink the structure of fixed-width elements; yes, all fixed widths.  Why?  In the world of mobile devices and all sorts of browsers and options, it’s going to be more and more important that your sites’s content can reflow in an accessible way regardless of the platform.

Ergo, my tack is to put any sort of important definitions pertaining to a width: definition down to the bottom of the CSS file, inside my @media all and (min-width:...) {} block.  What once was:

#page {width:820px; margin:30px auto; padding:10px;}

now instead becomes:

#page {padding:10px;}
@media all and (min-width:840px) {#page {width:820px; margin:30px auto;}}

The 840px minimum width is to figure in the padding on each side; and the result is that if my browser window is more narrow than that, I don’t have any horizontal scrolling to do.

In my structure, #page contains both a main section and a sidebar.  I floated the sidebar left, along with its children; and then in the media query block alone I set the width of the actual sidebar.  There is a bit of a jumble of elements at the bottom now, but moving to a small screen makes it worth it.

My pattern, then, is to let the browser expand all the elements as it needs, and to only set the large-screen elements for the browsers that can handle it.

Choice philosophies

With the above plan, Internet Explorer and the other non-supported browsers are going to see my site in some sort of goofy layout that’s meant for phones and pocket devices.  I’m OK with that, because I can still get at the content in a nice enough way.  I feel that the standards have to logical, but they also have to be pushed forward by aggressive use and stricter implementations, and browsers which accept these standards are the only way towards true progress.

The bigger picture, beyond my half-assed vendetta, is that CSS is alive and well; and I’m more than happy to be ditching the practice of checking browser strings in order to get my site readable on all platforms.  I also would urge anyone who takes a quick look at my site and gives the concept a pass: that there’s more than my solution out there; and if you have something even better than what I’ve dreamed, please have at it and leave a note for me in the comments :)

Why this matters

The idea is that browsers now support the ability to download and incorporate fonts not on the host system.  This is a big leap forward, because there is a very limited set of fonts which you can use for the web.  Mac fonts aren’t all in Windows or in Linux installations, ditto for Linux into Windows, etc.

You can use CSS to have a list of fall-back font families, though all this does is allow for the particular system to use a different font which is “good enough.”  Namely, you can have:

body {font-family:"Helvetica","Arial", sans-serif;}

which reads that the body tag should first utilize the Helvetica font; if Helvetica is not available, then use Arial; if Arial is not available, then use any sans-serif font on the system.

With embedded fonts, I can keep this same syntax yet with an additional font which isn’t necessarily on the visiting computer:

* {font-family:'Fontin', 'Helvetica', sans-serif;}

This says that for all elements, use the “Fontin” font first, then fall back in the same way as in the other example.  Fontin is a free font which is publicly available and is released under terms which allow for embedding into a page.  You can download Fontin at the exljbris Font Foundry website, and view a list of other fonts also available for this purpose at the webfonts.info wiki.

Making the font files findable: @font-face

“f”.

So, if you have tried the above without more work, you’ll quickly see that nothing new is happening.  The trick, then, is that the browser needs to know a bit more about this “Fontin” typeface which is not on the computer.  Before the declaration of the font family in the CSS file, you’ll need to add something like this:

@font-face {
font-family: "Fontin";
font-weight:bold;
src: url(/fonts/Fontin-Bold.otf) format("opentype");
}

@font-face {
font-family: "Fontin";
font-style:italic;
src: url(/fonts/Fontin-Italic.otf) format("opentype");
}

@font-face {
font-family: "Fontin";
src: url(/fonts/Fontin-Regular.otf) format("opentype");
}

Hopefully this is mostly self-explanatory, though what’s a bit tricky at first is that there are multiple declarations for the same font.  There’s also a src for each font file; so you’ll have to have these publicly accessible on your web server in order for the browser to download and utilize them.

Browser support: not all there yet

With the overloading CSS as above, both Opera and Safari under OS X fail a bit, instead rendering whatever is the last listed directive.  In that case, it’s probably safest to list the normal font last, unless you want everything in italics, etc.

One way around this is to use different font-family names, and then re-define the CSS such that em tags and any other italicized text gets the alternate font-family definition; i.e., font-family:'Fontin-Italic', etc.

Firefox 3.5 works without a hitch, however, so hopefully this will just be reconciled with later versions of the other browsers. Internet Explorer doesn’t play game at all; my guess is that there are additional tweaks specific for IE, as is most alway the case.

Still, what’s great about the system is also what’s great about CSS: even lacking browser support for the latest iterations, your site will fall back to using the same fonts you had set up previously.

Proceed with caution: license considerations

One trick with this font system is that there are not all that many fonts available for this particular use.  Most TTFs are not free, and even those that are free cannot necessarily be shared in such an open way.  While this may seem a bit cruel on the part of the font foundries and font makers, using this system does require that the font files are open and unrestricted: it doesn’t take much work to look at the CSS files to find the web location of the fonts themselves, which then leads towards very easy propagation of the files without a requirement for attribution, etc.

Conclusion

The constant problem in being on the edge, especially with the web, is that it doesn’t always work out for every system.  In terms of danger, however, setting alternate fonts does not seem to me to be all that dangerous.  In the absolute worst case, the site will just display whatever is next in the CSS list of fonts.  I personally am conservative in terms of utilizing new web technologies, though in this case I don’t see too much reason to hold back.

WordPress/PHP code

This isn’t rocket science, though in the case that other people want to do the same, here’s what I have.  Please adapt to fit in with whatever schemes you have in your site:

<link rel="stylesheet" href="<?php bloginfo('stylesheet_url'); ?>" type="text/css" media="screen" />


<?php $header_colors = array('rgb(111,111,111)', 'rgb(222,64,0)', 'rgb(0,111,222)');
$header_color = $header_colors[array_rand($header_colors)]; ?>


<style type="text/css">
#header {background-color:<?php echo $header_color; ?>;}
</style>

Add to / subtract from the $header_colors array to make changes to the set of colors which are randomly selected.  Nothing too complicated here, but it can spice things up a bit without too much work.

I will hopefully get into more about the mobile version at some point.. though if you’re trying it now, this page ought to look just as good on smaller screens, as well as large.

One further step I’ve taken in this theme is to use a bit of WordPress functionality in adding a configuration menu, in the vein of this Codex page. I’m not getting into anything fancy, and anyone visiting really won’t care or even be able to notice.. though I now have my own simple menu by which I can place in my Google Analytics code and have it show up at the bottom of the page as it should. Again, that’s a topic for another day, which I hopefully will not neglect to write up in more detail. For now, I give myself a mini-yay.

Setting up the environment

In order to use the above tools, you’ll have to install calibre and then install the command line tools under the preferences menu. From there, you can run the two tools from the command line. All you’ll need to do, in terms of syntax, is to be able to run:

lrf2lrs <filename>
lrs2lrf <filename>

You can add in the -o <output-filename> option to either of the above in order to redirect the output.. though I haven’t personally found this particularly essential. It will, by default, use the same file name with differing extensions of .lrs and .lrf, though in my workflow I just make sure that I save a copy of the LRS file when necessary in order to roll back changes.

Editing the LRS files

If you aren’t all that familiar with code, especially XML code, don’t expect any miracles. It is very easy to change the meta information, such as the author, title, etc., just by changing the text that you see into the text that you want.

Editing the Table of Contents

The top of the file contains the table of contents, under the tag <TOC>, with entries as <TocLabel refobj="X">Chapter Name</TocLabel>, where X is the target objid. There is also generally a “refpage” attribute in TocLabel, though you can safely enough ignore these since they’ll be recalculated when transferred back into the LRF format.

objid — object ID’s

The important thing to know about the objid (think object ID) is that it must be unique. It does not have to be sequential, however, since when you run the conversion to LRF (and back to LRS, if so desired) these numbers will be recalculated. The objects to which objid’s are assigned, can be things such as a Page, TextBlock, Image, BlockStyle, TextStyle, etc. In order to keep things straight, I often would enter in new objects as fresh ID numbers way above the max in the document, then convert to LRF and back to LRS. This way, the new LRS will have sequential indexes again.

Body content and styling

The bulk of the text of the LRS document is contained within Main, which contains a number of Page and TextBlock elements, which therein contain paragraphs (P), line breaks (CR), and formatting code such as Italic.

After Main, there is a Style block towards the end of the LRS file. These contain certain elements with their own objid numbers, which are referenced in the attributes of the elements within Main. This is vaguely like CSS, though it is different in that it is a bit more obtuse to write since the styles are only maintained by numbers which can and will be re-indexed in converting between LRS and LRF formats.

Conclusion

There is obviously much, much more to creating files from LRS, and to tricks in editing these source files in more depth. Starting from an existing document, however, it is not too painful to make certain re-arrangements and additions to the structure, and in some cases to simplify code blocks which may have been misinterpreted via conversion or user error. With some trial and error and an attention to detail in maintaining the proper XML format, however, it is nice to be able to control most all aspects of a book by editing a single file. Additionally, even if your target is not LRF, there is relatively easy conversion to EPUB or other formats, using calibre and other open source tools available online.

The trouble with the random selection, at least with the way I had previously coded it, was that especially for small sets of photos, you’d get the same image twice in a row. By keeping track of a counter variable, you can easily get by this. There are, of course, many other ways to do this, though I want to share:

function advanceSlide(item_class, display_id)
{
var display = $('#' + display_id);
display.empty();

var items = $('.' + item_class);
display.append(items.eq(currentItem).clone());
display.children('.' + item_class).fadeIn();

currentItem = (currentItem + 1) % itemCount;
}

$(document).ready(function()
{
var item_class = 'gallery-item';
var display_id = 'gallery-display';
$('#gallery-1').before('<div id="' + display_id + '"></div>');
$('#' + display_id).attr('style','height:500px');
$('.' + item_class).hide();

itemCount = $('.' + item_class).size();
currentItem = 0;

advanceSlide(item_class, display_id);
setInterval("advanceSlide('" + item_class + "','" + display_id + "')", 4000);
});

The main difference is in using global variables to keep track of which image we’re on, and to keep track of how many images total we have. The modulo operator (%) is a standard method for restarting the count once it reaches a certain level, which is what you want when you reach the end of the list of images.

Although I generally do not like global variables, using them in the above (announced by having the variable declaration without the var keyword, in JavaScript) certainly does cut down on the complexity of the code.

I really believe the future is going to be more and more about getting information organized in very particular and portable ways. Google, and increased computing power in general often makes it easy to throw caution to the wind, abandoning structure with the expectation that “technology” will solve all ills. The reality, though, is that we still have to index, catalog, and in many cases refactor our data and related systems in order to fit the needs at hand. Searching alone is not the savior, and, ultimately, it is not going to change the game.

Busy work, then, can be defined as needing to hand-sort large sets of information simply because the existing form lacks a reasonable organization. Said another way, it is much more efficient to be able to just change the names, be it piles on a desk, structures of nested folders, or deeper database systems; but it is an entirely separate problem if we cannot even see what we’re looking at without a lot of work. The more general corollary to what I’m saying is essentially that it is more important to work intelligently than to work hard. More specifically, computer systems alone are not the savior if the fundamental practice is broken from the outset.