Looseideas.co.uk - Ryan Mitchell

Making session storage play nicely with server side sessions

2011-10-22T14:30:54+01:00

Session and local storage have made the storage of data on a clients machine respectable, gone are the big cookies and window.name, partnered with the ability to define manifest files developers can now exert control over how resources and data are cached to a level that makes Apache and IIS look embarrassing.

However, with every new feature, some things get easier and some things get harder.

Session storage is held only in a particular tab or window, allocated to the domain and lasting as long as that window persists. Opening the same domain in another tab will create a new session. Local storage is also allocated to a domain but persists between sessions, tabs and windows.

Web storage does not cater for different users, domains and windows are all it knows.

There are additional complications if users on your site are able to login, if your web storage includes data individual to the user you need to take care to clear and refresh data whenever the state changes

How to maintain state between web storage and server sessions

It might be a bit old-school, but Cookies are still the way that most back-end systems track user sessions. The simplest thing to do is to store the value of the session cookie in your web storage and to compare those values when the page loads and if the values differ clear the session of user specific data.


	sLocalKey = 'StoredIdentity',
	sCookieKey = 'CookieKey',
	storedIdent = window.localStorage.getItem(sLocalKey);
	sCookieValue = readCookie(CookieKey);

	if (sCookieValue === storedIdent) {
		return true; //same cookie value
	}
	else {
		return sCookieValue; //different value, new session
	}

Another case to watch for is a login/logout events, it's unlikely the cookie value will change (the session existed before login) but either you can watch for a query-string value or particular pages like login/logout success.

"The Web Behind the Medium" - An article for the Idea Engineers Blog

2011-09-18T10:53:09+01:00

Over the past few months I've been amazed at how simple it can be to reuse the same code and structures on quite different devices. When I was asked to write an article for Sapient's Idea Engineer blog I straight away knew that was what I wanted to talk about.

The purpose of the article is to highlight the idea that using the technology of the web (APIs, JavaScript, CSS) can save us time and effort when developing for multiple, disparate platforms.

Read The Web Behind the Medium (Idea Engineers)

Hashbangs, useful, but probably not what you want

2011-07-18T10:12:42+01:00

In the modern web AJAX is the workhorse behind the interactions. CSS3 might add the shine but AJAX is still doing the work. The strength of AJAX is that it's a background request, the UI will ignore them completely, which is fantastic unless you've just ripped out the hole page content and replaced it with another one.

To enable the user to track that changed state you need to change the URL, and this is where hashbangs come in. Hashbangs are a work-around. But Hashbangs are an old workaround for an old problem.

Where previously we only has window.location available to us we now have the history API, window.history.

Use pushState to add states and watch for the popstate event to revert to previous states.

One final caveat, if you are updating only a region of your page then a hashbang may still be valid for you. The hashbang URL must convert into a querystring URL for search engines to parse the content. They expect only the changed content to be returned when they visit that converted URL.

Resources

Open up to better project tools

2011-07-10T13:45:33+01:00

Project tools are there to support the project. If those tools are sub-standard then it's likely they will cost your team time and raise their irritation levels. An annoyed developer is a dangerous thing, we're fully capable of complaining about minor things for hours so imagine what seriously crap bit of software can do.

When working as a team, solid, clear and simple communication is paramount. Whether it be about initial requirements, planning, defects or delivery, the task should be the focus and the tool is just the medium. Customization comes later, the Project Manager has different priorities than a Developer, they can tailor their own views and then everyone gets to see what they need and get past the noise.

Info in, detail out

Email is not a good project communication tool, email is a very bad project communication tool. In email all messages are equal; your email with client changes is probably sandwiched between an email about IE6 and an invitation to drinks. When i try to find it again the only word that describes that process is trawling.

CC your email to your project tool and it'll be tracked there, anyone with access can find it, and I'm less likely to delete it when Entourage tells me I've no space

Track tasks and defects in the tool, create sub-tasks, allocate them to developers and have them update the status as it changes. If we did this then status meetings get shorter and our productive working days get longer, and your status report becomes a link to the tool. Even with the burn-down filled in if that's your thing.

Use SVN or Git, because not doing is irresponsible, dropbox is not a replacement for SVN, it's a lazy insecure shared space. Think of those shared drives we used to all have. The only "improvement" that dropbox has over them is your sysadmin doesn't have to be involved and it's got an icon in the taskbar.

Most of all, just because you have tool you've used for ages, investigate alternatives. Basecamp is good, Assembla is better, because it's got an SVN. Both can be bought and stored locally, useful when your systems people complain about where the data is held. Don't settle for crap tools.

Looseideas in 2011

2011-06-20T11:21:51+01:00

I've made a few changes to this site recently, the blog is now upfront and the old "content" has gone. Previously I maintained this site to pad out my portfolio, but since working at Sapient I've ignored and patched it until the code is mush

From now on it's going to have a change of emphasis. I'm going to write bits and pieces, rambling through a topic with a couple of decent links. I don't expect anyone to read it but it's better out of my head than bubbling away in there.

Love and hugs,
Ryan