Disco Shiny

Caching In On Performance Boosts

Kurt — Tue, 16 Jun 2009 18:10:24 +0000

Part of my intent in making this blog was to be able to talk about ongoing development in my various projects. Unfortunately, a lot of the work I typically do is simple HTML and CSS and it’s not challenging me to learn something new. Today, however, I have something to report.

I received an email from Dreamhost last week informing me that they were throttling connections to my video hosting site because recent traffic spikes from the Sonic Unleashed Let’s Play were causing the Apache server to have problems. Now I’ll be the first to admit that my video hosting solution is not elegant or efficient. I started it small and hacked on features as I went. Yeah, one of those. Everyone makes one eventually, but in this case, mine got popular so I needed to fix it.

I determined that I needed to implement a form of caching to cause my spaghetti code to run as infrequently as possible. Professional-level caching solutions require control of the server the site is running on, both hardware and software. These same solutions are also rather complicated and work to cache selectively only those parts of the site (and sometimes within individual pages) that do not change very often or ever. For my site, I know that once a video is added, the page that lets you view it almost never changes, so this is the part of the site that will be cached. This is also the part of the site that sees ~80% of the traffic total and closer to 100% of the traffic during the spikes. Fantastic.

The rewrite involved a few steps. First I removed all the code used to draw the page contents and put it in a function. The function, printVideoPage, takes the ID of the video in the database and returns a string of the page content. I also took this opportunity to optimize the way I use ADOdb because I have a better understanding of it now than when I wrote this 3 years ago.

The second function I wrote creates a cache file. This function, updateCache, also takes an ID. It opens the cache file located at the configured location with the configured file name and starts writing. It actually writes a PHP file which declares two variables, $name and $contents. When show.php includes the cache file for the requested ID, it can put the name of the video in the title and the contents where they belong.

For the average visitor to my site, this eliminates all SQL calls and a great deal of very bad PHP. If a cache file does not exist, the site displays an error. This means that the cache must absolutely be a correct and accurate representation of the database at all times which annoys me, but as long as I call updateCache any time I change or add a video record in the database, everything should be fine. I do not think there are any bugs, but there are certain aspects which have not yet been tested as much as they should be. show.php is functioning as expected which for now is the most important thing.

I cannot show you empirical evidence that my measures to reduce load have worked. I’m on shared hosting; I don’t get access to that kind of stuff. I can only hope it has made a difference and that Dreamhost sees that and unthrottles me. If that’s not good enough for them (and it really should be, Sonic 2006 had way more traffic and this didn’t happen), I am at the end of my bag of tricks on the current codebase and I will have to rewrite. Ughh.

Body Classes Can Be A Smart Choice

Kurt — Sat, 23 May 2009 17:28:53 +0000

At my place of work, one of my projects is to develop our department website. Because this is a major website at the university, it has to follow all the rules. These include accessibility, cross-browser support, and conservative design sensibilities. But being a non-technical corporate environment, they want to have their cake and eat it too, so I have to reconcile the JavaScript carousel and scrolling news widgets they wanted with the accessibility concerns for people with text readers or what have you.

I was poking around the internet and found the solution on another page at our university. I believe it was created by our competition, Creative Services, who we’re pretty sure take templates and butcher them to be Mason-branded. The implementation on that page was the answer no matter how much I loathe their cookie-cutter techniques. The answer is classes.

In the past I had dismissed body classes as being a poor design strategy for a site. This was because I’d only ever seen poor implementations of them, parroted by Lynda.com. You should not use classes automatically on every site you design. This encourages inconsistency in design between pages. It also bloats your CSS because if you’re using a class, you’re using a lot of descending selectors and creating styles like .bodyclass #sidebar ul li.

But there are circumstances in which body classes can be used correctly and one of these circumstances is my problem. The idea is to first create your page without any JavaScript functionality at all, but with JavaScript functionality in mind. That carousel of images, for example, becomes a grid of images. The scrolling news shows only the top three items. The animation is not present. Then in your $(document).ready() block before anything else, you do this:

