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.
Java Rant #1
Feb 17th
Once apon a time, I to some extent spent time learning Java. It was not a lot of Java, and it wasn’t extremely indepth. It was more of a “get to know the language”; doing some simple database hits, very basic console and windows app. This was all back in 2000-2001 so much has changed since then. I have since learnt and worked with c#, Python, Ruby and have for the most part been happy with what these languages bring to the table.
In recent days I have been contemplating over working on a few personal projects, some being “desktop apps” and others being web apps. Normally I would have written any desktop apps with C#, but with my recent migration away from just windows I feel it might be a good time to give Java another chance.
It seems a lot of the things I really wasn’t a fan of are still there today, things that other languages have been able to overcome several years ago and Java still can’t seem to handle.
Properties
Why is it that a language as “young” as C# not only has been able to handle properties in a nice way but they have also been able to change it a second time allowing for “automatic” generation of “basic” properties…
Simple “Person” Class in C#
public class Person {
public string Name { get; set; }
public string Email { get; set; }
}
Similar class in Java.
public class Person {
protected String name;
protected String email;
public String getName() {
return name;
}
public String getEmail() {
return email;
}
public void setName(String value) {
name = value;
}
public void setEmail(String value) {
email = value;
}
}
I guess you could expose the values in Java as protected to be public and change them directly, But if you need to make a change down the road where you need to add some sort of validation or something to these values, your left to putting it outside of the class that is responsible for the properties.
I am not turning away from Java, but I would think after so many years and so many implementations in other languages that something would have been implemented. Unless there is some hidden command I have not been able to find online or in documenation.
