The second incarnation of the Web Directions Code conference was this year on 2.-3. May, and I was fortunate enough to both attend and speak. The conference held in Melbourne Town Hall was the place to geek out about all things web: JavaScript, HTML5, and CSS3. More than 250 web professional turned up to learn about new directions the web is taking. In this blog I will summarise those talks that left the biggest impression on me.
OpenCms websites tend to place a lot of responsibility for the controller and view functionality of a page on the JSP, a JEE anti-pattern known as a Monolithic/Compound JSP. We recently integrated SpringMVC into an OpenCMS website at one of our clients to gain the advantages of a Model-View-Controller framework without an extensive rewrite of the codebase.
We recently shifted from Backbone Boilerplate to the Rails Asset Pipeline for generating the various assets (Javascript, CSS, HTML, images, etc) that comprise teamstuff.com, a single-page app. In this post I’ll talk about our motivations for making the shift, what we had to change to get there, and how the end result turned out.
A leading online learning provider recently engaged us to add social features to their website so that students could more easily collaborate, and thus be more successful with their study. One of the main social features required was providing students with the ability to form ‘buddy’ relationships, and then to initiate persistent chat sessions between each other. In this blog post, I will describe how we used the Atmosphere Asynchronous WebSocket/Comet framework and the Hazelcast In-Memory Data Grid to build this chat implementation.
I work in a team that is constantly faced with the challenge of getting features approved for release into production. This is largely because the business is very fast moving, and business priorities change often. As priorities change, the focus of the business shifts from feature to feature, so resources for testing and approving features can be scarce. Consequently, our trunk codeline contains approved and unapproved features. This becomes a problem during our releases, because unapproved features have to be removed from trunk, which as most developers would know, is a painful process that results in dozens of conflicts.
In this blog I will present a solution to minimise the problems surrounding unapproved features in the codeline at the time of a release. This solution involves having a separate branch that only contains features that have been completed and approved by the business. I will also contrast this approach with popular alternatives like Feature Branching and Feature Toggling.
In my previous post I presented the basics of sharing sessions in a cluster by storing session data in a client-side cookie. In part 2, I’ll talk about the security aspects of this client-side cookie store, i.e. how to protect it from security threats.
To prevent attacks specific to client-side sessions, I’ll add encryption, signing, and session timeout to the code. In addition, I’ll talk about solutions to protect against security threats common to any web application, such as Session Hijacking, Session Replay, and Cross-Site Scripting. The result will be an implementation of the Session-In-Cookie pattern that allows simple and secure session-sharing in a cluster.
One problem with single-page apps is that application state can stick around for longer than it would in a more traditional request-response web app. Because your users aren’t refreshing the page very often, you can have JavaScript objects sitting around in the browser for hours, or even days and weeks.
At Shine, we’ve been working on a large Backbone.js application recently and found that identity issues relating to long-lived objects caused a number of subtle and not-so-subtle bugs. For us the solution was to introduce an identity map.
In this blog entry I’ll talk about what an identity map is, why you’d want to consider using one, and will introduce you to an implementation that we’ve put on Github.
