The Simple Part

It’s been some time since I started writing this three part series, and it certainly took a while longer to get done than I expected. A busy work schedule does tend to do that, but if it makes anyone feel better, having left the third part hanging did give my conscience a field trip. So let’s do a quick recap and get on with it

• In part 1, we created a jQuery plugin which displays a simple static calendar.
• In part 2, we added the facility to pick a date, and to switch the month on display.
• In part 3 (this post), we will add some sanity checks, and the ability to display events on given days.

Read the full post

Following last week’s implementation of the basic shape of the calendar, this week we will add behaviours so that we can pick a date on it.

This post is part of a series of three posts:

• In part 1 we created a jQuery plugin which displays a simple static calendar.
• In part 2 (this post), we will add the facility to pick a date, and to switch the month on display.
• In part 3, we will add some sanity checks, and the ability to display events on given days. Read the full post

A few years ago, I wrote a calendar control for a Code Project article. Although I’ve used it myself several times, and despite the fact that people still appear to be using it, I can’t help but cringe every time I look at it again. Every time, the thought that comes to mind is “It could have been so much cleaner in jQuery…”.

Well, the time has come to bite the bullet and see how it can be pulled off again. Rather than going over the whole thing in one go though, we’re going to take it in steps over a number of posts to implement a feature or a group of features, so we can look each in slightly more detail. This is as much for my benefit as everyone else’s. If anyone spots anything weird, inefficient, or badong in these posts, please let me know. I like to think of this as public code review, so, you know. Bring it on.

We can rebuild him – we have the technology

The posts will be divided as follows:

• In part 1 (this post), we will deal with the display of a simple static calendar.
• In part 2, we will add the facility to pick a date, and to switch the month on display.
• In part 3, we will add some sanity checks, and the ability to display events on given days.

And with that, on to the post itself. Read the full post

Wrote a brief note on the speed of digests in PHP vs. the speed of the same digest in MySql.
Read it at http://fwebde.com/php/encryption-php-vs-mysql/

Recently, I needed to write an up/down selector – you know the sort, it’s where you select a number by clicking on an up or down arrow. Since they can be useful for other things besides numbers, I gave it the plugin treatment.

Most of the information about the plugin can be found in its documentation page.

Also available is a slightly beefier styled and animated demo of the plugin.

If you’re just interested in the plugin itself, you can find it here.

The people of the web are revolting against IE6! (at last). While many web developers and designers have been complaining about Internet Explorer 6 for ages, more people are now making a concerted effort to ease users away from this museum piece. There’s even a wiki about this worthy cause.

Simone Chiaretta wrote a great article about this campaign at CodeClimber, with instructions on including Vincent Hasselgård’s IE6 warning. Joe Levi also created a great variation of this to scare IE6 users with

Vive la revolution!

How to create a sliding popup like the one used at SitePoint using jQuery.

Read the full post

A good user experience requires responsiveness. Speed. Web pages that don’t make you wait more than a couple of seconds while they load, or even worse, load in bits and pieces and reorganize themselves in front of the user; “that’s the way these things work” isn’t good enough an excuse. Your users don’t want to know how your site works (even if your site is about how the internet works – they want to read about the problems, not experience them), they just want to get things done and move on. As Eve says in Gaiman’s The Sandman Vol. 6: Fables and Reflections, “Some people have real problems with the stuff that goes on inside them … sometimes it can just kill the romance”.

Two of the culprits these days seem to be huge JavaScript and CSS files. They’re by no means the only causes, but they can cause trouble at times. Delays when loading a CSS file result in the dreaded flash of unstyled content on some browsers. Problems loading a JavaScript file… well, let’s just say it ain’t pretty. The delivery of these files can be slowed down by a number of factors. File size is one of them; a 168kb file will download considerably more slowly than a 6kb one.

This is made worse by the use of multiple JavaScript and/or CSS files. Separating functionality or styles in a sensible way is heaven-sent when it comes to maintenance, but the way the web works means that it’s a lot easier to download one largish file than several small ones. Multiple files mean that the browser must make multiple requests to the server, and each request carries a small overhead since the server has to include a certain amount of information with each response it makes. To top it off, most browsers are configured to open a limited number of connections to a server at any one time – IE8 allows up to 6 concurrent downloads on broadband, while Firefox allows 8; these connections must be shared between the JavaScript, style, images, and other embedded files. This can cause the downloads to be queued up on pages with a lot of stuff on them.

What we need, then, is a small number of reasonably sized files: how do we get to that?

Read the full post