$('body').addClass('js_ready');

You’ve just added a class to your body tag with JavaScript. If the user does not have JavaScript enabled, this will not trigger. So now you can put all your JavaScript styles under the .js_ready selector. Because of the specificity of CSS, adding more information to an element selector will override any other reference to that selector. So if you have #carousel ul li and .js_ready #carousel ul li, any styling in the latter block will override the former, making your page style differently in the presence of JavaScript. This may necessitate updating the prepackaged CSS that came with your widget to include the body selector.

Well that’s a pretty cool thing, and while I was realizing how it worked I thought of another possibility. Admittedly it’s not going to be widely used, but I guess it could make a good tech demo. What if you want to have different themes for your page? Each theme is under a different body class and could be changed via JavaScript. I imagine this would be most handy if you’re pitching to a client and you’ve created a couple different designs and you wish to cycle quickly through them for comparison. The theme change would not be persistent across pages without some extra work, and who wants to create more than one completely realized style per site anyway? But it was a neat idea I had. Maybe I will implement it here on Disco Shiny…

Serial For Breakfast

Kurt — Wed, 20 May 2009 21:14:08 +0000

As I posted mere minutes ago, I’m working on an invoicing system. Part of this blog’s function is to be a regurgitation of things I think about when working of various projects, so here we go.

Being a central database for all our services and all jobs we’ve ever done, it becomes easy to update information regarding our services and have them take effect immediately. It has occurred to me, however, that this could be very bad for invoices we have already submitted and been paid for if, say, we changed the price of plain paper. Those completed invoices would suddenly change. I’ve decided the answer is serialization.

When we submit an invoice to accounting, it changes status to “Submitted” (or it will when the admin section is up and running). At this point, we don’t want the invoices to change any more ever, so we load up an invoice in our Invoice class and call serialize() on it. This makes it a string which we then store in a new field. Upon loading an invoice, the class should check a) the status of the invoice and b) if the serialized field is populated. If the conditions are right, it replaces itself with an unserialize()‘d version of the invoice.

I’m just glad I thought of this before I started coding the admin section. If all goes well, though, nothing should change from the perspective of the parts of the application using the class. It just seems like something that could have easily slipped under the radar and then never gotten fixed because we don’t change our prices often at all and I would be gone the next time we did it.

Mason Media Lab Invoicing System

Kurt — Wed, 20 May 2009 20:30:03 +0000

The Front Page

XHTML
CSS
PHP
MySQL
jQuery/AJAX
PDF Creation

One major project I’ve been working on has been replacing the person who’s job it was to aggregate all our invoices, send them off to accounting, and report our numbers each month. Her system comprised a number of excel spreadsheets between which she would copy all relevant data. Naturally a database is a much better solution and so I set about creating one. The project is not yet complete, I still have to create the administration section. Most of the framework is in place, though, and the front end is what I consider to be beta status.

This project was a vehicle for me to learn JavaScript. Since our previous system of creating invoices was entirely based in Excel, the new system had to have at least as much functionality. This meant creating a rich web application which would carry out the calculations for costs automatically.

Using jQuery has allowed me to do a number of things with the site that are both aesthetically pleasing and highly functional. The page that allows users to search for and filter invoices, for instance, uses hidden form inputs combined with a table to simulate rich checkboxes. Clicking a table cell highlights or normalizes it, indicating that it is active or not. The actual form element is a hidden input for each table cell that toggles between ‘off’ and ‘on’ through the use of jQuery.

One very important feature of the new system relates to the way we are paid as a university organization. Each organization has one or more fund numbers which they can supply as a form of payment, and funds are automatically deducted when we submit the completed invoices to accounting. Unfortunately, these are simply numbers and are rather non-descriptive. This invoicing system uses PHP/cURL and AJAX to look up the unit name tied to a given org number so we can double check with clients. We have since caught three instances of clients giving us entirely the wrong department’s number.

