Archive for May, 2010
Website Image Caching
May 9th
In a previous post titled Django Json Woes I mentioned setting response headers for caching for Json responses. This was done to make sure that data that was sent was always refreshed and the browser didn’t use cached content. Most times this is accomplished with a technique called “cachebuster”, which means adding a pseudo random string to your request. This is done because your web browser, performs caching on your content based on urls including any parameters that are passed. By adding a random string onto the URL, your tricking your browser into thinking its a totally different URL and the browser will bypass the cache and download it.
I personally am not a huge fan of using the “cachebuster” because deciding if something should be cached or not should be decided on by the site and less by the connection to the site for 90% of requests.
This kind of cache bypassing can be useful when trying to get a bit more performance from a image heavy website. By hosting your images with a cache set to essentially never expire, and having your website pass “cachebuster” type information at the end.
<img src="/images/background.jpg?1273456709" >
The data at the end of the image url could be anything that indicates that the image has changed. When a request comes in the first time the browser would download the image based on the given url, each time afterwards it would continue to use the cache image. When you modify or change the image the data on the url would change and any hit from cached browsers would see the change and download the new copy of the image.
I am currently working on a template command for django that can do this easily, once its completed ill update this post.
Html5 LocalStorage, Client Side Memcached.
May 5th
Although HTML5 isn’t 100% finalized, there are a few things that have been finished up and implemented in the newer browsers. One such feature is a local storage, it doesn’t provide any fancy functions it’s more of a client side Memcached. It’s a persistent storage area that’s accessed using a key, value pair, attached to the window object.
window.localStorage['key'] = 'value'
Setting the value of the key is just a matter of assigning a variable. Obtaining an already saved value is also just as easy.
var value = window.localStorage['key']
Here is a small sample using a few basic functions to show how it might be used. You are able to enter text in the box and save it. when the page reloads that new value will display in the browser. When you click on load it will load whatever value is saved in the current storage.
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html>
<head>
<title>Html LocalStorage</title>
<script type="text/javascript" charset="utf-8">
function save() {
obj = document.getElementById('btn_text');
if(obj.value)
window.localStorage['text'] = obj.value
}
function load() {
obj = document.getElementById('btn_text');
value = window.localStorage['text'];
if(value)
obj.value = window.localStorage['text'];
}
</script>
</head>
<body onload="load();">
<input type="text" value="" id="btn_text">
<input type="button" onclick="save();" value="Save"> | <input type="button" onclick="load();" value="Load">
</body>
</html>
Keep in mind that because of browsers are only starting to roll out these implementations now, it might not work in all browsers. Also be sure to use the most recent versions.
I’ll be writing and posting more HTML5 posts, giving examples and code on implementing some of the new exiciting things that will be out soon.
Apple vs Adobe Flash, Rant.
May 5th
You can not go on any tech related site without seeing some comment, post, or article related to The iPhone and/or Adobe. There is a line drawn in the sand, you have iPhone supporters on one side and Adobe Flash supporters on the other.
Here is a little back story. Everything was to some extent fine, well as fine as everything can be. Until April 8, 2010, Apple announced the new iPhone OS 4, they showed off some of the stuff people have been waiting for. Shortly after the announcement there leaked out a slight change on the new Terms Of Service indicating that Apple didn’t want applications not written in C/C++/Obj-C or “Open Standards” Html5, Javascript, and CSS on their platform:
Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs. Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited).
This was just days before Adobe was to launch their new Creative Studio, containing a system that allowed users to write applications using Flash and export them to the iPhone. This was also after a large helping of applications had already been approved and sold on the iTunes App Store that were in violation of this very change, it’s unknown what the future for these applications is.
Now, was this a under-handed tactic, for Apple to pull off? A calculated move to screw over Adobe and everyone else that wouldn’t fall into the allow list? All very good questions, and questions that everyone will have there own opinions on.
Many speculate that this change was done in hopes of maintaining a powerful eco system of applications. There are a few reasons that can be used to argue this:
1) Applications written for multiple platforms always need to be written for the lowest common denominator, otherwise they are not really multiple platform applications. In this case Apple’s argument is that they want applications written to utilize all the capabilities of the iPhone, not just whatever the lowest machine the developers decided to support. This directly affects the customer in a positive way.
2) Applications written using a 3rd party library takes control of the eco system away from Apple and gives it to the 3rd party libraries. If Apple decides to release changes to the Operating System, they now have to rely on the 3rd party library makers to add the functionality on there side before those developers can use it.
3) Applications written in one language and simply translated to another language (C, C++, Obj-C), historically end up with a slower, performing application then the original. Works very similarly on the same basis that how you code something in Java isn’t the same as how you would code it in Python.
All these points can be argued back and fourth, for and against. But in the end it comes down to the customers. After all the dust settles, and either Apple changes there terms or they keep them and enforce it. Companies will still be writing iPhone applications, along with those Flash apps. Flash developers won’t be loosing there jobs, and C/C++/Obj-C developers will have more work. What will be different is iPhones will have native, fast running applications. While other phone customers will get the occasional Flash apps that might or might not be as good as a native app.
P.S: I understand that just cause the application is written in C/C++/Obj-C, does not mean they are guaranteed to run fast. But a properly written one will run faster 9 times out of 10 against a properly written flash app. 
Password Rules!
May 2nd
Most websites in some way or another, utilize a user authentication system. Sites that decide not to implement existing systems such as OpenId should be written to follow a few important Rules.
Very often people use the same username and/or password across all the sites they use. Although not a good practice and highly frowned on, it should be taken into consideration while rolling your own authentication system. Here are a few basic rules I try and follow:
- Passwords should contain more then 5 characters.
- Passwords should have no real limit in max size.
- Passwords should be case sensitive.
- Passwords should contain both alpha and numeric values.
- Passwords stored in the database should not be reversible.
- Passwords should be Salted and hashed, I usually add to both begin and end of original.
- Password resets should not be sent via email, due to being insecure
There are many other Rules that can be implied. These are mostly what I follow with outside of any specific business rules. By not storing the original password in the database, it will require that you add some sort of system for resetting forgotten passwords, using a combination of user email and/or confirmation questions. Also during login it would require taking the password the user enter to be salted the same way and compared against in the database.
In basically comes down to, if you are capable of retrieving users password as they typed it, its more then likely that you may have a potential security risk. Simply encrypting the username can be cracked easily if a hacker is already on your system, using a salted hash is much more secure.
