Caching & WebApplications

One of the funny observations as a web developer: It’s amazing how many people consider caching bad by definition. If you know what you’re doing, caching is an amazingly powerful tool, which can provide cheap and efficient scaling to those who know how to use it.

Know when it’s okay to cache

If thousands of people see the same non-personal frontpage of your website – do you then do the 20+ database queries to build a fresh one for each visitor or do you just refresh a cacheable version from time to time?

Cacheing isn’t a binary this

While a page on a website may not be cacheable as a whole, is your navigation, your header and footer – and other static parts of the site cacheable? is new menu-items are rare compared to the number of page views, the pages probably receives, the “semi-static” parts of a site should absolutely be cacheable (server side).

Consider you cacheing options

Do make a caching strategy and see what works best for you. Is it a caching server in-front of your website (such as varnish), is it pre-build HTML-files, is it shared memory or is it blobs in the database serving pre-build pieces? The efficiency and the fit to the task may change from case to case, but knowing there is a range of options and knowing what the different options are good for, should be a required skill for any professional web developer.

Caching isn’t evil, it’s your friend – if you know how to use it efficiently.

Changing a form submit url with javascript

Sometimes you might need to change the address a form submits to, it’s quite easy with javascript. One example could be if you – like me – from time to time is hit hard by comment-spammers. Changing the submit URL on the form with javascript, makes it at least somewhat harder for “automated brainless robots” to kill your site in a spam attack.

The recipie below is a very simple example, but so far it seems to work quite well:

<script type="text/javascript">
function doSubmit() {
  var target1 = 'hello';
  var target2 = 'world';
  var target3 = '.cgi';

  var supertarget = target0 + target1 + target2 + target3;
  var theForm=document.getElementById("theForm");
  theForm.action = supertarget;

<form id="myForm" method="post" action="some_fake_address.php">
<input type="text" name="dummy field" value="">
<input type="button" onclick="javascript:doSubmit();">

Whats going on?

The form is a regular form except for to small things:

The action-url is a fake address. On the url it points to, is only an empty file (to prevent 404 errors in my errorlog.
The normal submit button has been changed to a regular button, and the onclick-evnt calls a small piece of javascript, which does the magic trick.

The javascript function can be more or less advanced depending on your needs. In this example it constructs the new target for the form submit by pasting three strings together and replacing the action of the form.

Validation: black or white list

When you’re validating data – either client- or serverside – there are basically two strategies you can choose between. You can either blacklist data or white list data. Blacklisting seems to be the most popular way to validate data, but white listing is so much better. Here’s a brief description of the two strategies and why the white listing is better.
Continue reading Validation: black or white list

Don’t use Ajax blindly

GMail and other web applications have adopted a new technique coined Ajax (by Adaptive Path). It brings web applications a step away from the stateless web and closer to real applications. It’s harder to built applications with the applications, but it’s hot – and the most recent release of Rails (for Ruby) promises to make it much easier to do Ajax applications. Before you do too many Ajax applications, do think for a second.
Continue reading Don’t use Ajax blindly

Developers, Designers and Templates

David HH has an interesting piece on “The false promise of template languages“. While neither Perl nor PHP may offer the same clean syntax in the code as Ruby can do, it does indeed raise a few interesting questions about how actually benefit from the templates and who does in the space between designers and developers.
Continue reading Developers, Designers and Templates

Clientside sortable tables with memory

It’s been awhile since Stuart Langridge released some cool javascript which allows you t do client-side sorting of tables in an unobtrusive manner. Soon after Andy Edmonds released a merge with a function to made alternating row coloring he had made. Now Caspar has done a little magic and added (cookie) memory to the script – so it remember you most recent sort from visit to visit. The code is in my pre-alpha markup area.

Protocol relative linking

An odd discovery today – if you don’t specify a protocol in your links, the browser apparently suppose it’s the same (be that http or https) as the current page. You can se it in action on Slashdot by viewing their source – none of the regular links has protocol specification – they just start with two slashes and the hostname (ie. //

In the case of Slashdot I suppose they don’t use it to save bandwidth, but in most cases it’s probably useless.

(Discovered by mkyed).