The system is incomplete, as I have said. I am actively developing it and hope to have it deployed in beta or gold status by the next fiscal year. At this point we intend to start shopping it all over the university to other organizations that provide services within the university. This is highly tentative and should not be taken as official word.

Blinded By JavaScript

Kurt — Tue, 12 May 2009 06:30:09 +0000

Before about a month ago I had never touched JavaScript, I thought it unnecessary. I had been able to do everything I ever wanted in CSS, and if some task could only be done in JavaScript, then it was not a task worth persuing. Well as of a month or so ago, I began a project at work to create an invoicing system. I’ll get into the specifics of the project in some other post, but a large part of it was using jQuery to create a true dynamic web application. Picking up jQuery does not strictly imply that you pick up JavaScript, but they are rather close enough that you begin to see the majesty and wonder of being able to manipulate the DOM so freely.

This is a trap. I fell for the trap.

A large part of the web designer’s job is to translate a mockup of a design from Photoshop or something into HTML/CSS. This means looking for logical divisions of content and thinking about how the box model can help you achieve this layout. When I created the current design, I saw two columns separated by the fake 3D effect and said “Ah! I will have two columns! One of them will have the repeating background trick and an image each at the top and bottom!” Easy to think, impossible to implement. First off, the sidebar needs to scale with the content, or the 3D illusion is broken. And thus begins my descent (the highest form of patriotic) into the trap. I turned to JavaScript.

All I need to do is grab the heights of the sidebar and content, find which is bigger, and resize the other! Oh, but I need to take into account the offset. Oh but I need to move that bottom image as well. And after not too long, I’ve created something that functions. Hooray. Unfortunately, this is a problem for a number of reasons,

It is highly inelegant. It’s overly complicated and the browser should be doing it for me.
The syntax highlighting code breaks it because it takes longer to execute
It can be easily solved in CSS with a little more creativity

Look, all that needs to happen is have the content div be the combined width of the current content and sidebar divs, images at the top and bottom (use an inner footer div that clears both and has an image background), and then have the two columns with no image backgrounds just take up however much height they need and let the browser sort it all out. That’s what browsers do best.

I got caught up in the shine. I saw what JavaScript could do and was tempted to make bad layout choices by the fact that JavaScript can be used to crutch almost any situation. Learn from this. Think long and hard about each thing you want JavaScript to do. Can it be done no other way? Could you handle it in either the PHP/ASP/Perl/Python or the CSS? Because you should. Here are some things which you can and sometimes should use JavaScript for:

Animation. This is a whole can of worms, another post maybe.
AJAX and all that cool web 2.0 stuff
Form validation. Can be used with number 2

If it’s not one of those things, think again.

This post brought to you once again by the

tag.

Monocle Radio

Kurt — Sat, 09 May 2009 15:25:03 +0000

Monocle Radio

XHTML/CSS layout
PHP
MPD class for PHP
MySQL for user management
Icecast2 streaming server

Monocle Radio is a front end to Music Player Daemon, an application for Linux that does exactly what its name implies. The only way to use it is to run a front end, such as Monocle Radio.

SourceForge Page

In my freshman year of college I had an old computer I used as a server. I kept some backups on it as well as my music. I wanted to be able to listen to my music even when I was not in my room, so I decided to set up a streaming solution.

I looked into available solutions and at the time all the software I could find was either incomplete or too complete. My server was not powerful enough to handle Ampache, for instance. It was for this reason that I decided to make a web-based interface to suit my needs. I wanted something no-nonsense and responsive, even on my aging Pentium 2 box.

My roommate and a couple other people I know wanted to be able to listen as well and have control when I wasn’t using it, so I implemented a multi-user system. It was not very secure and focused more on getting the job done. It required users to be logged in to change the playlist or control the playback, but anyone could listen.

At its completion, Monocle Radio fulfilled my needs. I released a couple bug-fixing releases, but have since ceased development. I no longer maintain a server for my music due to bandwidth and power constraints. Also the old server was 2.5 feet tall and weighed well around 40lbs, an impractical machine at best.

Thoughts on Cross-Browser Coding

Kurt — Fri, 08 May 2009 16:37:30 +0000

I’ve met some people who hold low opinions of IE. Scratch that, I’ve met a whole lot of people for whom IE doesn’t butter their bread. I’m one of these people. These people tend to be web developers, because IE did a number of unfortunate things for people looking to create websites beyond the very baseline. There exist a number of “danger zones,”

Transparent PNG support
z-order
Rounded corners
Floats and margins
Expanding boxes

Okay that’s all I can think of off the top of my head. The point is though, that none of these things are strictly necessary for a website. It’s easy enough to create a site that looks pretty much the same in IE5.5+ and the Firefox/Safari/Opera crowd, but if people choose to use a more modern browser, including newer versions of IE, the site will only get shinier.

Point of all this is, the people who don’t like IE and actively leave out fixes for it are not really professional level yet. Professional level developers neutrally regard or hate every browser equally. Firefox 2 has some weird layout issues, for instance, on sites that look fine in every other browser! CSS 3 support is still handled differently by everyone, each browser supporting a subset. The list continues.

Of H1 Images, Opacity, and Other Curios

Kurt — Fri, 08 May 2009 06:17:41 +0000

I am starting a blog. This may seem like an odd move to a lot of you for a couple reasons:

I don’t update the blog I have because I stopped being emo forever ago
I already sorta have a blog?

But I want to start a real blog. One in which I can chronicle my development revelations and tribulations. Strictly technical junk here, no personal life stuff. It all starts with this post about the development of said blog…

You see, I am not a designer. I have often been praised for my design sense, and I admit I may have some aesthetic sense about me, but I do not enjoy designing and creating designs from the bottom up, and coming up with even the most meagre of layouts causes me great mental anguish. I really like to focus on the backend of my projects. I cram as many neat gizmos and features as I can think of into each one (the mcguffins I have completed here thus far will be detailed below), but each is a slave to the design, not a driving force.

This site has to be my own. I have to design it, I have to pump up the design, and in this case, I have to make it Disco Shiny. So here I am, I’ve started down the path, and I am about 40% of the way to the point where I feel my own ability to embellish existing design can kick in and make it awesome. Anyway, let’s get into the things I’ve done so far on the technical side.

The first order of business was to make this content div semi-transparent. The silly way is to use the opacity CSS attribute which is undesirable for a couple reasons:

Does not work in IE.
Everything inside an opacity-adjusted element is itself rendered at lower opacity, at least in Firefox.

The solution is to use an image that is a strip of 80% opacity white. Some versions of IE hate on the alpha channel in PNGs powerhard, but the fix for it is easy and in JavaScript. All I had to do was include jQuery and the pngFix plugin, and I’m set! It feels a bit hackish, but it also fixes the second issue there, so I feel it’s good, clean fun all around.

I was just slightly pleased with myself after that, but I realized that I could do more. I’m still getting used to jQuery and JavaScript in general, but I’m loving every minute of it. I decided I wanted to use my own font for header images, but that it’s certainly not a font the average user would have on his computer. The solution to that is typically to use an image, but that’s messy and time-consuming, so I wrote a script to do it for me using PHP’s GD image functions (they are awful and clunky but that’s a rant for another post). It accepts some parameters, the least of which is the text you want to make into an image. The JavaScript is a piece of cake after that.

var color = "333333";
if($(this).hasClass('red')) color = "CC2233";
else if($(this).hasClass('blue')) color = "223399";

var size = "18";
if($(this).hasClass("huge")) size = "35";

$(this).html('/futura.php?text='+$(this).html()+'&color='+color+'&size='+size+'" alt="'+$(this).html()+'" />');

This is wrapped in an each() function that iterates over all H1 tags in the page. It replaces the text in each with an image of the text in my font of the moment which is Futura. The ramifications of this are that it has great accessibility while maintaining a comfortable viewing experience for the majority of my readers. Have an example:

Here is some header text that is NO LONGER plain

And that’s about it for tonight I’m bushed. Development continues tomorrow.