Wordfeud for Windows Phone ble lansert 01. Februar, samtidig som Nokia lanserte sin Lumia 800. Spillet ble umiddelbart en av de mest nedlastede appene på Marketplace, og er fortsatt på topp 5 listen i blant annet Norge, Sverige, Danmark, Nederland. Spillet har fått en rangering på 4.5 av 5 i snitt, basert på over 1250 anmeldelser fra sluttbrukere.

Etter suksessen med Wordfeud for Windows Phone 7, bestemte Bertheussen IT og Microsoft seg for å bruke Wordfeud som en av lanseringsappene på Windows 8. I april begynte vi jobben med å tilpasse Wordfeud for Windows 8 plattformen, og spillet ble gjort tilgjengelig på Windows Marketplace samtidig som Microsoft lanserte Windows 8 Release Preview i begynnelsen av Juni. Dette er den første Norske applikasjonen utviklet for Windows 8 sitt nye Metro grensesnitt.

I løpet av utviklingen av Wordfeud for WP7 og Windows 8 høstet vi mange erfaringer rundt hvordan designe for Metro, hvordan oppnå størst grad av kodegjenbruk på tvers av WP7 og Windows 8, samt erfaringer rundt test- og release-planlegging for Windows Marketplace. Disse erfaringene delte vi på årets NDC, i form av foredraget ”Bringing Wordfeud to WP7 and Windows 8”. Foredraget er nå tilgjengelig som video – og du kan se det i sin helhet nedenfor.

Jonas Follesø – Bringing Wordfeud to WP7 and Windows 8 from NDCOslo on Vimeo.

Bringing Wordfeud to WP7 and Windows 8

This winter a development team from BEKK has worked closely with Bertheussen IT, Microsoft and Nokia to bring the massively popular game Wordfeud to WP7 and Windows 8. In this sessions Jonas will share lessons learned while porting the game, and showcase how the game takes advantage of the various unique features of each platform.

The sessions will cover a range of topics such as; how to port an iOS designed application to the Metro design language, why taking advantage of Live Tiles is important, how to use operating system features such as Charms, Lock Screen Apps, Launchers & Choosers and more.

The session will also cover the more technical aspects of architecting an application for maximum code reuse across Windows Phone 7 and Windows 8. Jonas will demonstrate 4 different techniques for enabling reuse of code.

This is the risk rating from OWASP:

The problem

When a server receives a POST request, there is no secure HTTP or browser specific way in which the server can know how the request was created. Consider a form posting data a given URI of the server. The different fields in that form and their corresponding values are normally formatted in the application/x-www-form-urlencoded and multipart/form-data.

Additionally the browser will include a set of headers. The Cookie header includes any cookies for the given url. The Referer header contains the url of the page the request originated from. The Origin header contains the domain name, port and schema of the request the request originated from, but has no path information.

Consider a website A that has no CSRF-protection. A user logged in to site A, is tricked by the attacker into visiting his site B. Javascript on site B automatically builds and submits a form to site A in a hidden iframe. Now because the user is already logged in on site A and the request is headed for site A, the browser will happily include the users cookies for site A. This includes the session cookie. So the server on site A, will see an incoming request with a valid session. And because it trusts the session it will happily accept the request and perform the required action.

For a relatively new list of high value targets having this vulnerability, see Egor Homakov’s blog post: “A few CSRF-like vulnerable examples”.

Attempted solutions

There are many ways developers have tried to mitigate this vulnerability.

GET vs. POST

The first kinds of CSRF attacks often used GET requests. The attacker would typically add an img tag pointing to a url that performed some action. An example could be:

<img src="http://victimserver.com/add_friend?userid=123" style="visibility: hidden" >

While using GET requests for state changing operations is considered bad practice, as explained above, POST requests are just as vulnerable to CSRF.

The Referer header

When looking at the headers above, the first thing that might strike you, is to use the Referer header. But this is probably not the best choice. This header contains path information and is often blocked/removed in firewalls, browser plugins etc. for privacy reasons. Most browsers also strip it when moving between schemas, so a post from https to http would probably result in the header being stripped out.

The Origin header

While the Origin header does not have the same privacy issues as the Referer header, it lacks support in older browsers. It may be a suitable defense in the future, it may not be the best choice for now.

Working solutions

Here are two of the most popular approaches.

The token approach

The token approach has quickly become a popular way of mitigating CSRF. Ruby on Rails and ASP.NET MVC both use this approach (authentication_token / anti_forgery_token). The server generates a cryptographically random value – a token or nonce – and sticks that token in the user’s session. The token is also included as a hidden field in any form generated by the server. When a POST request comes back to the server, the server can check that the token included in the request, is the same as the token in the user’s session. Because the attacker cannot possibly guess this token, any POST request originating from the attacker’s server, would have the wrong token.

The double-submitted cookie

This approach is somewhat similar to the token approach in the sense that it’s using a cryptographically random value. But instead of sticking this value in the user’s session, the token is set as a cookie. Javascript in the browser will read out the token from the cookie and add it as a hidden field in the form. Upon receiving a request, the server can now check if the value in the incoming cookie is the same as the value included in the POST body as a form field.

This relies on the Same Origin Policy blocking the a web page on the attacker’s server from accessing the token cookie, and thus from including the correct value as a hidden field in the form.

What about Javascript based single page web apps

Javascript based applications typically make use of XHR requests for submitting POST requests. In addition many applications built on frameworks like backbone.js, will read and submit pure JSON-objects instead of using the application/x-www-form-urlencoded and multipart/form-data encodings.

If we decide to use the token based approach, we typically make a request to the server in order to get a JSON containing the token. In later POST request, we simply include it as a header. This can easily be achieved when using jQuery:

$("body").bind("ajaxSend", function(elm, xhr, s){
	if (s.type == "POST") {
		xhr.setRequestHeader('X-CSRF-Token', csrf_token);
	}
});

If you are using REST services supporting PUT and DELETE, you can easily modify the above code to also send the token for those methods.

If you are on node, there is a server side library for csrf protection in Connect.

CS#RF – Cross Site Hash Request Forgery

Consider an application where we have applied the token and jQuery based mitigation above and it works as intended. Our app includes the tokens on POST requests. Also consider that the application is using hash based navigation. Let’s use the Conference application as an example with regards to routing. This application the following routes:

• #/talk/1 – show the given talk
• #/talk/1/edit – open the given talk in edit mode
• #/talk/1/delete – delete the given talk

The first link will show the talks title, description etc. as HTML. Nothing special there.

The second one will open the talk in edit mode, allowing the user to update the title or description. Upon saving the changes, the Javascript will extract the values from the form, stick them inside a JSON object, and submit it back to the server while automatically including our CSRF token. So the protection works as expected.

But the last route can be problematic. If it simply opens a confirmation page and then posts the request to the server when the user confirms the deletion, then we’re all right. But if triggering that route is enough for the request to be submitted, we’re in trouble. An attacking site can simply open a hidden iframe pointing to that route, and trick an innocent victim into visiting the page. Our javascript will happily submit the request including the CSRF token, just like we programmed it to. In that respect action triggering routes (routes that actuallly cause server side state changes) are similar to the problem with GET request as described under “GET vs. POST”.

Mitigation summarized

All of these need to be implemented

• Reject GET requests on state changing operations
• Include cryptographically random token in each state changing request (POST, DELETE, PUT)
• Don’t let routes directly change data

But first, this is the risk rating from OWASP:

The anatomy of a typical single page app

A single page web application – and especially those built using backbone.js – tend to have be composed of a single base HTML page (this single page), a set of javascript models, routers and views, a set of templates for the views and a set of server side services providing data. The service side services will typically be REST based and deliver JSON.

If both the client side and server side is implemented using JavaScript, we can imagine having the same data representation on both the server side and client side. It will be the same data object, serialized as JSON when being transferred between browser and server. On the client side, a framework like backbone.js will wrap the data object inside a model augmenting it with functionality. The same thing may or may not be done on the server side.

If the server side is also using a document oriented NoSQL-database, we can even imagine having the same data model stored in the data store. No need for grumpy old ORM-frameworks to transfer data back and forth from one model to the other.

While having the same model in every part of the application has obvious positive sides like simplification and consistency, it also introduces problems, especially if we don’t take care how we implement our server side services.

Consider an application for Call for Papers for a conference. The application accepts suggestions from registered users, and organizers (admins) can approve talks. In fact I created such a system for demonstrating the kind of problem I’m about to explain and you can find it on Github. A typical talk suggestion could look something like this:

{
	"id"		: 1,
	"title"		: "funnybone.vbs",
	"description"	: "A backbone.js implementation in vbscript"
}

Classical Insecure Direct Object References

The classic problem occurs because the server side fails to check the users access to the object he/she is editing. So in the Call for Papers app, what happens if on speaker tries to alter another speakers talk? While this may not be possible to due to access control checks in the client side javascript, there is nothing stopping a determined attacker from simply changing the code from the javascript console in order to have his/her way. So while having these controls in place is a good thing from a usability perspective, we also need to implement access control on the server side. These kinds of attack have earlier been performed on photo sites (I think there was even one in Facebook) and even online backing applications where one user could access other user’s accounts. The most famous of the recent ones, is probably Patrick Webster’s disclosure to First State Super Annuation where he demonstrated a problem in their website allowing him to download other peoples’ documents.

Mass assignment/overposting

We forgot about something in the model above. If admins should be allowed to approve talks, we probably need some fields for that too. So lets go ahead and add that:

{
	"id"		: 1,
	"title"		: "funnybone.vbs",
	"description"	: "A backbone.js implementation in vbscript",
	"approved"	: false
}

While having this field on the client side is good as it allows us to display which talks have been approved and not, it also creates a potential security issue. If a speaker is able to update a talk, what will stop that speaker from also updating the approved field. A malicious speaker could do this even if this fields has no corresponding UI element. He could simply add that element in firebug, or modify the JSON using an interception proxy (like OWASP Zap) on its way back to the client. The attacker could even add fields that are not present in the JSON, but which the attacker assumes are available in the database. He could try to add a role field when creating or updating his user account. Or modifying timestamps like Egor Homakov demonstrated on Github(see image on the right). This is often referred to as mass assignment or overposting, and is not only a problem in javascript based application. It’s a weakness in how data is mapped to objects on the server side.

It’s obvious that in order to stop the above mentioned speaker from approving his own talk, we can not use client side code. This needs to be fixed on the server side. The server needs to know which fields it should support updates for given the current user role.

Schema injection

There is another problem that can also occur if the server side does not filter the incoming JSON. If the JSON is simply converted to a client side object containing exact same fields, and then those fields are dumped into a document database or key value store, what happens if the attacker add 1000 new fields? Or 1 million new fields? Now we suddenly have a simple object for a talk, taking several MBs or even GBs of disk space/memory. As the name implies this problem might as well have been mentioned under A1 – Injection, but seemed a better fit here.

Mitigation

• Perform server side access control
• Perform server side filtering of received data and rejected unwanted parts

This is the risk rating from OWASP:

Session fixation

Session fixation is an attack where the attacker is able to somehow preset the session id of antoher user. When that user logs in the attacker already has the valid session id and can use that to log in. Typically this is happening in applications that make the session ID a part of the URL:
http://examples.com/;JSESSIONID=12312312312312321
This is a bad pattern. SessionIDs should never be a part of URLs. Furthermore it’s important to always change the session ID when the authentication/autorization level is changing – typically during login/logout.

For javascript based web apps this typically means checking to see how the server based session components handle sessions. So typically you will want to check that whatever session framework and authentication framework you use, they should replace the sessions upon login and should not accept session IDs in URLs.

Session stealing

If the attacker steals the session of another user, the attacker can now access whatever the user has access to, because from the server side the two is the same. There are typically two ways of stealing sessions:

• Sniffing and open wireless network
• Cross Site Scripting

A few years back lots of websites like twitter and Facebook would only protect the login with https when the username and password was transferred. After the login, the connection would go back to http. This is a bad pattern. After login the session ID becomes a temporary replacement for your username and password, and thus we want to protect from anyone listening in. To achieve this we can make sure the browser never sends our session cookie over http, but setting the Secure flag on the cookie. This will instruct the browser never to send the cookie in http requests.

The next thing we need to do is to protect the application from Cross Site Scripting as explained in A2 – Cross Site Scripting. If an attacker can insert script into our page, the attacker could access document.cookie and steal the session cookie from there. A secondary protection mechanism we can use there, is to set the HttpOnly flag on the session cookie. This will instruct the browser not to make the session cookie available to javascript through docment.cookie. The browser will still send it in requests back to the server, but it will just not be available directly in JS.

Session guessing

It’s of key importance that the server side component generating session IDs is using a cryptographically secure random function to do so. If the attacker is able to predetermine what the next session id is, the attacker could simply try different session IDs, and would at some point find a valid authenticated session, because a user logged in and got that very same session ID. I recently tested Node.js Connect‘s session ID generation using Burp Suite‘s sequencer, and Connect seems to do a decent job (the rating from Burp Suite was: Excellent).

Session timeout

Sessions should always time out after a certain period of time. Some sites use a sliding expiration, where the user is logged out if the user with the active session has been inactive for some time. Other sites use an absolute expiration, where the login is valid for a maximum of say 30 minutes. For high value sites like online banking it’s probably a good idea to use both a sliding and absolute timeout. The rationale behind session timeout, is the fact that a session should be a temporary replacement for the username and password, not a permanent one. There are a couple of reasons why this is important.

If the user leaves his device or computer unattended for some time, a time out will make it harder for any attacker stealing the device to reuse the existing sessions. This can of course be partially mitigated by automatically locking the device or computer after a given period of inactivity, but this will not stop a determined attacker.

The second reason is if the session is somehow stolen, not having an absolute expiration, will allow the attacker to use that session as long as he wants – or at least until the user logs out (which many users rarely do).

Client side only sessions

Some frameworks promote client side only sessions. The way this works is that the user will log in on the server side, the server will issue a cookie which holds the session data, and send that back to the client. The benefit is of course that the javascript on the client side is now able to see and use the data in the cookie. It also frees up resources on the server, which no longer needs to maintain copies of all sessions. In a clustered backend, there is also no need to synchronize the session, as it’s now being sent on every request.

However in my opinion the drawbacks outweigh the positive aspects. First of all we need to make sure the client side code cannot change the session data, because the server now inherently has to trust this cookie in later decisions. This could easily lead to a broken authentication scenario, where the user logs in as user “joesmith” and then changes the username in session to be “admin”. What this means, is that the cookie needs to be signed by the server and only the server should be allowed to change it. And this can be a bit hard to get right. Naive approaches of using something like MD5(secret key + data) has been proven susceptible to length extensions attacks. Typically the developer should use something like HMAC. And we have to make sure to check the signature on the server side on each and every request to the server.

The next problem is the ability to have the session timeout. A naive approach of setting a timeout for the cookies is of course insufficient. This timeout can easily be increased by the attacker. So the timeout timestamp needs to live inside the signed session data, and be checked on the server side for each and every request.

As described under session stealing, we usually want to set the HttpOnly flag in order to protect are sessions from being stolen from javascript. This of course will not work if we also want to have benign access to that data from the client side code.

The biggest problem is however that there really is no way to log a user out. If the server side has no concept of which sessions exist, neither can it mark one as logged out. If the attacker is at some point able to steal a valid session, that session is valid in itself because of the signature, and thus the server will happily accept it until it expires. So a logout would typically mean deleting the cookie on the client side, and that’s of course not sufficient if anyone else has a copy.

The last problem with client side sessions in cookies is that there is a limit on the size of the session. If you put too much data there, the server will no longer be able to respond, because the header size limit is exceeded. From javascript that means every request will result in an error and there is nothing the server can do to help the client fix the problem.

Session logout

In addition to the logout problem mentioned in the previous section, there are other logout related problems as well. Simply deleting the session cookie on the server side is not sufficient. The session should always be terminated on the server side.

Also HTML5 allows us to store more data on the client side in the Web Storage. This can greatly improve performance, but can also lead to some problems. First of all, if I’m logged in and my private data is stored in Web Storage, what happens to that data when I log out. Will the next user on the same device or computer see my data? Typically the application will use either localStorage or sessionStorage or both. In my opinion localStorage should be used for generic data like compiled JS templates or other things you may want to cache, while sessionStorage could be use for private information. However we will still need to clear out the sessionStorage during logout (and session timeout if possible). The reason is that the sessionStorage is not tied to the authenticated session in any way. SessionStorage simply means it’s deleted when the browser is shutdown or restarted, which a lot of users never do unless they have to (due to a reboot or browser upgrade).

Mitigations

• Avoid client-side only sessions unless you absolutely have to
• Use session timeouts
• Protect your sessions from tampering and leaks
• Clean up session and affiliated data server side and client side on log out
• Use a cryptographically secure random generator for session IDs
• Don’t put and/or accept session IDs in URLs

A lot have been said and written about the technical aspects of continuous delivery—why it reduces overhead for development by automating everything that can be automated. This blog post, however, will focus on three core business aspects of delivering continuously.

Smaller deltas of change means lower risk

We call the amount of changes between two deploys the delta of change. Reducing this delta means that less can go wrong when a new version is deployed. Why? Both from a technical and business perspective it is far easier to pinpoint the problem when there are less changes in the product. By delivering fewer changes at a time we can be more certain that we are actually delivering the right thing.

When releasing fewer changes it is also easier for business to understand the impact of each additional change. This enable us to learn more about customers and not waste money building features that don't add value.

Also, fewer changes means that we can deploy more often. And deploying more often means shorter feedback loops. And shorter feedback loops means we will learn more about customers.

Shorter feedback loops

There is a feedback loop between the team developing the product and the customers using it: The development and delivery of the product, the customers usage of it, the interpretation of this usage, and the final decision regarding possible changes to the product and the strategy. Delivering continuously shortens the feedback loop, which enables us to learn more—and more rapidly—about our customers and making the correct decisions faster.

The developers of a product often have several layers between them and the customer. Smaller code changes delivered often means shorter feedback loops, which will increase the developers understanding of what the customer wants. This improvement can lead to improved decisions and technical innovations that are more aligned with what the user needs. The more you know your customers, the easier it is to build the right thing.

Increased responsiveness

By continuously delivering small changes rapidly you can be more responsive with regards to customers, the market, and your competitors. Increased responsiveness means that you are able to adapt faster to customer needs and market changes. For example, the faster you are able to deliver on a customer request the happier and more satisfied the customer will be.

Why keep a feature that is already developed and ready for production just lay around waiting to be deployed in a year? Or for that matter, in a month or a week? A feature only adds value after being delivered to the customers, if not it's only inventory waste.

For years now we have built systems and web pages from the bottom up, never asking what is important for the people that use these applications. The solution involved a reliable and functional system, but pleasure and enjoyment was never apart of this equation.

The world has changed and we are trying to reform the prior world of systematic digital solutions. Emotional and well-designed solutions are the success factors in order to gain a leading market share in your industry or to just be the best at what you do.

Take banking for example

In the past, banks used a huge chunk of money to hire the right people and open ¨shops¨ in several places. They provided personal service to there clients with physical contact and warm faces. So what happened to the online bank?

What happened to creating an online welcoming place where people enjoy there banking experience and receive personal attention?

The traditional way of designing an online bank was to make the services accessible online without thinking about the user experience. This translated into getting the system up as fast as possible. It should be secure and functional. There was zero interest in making this system enjoyable.

Times have changed

There are many factors involved when people choose their bank. Good rates, low costs and local offices have been some of the major influential factors. However the visual identity and online/mobile experience is a growing factor that people care about. When customers see that there product or service cares about them, they react. They show loyalty. Apple and Starbucks are great examples that have created a visual and emotional connection to there clients where every detail counts.

So how do we get there

A good design and technical team is essential. We are not talking about one Interaction Designer that makes some wireframes and then passes it on to the programmers.

We are talking about a team that builds off each other and works closely with the client and organization. This team consists of at least one Interaction Designer, a Graphic Designer, one or several Programmers and a Copywriter.

The innovation happens when this team works closely together with the client and are given the freedom to transform an existing product into what it should be.  The interaction designer works with the emotional and user experience aspects. The graphic designer makes the product visually appealing. The programmers work closey with the designers and discuss alternative solutions to the problem. The copywriter creates meaningful and personal communication that shapes the user experience.

The wildfire effect

This is a phenomenon that happens when the client sees change. They suddenly see how their products can be and become proud owners of innovation and design. Pride and happiness spreads like wildfire in an organization. They start to understand the importance of good design and creating digital emotional experiences for their customers.

Online services become the new form for advertising. If your product or service is that good, then word of mouth is your number one source for gaining new customers. The amount of money that was invested in your product has now created a return on investment and the amount of money needed in advertising is reduced.

Good things happen when we are able to turn a systematic rigid application into a welcoming and delightful user experience. It all starts when we switch our focus to the people using the product and create a
top-down strategy where design and communication are equally important as technical functionality.

This is the risk rating from OWASP:

Traditional XSS

We traditionally talk about two types of XSS – reflected and stored. In reflected XSS, the attack is a part of the URL like this one:
http://www.insecurelabs.org/Search.aspx?query="><script>alert(1)</script>
You can test that one here. In reflected XSS, the attacker has to trick the user into opening the URL somehow – typically by employing iframes, phishing or shortened URLs.

In stored, or persistent, XSS, the attacker is able to store the attack string in the database. Since the attack is not dependent on the exact URL being visited anymore, the attacker can simply wait for a victim to visit the otherwise legit page. An example could be the commenting section here: http://www.insecurelabs.org/Talk/Details/5.

Twists on traditional XSS

Single page webapps are usually loading a static HTML-layout, which is the exact same file for all users, and then data and private information is loaded using JSON services. If there is HTML-tags inside our JSON-data we would normally expect the browsers not to render this content, but rather treat application/json as, well, JSON. However this is not always the case. Some browser, and especially IE, tends to try to second guess the content-type given by the server. This is called content-sniffing, and is in place because at some point in time servers tended not to send the correct content-type, and thus browsers could help the developers and end user by checking “what the content really was”.

I built a small test bed for showing how this works. You will see a green check if the browser treats the content as HTML (and thus allows scripting). It is expected that this happens if we return the JSON with Content-Type text/html, but not with any of the others. Well maybe an empty Content-Type could be excused, but if the browser says application/json, the browser should definitely not treat the contents as HTML.

DOM-based XSS

It’s expected that DOM-based XSS will be more commons in apps reying heavily on JavaScript, than what has been seen in traditional apps. DOM-based XSS occurs because user input is unsafely handled in javascript running on the page. We will address a few examples on this type of XSS. Some of these attacks never reach the server side, and thus cannot be detected by server side code.

Insecure writes

Insecure writes happens when user input is written to the DOM without first being sanitized. Data can come in through user input in the browser, or it can be loaded through JSON from the server (which would mean it was a stored DOM-based XSS attack). Insecure writes means we are either outputting the data directly in the DOM using .innerHTML or through unsafe jQuery functions like:

• $.after()
• $.append()
• $.appendTo()
• $.before()
• $.html()
• $.insertAfter()
• $.insertBefore()
• $.prepend()
• $.prependTo()
• $.replaceAll()
• $.replaceWith()
• $.unwrap()
• $.wrap()
• $.wrapAll()
• $.wrapInner()
• $.prepend()

Insecure code execution

As mentioned in A1 – Injection the use of insecure functions in JavaScript can cause insecure code execution. More specifically this means using functions that build JavaScript from strings:

• eval(string)
• new Function(string)
• setTimeout(string, time)
• setInterval(string, time)

In addition to these we find API specific functions like $.globalEval(string). As we can easily imagine dynamically building code containing user input is probably not a good idea, and is very likely to lead to problems down the road. JSHint, which is a common tool for quality checks on JavaScript, agrees: eval is evil.

Insecure use of APIs

Insecure use of jQuery can also lead to unexpected XSS. As mentioned in jQuery XSS something as simple as this can lead to XSS:
$(location.hash)
This can be exploited with:
http://example.com/some/page#<img src=insecure onerror=alert(1)>

The next one is a bit more subtle (courtesy of An overview of DOM XSS):

hash = location.hash.substring(1);
if (!$('a[name|="' + hash + '"]')[0]) {
    // not important
}

An input of "] <img src=insecure onerror=alert(1)> would actually work here.

While the examples above jQuery specific, it is very likely that there are similar problems in other frameworks.

Insecure use of document.location

Allowing user input to be directly assigned to document.location, can easily lead to XSS in the form of javascript: URLs. The following example is from twitter back in september 2010 (I highly recommend you read the full blog post here: Minded Security Blog: A Twitter DomXss, a wrong fix and something more):
(function(g){var a=location.href.split("#!")[1];if(a){g.location=g.HBR=a;}})(window);
The code above, extracts whatever comes after #! in the url, and asigns it to window.location. The intention was to allow a url of http://twitter.com/#!/webtonull to be redirected to http://twitter.com/webtonull. However consider the following url:
http://twitter.com/#!javascript:alert(1)

Persistent client side XSS

If the XSS vector is persisted in Web Storage, and later rendered in an insecure way, we call it a persistent client side XSS. As the name implies this attack will never reach the server, but still trigger every time the vulnerable page is loaded in the given browser.

XSS when using templates

Templating from frameworks like Mustache.js and underscore.js etc. allow javascript frameworks to clearly seperate view from data. They normally provide a set of tags for allowing coding and data output. The set from underscore.js looks like:

• <% %> – view logic (JavaScript code)
• <%= %> – data output (no escaping)
• <%- %> – data output (HTML escaping)

The HTML escaping escapes &, <, >, ", ' and /. I don’t intend to pick on underscore.js. This is one of the better escaping functions I’ve seen. But we need to remember to use the HTML escaping tag. And there are contexts where this will not work, simply because HTML escaping is not the correct escaping.

Quoteless HTML attributes
Template code:
<img title=<%- title %> ...>
Attack:
<img title=something onclick=alert(1) ...>

HTML comments – courtesy of http://html5sec.org/#133
Template code:
<!-- <%- title %> -->
Attack:
<!-- ` I'm now outside the comment in IE6-8 -->

Inside script tags, but you are not using those in a javascript app, right?
Template code:
<script>
var id = <%- id %>
</script>
Attack:
<script>
var id = 1;alert(/XSS/.source);
</script>

Inside javascript event handlers, but you are not using those in a javascript app, right?
Template code:
<img onmouseover="showToolTip('<%- title %>')" ...>
Attack:
<img onmouseover="showToolTip('&#039;);alert(&#039;XSS')" ...>

Insecure use of URLs
Template code:
<a href="<%- url %>" ...>
Attack:
<a href="javascript:alert(1)" ...>

The above list is not complete. There are a lot more weird contexts. See http://html5sec.org/ and the OWASP cheat sheets listed below.

Third-party javascript

When you are adding direct links to third-party javascript files, instead of putting the files locally on your server, you have to remember that you are now allowing XSS from the domain hosting that file. That’s regardless of whether you are loading a javascript library or “just” using JSONP to load data. Consider a script tag like this:
<script src="http://example.com/example.js"></script>
Now if example.com goes rougue or is hacked, example.js could start delivering malware to your users or silently stealing their credentials when they log in.

Another thing to consider any security vulnerabilities in downloaded libraries. When you are pulling in some third party script, you should also make sure you later stay up to date, and follow any announcements from the developers of that library.

Mitigation

• Default to secure methods – use $.text() instead of $.html()
• Default to escaping output – use <%- %> instead of <%= %>
• Check your templating framework’s escaping code – is it as thorough as underscore.js or does it escape fewer characters?
• Prefer frameworks with secure defaults
• Set the correct Content-Types and use proper JSON escaping
• Beware of XSS contexts – make sure you are not using the wrong/insufficient escaping for the contexts
• Avoid sticking user data in insecure functions like eval
• Beware when using user data with APIs like jQuery – test it
• Use automated tests with XSS attacks – test your code and templates using automated javascript tests and bad data
• Read and learn the OWASP XSS cheat sheets by heart
• Use jQuery encoder for complex contexts

Resources

• OWASP XSS Prevention Cheat Sheet
• OWASP Abridged XSS Prevention Cheat Sheet
• OWASP DOM-Based XSS Prevention Cheat Sheet
• An overview of DOM XSS
• jQuery XSS
• HTML5 Security Cheatsheet
• jQuery encoder

Missing anything?

Contact me on twitter or add a comment below, and I’ll be happy to add (with attribution).

This is the risk rating from OWASP:

Server side vulnerabilities

When you are accessing a database of some kind there is always the chance of SQL- or NoSQL-injection. To avoid these problems, we should of course avoid building queries by string concatenation. Look for parameterized alternatives. If you are using node.js with mysql, there you could use client.query() with parameters like:
client.query('SELECT id, user_name FROM user WHERE email=?', [email], ...)

In javascript based backends there is a far bigger problem than SQL. JSHint tells us that eval is evil, and I tend to agree. Unsafe use of eval – sticking unsanitized user data inside eval statements – can lead to full compromize of the server.

Bryan Sullivan of Adobe did a talk at Blackhat USA 2011 called Attacking NoSQL and Node.js: Server-Side JavaScript Injection (SSJS), and this type of injection is also mentioned in Node.JS Security – the good, bad and ugly.

Consider a node.js application where the developer makes insecure use of eval to parse incoming JSON:

var http = require('http');
http.createServer(function (request, response) {
    if (request.method === 'POST') {
	var data = '';
	request.addListener('data', function(chunk) { data += chunk; });
	request.addListener('end', function() {
	  var stockQuery = eval("(" + data + ")");
	  var price = getStockPrice(stockQuery.symbol);
	  ...
});

This leads to full remote code execution on the server. It’s actually worse than SQL-injection. The attacker could send in code to read out local files:

var fs = require('fs');
return fs.readFileSync('/etc/passwd');

If the attacker is not able to directly read the response, we can also imagine types of blind eval injection. The attacker can send in while(1); and easily overload the server’s CPU. Alternatively the at could upload files and run them using child_process.spawn, or send code that reads out the entire file system or the database (hello SQL-injection), and uploads it to a remote location.

To avoid this problem we should really just avoid sticking user data inside eval statements. At least void using string concatenation. For JSON parsing we sould really stick to JSON.parse(). If we really have to use eval for anything, we could use a syntax like:

with({username: user.username, email: user.email}) {
   result = eval("doSomething(username, email)");
}

Of course in the above example there is no reason to use eval, but you get the point. Access variables instead of using string concatenation.

Typical use of eval involves trying to set dynamic properties or invoke dynamic methods on objects. A typical eval statement thus looks something like:

eval("user." + propertyName + " = '" + propertyValue +"'"); //Set property with dynamic name
eval("user." + methodName + "()"); // Invoke method dynamically

It is really easy to avoid using eval in this example. We can just use array lookups instead.

user[propertyName] = propertyValue; //Set property with dynamic name
user[methodName](); // Invoke method dynamically

Client side vulnerabilities

On the client side, unsafe use of use input can also result in injection issues. We’ll leave out HTML injection and XSS for now, and cover that in the next post.

JSON injection can happen if JSON is built by string concatenation before being sent to the server:
'{value1:"' + value + '"}'
In this case value could escape the quotes and inject new key value pairs:
'{value1:"hello",value2:"world"}'

Similarly this can happen when building URLs in an unsafe manner:
url: "http://example.com/search/" + searchTerm
This could lead to URLs like:
url: "http://example.com/search/../something/evil"
Similarily we can have the same problem for URL parameters:
url: "http://example.com/search?q=" + searchTerm
which could lead to:
url: "http://example.com/search?q=notmuch&someother=parameter"
An example of a bug like this on AOL can be seen in the end of the DOMinator tutorial video from Minded Security.

Missing anything?

Contact me on twitter and I’ll be happy to add (with attribution).

1. Gerry McGovern – Top Task Management

@gerrymcgovern

Irish Gerry McGovern is absolutely clear about one thing: ”Cut content or you´ll kill the user experience”. His speech is convincing and spiced up with British Monty Python-like humour. He describes the web as an organism, which is just eating and eating, meaning adding more and more content, without pooing. Some of the things pushing this behaviour is the counting of content produced, of hits, time spent on a page and so on. This counting sometimes gives a false and damaging impression of a website’s performance. ”Traffic is how idiots track success”, he says.

His solution is Top Task Management.  All websites are made up of a series of customer tasks and many organizations spend too much time focusing on the tiny tasks, instead of the important ones; the top tasks. In his workshop we learn why the tiny tasks in the “Long Tail” get in the way of the top tasks of the “Long Neck”—and what to do about it. Download his presentation.

2. Joshua Porter – Microcopy

@ bokardo

In this speech Joshua Porter describes how to use microcopy to reduce interface friction, prevent cognitive blocks and to bring personality to the interface. Using these small, helpful and sometimes encouraging words is a quick way of improving the user experience. If we understand the users mental models, predict what they will ask for and add microcopy, we`ll manage to clear the path for the users.

Joshua gives a number of nice examples and I´ll give you some of them. Add the text ”No credit card needed” to the ”Free Trial”-button, just to make that absolutely clear. Add some humour to an email sign up with this line: ”We hate spam just as much as you” or tell people you`re serious about a survey by saying: ”We promise to read every word”. Adding microcopy is both simple and useful, so why not use it? Have a look at his presentation!

3. Nate Bolt  – Remote Research

@boltpeters

The history of user testing shows an academic focused and lab-based testing, which sometimes lead to wrong conclusions. Nowadays we have an array of methods and tools for remote research to choose from. We can observe users, through Skype, GotoMeeting or other screen sharing tools with so called moderated tests or we could easily automate and scale the test by sending out a survey to a large number of users, using automated tools like Usabilla or similar.

The big advantage with remote user testing is that we survey or observe the users in their actual enviroment, which is both timesaving and cost effective too. In this workshop we learn how to choose the appropriate tool, how to recruit participants and how to facilitate the test . But make sure you´re prepared when doing remote research, cause everything could go very wrong!

Check out Bolt´s webpage if you want to learn more about remote research.

The Remote Research Workshop

4. Debra Gelman – Designing for Children

@dgelman

Debra Gelman´s workshop includes concrete tips, her experiences, as well as the surrounding theory of designing for children. She also talks about how to employ the acquired knowledge, to be used in the development of concepts, with children as the target user group.

Based on psychological and sociological differences, she divides children in several age groups: 2-5, 6-9 and 10-12 years old. Each age group requires special consideration as they significantly differ from each other. In addition, Debra touches on the differences and similarities between designing for children and designing for adults. For example, she has found that while adults can categorize information based on several variables (like color, shape, size, etc.), children are only capable of identifying one variable. More so, that variable tends to be color, a phenomenon she referred to as “color serve”. Finally, she briefly describes how to perform research with kids, a problematic topic due to both legal and psychological aspects.

For more, view Mutte´s notes.

5. Jesse James Garrett – Design for Engagement

@the_uMe

Garrett´s talk is less practical and more philosophical. It´s inspiring and make us think about our practice, what we’re actually doing and who is really a designer. Beethoven was an experience designer through his music, he claimes.

He talks about the user experience of tomorrow. The history of user experience, which started years ago with products, then expanded to involve services, then environments and now it is all about creating cross-channel-experiences. The ultimate goal is to create human engagement, which can occur in the four areas of PACE (Perception, Action, Cognition and Emotion), he says. Design is not anymore about “mediumism”, but rather a cross-channel experience.

6. Peter Morville – The Architecture of understanding

@morville

The wellknown author of the book “Information Architecture for the www” talks about the importance of a cross-channel strategy too. He means that IX-people (more precise IA`s) are bridge builders and must be good at both understanding what people are asking for and at encouraging and helping the customers to understand the importance of a cross-channelstrategy.

Have a look at his inspiring talk.

7. Indi Young- Mental Models

@indiyoung

A mental model is “a mental representation” of how people think, feel, react, and interact with their environment. These models are useful in the development of services and products as they can remind your team of the users’ mentality.

In this workshop Indi Young reminds us of the importance of attempting to deduce the mental model of a user, as she rightly says “we are not the target audience”. For example, she recommends researchers to consider user interviews more as conversations. We should strive to encourage the interviewee to share stories, as “stories are just data with a soul”, and stories are easier for an interviewee to recall and retell, she says. The workshop gradually transforms from theory to practice. She performs a live demonstration on stage, interviewing a volunteer and tells us a lot of useful tips. For example, never ask an interviewee to imagine a future/potential mental state. This is because we do not want speculation and guesswork, but rather reasons for why they actually do what they do. This is a very educational workshop about an interesting topic, excellently presented by an expert.

For more, view Mutte´s notes.

Want some more? Check out the currently available speaker presentations from UXLx 2012.

Participants from BEKK: Lena Hjalmarsson, Kristin Edvardsen (student and winner of FFC), Oskar Lindh (student and winner of FFC), Mattias Olovsson, Moquan Chen and Samuel Ericson (photographer).

Google guava cache

Not long ago, we started using the Google Guava project for our caching needs. This is a very nice cache system that can be plugged in to any class structure to cache method responses. From the outside, you call, for instance, an interface function. And in the implementation class you use a builder to create a static cache for the class method. You delegate your actual call to Guava, and the cache will look up a key and return a value if it exists in the cache, otherwise it will execute the actual method.

A typical, simple implementation of a Guava cache:

@Component
public class DataService(){
	private static Cache cache;
	private static final int CACHE_SIZE = 10;
	private static final int CACHE_EXPIRATION_IN_HOURS = 24;
 
	@Autowire
	private MyWebServiceBean myConnectorBean;
 
	public Document getDataFromService(Document request){
		if (cache == null) initializeCache();
 
		Document response = null;
		try {
			CacheKey key = new CacheKey(request.hashCode(), request);
			response = cache.get(key);
		} catch (ExecutionException e) {
			throw new RuntimeException("Error fetching from cache", e);
		}
		return response;
	}
 
	private void initializeCache() {
		cache = CacheBuilder.newBuilder()
			.maximumSize(1000)
			.expireAfterWrite(CACHE_EXPIRATION_IN_HOURS, TimeUnit.HOURS)
			.build(new CacheLoader() {
				@Override
				public Document load(CacheKey cacheKey) throws Exception {
					return myConnectorBean.getDataFromService(request)
				}
			});
	}
}

Guava has all the functions you want in a cache: Time to live, max elements, eviction, invalidation, statistics, eviction events and much much more. However, implementations tend to be quite complex and new developers struggle to get the grasp of what is going on when they see the code. It can also be difficult to write code that is non-intrusive in the classes that need caching. The example above could probably be written much smarter that this, but the complexity of the code is quite obvious.

Spring Cache Abstraction

Spring Cache Abstraction is new in Spring 3.1. It seems to be built on previous work done with spring ehcache annotations.

Spring cache abstraction is just that, an abstraction. It is based on some very powerful annotations like @Cacheable, @CachePut, @CacheEvict and more. I will not show examples for all annotations in this blog, just the few that helped me replace Guava.

Basically what you do is annotate a method, or a class, with @Cacheable(“name-of-cache”). Spring will then proxy the class and any calls done to the methods will be cached in the named cache. The default cache key will be based on the input parameters to the method. Next time you call the method with the same parameters, the cached data will be returned. This is all you need to do with the class to enable caching for this method, or class. (This means of course that the method should be deterministic. Costly numerical calculations could be an example.)

@Component
public class DataService(){
 
	@Autowire
	private MyWebServiceBean myConnectorBean;
 
	@Cacheable("name-of-cache")
	public Document getDataFromService(Document request){
		return myConnectorBean.getDataFromService(request);
	}
}

But to cache something, you need a cache engine!

We use annotated Spring beans to wire up the application. (NO XML FTW) In our @Configuration class we added the @EnableCaching annotation. This is new in Spring 3.1.1! We then create a @Bean for CacheManager. This class is used by Spring Cache Abstraction to control the caching. We can choose to use a simple ConcurrentMapCache, with a name equal to the one we use in @Cacheable, for very simple caching:

@Configuration
@EnableCaching
public class ServiceContext{
 
	@Bean
	public CacheManager cacheManager(){
		CacheManager cacheManager = new SimpleCacheManager();
		cacheManager.addCaches(Arrays.asList(new ConcurrentMapCache("name-of-cache")));
		return cacheManager;
	}
}

And that is it! Your applications should now be able to cache the class methods you annotate.

What if I don’t want the cache to live for ever?

An easy way could be to annotate a method with @CacheEvict(“name-of-cache”, allEntries=true) When this method is called, the cache will be emptied.

However, in our web application, we typically want to cache the xml response from a slow web service. This data is quite static, but it can change. The question is: When does it change? When should we evict data from the cache? And what do we do when the concurrent map becomes large? We need functionality that Guava gives us. At this point, there exists no ready made implementations of Guava with Spring Cache Abstraction. (…let’s start implementing!) Spring provides an implementation of Ehcache, a well proven cache system.

What we need to do to unilize Ehcache is to replace our concurrentMapCache with an Ehcache manager. Notice that we have added an interface to the @Configuration class. This is to help Spring understand that the @Bean keyGenerator is the implementation that we want to use to generate default keys.

The KeyGenerator is an interface that takes the actual object that is doing caching, the actual method that is being called and all parameters to that method as input. Based on that input, it generates a key for the cache and returns it. The DefaultKeyGenerator that is used above creates a hashcode as key. This should work very well for methods that are deterministic.

@Configuration
@EnableCaching
public class CoreServiceConfig implements CachingConfigurer {
 
	@Bean
	@Override
	public CacheManager cacheManager(){
 
		EhCacheManagerFactoryBean factory = new EhCacheManagerFactoryBean();
		factory.setCacheManagerName("My cache manager");
		factory.setConfigLocation(new ClassPathResource("ehcache.xml"));
		factory.setShared(true);
		try {
			factory.afterPropertiesSet();
		} catch (IOException e) {
			throw new RuntimeException("Init cache crashed", e);
		}
 
		EhCacheCacheManager managerEH = new EhCacheCacheManager();
		managerEH.setCacheManager(factory.getObject());
 
		return managerEH;
	}
 
	@Bean
	@Override
	public KeyGenerator keyGenerator(){
		return new DefaultKeyGenerator();
	}
}

To configure Ehcache we use ehcache.xml on the classpath:

<ehcache>
	<diskStore path="java.io.tmpdir"/>
	<defaultCache
		name="name_of_cache"
		maxEntriesLocalHeap="1000"
		eternal="false"
		timeToIdleSeconds="120"
		timeToLiveSeconds="120"
		overflowToDisk="true"
		maxEntriesLocalDisk="10000000"
		diskPersistent="false"
		diskExpiryThreadIntervalSeconds="120"
		memoryStoreEvictionPolicy="LRU"
		/>
</ehcache>

There are of course classes that makes it possible to do this in Java code instead, but some xml could be nice just to be able to easily configure our caches. Remember to add Ehcache jar on you classpath..

Security

If we cache web service responses per user, an different user could in theory fiddle with some parameters and access data he or she should not. This is a serious security issue! We need to make the cache smarter. What if we could chacnge the cache keys by adding data that the user can not control? Our web application is actually a rest api using Jersey resources, and on top of that, we have a single sign-on solution to control user access.

We implement a custom key generator:

public class SecureKeyGenerator implements KeyGenerator {
 
	@Override
	public Object generate(Object target, Method method, Object... params) {
		Object keyPostFix = new DefaultKeyGenerator().generate(target, method, params);
 
		if (target instanceof SecureKeyAware &&
			((SecureAware) target).getSecureKey() != null) {
 
			return ((SecureKeyAware) target).getSecureKey() + keyPostFix;
		} else {
			throw new RuntimeExeption("Target for key generation is not secure key aware.");
		}
	}
}

The single signon solutions helps us here, because the backend has a unique identifier for each user. We just add this identifier to the key and then we have a secure cache since method parameters no longer are the only providers for key generation. Since the key is any subclass of Object, we could create the key using a MyKeyImplementation if we needed to do something smart with the keys in the cache in stead of leaving it as a string.

In this blog, we have shown how to add caching to a class or method in a non-intrusive way with Spring. The example is quite simple, and for this application it works very well. Spring cache abstraction can be used in much more complicated ways – Check out the Spring documentation! Remember that Spring is only an abstraction layer. Spring does not handle the actual caching but leaves that to the underlying implementation library.

I mitt forrige blogginnlegg - Å være kundesentrisk er mer enn å tilby god kundeservice - tok jeg for meg begrepet og betydningen av det å være kundesentrisk. Det er spesielt tre aspekter som understøtter behovet for å orientere seg mer kundesentrisk, og jeg vil trekke frem tre steg på veien for hvordan man kan imøtekomme disse:

1. Ny generasjon forandrer spillereglene – Vær løsningstilbyder

Vi ser stadig en sterkere endret kundeadferd i form av at:

• yngre kunder er mindre lojale
• en ny generasjon kunder har et annet forhold til IKT – de har mer informasjon tilgjengelig og ønsker å gjøre jobben selv
• de ønsker nye kommunikasjonskanaler

Dette har implikasjon for bedrifter! Tidligere kunne bedrifter lansere et produkt, og la det være opp til kunden hvordan dette skulle integreres med andre produkter. Det er ikke lenger tilfelle; bedriftene må hjelpe kundene med å forstå hvordan produktene passer inn i deres situasjon. Bedriften må med andre ord være løsningstilbydere. Det betyr at bedriftene må ha kapabiliteten; både operasjonelt og organisatorisk, til å kunne tilby ulike produkter og tjenester til ulike type kunder.

2. Kundene er heterogene og har ulike behov – Gjenkjenn kunden og dens behov

Jeg mener at den “gjennomsnittlige kunde” ikke eksisterer, da bedrifter i dag opererer med en heterogen kundeportefølje i henhold til hva kunden er verdt, hvordan kunden vil respondere til produktet eller tilbudet, samt deres villighet til å handle og snakke med hverandre. For å klare å tilby riktig produkt til riktig kunde er man avhengig av å gjenkjenne kunden eller segmentet den tilhører, og klare og skille de kundene som er verdifulle fra de som ikke er det.

Min erfaring er at mange bedrifter i dag har segmenteringsmodeller basert på tenkning fra tradisjonell produktmarkedsføring. Inndelingen av kundeporteføljen er da ofte basert på observerende ting og karakteristikker som for eksempel demografi, kjønn og geografi.  Disse karakteristikkene mener jeg i dag blir for enkle og lite effektive i forhold til heterogeniteten og dynamikken som er i selskapenes kundeportefølje. Med dagens kunder og deres behov, anser jeg det som sentralt å segmentere kundene på deres verdier. Jeg snakker ikke om historisk lønnsomhet, men om fremtidsrettet kundeverdi – hva kunden kan være verdt for selskapet i fremtiden. I dette arbeidet bør selskapene fokusere på økt levetid, økt salg («share-of-wallet», kryssalg, økt volum osv), og/eller reduserte kostnader (salg, service, distribusjon osv).

3. Ikke alle kunder er verdifulle for deg – Ha riktig kundeportefølje

Det er en gammel sannhet at det er lønnsomt å ta vare på gode kunder; men hvordan klare å finne de riktige kundene å fokusere på? En forutsetning for lønnsomme kunderelasjoner er at bedriften må skaffe seg kundeinnsikt og innovere seg i den enkelte kundens behov. Gjennom å gjøre dette kan bedriften tilegne seg kundenes tillit og lojalitet, og kan skape synergier ved å balansere innsatsen av ressurser mot ulike typer av kunder i porteføljen. På denne måten vil bedriftene kunne klare å fokusere på de riktige kundene, og dermed øke lønnsomheten.

Med andre ord bør selskaper på veien mot å bli kundesentrisk starte med å jobbe mer effektivt med sine kundeporteføljer. Selskaper bør i økende grad orientere seg og agere mer differensiert mot ulike kunder. Gjennom å ha god innsikt i den enkelte kundes behov og adferd, vet man hvilke kunder man bør investere i og hvilke som bør pleies med mindre ressurser.

1. Enkle verdiforslag til kundene

De nevnte virksomhetene har enkle verdiforslag og et klart svar på hva de løser for kundene. Dette gjør at markedet aldri er i tvil om hva de leverer: Flytoget tilbyr passasjerene den korteste reisetiden til og fra Gardermoen. FINN representerer mulighetenes marked og gir kundene full oversikt over jobb og eiendom, mens annonsørene tilbys en godt besøkt markedsplass. Ved å fokusere på kvalitet gjennom hele verdikjeden leverer Toyota markedets mest driftsikre biler. Verdiforslaget til One Call er heller ikke til å ta feil av: De gir deg landets laveste telefonregning uten skjulte kostnader, og hjelper deg med å finne det billigste abonnementet basert på eget bruksmønster.

2. God kundeinnsikt

Evnen til å tilegne seg og dra nytte av kundeinnsikt er viktig for å fremstå som relevante, innovative og interessante for kundene. Her kan det være verdt å trekke frem hvordan Flytoget har begynt å bruke infoskjermene ombord til å vise ventetid i sikkerhetskontrollen på Gardermoen. Dette viser at de forstår hvilke behov de reisende har og at mange er bekymret for om de rekker sine respektive fly. FINN gir på sin side kundene mulighet til å lagre søk og personalisere sin egen side gjennom konseptet Min FINN. Basert på dette, samt tidligere trafikkmønster, kan de da foreslå relevante annonser tilpasset kunders ulike individuelle behov.

3. Åpenhet om egen kundestrategi

Et annet fellestrekk er at virksomhetene er åpne om egen kundestrategi og verdien av tilfredse kunder, noe som bidrar til at kundene føler seg verdsatt. Under dagens overrekkelse av Kundetilfredshetsprisen uttalte Flytogets representant følgende: ”Kundene er våre eneste sjefer og de påvirker alt vi gjør.” Et annet eksempel er hvordan One Call fremhever god kundeservice som ett av tre viktige argumenter for at kunder skal velge dem. Bevisstheten og topplederforankringen rundt dette understrekes blant annet gjennom TV-reklamer der administrerende direktør Øistein Eriksen selv forteller hvor viktig god kundeservice og fornøyde kunder er for dem.

4. Personlig service og enkel selvbetjening

Videre tilbyr virksomhetene personlig service og enkle selvbetjeningsløsninger som kundene verdsetter. Flytoget har for eksempel automatisert kjøp og kontroll av billetter, noe som gir kundene effektivitet i billettkjøp og ro ombord i toget. Toyota tilbyr blant annet enkle ”gjør-det-selv”-veiledninger på nettsidene sine, slik at kunder som ønsker å foreta mindre reparasjoner selv får hjelp til dette. Den enkle prosessen for å bli kunde i One Call er et annet eksempel: Alt du trenger å gjøre er å fylle ut et kort webskjema med nåværende telefonnummer og ønsket abonnement – resten blir håndtert av One Call.

5. Kompetente og fornøyde medarbeidere

Sist, men ikke minst, legger virksomhetene stor vekt på opplæring og oppfølging for å sikre kvalifiserte og motiverte medarbeidere. Dette bidrar til at medarbeiderne blir gode ambassadører, yter bedre service og fungerer som virksomhetens beste ansikt utad. Både Flytoget og FINN har i flere år ligget i toppen av kåringen Great Place to Work og hatt de mest tilfredse medarbeiderne. Virksomhetene som har de mest tilfredse medarbeiderne jobber bevisst med dette og med å synliggjøre medarbeidernes bidrag. Sett i lys av dette er det kanskje ikke tilfeldig at Flytogets ledelse ble igjen på kontoret, mens de lot en alminnelig flytogvert få æren av å motta dagens pris… 

Dette er noen av fellestrekkene blant virksomhetene med høyest kundetilfredshet. Kanskje er du enig, eller kanskje ser du andre fellestrekk som er verdt å nevne?

So — what's a mixin?

Basically, a mixin allows you to extend your Backbone components with utility functions. Let's, for example, say that we have pagination which is similar in many views, but not in all. How should we include this functionality?

We have the following API for adding extra functionality:

UsersView.mixin(Pagination);
AppView.mixin(Transitions);

We have, however, taken the concept of mixins one step further than what I've seen before. In addition to including all the properties which are present in the mixin, our implementation enable mixins to include their own initialize which will extend the existing initialize. When mixing into views a mixin can also include its own render and events. Let's take a look at what this means in practice:

var UserView = BaseView.extend({
    events: {
        "click h1": "user"
    },
 
    initialize: function() {
        console.log("user init");
    },
 
    user: function() {
        return this.model.get("name");
    }
});
 
// This is our mixin:
var Pagination = {
 
    // expects the view it's mixed into to have a link with class `next`
    // present in the DOM
    events: {
        "click a.next": "next"
    },
 
    initialize: function() {
        console.log("pagination init");
    },
 
    next: function() {
        return "next for: " + this.model.get("name");
        // yeah, you would absolutely use a collection as it's named
        // pagination, this was just to keep the example short ;)
    }
};
 
UserView.mixin(Pagination);
 
var model = new Backbone.Model();
model.set("name", "Kim");
 
var view = new UserView({ model: model });
// this initialization console logs (in order):
// "user init"
// "pagination init"
 
console.log(view.user()); // "Kim"
console.log(view.next()); // "next for: Kim"
console.log(view.events); // {
                          //   "click a.next": "next",
                          //   "click h1": "user"
                          // }

As we can see from the code, a mixin has access to this in the same way as the model, collection or view itself. Additionally, mixins can potentially be self-contained, i.e. because initialize, render and events can be extended the component we mix into does not need to know anything about the the mixin. This makes it especially easy to include a new mixin or remove one that is in use.

Implementation

Let's have a look at an example of how these mixins can be implemented. Specifically we will take a look at an implementation of mixins for views:

Utils = {};
 
Utils.viewMixin = function(from) {
  var to = this.prototype;
 
  // we add those methods which exists on `from` but not on `to` to the latter
  _.defaults(to, from);
  // … and we do the same for events
  _.defaults(to.events, from.events);
 
  // we then extend `to`'s `initialize`
  Utils.extendMethod(to, from, "initialize");
  // … and its `render`
  Utils.extendMethod(to, from, "render");
};
 
// Helper method to extend an already existing method
Utils.extendMethod = function(to, from, methodName) {
 
  // if the method is defined on from ...
  if (!_.isUndefined(from[methodName])) {
    var old = to[methodName];
 
    // ... we create a new function on to
    to[methodName] = function() {
 
      // wherein we first call the method which exists on `to`
      var oldReturn = old.apply(this, arguments);
 
      // and then call the method on `from`
      from[methodName].apply(this, arguments);
 
      // and then return the expected result,
      // i.e. what the method on `to` returns
      return oldReturn;
 
    };
  }
 
};

Now we need to include this mixin in such a way that this means the correct thing and we can use it like we saw in the example above. This can be done in two ways, both of which utilize the viewMixin method we created above:

1. As mentioned in the Backbone docs it's okey to add methods directly to a Backbone component. We can use this idea and add mixin like this:

   Backbone.View.mixin = Utils.viewMixin;

2. If you create a layered architecture you can include viewMixin in one of your layers. In our project we had a BaseView which we created all our views from. Remember, this is how Backbone views are defined:

   Backbone.View.extend(properties, [classProperties])

   So, in order to create our desired API we can add mixin as a class property on our BaseView, for example:

   var BaseView = Backbone.View.extend({
     // lots of methods
   }, {
     mixin: Utils.viewMixin
   })

In my project we chose to go for the latter solution as we already had a BaseView.

Testing

Mixins can be tested both by themselves and when mixed into a component. We'll take a look at how the latter can be done.

Jasmine has a great way to include similar tests several places. Davis W. Frank of Pivotal Labs wrote a great blog post about this a year ago. Basically, the point is to write a function that contains regular Jasmine specs. For example:

function sharedBehaviorForPagination() {
  describe("pagination", function() {
    it("should be able to paginate to the next page", function() {
      // ...
    };
 
    it("should not be able to paginate to the next page when on the last page", function() {
      // ...
    };
  });
}

In the specs for the component we mix into we can then call this function:

describe("users", function() {
  // ... lots of users specific specs
 
  sharedBehaviorForPagination();
});

We have now included the shared set of specs into our regular tests for "users". If some shared state is needed, we can change sharedBehaviorForPagination to receive arguments in order to share state. We found this to be a great technique for ensuring that our mixins works as expected in all the components which include them.

When?

Mixins are a simple but potentially very powerful abstraction. We used them for mainly for three things: pagination, local error handling and handling transitions between pages. Basically, we used mixins when we found them to help decouple our code and make each component more focused. The right time to use them appears to be when a component does more than one thing and when we can better separate concerns when splitting to the code.

In this blog post I've only looked at using them for views, but they are also great for breaking up models and collections.

To give credit were credit is due, this blog post, and our solution to the mixin problem, was heavily influenced by Dmitry Polushkin's gist on mixins.

Hva er Social CRM?

Det finnes en rekke upresise definisjoner av Social CRM som samlet sett bidrar til mytene jeg her skal diskutere. La meg derfor starte med å definere Social CRM som en prosess for å overvåke, engasjere og administrere nåværende og potensielle kunder på tvers av sosiale medier for å kunne forbedre egen virksomhet og dens relasjon med kundene.

Myte 1: Social CRM kan erstatte tradisjonell CRM

Den tradisjonelle tilnærmingen til innsamling av kundedata baserer seg på virksomhetens kontakt med kundene, for eksempel gjennom kjøpsprosesser, kundeservice og kundeundersøkelser. Dette gir nyttig, men likevel begrenset informasjon. Mens tradisjonell CRM først og fremst handler om å samle kundedata i skjæringspunktet mellom kunde og virksomhet, muliggjør Social CRM innsikt i hva kundene sier til hverandre. Både eksterne sosiale nettverk, samt virksomhetens egne diskusjonsforum og idéportaler er aktuelle informasjonskilder. Slike informasjonskilder gir bedre grunnlag for å forstå hva kundene faktisk er opptatt av, hva de søker etter, hva de deltar på, hva de liker og hva de misliker. Men til tross for at sosiale medier muliggjør ny kundeinnsikt, må dette fortsatt kombineres med kjøpshistorikk, reklamasjoner og annet som samles gjennom tradisjonell CRM. Social CRM endrer derfor ikke definisjonen eller viktigheten av tradisjonell CRM – Social CRM er et supplement til dette.

Myte 2: Social CRM gir virksomheten bedre kontroll over kundene

Det er ikke overraskende at det oppstår misforståelser rundt Social CRM fordi navnet i seg selv er relativt misvisende. Bakgrunnen for en slik påstand er at CRM, eller Customer Relationship Management, indikerer noe virksomheten har kontroll over og kan lede. Dette strider mot den grunnleggende filosofien bak Social CRM. Social CRM handler ikke om ledelse og kontroll av kunden, men om engasjement med kunden. Man kan derfor diskutere om et bedre navn ville vært Social CRE – Social Customer Relationship Engagement. Jeg skal ikke gå nærmere inn på en navnediskusjon her, fordi et navn i seg selv gir lite verdi. Det som imidlertid er viktig er forståelsen av at maktforholdet mellom virksomhet og kunde nå er snudd på hodet: Skal man lykkes med Social CRM må man først og fremst innse at det ikke lenger er virksomheten, men kundene som har kontroll.

Myte 3: Social CRM handler bare om tilstedeværelse i sosiale medier

En tredje vanlig misforståelse er at Social CRM sidestilles med tilstedeværelse i sosiale medier. Mange virksomheter ser sosiale medier primært som nye kanaler for markedsføring og kundeservice, noe som riktignok kan gi verdi og tjene sine respektive formål isolert sett. Antall følgere på Facebook og Twitter er imidlertid ikke noe mål på om man lykkes med Social CRM eller ikke. Hvorvidt du har opprettet egne stillinger for kundeservice i sosiale medier, eller hvorvidt du har gått til anskaffelse av sosiale lytteverktøy er heller ikke noe mål på om man har forstått og innført filosofien bak Social CRM. Social CRM handler om evnen til å analysere og utnytte kundeinnsikten man får gjennom sosiale medier til å forbedre egen virksomhet og dens relasjon med kundene.

Myte 4: Social CRM gir ingen verdi

Som tidligere nevnt gir Social CRM bedre innsikt i kundens reelle behov. Dersom man evner å utnytte denne kundeinnsikten til faktiske forbedringer, vil man lettere kunne innfri og overgå kundens forventninger til produkter og tjenester. I tillegg til bedre produkt- og tjenesteutvikling, signaliserer dette at man tar kundene på alvor. Når kundene føler seg inkludert og viktige, vil de lettere etablere eierskap og forpliktelse til virksomheten, dens produkter og tjenester. Social CRM bidrar i tillegg til at virksomheter fanger opp problemer og misnøye tidligere, noe som gjør at kundeservice lettere kan kommunisere proaktivt. Færre kundehenvendelser og kortere ventetid, bidrar både til lavere kostnader og mer fornøyde kunder. Social CRM bidrar derfor til økt verdiskaping både gjennom produkt- og tjenesteutvikling, salg- og markedsføring og kundeservice.

Dette er noen av de vanligste mytene rundt Social CRM. Kanskje kjenner du deg igjen i disse, eller kanskje har du andre myter som kan diskuteres?

First of all, how do you test these views? Or, this is JavaScript, so you probably don't. Cheekiness aside, the basic problem is that you need the DOM present to enable searching for selectors, and to have the DOM present you (often) need to set up the entire application — which, obviously, slows down tests considerably.

Secondly, who is allowed to change what? Can all functions change whatever part of the DOM they want? This wreaks havoc for your tests and creates uncertainty as to where something occurs. And once again, you most likely need to set up the entire application to test the view.

My solution: A view is responsible for one HTML element and everything inside it.

And, of course, a view may contain several sub-views which again are responsible for themselves.

What's a view?

Basically, a view is a component which handles some part of a user interface. My views have five primary responsibilities (Those familiar with MVC and MVP will probably call these views Controllers or Presenters, but the nomenclature is not important — splitting responsibilities between different components is):

• Rendering the view, i.e. making changes to the DOM.
• Listening for DOM events, such as click and submit.
• Listening for events from the rest of my application, plus triggering events when the view is in certain states.
• Creating sub-views if they are needed.
• Updating models based on changes in the view (Don't you dare make $.ajax calls directly in views!)

A view is, however, never ever allowed to access something which is outside its subset of the DOM.

Let's look at an example of a view:

// a view constructor which accepts:
// - el, which is a jQuery object of the HTML element the view owns
// - user, which is a user model with key-value pairs
var UserView = function(el, user) {
  this.el = el;
  this.user = user;
}
 
UserView.prototype.showImage = function() {
  this.el.append('<img src=' + this.user.image + '>');
}
 
// let's just create a super simple user object
var user = {
  image: 'http://example.com/image.png'
};
 
// initialize the view with the jQuery object the view owns and a user
var view = new UserView($('.user'), user);
 
// ... and now we can do stuff which changes the DOM
view.showImage();

This view is never ever to go outside of .user. Ever.

No frameworks or libraries are needed, just being strict with how you write your code. With these small changes we have contained a subset of the user interface to a specific view, and this UserView is easily testable and can easily be moved around on the page. It can even be removed without being afraid of how it impacts the rest of the application.

Easily testable

Just as an example, to test this bit of code we can initialize it with $('<div></div>') instead of $('.user'). This just means that we let an empty div live in the jQuery object instead of the .user subset of the DOM.

Using this trick, we can test the user view by calling showImage and then check that the image is present. As everything lives in the jQuery object we don't need to set up the DOM. Let's look at a code example using Jasmine:

describe('user view', function() {
  it('should be able to show image', function() {
    var user = {
      image: "user.png";
    };
 
    var view = new UserView($('<div></div>'), user);
    view.showImage();
 
    // remember that `view.el` is a jQuery object. So now we can call
    // `find` on it directly instead of looking for `img` in the entire
    // DOM.
    var image = view.el.find('img');
 
    expect(image.attr("src")).toEqual("user.png");
  });
});

With a small helper function the code becomes even easier to work with:

UserView.prototype.$ = function(selector) {
  return this.el.find(selector);
}

Now you can write view.$('img') instead of view.el.find('img').

But I need to change something 'over there'

So let's say you have created several of these views, but now one view needs to change something in another view — but how? Remember, a view is not allowed do anything outside its HTML element.

The solution is events.

Events are basically just a way to say: "Hi, I want to know when some action occurs" and "Hi, you know what? The action you're waiting for just occurred!" We are used to this idea from jQuery DOM events such as click and submit. Now we are just moving it into the rest of our code.

Let's look at some examples using EventEmitter:

var events = new EventEmitter();
 
var UserView = function(el, user) {
  this.el = el;
  this.user = user;
 
  // Let's listen for someone emitting the event 'user:showImage', which
  // we listen for and then show the user's image.
  // The first parameter is the event name, the second is the function
  // to call when the event is triggered, and the third is the context
  // the function is called with.
  events.addListener('user:showImage', this.showImage, this);
 
  // We can also emit events. Let's tell listeners that we have created
  // a user view.
  events.emit('user:created');
}

Now, whenever you are interested in something outside a view, you can listen for events, and you can also let other views know when something has occurred. This creates a highly decoupled application which is easy to test and easy to extend.

But, why?

To sum up, there are three primary benefits of writing your JavaScript views like this:

• You always know who is responsible for some subset of the DOM, and changing a view will never impact the DOM outside of its "walls".
• You can have localized DOM lookup. Instead of looking for .user img you can look for img on the user view. Based on the above example we can find the image by writing userView.DOM('img').
• It's very simple to test. And your tests will be blazingly fast as they do not depend on the DOM or on the entire app being set up.

Many of the ideas I discuss in this blog post is both inspired by and beautifully handled by Backbone.js and Spine.js. I truly recommend checking out those libraries if you're working on a large JavaScript application.

We experience three primary benefits from these tests:

• Rather than being implementation-oriented, they focus on the end result. This means that restructuring and changing code rarely breaks tests, as long as we don't break the application's end-to-end behaviour.
• They are very easy to write using Backbone's abstractions. They are also more natural to write as they focus on the end result.
• They are very fast, so we could run them all the freakin' time.

Let's look at an example:

it("should list all persons in response", function() {
 
  // fetch an Ajax response
  var response = readFixtures("responses/persons.json");
  var options = {}; // no additional options for the Ajax request
 
  // create our view, sending in an empty collection
  var view = new PersonsView({ collection: new Persons() }); 
  view.render(); // show header and other static stuff
 
  // mock out all requests (this is our core test abstraction),
  // i.e. what this function does is responding to all Ajax requests in
  // the callback with the same response and with the same options.
  // Thus, when `fakeResponse` is finished, all Ajax requests will have
  // responded, and as we listen for finished Ajax requests in our view,
  // we will then have properly set up our PersonsView.
  fakeResponse(response, options, function() {
    view.collection.fetch(); // trigger Ajax request
  }); 
 
  // ensure that all persons are present
  expect(view.$('.persons li').length).toEqual(20);
 
});

So, basically, we test the end result given a specific response.

We use the following libraries for writing tests:

• Jasmine as our test framework.
• Jasmine-jQuery for fixtures.
• Sinon.js for test spies, stubs and mocks.

The core test abstraction in the example is fakeResponse. This method creates mock responses for Ajax requests using Sinon.js. This is a simplified implementation of the function:

function fakeResponse(response, options, callback) {
  var statusCode, headers, server, resp;
 
  // some default values, so we don't have to set status code and
  // content type all the time.
  statusCode = options.statusCode || 200;
  headers = options.headers || { "Content-Type": "application/json" }
 
  // we create what Sinon.js calls a fake server. This is basically just
  // a name for mocking out all XMLHttpRequests. (There are no actual
  // servers involved.)
  server = sinon.fakeServer.create();
 
  // we tell Sinon.js what we want to respond with
  server.respondWith([statusCode, headers, response]);
 
  callback();
 
  // this actually makes Sinon.js respond to the Ajax request. As we can
  // choose when to respond to a request, it is for example possible to
  // test that spinners start and stop, that we handle timeouts
  // properly, and so on.
  server.respond();
 
  server.restore();
}

With this relatively simple abstraction we can do a lot of powerful stuff in our tests. Let's look at a new example where we interact with the view and perform several Ajax requests:

it("should show error message when pagination fails", function() {
 
  // ajax responses
  var response = readFixtures("responses/persons.json");
  var errorResponse = readFixtures("responses/errors.json");
 
  // create our initial view
  var view = new PersonsView({ collection: new Persons() });
  view.render(); // show header and other static stuff
 
  // mock out all requests
  fakeResponse(response, headers, function() {
    view.collection.fetch(); // trigger Ajax request
  });
 
  // now we have set up our initial state, and can go on to doing things
  // in the view.
 
  // we ensure that errors are not present
  expect(view.$('.errors')).not.toExist();
 
  // we set up an error response ...
  fakeResponse(errorResponse, { statusCode: 503 }, function() {
 
    // ... and we trigger the error by clicking the next button
    // (in our view we listen for the click event and start the
    // pagination process)
    view.$('a.more').click();
 
  });
 
  // ensure that errors are present
  expect(view.$('.errors')).toExist();
});

We often initialize views the same way for several tests, as with PersonsView in the examples above. It is usually a good idea to create abstractions for these at some point. For example we can create a getPersonsViewFromResponse as follows:

function getPersonsViewFromResponse(response, options) {
  var view = new PersonsView({ collection: new Persons() });
  view.render();
 
  fakeResponse(response, options, function() {
    view.collection.fetch();
  });
 
  return view;
}

Thus, we can call getPersonsViewFromResponse to initialize our view, which makes our tests even easier to write.

We have written more than 200 of these tests, and, as they don't change the DOM, they are blazingly fast. Ours run in about 1.3 seconds. Additionally, they work wonders for our confidence and our code.

#!/bin/bash
repo_dirs=$( ls -d1 $@ )
for repo_dir in ${repo_dirs[@]}
do
  cd $repo_dir
  echo "checking if $repo_dir is a git repo"
  if [[ -d .git ]]
  then
    echo "Garbage collecting $repo_dir"
    git gc
  fi
done

The script is scheduled to run every night in Jenkins. Create a new Job and select “Build a free-style software project”. Fill in Build as follows:

The script can also be used manually from the command line or as a cron job with path(s) to your repos as an argument. Without an argument it will process current directory.

The external serializer problem

Lately we’ve been working with Hazelcast, an open source Java In-Memory Data Grid. In its simplest form Hazelcast is extremely easy to work with. Just use the static getMap method and starting putting objects into the grid:

Map<Integer, String> testMap = Hazelcast.getMap("test");
 
testMap.put(1, "entry 1");
testMap.put(2, "entry 2");

If you are running several grid nodes, the data is serialized across the cluster automatically. So after running the code above on one node you can extract the data on a different, or the same, node:

Map<Integer, String> testMap = Hazelcast.getMap("test");
 
String entry = testMap.get(1); // "entry 1"

The only requirement on the objects going into the grid is that they are serializable, either by implementing java.io.Serializable/Externalizable or com.hazelcast.nio.DataSerializable. Our problem is that we need to be able to work with an existing domain model. We can add implements Serializable, but standard Java serialization is inefficient both in terms of speed and size. We would rather not implement Externalizable or DataSerializable as the domain model is used in other places, and we don’t want to clutter it with serialization code.

We took a quick look at different serialization frameworks and decided to try out Kryo, an easy to use framework scoring pretty good in benchmarks. Hazelcast however does not support plugging in a custom serializer at the moment (version 2.0.2). So this is our problem:

How to utilize an efficient serialization framework like Kryo with a product that does not support plugable serializers?

Proposed solution: serializable wrapper

What we’ve come up with so far is the following. First we put all Kryo specifics into a utility class KryoSerializer:

package eivindw.io;
 
import com.esotericsoftware.kryo.Kryo;
import com.esotericsoftware.kryo.ObjectBuffer;
 
public final class KryoSerializer {
 
   private static final Kryo kryo = new Kryo();
 
   static {
      kryo.setRegistrationOptional(true);
   }
 
   public static void register(Class... classes) {
      for(Class clazz : classes) {
         kryo.register(clazz);
      }
   }
 
   public static byte[] write(Object obj) {
      ObjectBuffer objectBuffer = new ObjectBuffer(kryo);
      return objectBuffer.writeClassAndObject(obj);
   }
 
   public static Object read(byte[] bytes) {
      ObjectBuffer objectBuffer = new ObjectBuffer(kryo);
      return objectBuffer.readClassAndObject(bytes);
   }
}

What this does is provide an easy way to turn objects into byte arrays and vice versa, the Person class in this example doesn’t even have to implement Serializable:

Person person = new Person("Eivind", 35);
 
byte[] bytes = KryoSerializer.write(person); // serialize to byte array
 
Person samePerson = KryoSerializer.read(bytes); // deserialize back to object

To make use of this on the Hazelcast grid we created a serializable “wrapper” class:

package eivindw.io;
 
import java.io.ObjectStreamException;
import java.io.Serializable;
 
public class KryoWrapper implements Serializable {
 
   private byte[] s;
 
   public KryoWrapper(Object target) {
      s = KryoSerializer.write(target);
   }
 
   private Object readResolve() throws ObjectStreamException {
      return KryoSerializer.read(s);
   }
}

The wrapper will use the KryoSerializer to store a given object as a byte array, which the JVM of course knows how to serialize efficiently. Then the readResolve method will use the KryoSerializer to recreate and return the original object from the byte array. The JVM allows this as a sort of automatic replacement of the deserialized object – for reference see java.io.Serializable JavaDoc. This allows us to use the wrapper directly on the Hazelcast maps:

Map<Integer, Object> testMap = Hazelcast.getMap("persons");
 
Person person = new Person("Eivind", 35);
 
testMap.put(1, new KryoWrapper(person)); // Putting a wrapper - serializes fast and small
 
Person samePerson = (Person) testMap.get(1); // Getting a Person - "automatic" deserialized

The wrapper will work with standard Java serialization as well:

ByteArrayOutputStream baos = new ByteArrayOutputStream(500);
ObjectOutputStream oos = new ObjectOutputStream(baos);
 
oos.writeObject(new KryoWrapper(person)); // Using wrapper when writing
 
ByteArrayInputStream bais = new ByteArrayInputStream(baos.toByteArray());
ObjectInputStream ois = new ObjectInputStream(bais);
 
Person person = (Person) ois.readObject(); // Casting result directly to Person

Why use the readResolve method with a cast instead of an explicit wrap method? Hazelcast provides a series of ways to access the serialized objects in the grid, for example queries. Having the wrapper automatically deserialize to the object allows us to use all these features directly, as if the object was serialized directly on the grid.

Feedback?

I feel we’ve come up with a pretty good way to make use of an external serializer in a framework requiring class-internal serialization. Our first tests indicate that we are saving both time and space using this approach. What do you think? Is this use of the readResolve method a viable way to solve this problem? Please leave a comment if you have any suggestions for improvement/alternatives or questions

The code shown in this post is available as a github project.

Smidig ledelse

Forfatteren tar på seg ambisjonen det er å beskrive de mer grunnleggende egenskapene i de smidige metodene vi kjenner. Han beskriver hvordan vi både kan lede prosjekter og team bedre. Appelo tar utgangspunkt i forskningsbaserte metoder og funn, og setter den smidige tenkningen i perspektiv. Han peker på en retning for å utvikle en mer helhetlig modell for ledelse basert på suksessen smidige metoder har hatt både innenfor systemutvikling, produksjonsprosesser og tjenesteyting.

Helhetlig tilnærming

Gjennom å delta i og lede smidige systemutviklingsprosjekter har jeg vært borti flere ulike modeller for smidig utvikling. Det være seg timeboksbaserte metoder som Scrum og XP, eller flytbaserte som Lean og Kanban. Alle modellene har elementer som er gode og dårlige, og det har etterhvert utviklet seg en praksis hvor utviklerteam og prosjekter tar elementer fra ulike smidige teknikker og setter sammen etter teamets og leverandørenes smak. Av og til oppstår energitappende “religionsdebatter” om metoder og teknikker. Apellos bok beskriver et tankesett som frigjør oss fra spesifikke metoder. Med en helheltlig tilnærming beskriver han hvorfor smidig virker, og hvordan vi kan få det til å virke enda bedre.

Appelos utgangspunkt er at alle tradisjonelle ledelsesmodeller er fokusert rundt optimalisering (1.0) og suboptimalisering (2.0) av deterministisk tenkning og hierarkiske strukturer. Han mener, og eksemplifiserer at, de tradisjonelle ledelsesmodellene har bevist sin utilstrekkelighet og beskriver svært overbevisende en ny modell han kaller Ledelse 3.0. Nøkkelbegrepet er kompleksitet.

Seks hovedegrener

Modellen Appelo har laget for Ledelse 3.0 har han kalt “Martie”. I boken ser han mer detaljert på hver av disse grenene:

Management 3.0

• Energizing people
  Hva er det som får mennesker til å “tikke og gå”?
• Empower teams
  Hvordan kan en gruppe gjøres selvstendig og å ta sine egne beslutninger?
• Allign constraints
  Hvordan beskrive rammebetingelser slik at de kan sees på som hensiktsmessige og ikke som hindringer?
• Develop competance
  Hvorfor er kompetanse så viktig?
• Grow structure
  Hvordan styrer man komplekse strukturer når de blir store?
• Improve everything
  Hvordan jobbe med læring i komplekse organisasjoner?

Forfatteren diskuterer en forståelse av menneskelig samspill og kommunikasjon basert på psykologiske og biologiske fakta. Determinisme, kompleksitetsteori, reduksjonisme og holisme er alle begreper som omtales. Som eksempel bruker forfatteren bl.a vannets egenskaper. Man kan ikke ved å beskrive vann etter formelen H2O forklare (på en enkel måte) vannets oppførsel og egenskaper. Summen av argumentene er at det gir mening å legge en kompleks modell til grunn for en smidig planlegging og styring av menneskelig aktivitet og interaksjon. For å forutse adferden til slike strukturer , og lede dem, bør man forstå hvilke egenskaper som kjennetegner dem. Mange av de teoriene vi kjenner fra smidige metoder kan gjenkjennes fra denne grunntenkningen.

Heller tankegang enn metode

Jeg har jobbet med smidige systemutviklingsprosesser siden 2006. Det begynner å bli lenge siden Agile Manifesto ble skrevet (2001). For meg var det veldig stimulerende å lese en bok hvor jeg drar kjensel på utfordringene i prosjekthverdagen, og forstå hvorfor disse utfordringen oppstår. For meg bidro boken til å bygge bro over de smidige metodesiloene.

Anbefalt lesning for alle som jobber med smidig ledelse: Management 3.0; Leading agile deveolopers – Developing agile leaders av Jurgen Appelo

Stadig flere spør kunden jevnlig om hun liker produktet som tilbys, hva hun liker og ikke liker ved produktet og hvordan produktet kan tilpasses kunden bedre. Dette innebærer “å se på kunden gjennom objektivet av produktet” og er etter min mening ikke tilstrekkelig til å kunne si at man har en kundesentrisk tilnærming. Hva skiller da kundesentriske organisasjoner fra andre bedrifter som proklamerer sitt kundefokus?

Kort fortalt vil jeg si at kundesentriske organisasjoner har flyttet seg forbi tradisjonell kundeservice til å re-orientere hele forretningsmodellen rundt kunden, og gjennom dette øke kundetilfredsheten og sin egen lønnsomhet. Kundesentriske bedrifter forstår ikke bare hva kundene verdsetter, men også hvilken verdi den enkelte kunde utgjør av bunnlinjen. Kundesentriske selskaper orienterer forretningsmodellen etter en kundestrategi som gir svar på hvilke kunder bedriften skal prioritere. I tillegg skreddersyr de forretningsprosesser, eksempelvis produktutvikling og kundepleie, for å levere størst mulig verdi til de mest verdifulle kundene for minst mulig kostnad. Sentrale elementer av det å være kundesentrisk er:

God kundeservice

God kundeservice alene gjør ikke en bedrift kundesentrisk, men den sikreste måten å miste en kunde på er å få ham til å føle at du ikke bryr deg om ham. Å tilby god service og spørre etter tilbakemeldinger fra kunder er derfor en av flere viktige elementer av det å være kundesentrisk.

Differensiert tilbud til kundene

En kundesentrisk organisasjon bør være imøtekommende, og utvikle nye varer og tjenester for de mest lønnsomme kundene og ikke nødvendigvis for de andre kundene. Det vil ikke si at man skal ignorere kunder, si opp kunder eller håndtere dem dårlig. Det handler om å differensiere innsatsen mot ulike kundesegmenter. Denne differensieringen av tilbudet til kundene medfører knallhard prioritering og fokus på verdiskapning.

Kundeorientert organisering

Skal man differensiere tilbudet til kundene innebærer dette også i mange tilfeller at bedriften må organiseres med hensyn på kundene – ikke med hensyn på produktene.

Kundeorienterte produkter

En kundesentrisk tilnærming innebærer at man tenker på hvem kundene er, og hvordan man kan være tjenestetilbyder innenfor de problemområdene som kundene står ovenfor. En kundesentrisk bedrift ønsker å løse disse problemene for kundene, og finne frem til en best mulig måte å gjøre det på, fremfor å fokusere på å selge enkeltprodukter til kundene. I et kundesentrisk bank/finans-konsern vil man, eksempelvis, fokusere på hvordan man kombinerer produkter fra forsikring, bank og fond for samlet å skape en god løsning for kunden. Kundene forventer at produktene tilpasses deres individuelle behov, og de forskjellige produktmiljøene vil da samarbeide om løsningen.

Jeg mener med andre ord at kundesentrisk er mer enn bare det å gi god kundeservice. Hva legger du i begrepet kundesentrisk?

Introduction

I wanted to share some of what I have learned about IoC containers, not only because I believe they help you create better software, but also because I struggled for a while to really understand the concept and what I was gaining by using one. An IoC container is closely related to dependency injection (DI) where you inject objects into a class instead of creating the objects inside the class. You can basically think of an IoC container as a tool that helps you do this in a more flexible and customizable way.

So what exactly is Inversion of Control (IoC)? Inversion of Control is a principle that states that the flow of control is somehow inverted from regular procedural programming. It is a general concept that applies to systems where some framework takes control of the code execution and calls back into your code. IoC containers make use of this principle, but in my opinion they might as well have been called dependency injection (DI) containers because this is the pattern they help you implement.

Don’t repeat yourself!

Before I get more into IoC containers, let’s start with a simple dependency injection example. I will assume that you are familiar with DI and are aware of the advantages of constructor injection If not, I recommend reading this short intro to DI and then this guide about writing testable code.

Lets say we are creating a pirate game and want to create Jack Sparrow’s pirate ship, the Black Pearl. Jack Sparrow is injected into the ship’s constructor along with a crew to help him sail the ship. As any decent pirate captain, Sparrow needs a sword and a treasure map, both of which are injected into his constructor. Without using an IoC container the code looks like this:

IShip ship = new BlackPearl(new JackSparrow(new Sword(), new TreasureMap()), new Crew())

In this simple example the BlackPearl depend on two interfaces; the ICaptain and ICrew which Sparrow and Crew implement. Looks fairly reasonable right? But what do you do if you want to use the BlackPearl in many different places in your code? The worst approach would be to violate the DRY principle and just copy the code to wherever you need it. Don’t worry, I won’t waste time explaining why that is a bad idea! A much better approach would be to create a BlackPearl factory that creates BlackPearl objects for you. Using this approach, if the BlackPearl changes and needs another class to be injected, you only need to update the code found in the factory.

public class BlackPearlFactory{
   IShip Create(){
       return new BlackPearl(new JackSparrow(new Sword(), new TreasureMap()), new Crew())
   }
}

The factory pattern is nice, but what if you need Sparrow and the crew in other classes than the BlackPearl? You might create a few more factories that look similar to this one, but they would create other types of objects that also depend on Sparrow and maybe the Crew. This probably seems reasonable, but there is a problem. You are still repeating yourself. Every time you write new JackSparrow() more than once you are repeating yourself. If Sparrow suddenly wants a bottle of grog to be injected you have to update all the places where you have new’ed him up. When the number of classes increase and the dependency tree grows, this quickly becomes a maintenance nightmare. It will also become an incentive to keep adding code to existing classes (violating the SRP) when you should be creating new, small classes with specific responsibilities!

A way out of this mess

This is where IoC containers come to the rescue and give you a solution to this problem. You basically outsource the responsibility for creating objects to an IoC container which can, with a bit of configuration, give you any object with all necessary dependencies injected for you. If we return to the last example and leave out some configuration details you would be able to create the BlackPearl like this:

IShip ship = container.Resolve<IShip>();

The IoC container would be smart enough to first create the Sword and TreasureMap, and inject them into a new instance of JackSparrow. Then it would create the Crew and inject both JackSparrow and the Crew into a new instance of the BlackPearl which would finally be returned back to you from the Resolve method call. The container takes care of creating all the dependencies for the BlackPearl that you normally would have to create yourself. This saves you a lot of work, especially later when you want to make changes to your code. For instance, if you want to remove an injected dependency from the constructor of a class that is managed by the IoC container you can just remove it and update the code in that class accordingly. The IoC container will simply skip injecting that dependency when it creates an instance of the class and since the container is the only one (except for maybe unit tests) that knows about the constructor, the rest of the code won’t even know that this change happened!

How does it work?

If you are new to IoC containers you might be wondering how the container creates instances of other classes, especially when the types that are injected into the constructor are interfaces. All IoC containers must be configured so that they can identify all injected types and be able to map interfaces to specific class implementations. The configuration is usually written in code or in some kind of XML based configuration file. If it is done in code you typically use a “fluent” API which makes the configuration code very easy to read. There are pros and cons to either approach, but I cannot possibly understand why people still use XML for this unless it is for legacy reasons.

Here is how you would register a single dependency in Castle Windsor, currently my IoC container of choice, using its fluent registration API:

container.Register(Component.For<IShip>().ImplementedBy<BlackPearl>());

Castle Windsor now knows that when an instance of the interface IShip is needed it can provide it by creating an instance of the BlackPearl class using reflection. In order for interfaces to be resolved and dependencies to be injected automatically they must all be registered in the container. For example, in order to resolve the BlackPearl in the previous example you would have to add the following registrations:

container.Register(Component.For<ICaptain>().ImplementedBy<JackSparrow>());
container.Register(Component.For<ISword>().ImplementedBy<Sword>());
container.Register(Component.For<ICrew>().ImplementedBy<Crew>());
container.Register(Component.For<ITreasureMap>().ImplementedBy<TreasureMap>());

If you have been paying attention you might be thinking that this example is flawed because if we do it this way we can only have one type of ship, one type of sword, etc. And you would be right! If you wanted to create different implementations of IShip you would still have to create a factory even when using an IoC container. However, in order to keep things simple, this example assumes there is only one implementation for each interface.

“Don’t call us, we’ll call you!”

By now you probably think this is so awesome that you want to just run off and start using an IoC container in your project, but wait one second! A classic mistake is to use an IoC container directly to resolve whatever you need anywhere and everywhere! It is NOT how it is intended to be used. Use the container according to the Hollywood principle; Don’t call the container, it’ll call you!

What does that even mean? It means that you should resolve classes directly from the container in as few places as possible, preferably only one place and let the container automatically create instances of all other classes. Typically you should only need to use the container when you initialize your application and maybe to respond to events that you are not in control of. For instance, if you use it in a web application you should keep the container available as a singleton and use it directly to service a http request, but only once for each request. The reason it is called the Hollywood principle is the same reason it is called inversion of control; when you resolve a class or interface from the IoC container it takes control of the code execution and calls back into your constructor code for every class instance it creates.

Final thoughts

I have barely scratched the surface of what is possible with IoC containers and I have deliberately left out many details concerning their use and how they work, but hopefully this is enough to inspire some of you to find out more. If you are a .net developer I recommend you to check out Castle Windsor, StructureMap, Ninject or Autofac. They are all excellent IoC containers. If you for some reason don’t want to use an existing IoC container why not create one yourself in 15 lines of code?

In case you are still confused about what IoC is and how it relates to IoC containers, I think Bernard over at Stackoverflow sums it up nicely:

Inversion of Control = Marriage
IoC Container = Wife

Marriage is the definition of a known pattern – Wife is the implementation of that pattern

Enjoy!

En vanlig felle å gå i er å fokusere for mye på IT-systemer, og for lite på prosesser og kunder. Mange tenker at hvis vi bare erstatter systemene våre så kommer resten av seg selv. Det hadde vært veldig behagelig om det var så vel, men dette er en farlig vei å gå. IT-systemer i seg selv løser ingenting. Systemene må passe inn i de riktige prosessene, og prosessene er riktig når de løser kundenes behov mest mulig effektivt. Formålet med modernisering er derfor å re-etablere hvordan vi jobber, for å kunne skape mer verdi for kundene. Dette krever et godt samspill mellom kunder, prosesser og systemer.

Kunder: Bedrifter er til for kunder og ikke omvendt. Hva er de vesentligste driverne for kundene deres i dag og i fremtiden? Ønsker de gode kjøps- og bruksopplevelser? Gode produkter? Råd og veiledning? Lave priser? Ja faktisk – hvem er kundene? Er de alle like? Er det forskjeller i hvordan de ønsker å betjenes? Og gitt bedriftens egne strategiske mål – hva er det viktig for dere at dere lykkes med? Bundling av flere produkter og tjenester for å øke kundelønnsomheten? Effektivisere kundebetjeningen? Uansett om du velger å tenke overflatisk eller tenke grundig gjennom dette vil det være en viktig øvelse å gjøre.

Vellykket modernisering krever et samspill mellom kunder, prosesser og systemer

Prosesser: Kjernen i all kommersiell virksomhet er å dekke kundenes behov mest mulig ressurseffektivt. Et viktig spørsmål å avklare er om dette først og fremst handler om å redusere ressursbruken og øke lønnsomheten gitt dagens kundeomsetning, eller om det også handler om å skalere opp dagens operasjoner og sikre at dagens prosesser kan ta unna for en forventet kundevekst? Et annet viktig spørsmål er hvilke muligheter vi har for å forbedre prosessene – gjennom å utnytte teknologi til for eksempel digitalisering, automatisering, samhandling eller informasjons- og kunnskapsdeling. Og hvilke muligheter har vi rett og slett for å gjøre ting enklere – med eller uten teknologi?

Systemer: En modernisering krever til syvende og sist en utskiftning eller større videreutvikling av IT-systemer. En vellykket modernisering krever at fremtidens IT-systemer samspiller godt med hverandre og med hvordan bedriften ønsker å jobbe. Moderne IT-systemer må ikke bare understøtte effektive prosesser og møte bedriftens strategiske behov. De må også være kostnadseffektive i drift. Og enda viktigere er det at de understøtter en fleksibilitet og en smidighet som sikrer at dere har muligheten til å snu dere rundt når markedet og kundene sine behov atter igjen skifter retning. Systemene må være tilpasset prosessene, men prosessene må ofte også tilpasses systemene. Dette gjelder særlig ferdigutviklet programvare som kjøpes inn for å tilpasses bedriftens ønskede arbeidsform.

Mange starter moderniseringsarbeidet med det konkrete systemet de opplever som flaskehalsen. En slik systemorientert innfallsvinkel kan gi mer effektive systemer, men det gir også lite rom for å tenke nytt rundt hvilke behov kundene våre har som vi må løse, eller hvordan vi skal utforme arbeidshverdagen til våre medarbeidere slik at de enklest mulig kan møte kundenes behov. En modernisering som kun fokuserer på systemet reproduserer bare gamle prosesser i nye farger. En vellykket modernisering av prosesser og systemer avhenger derfor av et helhetlig samspill mellom kundebehov, prosesser og IT-systemer.

Lykkes man med dette samspillet gir det desto større muligheter for store gevinster.
• Økt inntjening og verdiskapning gjennom prosesser, systemer og kundeløsninger som skaper betydelig merverdi for virksomheten og kundene og som reduserer graden av manuelt arbeid
• Redusert time-to-market og reduserte kostnader gjennom prosesser, systemer og kundeløsninger som gir økt fleksibilitet, økt smidighet og økt endringsevne
• Mer kostnadseffektiv systemforvaltning gjennom systemer og løsninger som er moderne, tjenesteorienterte og helhetlige

- Vi er imponerte over hva alle lagene har klart å komme fram til i løpet av den korte tiden dere har hatt til rådighet, sa juryleder Harald Krogh, avdelingsleder i Bekk Management Consulting, da han foran spente studenter skulle utrope vinnerlaget. I juryen hadde han med seg konsernsjef i NSB, Geir Isaksen, konserndirektør for strategi og forretningsutvikling Arne Fosen og administrerende direktør i Bekk Consulting, Olav Folkestad.

NTNU ble utropt som vinnerlag til applaus fra juryen og de andre deltakerne. Dette er tredje gang NTNU har gått av med seieren gjennom Oppdragets femårige historie. Juryen forklarte at det som skilte NTNU fra de andre lagene var lagets evne til å tenke helhetlig løsning gjennom gode og gjennomarbeidede tiltak. For seieren mottar NTNU-laget 25 000 kroner, samt 25 000 kroner fra NSB som laget har valgt å donere til Norges Røde Kors sitt prosjekt ”Vann for livet”.

NTNU-laget forklarte konsernsjef Geir Isaksen i NSB at Røde Kors sitt prosjekt ble valgt fordi organisasjonen har vist en evne til å få mest mulig ut av hver bidragskrone.

Vinnerlaget består av Einar Bjering, Maren Omli Flasnes, Erling Laugsand og Maria Tandberg Nygård, alle fjerdeårsstudenter ved Industriell økonomi og teknologiledelse på NTNU.

BEKK ønsker å takke alle studentene for strålende innsats under Oppdraget og NSB for spennende problemstilling og stort engasjement.

Kjære kunde, “mobile first”…

I dag er det mer og mer vanlig å etablere seg i flere kanaler, men ikke alle er helt der enda. Morgan Stanley presenterte for en stund tilbake trender som sier at 91% av mobilbrukerne har mobilen innen 1 meters rekkevidde. Det nye “buzz wordet” er “mobile first”. The Economist presenterer frisk statistikk som “Every 4 seconds a child is born… and 15 mobile phones are sold”. Det er på tide å gjøre noe, ta noen valg.

Men mange forbinder “flerkanaleri” med økt kostnad, og man kvier seg litt. Hva om man prototyper en mobil løsning først, dette er jo raskt og enkelt å få til. I samme slengen kan man brukerteste det man lager for å få svar på om det man tenker fungerer på ordentlig.

Dette er vel dyrt? Egentlig ikke. Det blir en “Lakmustest” før man lager en ekte løsning, noe som er langt billigere enn å prøve å feile med ekte løsning.

Her er en oppskrift for hvordan man skaper en øyenåpner for kunden.

“Weapon of choice”

Axure RP Pro er et kraftig verktøy for prototyping av interaktive webløsninger. Når man skal lage prototyper tilpasset mobile enheter som iPhone og iPad er det noen hensyn du må ta for at prototypen skal fremstå korrekt i nettleseren på mobilen eller nettbrettet ditt.

Axure kan benyttes til å lage alt fra enkle skisser og wireframes til mer avanserte klikkbare og dynamiske prototyper. Verktøyet har et drag-and-drop widgets bibliotek hvor man enten kan benytte standardbibliotekene som følger med fra leverandøren, eller man kan tilpasse og lage egne bibliotek. Bibliotekene gjør at verktøyet er enkelt å bruke og man kan lage omtrent hva som helst, raskt, uten å skrive en eneste linje kode.

Prototypen

Vi valgte å prototype løsningen med en “standard mobil skjermbredde” på 320 pixler.

I prosjektet hvor vi første gang prototypet en mobil løsning, oppdaget vi at prototypen ble svært liten på mobilen når vi la den ut på webserveren. Mobilen vi testet på var en iPhone 4. Alt innhold ble svært lite og det ble presset opp i venstre hjørne som et frimerke slik skjermbildet under lengst til venstre viser.

Dette var verken realistisk eller optimalt i forhold til brukertesten vi hadde planlagt å gjennomføre. Vi prøvde derfor å løse problemet ved å øke størrelse på tekst og på skjermbredden i Axure til 480 pixler. Det ble litt bedre, men fremdeles ikke helt optimalt. Skjermbildet i midten over viser denne justeringen.

Vi fortsatte å eksperimentere til vi fant en mer optimal skjermstørrelse og landet på skjermstørrelsen 768 pixler. Skjermbildet over lengst til høyre illustrerer dette.

Lærdom: Vi hadde brukt lang tid med mye prøving og feiling for å komme fram til et resultat som vi ikke var fornøyde med. Vi hadde nå en prototyp som så grei ut på mobil, men som var håpløs å jobbe med i Axure. Den var håpløs fordi alt var gigantisk stort, man mistet oversikten og den var tung å vedlikeholde.

“Workaround”?

Det måtte da finnes en mer effektiv måte å jobbe på. Selvfølgelig gjorde det det. Et søk på Google viste at vi ikke var de eneste som hadde møtt på disse utfordringene. Litt magisk HTML-kode var alt som skulle til. Når man genererer en prototyp i Axure genereres et stort antall HTML-sider. Ved å inkludere en liten kodesnutt på hver av disse sidene i <head>-taggen ble ting løst av seg selv, helt automagisk. I hovedsak var det tre varianter som dekker det meste.

1: Automatisk skalering

Dersom man ikke vet skjermstørrelsen man utvikler for, eller skal vise prototype på forskjellige enheter, er det hensiktsmessig og benytte en kodesnutt hvor skalering skjer automatisk. Den kan se slik ut:

 <meta name = “viewport” content = ” width=device-width “>

Skjermbildene under viser forskjellen på en prototyp med 320 pixler bredde med og uten kodesnutten i <head>-taggen.

Skjermbildene under viser forskjellen på en prototyp med 480 pixler bredde med og uten kodesnutten i <head>-taggen

Skjermbildene under viser forskjellen på en prototyp med 768 pixler bredde med og uten kodesnutten i <head>-taggen.

2: Overstyring

Ønsker man å overstyre hvordan den mobile enheten skalerer bredden på siden, kan man eksplisitt sette bredden inn i kodesnutten slik:

<meta name = “viewport” content = “width=356″>

3: Begrensninger

Det er også mulig å sette begrensninger med kode slik at brukeren ikke har mulighet til å øke eller minske skjermstørrelsen. Dette kan gjøres på denne måten:

<meta name = “viewport” content = “user-scalable=no, width=device-width”>.

Eksperiment med iPad

Vi valgte samtidig å teste hvordan prototypen oppførte seg på en iPad. Vi testet med skjermbreddene 320, 480 og 768 pixler. Breddene 320 og 480 pixler utnyttet ikke iPad’ens skjermstørrelse særlig godt.  Den beste skjermbredden var på 768 pixler.

Under følger skjermbilder av hva vi så når vi testet med de forskjellige skjermbreddene. Vi testet også her med og uten kode for automatisk skalering i <head>-taggen:

<meta name = “viewport” content = ” width=device-width “>

Med 320 pixler bredde ble det seende slik ut:

Med 480 pixler bredde ble det seende slik ut:

Med 768 pixler bredde ble det seende slik ut:

Oppsummering

Så, var dette nybrottsarbeid? Sikkert ikke, men det gav oss svært nyttige erfaringer. Dette er ikke spesielt komplisert å få til når man har gjort det et par ganger, også var litt gøy også!

Hva har vi lært? Vi vet nå hvordan vi går fram og hvilke verktøy som kan benyttes til å prototype og til å testet mobile webløsninger. Slik vi ser det, men vi kan jo ta feil, så er dette en av de beste måtene å få testet nettopp dette på. Fremtidige prosjekter vil kunne gjennomføres raskt, effektivt og svært realistisk.

Videre vet vi ut i fra eksperimentering med skjermbredder, fontstørrelser og kodesnutter at dersom man skal lage en prototyp som både skal testes på iPhone og iPad bør den lages med en skjermbredde på 768 pixler med kodesnutten for automatisk skalering i <head>-taggen. Skal man kun teste på iPhone fungerer alle skjermbredder så lenge kodesnutten er inkludert.

Oppskriften

1. Lag prototypen i Axure – jobb innenfor “standard mobil skjermbredde” på 320, 480 eller 768 pixler

2. Legg til en av følgende kodesnutter i HTML-filene for prototypen i <head>-tag

Automatisk skalering: 

Dersom man ikke vet skjermstørrelsen man utvikler for, eller skal vise prototype på forskjellige enheter, er det hensiktsmessig og benytte en kodesnutt hvor skalering skjer automatisk. Den vil se slik ut:

<meta name = “viewport” content = ” width=device-width “>

Overstyring: 

Ønsker man å overstyre hvordan den mobile enheten skalerer bredden på siden, kan man eksplisitt sette bredden inn i kodesnutten slik:

<meta name = “viewport” content = “width=356″>

Begrensninger: 

Det er også mulig å sette begrensninger med kode slik at bruker ikke har mulighet til å øke eller minske skjermstørrelsen. Dette kan gjøres på denne måten:

<meta name = “viewport” content = “user-scalable=no, width=device-width”>

3. Legg prototypen ut på en webserver og åpne den på en iPhone eller iPad

Lykke til!

Et reelt oppdrag fra en reell oppdragsgiver

Casekonkurransen ”Oppdraget” arrangeres av Bekk Management Consulting for femte gang i år. Studenter fra de tre mest anerkjente merkantile studiene i Norge  konkurrerer om å gi de beste strategiske rådene til store næringslivsaktører.  Årets oppdragsgiver er NSB.

Gjennomføring og premie

Konkurransen går over to dager og finner sted i Oslo. I dag er første konkurransedag, og studentene har blitt presentert for problemstillingen og caset. De har også fått tilgang til underlagsmateriell og anledning til å intervjue nøkkelpersoner i NSB-konsernet. Noen av Bekk Management Consultings mest erfarne konsulenter er også tilgjengelige for å veilede dem.
 
I morgen skal studentene presentere sine råd og anbefalinger til en jury bestående av NSBs konsernsjef, NSBs konserndirektør for strategi og forretningsutviklingledelse, administrerende direktør i Bekk Consulting og avdelingsleder for Bekk Management Consulting. Laget som imponerer juryen mest får en pengepremie på 25.000 kroner, samt muligheten til å donere tilsvarende beløp til en valgfri veldedig organisasjon.

Trangt nåløye

Prosessen for å bli de heldige som får representere sitt studiested under Oppdraget er ikke rett frem. Lagene har sendt inn søknader med motivasjonsbrev og CV’er. Tre lag ved hver studieinstitusjon ble plukket ut til å være med i en kvalifiseringsrunde. Laget fra hver skole med de beste ideene og den mest overbevisende presentasjonen ble deretter invitert videre til finalen.

Hvem går av med seieren?

Det ligger prestisje i å vinne Oppdraget, og knivingen mellom skolene er stor. I fjorårsutgaven av Oppdraget var Sparebank 1 oppdragsgiver. Da var det NHH som presenterte de beste strategiske rådene, og donerte kr 25.000 til NHH Aid.  Vil NHH klare å holde på seieren? Vil NTNU ta tilbake gullpallen? Eller vil BI utmerke seg som best? Følg med!

“We’ve entered the age of the customer — an era where a focus on customers matters more than any other strategic imperative”

- men hva er kundeorientering egentlig? For å besvare dette spørsmålet mener jeg at vi må se kundeorientering i lys av en større kontekst. Det er dette temaet som belyses i denne bloggposten.

Kundeorientering, kundeverdi og kundeopplevelse er ikke synonymer

Før vi går videre ønsker jeg å forsøke å rydde opp i noen begreper som ofte brukes om hverandre, nemlig: kundeopplevelse, kundeorientering og kundeverdi. Ved å knytte begrepene til virksomheten, kunden og helheten blir det lettere å skille dem (Se Figur 1).

Kundeverdi – realiseres først når en kunde benytter seg av det aktuelle produktet eller tjenesten for å få løst den oppgaven han eller hun prøver å løse (”job to be done”). Det er viktig å skille på en virksomhets verdiforslag og reell kundeverdi. Om en virksomhet klarer å levere reell kundeverdi avgjøres av kundens grad av tilfredshet ved utnyttelse av produktet eller tjenesten for å utføre den ønskede oppgaven.

Kundeorientering – er å innrette organisasjonen, inklusive ledelse, prosesser og kultur, for å effektivt kunne imøtekomme kundenes skiftende behov og preferanser. Kundeorientering er knyttet til de aktivitetene en virksomhet utfører internt, helt fra produksjon og utvikling av varer og tjenester til kundestøtte.

Kundeopplevelse – kan oppsummeres som helheten av kundeorientering og kundeverdi. Det vil si summen av de inntrykk og erfaringer en kunde får i relasjon med en virksomhet i forhold til sine forventninger. Grunnlaget for kundeopplevelse legges ved alle kontakt- og interaksjonspunkter en kunde har med virksomheten (kundereisen), helt fra et behov for å løse en oppgave oppstår og til denne oppgaven er løst. Og inkluderer også opplevd verdi av de produktene og tjenestene som leveres.

Figur 1: Kundeorientering, kundeverdi og kundeopplevelse

Hvorfor har så mange virksomheter nå fokus på å være kundeorientert?

Den primære driveren for utviklingen i retning kundeorientering er akkurat som uttrykket tilsier: kunden. I BEKK har vi identifisert følgende forbrukertrender som påvirker virksomheters behov for å adoptere en kundesentrisk tilnærming til videreutviklingen av deres forretningsmodeller:

Den selvbetjente kunden – dagens kunder rapporterer at tidspresset i hverdagen bare øker og at de trenger nye løsninger for å selv utføre de nødvendige oppgaver ved ledig tid.

Den sosiale kunden – kunden er ikke lenger en selvstendig entitet. Kunder snakker i mye større grad sammen i åpne fora, som ikke kan kontrolleres og sensureres av virksomheter, om sine erfaringer med produkter / tjenester og leverandørene av disse.

Den teknologiske kunden – stadig utvikling og adopsjon av ny teknologi har senket inngangsbarrieren for nye aktører i mange markeder. Dette har medført større utvalg og lavere byttekostnader for kundene, noe som igjen har ført til lavere lojalitet.

Den forlangende kunden – kunden opplever i større grad at de nye aktørene i flere markeder lytter til dem og tilpasser seg deres behov. Dette medfører at den samme forventningen blir gjeldende for etablerte og modne virksomheter.

Kombinasjonen av disse endringene i forbrukeratferd medfører at kundene i større grad tar aktiv stilling til valg av leverandører for de produkter og tjenester som de anskaffer. Dermed blir reell kundeorientering et konkurransefortrinn for å kunne levere på kunders forventning.

Så hva innebærer det å være kundeorientert?

I all hovedsak mener jeg at kundeorientering handler om å invitere kunden til dialog rundt alle aspekter av kundeopplevelsen og ta avgjørelser basert på den innsikten som genereres gjennom dialogen. Dialogen bør dekke både:

• Utvalget og sammensetningen av produkter og tjenester en bedrift tilbyr selv, og i kombinasjon med andre aktører.
• Kundeopplevelsen underveis i anskaffelsen og bruken av produktet eller tjenesten.

Innsikten bør spesielt rettes inn mot å etablere:

• Enkle og brukervennlige fysiske og digitale kontaktpunkter
• En generell serviceinnstilling i alle kontaktpunkter ut mot kunde
• Evne til å omstille seg i henhold til endringer i kundebehov (fremfor en ’push’-mentalitet)
• En organisasjonsstruktur som i større grad er basert på kundesegmenter enn siloorienterte produkt/tjeneste-grupperinger

Min påstand er at kundeorientering er et virkemiddel for oppnå økt kundeverdi og en bedre kundeopplevelse underveis, og dermed må sees i tett sammenheng med dette. Dersom en virksomhet mangler en tydelig målsetning for hva kundeorientering skal bidra til, vil de sjelden lykkes i arbeidet.

Har du et annet syn på kundeorientering? Kommenter gjerne under eller send meg en epost!

Tilbakemeldingen på Twitter har vært overveldende positiv. Selv sitter jeg inne med et litt annet inntrykk av konferansen, men mer om dette til slutt i oppsummeringen.

Må vi ha et mål med samhandlingen?

Enkelte av foredragsholderne var tydelige på at man må ha et mål med samhandlingen. Veldig forenklet innebærer dette å gå strukturert til verks med behovsanalyser som kartlegger målgrupper, bruksscenarioer eller use cases, identifisere KPI’er og ta i bruk analytics for å følge med på om løsningen blir brukt slik vi håper på. Sjekk ut presentasjonen til Rawn Shah for mer informasjon om dette. Andre foredragsholdere, eller “praktikere” som de ble kalt under konferansen, hevdet at dette ikke var like nødvendig. Vi trenger ikke lengre snakke om hvorfor vi gjør dette, men hopp i det og lær underveis.

Hvilken av disse to fremgangsmåtene virksomhetene heller mot, kan ha noe å gjøre med hvor mye erfaring og modenhet de har med sosial programvare og Enterprise 2.0 fra før av. Dersom en er ny innenfor dette, er det kanskje greit å bare hoppe i det for å få i gang samtalene og la ansatte bli vant til å dele og kommunisere med hverandre via et slikt verktøy, mens bedrifter som allerede behersker dette godt ønsker å ta samhandlingen et skritt videre.

Hvor mye governance trenger vi egentlig?

Det ble hevdet at If you don’t have governance – it’s a toy blant en av deltakerne. Hvor mye styring trenger vi egentlig? Svaret er som i mange andre sammenhenger; det kommer ann på.

Ta for eksempel det å opprette et nytt community eller arbeidsområde. Skal ansatte få opprette dette på egen hånd eller er det en moderator som skal ha dette ansvaret? Praksisen blant foredragsholderne var begge deler.

En foredragsholder kunne fortelle at de krevde at ansatte søkte om lov for å få opprettet et nytt community. I søknaden måtte de oppgi hvorfor de trengte dette (mål og KPI), og hvor lenge de hadde behov for det. Foredragsholderen argumenterte med at det var mer frustrerende for brukerne å:

• ikke finne svar på spørsmål
• finne ufullstendige eller utdaterte svar
• finne døde commnunities

I tillegg til å få oversikt og kontroll over det som er av communities, skapte det også en større forpliktelse blant de ansatte til å holde informasjonen oppdatert og riktig.

Folk har vanskeligheter med å endre vanene sine. En god del av gruppene og arbeidsområdene som opprettes på sosiale plattformer er en gjenspeiling av organisasjonsstrukturen eller andre fysiske grupper som ansatte er medlem i. Dette kan være avdelinger, prosjektgrupper, faggrupper og sosiale grupper som de ansatte er med i. Noen av gruppene er åpne for alle, mens andre grupper er skjulte for dem som ikke er medlem. Vær obs på at “sosiale siloer” også kan dannes innad i samme verktøy, og ikke bare mellom ulike sosiale plattformer som ikke snakker sammen.

Ulik grad av modenhet blant organisasjoner

Både deltakere og foredragsholdere som deltok under årets konferanse, hadde ulik grad av erfaring. Enkelte virket ganske fersk på dette området og hadde mange spørsmål som de mer erfarne syns ble for banale og enkle. Fremfor å snakke om “bør vi tillate kommentering på artikler” og “sjefen min blogger“, viste denne gruppen større interesse for:

• Integrere sosiale features inn i eksisterende forretningsprosesser og tradisjonelle intranett
• Governance
• Mobil
• Måling og forbedring

I de aller fleste bedrifter lever sosiale systemer og forretningskritiske prosesser i to vidt forskjellige verdener. Sosiale løsninger er sjeldent integrert med resten av intranettet, og sosiale siloer oppstår rundt omkring i organisasjoner av forskjellige årsaker. Jane McConnell, forfatter av en årlig intranettundersøkelsen “Digital workplace trends 2012” håper vi vil se en bedring på dette området i årene som kommer. Sjekk ut presentasjonen hennes for å se hvilke trender en kan forvente å se på arbeidsplassen i året som kommer.

Finnes det en beste praksis?

Et av trackene under konferansen het “Best-Practices”.  Lyis Suarez som var en av foredragsholderne kom med denne tweeten “#e20s Seriously, best practices need to disappear from E2.0; there aren’t best practices! What works for some won’t work for others“. Denne tweeten spredte seg som ild i tørt gress og ble mye nevnt under de resterende foredragene. Poenget hans var at det finnes gode praksiser, men ingen beste praksis. Hver enkelt organisasjon er forskjellig, har ulik kultur, utfordringer og mål som må adresseres for å få til Enterprise 2.0.

Enterprise 2.0 Summit konferansen har også noe å lære..

For å være helt ærlig, så var det flere av deltakerne som var skuffet over måten konferansen var organisert på, deriblant meg selv. De fleste sesjonene var organisert som paneldebatter hvor to eller flere personer fortalte kort hvem de var og hvordan de har tatt i bruk sosial programvare. Resten av tiden ble brukt på spørsmål fra salen eller moderatoren. Tanken var helt sikkert veldig god, og arrangørene tenkte nok at dette skulle bli en interaktiv opplevelse og skape god dialog mellom publikum og foredragsholdere.

Flere av oss deltakere satt igjen med et annet syn på konferansen og følte at det ikke kom noe “nytt” ut av paneldebattene. Med såpass kort tid til hver enkelt, opplevdes mange av presentasjonene som svært like. Dette var veldig synd for foredragsholderne som kun fikk skrapet litt i overflaten, fremfor å virkelig dele sin erfaring med publikum. Jeg tror derfor konferansen hadde vært bedre tjent med å gi hver foredragsholder lengre tid slik at de hadde fått mulighet til å gå i dybden på det de snakket om.

Dersom du er interessert i presentasjoner fra konferansen, videooppsummeringer, bilder, twitter-feeds og bloggposter finner du det meste på denne siden.

iTouch

App’en som skal lages er et spill, hvor poenget er å taste en gitt tekst feilfritt, raskest mulig. Spillet skal støtte flere samtidige spillere, og alle spillere skal fortløpende se hvordan konkurrenter ligger an underveis, samt status på egen tasting i form av fargekoding av tastet tekst.

Jeg ser for meg en arkitektur der vi kjører JavaScript på server, JavaScript+HTML på klienter, og sanntidsoppdatering av konkurrentstatus over Web Sockets.

Tanken er at på hvert tastetrykk, sender klienten inntastet tekst til serveren for validering. Serveren sender så tilbake et statusobjekt som sier noe om hvorvidt tastet tekst er feil, hvor mye av tekst som gjenstår osv. Det blir så opp til klienten presentere denne statusen til brukeren.

Litt om teknologi

Til Web Sockets-kommunikasjonen skal jeg bruke rammeverket NowJS, som er ganske fascinerende. Det lar deg synkronisere JavaScript-variabler og -funksjoner mellom klient og server, slik at man kan kalle funksjoner på server direkte fra klient, og faktisk også funksjoner definert på klient(er) direkte fra server. NowJS baserer seg på veletablerte SocketIO.

Serverkoden kjører på Node.js, som er blitt en defacto plattform for serverside JavaScript.

Testdrevet utvikling

I JavaScript er det p.t. en rekke testrammeverk tilgjengelig. Jeg har valgt å bruke Jasmine, mest fordi jeg liker BDD-syntaksen, og at man kan benytte rammeverket til å teste både klient- og serverkode. I dag ville jeg nok gått for Buster.JS, men mer om Buster senere.

Man kan fint kjøre Jasmine-tester standalone i en nettleser, men det er fornuftig å benytte seg av en test runner, eksempelvis JS Test Driver. Bloggpost’en til kollegaer Torstein og Børge: ”Getting started with JS and TDD”,  gir en grundig innføring i hvordan Jasmine er i bruk, samt hvordan man integrerer med JS Test Driver.

Det avgjørende her er å få lastet ned riktige biblioteker, lagt disse inn i en fornuftig mappestruktur, og fått satt opp en jsTestDriver.conf-fil til å reflektere denne.  I tillegg kan det være fornuftig å installere “jstdutil”. Dette verktøyet lar deg kjøre kommandoene “jstestdriver” og “jsautotest” fra kommandolinja. Sjekk siden til Christian Johansen for installasjonsbeskrivelse.

Prosjektet mitt benytter altså Jasmine som testrammeverk, og JS Test Driver for å kjøre testene. Når disse tingene er på plass, er man klar til å skrive første test!

Første test

Dette blir litt som å skrive første setningen i en bok, eller i denne bloggposten for den saks skyld. Jeg tenker det enkleste å teste i min kode måtte være mekanismen som validerer inntastet tekst. Jeg ser for meg at vi oppretter en scoringobjekt som tar inn en tekst, og returnerer et statusobjekt som sier noe om hvilke bokstaver i teksten som evt. er feil.

Vi spesifiserer forventet oppførsel i filen spec/scoring.spec.js:

it("should validate text with 2 errors",
function() {
    var typedText = "DeTte Er en test";
 
    expect(scoring.validate).toBeDefined();
 
    var results = scoring.validate(originalText, typedText);
 
    expect(results.errors.length).toEqual(2);
    expect(results.errors).toEqual([2, 6]);
});

og kjører kommandoen ”jstestdriver –tests all –reset”, eller enda bedre ”jsautotest”. Vi får beskjed om å opprette scoring-modulen i namespacet TDD, med funksjonen “validate”. Og etter litt TDD’ing ender vi opp med en mer eller mindre komplett scoring.spec.js  med tilhørende implementasjon scoring.js.

Arkitektur

Før vi går videre med tester, kan vi titte litt på kodearkitektur. I tillegg til scoring-modulen, trenger vi funksjonalitet for å administrere selve spillets gang. La oss gi denne modulen navnet “game”. På klientsiden trenger vi en modul som styrer kommunikasjonen med server og oppdatering av skjermbilder; game_controller.js

Hvis vi skisserer opp systemet, så har vi et avhengighetsbilde som ligner dette:

Vi vet at game benytter NowJS-rammeverket for å formidle sanntidsinformasjon, i tillegg til scoringmodulen for å kalkulere status. Samtidig skal game_controller.js kommunisere med game.js vha. NowJS.

Når man nå skal sette sammen disse bitene, er det viktig å tenke at de skal være løst koblet. Dette kan man få til ved å spesifisere eksterne avhengigheter ved opprettelse av modulene. F.eks., får game.js sprøytet inn en referanse til scoring og NowJS når den blir opprettet, og kode for å opprette et game-objekt blir:

var game = TDD.game.create({
    originalText: "En tekst",
    scoring: TDD.scoring.create(),
    everyone: this.everyone
});

Dette gjør det lett å enhetsteste game.js, da man enkelt kan stubbe/mocke disse avhengighetene.

Mer testing

Nå har det liten hensikt å gå i gjennom all kildekode og tester i teksten her, men vi skal se litt mer på hvordan utvalgt funksjonalitet er implementert og testet.

Når det gjelder game-modulen, skal denne bla. ha funksjonalitet for å

• registrere deltakere
• sette i gang en ny omgang
• distribuere forløpende status til alle deltakere

Hvis vi ser nærmere på det siste punktet, så skal status sendes fortløpende til alle deltakerne i sanntid over Web Sockets vha. NowJS. Web Sockets-kommunikasjonen er fullstendig abstrahert bort av rammeverket, og alt man trenger å gjøre er å legge til funksjoner i det spesielle ”now”-objektet som blir synkronisert mellom server og klient. Rammeverket fungerer slik at man kan adressere server via now-objektet på klienten, samt adressere alle klienter via everyone.now-objektet fra serveren.

Når man vet hvordan dette rammeverket fungerer, er man i stand til å spesifisere testen:

it("should validate text and distribute scores upon validation request",
function() {
    var typedText = "Dette er en";
    var status = {
        "errors": [1],
        "percentage": 98
    };
    spyOn(this.game.scoring, "validate").andReturn(status);
    spyOn(this.everyone.now, 'receiveScores');
 
    this.game.validate(this.everyone.now, typedText);
    expect(this.everyone.now.receiveScores).toHaveBeenCalledWith({
        clientId: "123",
        name: undefined
    },
    status);
});

Her bruker vi spy-egenskapene til Jasmine, til å legge til en forventning om at når man kaller ”validate”-funksjonen på serveren, så skal ”receiveScores”-funksjonen kalles på alle klienter.

Selve this.everyone.now er en stub vi selv spesifiserer:

this.everyone = {
    now: {
        validate: function() {},
        receiveScores: function(clientId, score) {},
        startGame: function() {},
        displayTextToBeTyped: function() {},
        hideStartButton: function() {},
        showStartButton: function() {},
        clearText: function() {},
        gameOver: function() {},
        user: {
            clientId: "123"
        }
    }
};

Igjen, er det bare å implementere spesifikasjonen og kjøre testene:

Firefox 10.0 Mac OS [PASSED] Game.should massage original text
Firefox 10.0 Mac OS [PASSED] Game.should validate text and distribute scores upon validation request
Firefox 10.0 Mac OS [PASSED] Game.should NOT end game when text is errornous
Firefox 10.0 Mac OS [PASSED] Game.should end game when text is complete with no errors
Firefox 10.0 Mac OS [PASSED] Game.should start game on request
Firefox 10.0 Mac OS [PASSED] Validation of text and scoring.should validate typed text
Firefox 10.0 Mac OS [PASSED] Validation of text and scoring.should validate text with 2 errors
Firefox 10.0 Mac OS [PASSED] Validation of text and scoring.should calculate score when typed text is 100% complete
Firefox 10.0 Mac OS [PASSED] Validation of text and scoring.should calculate score when typed text is 0% complete
Firefox 10.0 Mac OS [PASSED] Validation of text and scoring.should calculate score when typed text is incomplete
Total 10 tests (Passed: 10; Fails: 0; Errors: 0) (8.00 ms)
  Firefox 10.0 Mac OS: Run 10 tests (Passed: 10; Fails: 0; Errors 0) (8.00 ms)

Hva med klienten?

Det er like enkelt å teste klientkode som serverkode, selv om man må hanskes med en DOM. Det avgjørende her er å gjøre klientkoden ”unobtrusive” og ikke mikse JavaScript og HTML-markup mer enn nødvendig.

Vi kan begynne med å tenke litt på hvordan markup’en på klienten skal se ut. Da spillet går ut på taste en gitt tekst, trenger vi i hvert fall et editerbart felt, og et element til å presentere tekst som skal tastes. I tillegg kan vi legge til en knapp for å starte en omgang, samt et element for å vise progress bars. Grensesnittet kan f.eks. se slik ut:

med tilhørende HTML:

<!DOCTYPE>
<html>
  <body>
    <div id="wrapper">
      <h1>iTouch</h1>
      <input id="name" type="text" placeholder="Skriv inn navnet ditt her og trykk ENTER"/>
      <button id="startButton">Start ny omgang (vent til alle er klare da)</button>
      <div id="text-to-be-typed"></div>
      <div id="typed-text" contenteditable="true"></div>
    </div>
  </body>
</html>

Med disse antakelsene, kan vi utvikle klientlogikken – test først.

Eksempelvis kan vi spesifisere at spillet skal startes når noen klikker på ”Start ny omgang”-knappen på følgende vis:

it("should do start game when start button is clicked",
function() {
    spyOn(this.game, "startGame");
 
    this.startButton.trigger("click");
 
    expect(this.game.startGame).toHaveBeenCalled();
    expect($(this.startButton).is(':hidden')).toBeTruthy();
});

Denne testen spesifiserer at startGame-funksjonen skal kalles, og at knappen skal skjules.
$(this.startButton) er et jQuery-wrappet element som er definert slik:

this.startButton = $("<button></button>", {
    id: "startButton",
}).appendTo(document);

og sprøytet inn i game_controller-modulens create-funksjon.

Slik kan vi fortsette; ta f.eks. koden som tester at tekst fargelegges korrekt. Ganske avansert GUI-messig, og ganske enkelt å teste da man kan simulere nettleser-eventer, kjøre css-spørringer osv.:

it("should color text upon text validation and update progress bar",
function() {
    var self = this;
    var originalText = "Dette er en test";
    var typedText = "Dette er En";
    var errorIndex = 9;
    var clientId = "123";
 
    spyOn(this.now, "validate").andCallFake(function() {
        self.now.receiveScores({
            clientId: clientId,
            name: "Snorre"
        },
        {
            "errors": [errorIndex],
            "percentage": 95
        })
    });
 
    this.game.now.displayTextToBeTyped(originalText);
 
    this.typedTextElement.text(typedText);
    this.typedTextElement.trigger("keyup");
 
    expect(this.now.validate).toHaveBeenCalled();
    expect($(this.textToBeTypedElement).find(":nth-child(1)").css("color")).toEqual("rgb(0, 128, 0)");
    expect($(this.textToBeTypedElement).find(":nth-child(" + (errorIndex + 1) + ")").css("color")).toEqual("rgb(255, 0, 0)");
    expect($(this.textToBeTypedElement).find(":nth-child(" + (typedText.length + 1) + ")").css("color")).toEqual("rgb(0, 0, 0)");
 
    expect(this.wrapperElement.find("#" + clientId).attr("value")).toEqual(95);
});

Når man lager JavaScript-koden “unobtrusive” (i mangel av et bedre norsk ord), blir man kvitt all spagettikode man ofte ser i $(document).ready(), og sitter igjen med en ryddig index.html.

Hmmm, hvorfor kjører vi alle testene i Firefox?

Inntil nå, har vi kjørt klientestene og servertesten i kontekst av en nettleser via JS Test Driver. Da vi at vet at serverkoden skal kjøre på Node, gir det ikke mening å la ymse nettleser-JavaScript-motorer - og ikke Nodes Google V8-baserte kjøretidsmiljø, tolke koden vår. Vi kan bote på dette ved å kjøre server testene med jasmine-node. Dette er en Node.js-modul, som installeres med npm (som nå bundles med Node-installasjonen). Da kan vi kjøre servertestene våre med:

~/dev/faggruppe/iTouch(git::master):➔ jasmine-node spec/server --verbose
Started
..........
Spec Game
  it should massage original text
  it should validate text and distribute scores upon validation request
  it should NOT end game when text is errornous
  it should end game when text is complete with no errors
  it should start game on request
Spec Validation of text and scoring
  it should validate typed text
  it should validate text with 2 errors
  it should calculate score when typed text is 100% complete
  it should calculate score when typed text is 0% complete
  it should calculate score when typed text is incomplete
Finished in 0.005 seconds
2 tests, 24 assertions, 0 failures

Dette fremprovoserer også det faktum at vi er nødt til å gjøre om scoring.js-modulen til å være Node/CommonJS-kompatibel, da Node krever dette. Dette gjøres ved å legge til disse linjene i scoring:

if (typeof module === 'object') {
    module.exports = TDD.scoring;
}

Man kan da “hente” ut en referanse til scoring-modulen som en vanlig Node-modul slik:

TDD.scoring = require("./src/server/scoring");

Buster

Her kommer vi tilbake til Buster.js. I tillegg til å være et flott testrammeverk på andre måter, gir Buster deg mulighet til å kjøre klient- og servertester med samme test runner. Buster.js er snart ute av beta, blir spennende å sjekke det ut nærmere.

Skru alt sammen

Når all JavaScript-logikken er ferdig implementert, gjenstår konfigurasjon av Node, slik at vi kan begynne å teste spillet. All denne konfigurasjonen gjøres i filen app.js. Her ser vi hvordan vi oppretter et game-objekt, med alle dets avhengigheter.

Her er et artig lite avbrekk i en ellers hektisk prosjekthverdag:

Oppsummering

Å komme fra en typisk hverdag der jeg skriver “mvn clean install” altfor mange ganger i løpet av en dag, er det utrolig frigjørende å se hvor raskt disse JavaScript-testene kjører. Når man først kommer inn i det, er JavaScript en fornøyelse å jobbe med, spesielt med tanke på egenskapene ved språket. TDD i JavaScript er definitivt ikke vanskelig, og det er like greit å lære seg teknikkene først som sist.

On a side note:

Magnar Sveen snakker om zombietdd-prosjektet sitt i morgen på Framsia at CiA 2012 – Responsive, realtime and Zombies! Meetup’en omhandler forøvrig Web Sockets og Node.js, så det er ikke helt urelatert til det som blir tatt opp her!

Den skoleflinke definisjonen

Det skulle ikke være nødvendig å si for mye om viktigheten av tydelige målsetninger og en tydelig strategi for å nå sine mål. Vi kjenner viktigheten av å prioritere satsningsområder, og alle som en gang har bitt over for mye vet at for mye bredde ender opp i ingenting – masser av ingenting.

Likevel – når det kommer til innovasjon virker det som noe har gått tapt i hukommelsen. Det er lett å bli arrestert når en forsøker å konkretisere: “Innovasjon for dette selskapet er…” og man kommer sjelden veldig mye lenger før noen påpeker at innovasjon er både inkrementelle forbedringer, radikale innovasjoner og disruptive nyskapninger, eller at man må huske Doblin, som sier at innovasjon kan og bør romme forretningsmodeller, produkter og tjenester, prosesser, merkevarer, kundeopplevelser også videre…

Vurder denne definisjonen: “Innovasjon er store og små endringer i produkter, prosesser, forretningsmodeller og adferd som skaper verdi for kunden og selskapet selv”. Ganske dekkende? Hvor verdifull er den imidlertid? Selv mener jeg at den er lite verd, fordi den ikke utelukker noen ting – den er ikke et middel for å lede oss på rett vei. Men den er skoleflink!

Diskuter bredt, iverksett smalt

Innovasjonsutfordringen bør absolutt angripes fra mange kanter – i et innledende strategiarbeid. Ta gjerne en titt på Alexander Osterwalders business model canvas eller på Robert Wolcotts innovasjonsradar – dette er verktøy som hjelper selskaper med å skape et bredt perspektiv på innovasjonsspillerommet.

Problemet oppstår når selskaper ikke kommer seg ut av diskusjonen, og ender med en definisjon og en strategi like bred som da de begynte fordi de har fått formaninger om å ikke begrense kreativiteten og innspillene – også gaper de over for mye. Imidlertid, flere og flere ser at innovasjonsledelse, som i all ledelse, handler om fokus. Booz & Co “avslører” vinnertrikset innenfor innovasjon som evnen til å velge noen få retninger. Robert Wolcott er enda mer spesifikk, da han konkluderer med at vinnerne velger mellom 2 og 5 strategiske retninger i hans 12-armede innovasjonsradar.

De som forsker på vinnere har talt: Smalt vinner over bredt når det gjelder gjennomføring.

Innovasjon i klartekst

Så la oss si at et selskap ser en fremtid der kunden kjøper varer gjennom flere kanaler, og velger leverandør basert på evnen til å yte service. Så selskapet etablerer en strategi basert på etablering i nye kanaler, og på økt kundeopplevelse i selskapets kontaktpunkter. Min hypotese er at et slikt selskap vil ha en langt lettere jobb når de skal etablere måleparametere, prosesser og påkrevet kompetanse for å skape nye og bedre løsninger, enn et selskap som skal skape “store og små endringer i produkter, prosesser, forretningsmodeller og adferd…” også videre.
Den skotske filosofen Thomas Reid sa en gang: “There is no greater impediment to the advancement of knowledge than the ambiguity of words”. Så vær tydelig med hva innovasjon er for ditt selskap, avgrens fokuset til noen veldig få satsningsområder, og kall en spade for en spade. Veien er vanskelig nok i seg selv – la oss sette målet klart for øyet.

Hva er HashDOS?

En angriper kan, ved hjelp av relativt få ressurser, få CPUene på dine webservere til å gå i taket. Et eksempel fra slidesettet viser f.eks. at man en java Tomcat kjørede på en i7 core kan utmattes med en ~6 kbits/s linje.

Hva er det egentlig som skjer?

Når en webapplikasjon mottar en POST-request, vil den, i de fleste rammeverk, lage en eller annen form for hashtabell eller hashmap som inneholder de parameterene som finnes i POST-requesten. En slik struktur benytter en hashfunksjon (derav navnet) for å fordele nøkler med tilhørende verdier på et begrenset antall med bøtter. Dette gjør det effektivt å slå opp verdier senere, fordi man ikke trenger å lete gjennom alle nøkler, men kan hashe nøkkelen, finne riktig bøtte, og se om nøkkelen med tilhørende verdi finnes i bøtta.

Men siden det er et begrenset antall bøtter, vil det naturligvis finnes flere mulige nøkler som hasher til samme bøtte (to strenger kan f.eks. gi samme hash). For å håndtere dette benyttes det gjerne en lenket liste i hver bøtte. Når man skal søke i denne bøtta, øker søketiden dermed lineært med antall nøkler i bøtta. Det samme gjelder innsettinger i tabellen. Før man kan sette inn et nytt element, må man sjekke om nøkkelen finnes der fra før. Og det er nettopp her problemet ligger.

En angriper sender f.eks. inn n=200,000 parametere som alle har navn med samme hash-kode. Når applikasjonen skal bygge opp hashtabellen, ender den da opp med å gjøre n^2 sammenligninger som i eksempelet blir 40,000,000,000 sammenligninger. Som man skjønner, kan dette bli svært kostbart CPU-messig.

Det er ikke spesielt vanskelig å finne slike strenger som gir samme hash. Hash-funksjonene som brukes i de forskjellige rammeverkene er ofte slik at der string A og B har samme hash, så vil AB (A konkatenert med B) få samme hash som BA, AA og BB. Dermed er det lett å lage permutasjoner som alle gir samme hash-verdi.

Hvordan beskytter jeg meg?

For flere rammeverkt, deriblant ASP.NET, leverer leverandøren av rammeverket en patch. Mange av patchene som har kommet baserer seg på at hash-funksjonen gjøres mindre forutsigbar. Hash-funksjonene har inntill nå, gitt samme hash-verdi for samme string hver gang man kjørte programmet. I noen rammeverk vil det nå være slik at en hash-funksjon alltid ville gi samme verdi for samme string innenfor samme prosess, men starter man applikasjonen på ny, endres hashfunksjonen slik at to verdier som før hadde samme hash, nå vil gi forskjellig hash. Dermed gjør man det nærmest umulig for en angriper å finne verdier som gir samme hash.

En annen mulighet som f.eks. PHP og Jetty benytter seg av, er å begrense hvor mange POST-parametere man kan ha. Man kan jo ganske greit argumentere for at man ikke trenger å kunne ha 200,000 POST parameter. De fleste klarer seg nok med under 100.

Dersom rammeverket man bruker enda ikke er patchet, kan man også begrense tillatt størrelse på POST-requester. For å sende 200,000 parametere må man kunne sende en POST-request på ca. 2 MB. Siden kompleksiteten er n^2, kan man ved å redusere til f.eks. 200KB, redusere fra 40,000,000,000 til 400,000,000. Og en lavere grense blir resultatet enda bedre. Men det beste er selvsagt om problemet håndteres i rammeverket eller webserveren.

Ressurser

• Opptak av foredraget fra CCC
• Slides

Dette virker da litt risky…

I det forrige innlegget mitt så vi på tre ulike måter å implementere emosjonell design der de mer forsiktige kan ta vekk litt av riskfølelsen. Da vi snakket om emosjonell design gjennom personlighet, var vi også litt inne på det at dette kunne føles litt risky. Nå skal vi ta tyren ved hornene!

Å vise personlighet i design, som ellers i verden, innebærer alltid en liten risiko. Noen personligheter klikker rett og slett ikke. Dette kan høres veldig skummelt ut, og man kan fort bli fristet til å “safe” med å bare være generelt likandes og ikke så mye mer. Men tenk på hvordan det er i det vanlige liv; er det ikke bedre at folk knytter en følelse til deg, enn at du holder deg flat og nøytral og alle sier “ Nei, hun Nina er vel ok hun.. ”?

Det vil alltid være noen personligheter som ikke passer sammen, men dette kan faktisk være en ganske god reality-check. Dersom du har utviklet en personlighet som speiler brandet og systemet godt, og det er noen kunder som så ikke liker personligheten vår, har vi kanskje spart oss for et potensielt trøbblete kundeforhold i fremtiden? Og når vi på motsatt side ser alle dem som nå virkelig digger oss fordi vi har en bra personlighet, heller enn å bare si vi er ok – da er det vel win-win og en liten risk å ta?

Hva annet enn personlighet er utfordrende?

I tillegg til at personlighetene må passe, må man av og til overkomme skepsis, latskap og likegyldighet.

Det første er rett og slett å få brukerne til å stole på deg. Som nevnt i et tidligere innlegg, er det da viktig at overflaten gir et tillitsvekkende ytre. Det er faktisk slik at når “panseret” tydelig har fått ettertanke og er gjennomarbeidet, da får man følelsen av at det som ligger bak sannsynligvis også er samvittighetsfullt og skikkelig gjort, og det er mindre grunn til å tro at du vil møte noe som ikke henger på greip senere i prosessen.

Folk er egentlig ikke så late, de bare leter etter minste motstands vei. Her kan man coache folk mot målet gjennom å gjøre prosessen nærmest til et spill ved å gi insentiver og premier som kommer nærmere og nærmere jo lenger brukeren kommer i prosessen. For eksempel bruker Dropbox en premie på 250MB lagringsplass som brukerne gradvis ser komme nærmere etterhvert som han bygger opp sin konto med bilder osv.

Likegyldighet skjer når innholdet i siden er irrelevant eller dårlig presentert. Her er det rett og slett slik at

 ”Great content delivered in an emotionally engaging manner is like kryptonite for apathy!”

Og når noe går galt…

Enten man bruker emosjonell design eller ikke, vil systemer alltid feile. En eller annen gang har du downtime eller menneskelig feil eller lignende, og dette liker selvsagt ikke brukerne.

Men! Når du har en positiv emosjonell forbindelse med brukerne, da er det mye mer sannsynlig at de tilgir, og fortsetter å bruke og elske systemet. Når en feil skjer, vil responsen til brukerne være tuftet på hvordan forholdet deres til systemet allerede er. Dersom man allerede har et godt emosjonelt forhold og så takler feil med å kommunisere rolig og ærlig, og kommer med oppdateringer (“Vi jobber så hardt vi kan!”), forsikringer og beklagelser, kan man langt på vei roe negative følelser og vri disse tilbake til det positive.

 ”Emotional deisgn is your insurance to maintain audience trust when things aren’t going your way”

Dette var siste episode i seks-dels føljetongen om emosjonell design. Jeg håper det har vært interessant lesing og at du har fått lyst til å snuse på temaet!

Ok, så da vet du en del om emosjonell design, og kanskje du er fristet til å prøve det. Kanskje har du til og med overtalt oppdragsgiver om at dette er veien å gå, og nå trenger du en plan for hvor dypt i bassenget dere skal plumpe. I boka forslår Aarron tre veier å gå, tilpasset hvor modig og moden man føler seg på området.

Dypenden

Som du kanskje har forstått, er den modige veien å gå å redesigne hele systemet og brandet med emosjonell design og fokus på en personlighet i høysetet. Dette er nok det som kan gi mest uttelling, og det finnes mange gode eksempler på dem som har gjort det meget bra her.

Et tidligere nevnt eksemple er MailChimp, der personligheten til systemet virkelig klikket med brukerne og man opplevde brukere som virkelig digget personligheten til systemet og ble sterke ambassadører for tjenesten, noe utallige positive Twitter-meldinger vitnet om.

I tillegg kan vi nevne Tapbots, som er nyttige, små iPhone apper som for eksempel konverterer mellom ulike måleenheter eller hjelper deg å følge med på kroppsvekten din. Ganske kjedelige oppgaver, men gjennom å ha gitt sine interface personligheter, føler brukerne at de har en “partner in crime”. Personlighetene er inspirert av Pixarkarakteren WALL.E, og når brukerne omtaler tapbots bruker de begreper som “love”, “adore” osv.

Det er også verdt å merke seg Betabrand.com, en nettbutikk som selger klær, men de velger å se seg selv som et online magasin som tilfeldigvis selger klær. Betabrand skriver om sine produkter på en utrolig morsom måte, og har et stort galleri av “amatør superhelter” som utsetter klærne for dagligdagse prøvelser. Det finnes en morsom historie bak hvert produkt og mange av brukerne, også noen som intielt var skeptiske, har blitt hard-core ambassadører for produktene!

I det små

Det går også an å begynne litt i det små. Du kan ta noen mindre, kanskje midlertidige stunt og følg emed på hvordan brukerne reagerer. Kanskje det kan være så enkelt som å vise mer personlighet i det du desverre må vise en feilmelding? Eller kanskje du rundt påske kan kjøre en påskeegg-jakt rundt på sidene dine?

CoffeCup Software kjørte en påskeeggjakt, der påskeeggene man skulle finne bare var synlige på enkelte tider av døgnet og etter så og så mange sidevisninger fra brukeren. Ved å samle påskeegg kunne man vinne cash og software-premier, og sidene opplevde voldsom trafikk. I tillegg gikk salget opp, og antall følgere på Facebook og Twitter like så.

Den gyldne middelvei

I mitt forrige innlegg snakket vi om MailChimp som virkelig hadde gått linja ut med emosjonell design. De var imidlertid ikke så selvsikre i begynnelsen, og innførte derfor et valg som kunne “slå av personligheten” til siten og få en “flat” versjon (de kalte denne “party pooper mode”!). Dette ga dem en trygghet og de følte seg sikre på at de nå ikke ville støte bort noen, men da de etter en stund gjorde noen analyser, viste det seg at bare 0,007% av brukerne ville være i party pooper mode!

Selv om det i MailChimps tilfelle viste seg at den “flate” løsningen nesten ikke var vits å ha, kan dette kanskje være en smart og trygg vei å gå for mange andre.

Da har vi vært gjennom “Hvordan?” og nå sitter sikkert noen og lurer på om alt er bare gull og grønne skoger, eller om det finnes noen risikoer her også. Og selvfølgelig gjør det det – de skal vi se på i mitt neste og siste innlegg i føljetongen!

Are you working on unmaintainable JavaScript code? Are you afraid to make changes to your 5000+ lines long JS file? If so, you’ve probably not written tests or done TDD. Fear not! Read on, and we will show you how to get started with writing tests and setting up the needed tools. We will show by example how to create a small, yet complex, JS web application using TDD.

JavaScript is becoming increasingly popular for developing full-fledged applications – both server and client side. Looking at the current trend of how JS is used, we can see that it’s being used for business critical applications and large-scale applications. With all this popularity and extensive use, we are under the impression that the testing and quality focus is lagging behind.

After reading this blog post, you will know how to get started with JS TDD using tools and frameworks we consider easy to use and relatively mature. If you already know why you should test your JS code, feel free to skip the background.

If you want to take a closer look at the example application, feel free to check out the entire project from GitHub @ http://github.com/bekk/jstdd.

Background

JavaScript has received a popularity boost from browser vendor’s quest to write the fastest JS engine, as well as the popular programming language node.js. In addition, jQuery has simplified the way we interact with the DOM and smooths over annoying browser differences – making JS more accessible for everyday developers. Focus have been primarily on producing functionality, and not on testing and good design/clean code. We believe that one reason is the lack of standardized or commonly available testing tools and frameworks. Another reason might be that traditionally JS have been written by UI and UX developers, who’s focus have been primarily on functionality – not on Clean Code and testability.

JS and all other dynamic programming languages is in dire need of tests since there is no compile-time checking. Tests can be used to ensure that the application behaves as expected, and gives developers confidence to make changes to existing code. Despite the obvious need for testing, many developers skimp on writing tests when developing large JS applications. All the advantages of TDD that applies for other programming languages, also applies for JS. Who does not want testable, maintainable, readable, well-designed, modular and working code? It’s well established that TDD has positive effects on code quality (read the chapter on TDD by Robert C. Martin in The Clean Coder).

Other popular programming languages like Java and C# have mature and well-documented testing-tools. At the time of writing, JS has several testing frameworks available, but only a handful mature. Looking at the options, no one really stands out as a clear choice. To make things worse, getting started with JavaScript TDD can be challenging. There are so many ways of going about setting up a complete test-environment for JS. We have looked into this and had some experience with what works and what doesn’t.

The runner

JsTestDriver is (as it’s name implies) a tool that let you run your JS tests. You can run your tests directly from your favorite IDE (at least in theory) to get into your TDD rhythm. It runs from the command line and even on your continuous integration server. In our examples we’ll be running it from the command line.

A quote from their home site says it all: “The goal of JS Test Driver is to make JavaScript unit test development as seamless as and easy as Java unit tests.”

JsTestDriver supports testing in different browsers through capturing browsers as a slave machines. It includes it’s own limited assertion framework, but also supports add-ons, which opens for a wide range of third party assertion frameworks. We will be using Jasmine BDD through an adapter.

As with everything else, there is room for improvement. JsTestDriver’s configuration can sometimes be too simple, and advanced users may feel limited. In our simple example it works great, but expect some issues when scaling up. As a note, we did not get the IDE integration in IntelliJ IDEA to work properly.

Recently Buster.js was released as beta, and is worth checking out as an alternative to JsTestDriver.

The framework

We’ve picked out Jasmine because it is a mature (compared to most other frameworks) and a popular testing framework for JS. It features BDD syntax, which gives clear and readable tests with functionality in focus. It does not depend on any other framework and does not require a DOM. It can be run in the browser, through JsTestDriver or through node.js. It is well documented and is easy to get started with.

There are a few things to consider. They don’t separate between mocks, stubs and spies. All of that is packed into what Jasmine describes as a spy. The bundled matchers are good, but few. To get readable tests, it’s often necessary to write custom matchers to match the domain language. Still, we consider this one of the few viable options for doing TDD in JS.

Installing, setting up and using Jasmine is easy, and will not be detailed here. We’re using Jasmine through JsTestDriver, and have configured it thereafter.

QUnit was considered as an option, but it’s syntax did not help us achieve as readable and clear tests as Jasmine. It’s simplicity makes it very attractive and useful for beginners, but more advanced users will want more.

Demo application

As stated in the introduction, we’ll make a little application that does an “I feel lucky” search from Flickr. One of the choices we made was to have a minimal setup. No jQuery and third-party libraries in the production code, with the intention to reduce complexity and make the example more transparent as to how things work.

Pre-requisites

If you want to use the same setup as us, we recommend doing the following.
(Or you can check out the entire project from GitHub @ http://github.com/bekk/jstdd).

Download these libraries:

• https://github.com/ibolmo/jasmine-jstd-adapter (version 1.1.1)
• https://github.com/pivotal/jasmine (version 1.0.1)
• http://code.google.com/p/js-test-driver/ (version 1.3.2)

Create the following folder structure:

.
├── lib/ # 3rd party libs lies here
│   ├── jasmine.js
│   ├── jasmine-jstd-adapter/
│   └── JsTestDriver-1.3.2.jar
├── spec/ # test/specs lies here
├── src/  # application source lies here
├── server.sh # Starts a JSTD server (symlinked)
├── test.sh # Runs the test (symlinked)
└── jsTestDriver.conf # JSTD configuration for our project

server.sh and test.sh are just shortcuts to scripts bundled with js-test-driver.

Configure jsTestDriver.conf to match your setup.

Getting familiar with the framework

We started off with a simple test to get familiar with the syntax and to verify that everything is set up correctly. Consider it a warm-up exercise.

describe("Jasmine", function() {
    it("makes testing JavaScript awesome!", function() {
        expect(true).toBeTruthy();
    });
});

Running it

Running it the first time might seem a bit overly hard, but once you’re set up it’s easy to run the tests. Before you start the server, you need to write a little config file. Take a look at ours if you need an example.
Starting the server can seem a bit tedious, but we found a shell-script that starts the server. All we had to do was modify the path to suit our project structure (see server.sh). Running it is just a matter of typing ./server and seconds later the server is up and running.

Example output from a test run:

Running all tests
Chrome: Runner reset.
....
Total 1 tests (Passed: 1; Fails: 0; Errors: 0) (1.00 ms)
Chrome 12.0.742.112 Mac OS: Run 4 tests (Passed: 1; Fails: 0; Errors 0) (1.00 ms)

Next task is capturing browsers. We spun up browsers on each others computers and went to http://[my address]:9876/capture and the browser became a slave. Excellent! We used Safari, Firefox and Chrome to test. Make sure to keep the browser running while testing.

Captured browser

JsTestDriver supports distributed test-running, but that is not something we will explore in this blog post. Now all that is left is telling the server to ask the browsers to run the tests. With the scripts, it’s just a matter of typing ./test in the shell and the tests are run.

The flow for starting the first time is the following:
1. Start server
2. Capture browsers
3. Run tests

After than you just type ./test each time you want to run the tests.

Working on LuckyFlickr

Start with the tests

We decided to start with writing tests to verify output on the result page. The simplest possible test we could think of was to test for a message when no result was found.

Next, we added a new test to verify that if a result were received, the parser would pick the first result and display the image on the result page. Since we were doing unit testing we didn’t want to go all the way to Flickr when we ran the test, so we created a simple stub that returned some JSON data on the expected flickr format so we could run the test in isolation. The specs for the parser read:

• “outputting result”
• “should not output an image when there are no results”
• “should output the image from the result”

Note: When reading these specs, read them like “Outputting result should not output an image when there are no results”.

When pondering what to do next, we figured we could create a test for the component that would fetch data from flickr. Since we wanted to get out data from another site, we decided to use JSONP to overcome the cross-site problem. We also wanted the component to send the flickr request asynchronously, so we had to write a test that would handle that. To fix this we created setup code to temporarily replace the default XMLHttpRequest implementation in JS with our own. That way we could control what the response would be. We decided to let it respond with the same JSON stub as in the parser test.

• “when querying flickr”
• “should create a global function that handles the JSON-P callback”
• “should do a search and call the callback function”

The last step was to create some tests to make sure the GUI was displaying the result in the right container in the result page. On this step, we saw that some of the components came together, and introduced the need for mocking. We mocked the result given by the “fetcher”. Doing so, we’re not dependent on a connection to flickr.com. We created 2 tests for this. The first asserts that the result from flickr is displayed in the result container, and the second one asserts that “Loading” is displayed while it is fetching data from flickr.

The result

Since our focus was unit testing, our implementation ended out with three separate “units” that each did one important thing. We have a “fetcher” that goes out and fetches the result from Flickr, a “result parser” that knows how to parse the JSON data structure from Flickr and finally the component that enables the user to do a search. No enterprisy patterns, no unneeded complexity, no silver bullets. Just enough to make things work. Also, the design emerged from writing the tests first.

Our experiences

We experienced a couple of notable challenges when doing TDD in JS. Doing TDD in it self is not a problem. Some challenges appear when doing browser-specific things with JS. Such as asynchronous callbacks, handling the DOM and the AJAX browser API.

The DOM is an issue. When not using jQuery, there are a lot of quirks that can mess up tests in specific browsers. Also, doing DOM-operations without jQuery results in a lot of ugly code that affects readability.

Testing AJAX without support from the test framework is problematic, and is why several tools exist and mitigate this (Sinon.js, Mockjax, etc.). Before we changed to JSONP, we wanted to do this with no extra support, and ended up with an extremely simplified version of what the mentioned tools provide. But for most people it would be simpler to use an existing tool to help you do AJAX-testing.

But all these things mentioned above are relatively easy to overcome and the upside of being able to write tests for your JS code easily outweighs the small quirks you may experience. And you won’t regret spending time on writing tests when your code base is expanding and you need to make a change.

Give me more!

Sinon.JS – Standalone test spies, stubs and mocks for JavaScript. Works with any unit testing framework.
QUnit – alternative to Jasmine. Developed by the jQuery-team
Cucumber.JS – early stages. Could be good.
Buster.js – a new test framework (currently in beta) from Christan Johansen (the man behind Sinon.js)

I disse dager hvor server-side er ut og klient-side er kult har det dukket opp mange avanserte JavaScript-rammeverk som flytter kompleksitet fra serveren til nettleseren. Backbone, Knockout og JavaScriptMVC er alle gode eksempler som kan brukes til å lage komplekse applikasjoner, uten antikvariske operasjoner som lasting av hele sider eller rendering av HTML på serveren. I denne nye verden tilbyr serveren et REST-API, og all koden for å bruke dette API-et er Javascript som kjøres av brukerens nettleser.

Vi vil gjerne presentere én metode for å strukturere komplekse JS-applikasjoner, sammen med to flotte biblioteker: Sammy og Handlebars.

Sammy er ikke like kjent eller kraftig som de tidligere nevnte rammeverkene, men er likevel svært godt til sitt bruksområde og fortjener en vurdering ved valg av rammeverk. Hovedsakelig brukes Sammy til routing, hvor en URL besvares av en JS-funksjon, og til å rendre HTML-en som skal vises på den aktuelle siden. Biblioteket er i seg selv svært lite, og delegerer det meste av funksjonalitet til sin strålende plugin-arkitektur. I dag er Sammy tungt avhengig av jQuery.

Handlebars har den siste tiden fått masse oppmerksomhet, og bygger på det allerede kjente template-rammeverket Mustache. Handlebars brukes til å sammenflette data og HTML på en enklere og strukturert måte. Hensikten er å skille HTML- og DOM-maipulasjon fra resten av applikasjonen, og Handlebars inneholder mange hjelpemetoder som gjør dette ganske elegant.

Model-View-Controller (MVC) er en type arkitektur som kan brukes til komplekse klient-side JS applikasjoner. I vår (svært) løse definisjon av MVC får vi følgende struktur:

• Datamodellene håndterer entiteter og kommunikasjon med serveren.
• View-modellene står for oppførselen og strukturen til HTML-elementene.
• Controllerene knytter datamodeller og view-modeller sammen mot spesifikke URL-er.

God struktur er vanskelig i komplekse JS-applikasjoner. Språket gir store muligheter og få begrensninger, og ingen forslag til hvordan strukturen bør være. Det hele kan fort bli uoversiktelig hvis man ikke baserer seg på velkjent struktur, som for eksempel MVC. I denne teksten bygger vi deler av en slik applikasjon.

I eksempelet har serveren en liste personer, som vi ønsker å få tak i, instansiere som modeller og vise en liste av i nettleseren. All kode i denne bloggposten kommer fra en minimal eksempelapplikasjon du finner på Github. Last den gjerne ned og prøv resultatet i din nettleser. Koden kan også brukes som refferanse om det er noe som er uklart i teksten.

Datamodeller og API-kall

Datamodellene tar seg av kommunikasjon med serveren via Ajax-baserte HTTP-kall mot et REST-API. Det er mange måter dette kan gjøres på, det finnes ingen fasit, men her kommer ett eksempel. Her har vi kodet modellene selv, men merk at på samme måte som Handlebars tar seg av templates, og Sammy tar seg av controller-ene, kunne vi brukt et tredje bibliotek til å ta seg av datamodellene. Men la oss lage noe selv.

Noen vil kanskje reagere på at datamodeller her potensielt defineres to steder — hos klienten og på serveren — men det er viktig å huske at disse modellene har lite felles funksjonalitet. Datamodellene på klientsiden er der utelukkende for å hjelpe view-modellene, ved å abstrahere bort funksjonalitet for kommunikasjon med serveren, formatering av modelldata og lignende.

Det er to oppgaver som kan skilles i datamodellene:

• Selve datamodellene som instansieres og har metoder for å jobbe med hver entitet,
• og statiske metoder for hver klasse av modeller, som blant annet gjør API-kall.

Vi har valgt å bruke standard prorotype-baserte JS objekter. I dette eksempelet lager vi en modell kalt “person”, lagt under namespacet “myapp.models”.

/* prototype for alle data-modeller. */
myapp.model.datamodel = {};
 
/* Metode for å instansiere en modell. */
myapp.model.create = function(prototype, properties) {
    return myapp.model.merge(Object.create(prototype), properties);
};
 
/* Prototype for person-instanser. */
myapp.model.person = myapp.model.create(myapp.model.datamodel, {
    name: function() {
        return this.firstname + " " + this.lastname;
    }
});
 
/* Instansiering. */
var person = myapp.model.create(myapp.model.person, { 
    firstname: “Foo”, 
    lastname: “Bar” 
});

Som sagt kan API-kall tilhørende hver modell skilles ut i egne moduler. Dette er flott når man skal teste systemet, og hjelper holde kompleksiteten nede. Her er et enkelt eksempel på API-kall for modellen:

/* Metode for å lage mange instanser. */
myapp.model.createAll = function(prototype, propertiesList) {
    return propertiesList.map(function(properties) {
        return myapp.model.create(prototype, properties);
    });
};
 
/* Metoder for å gjøre kall mot person-API. */
myapp.api.person = {
    all: function(callback) {
        /* Hent listen over alle personer fra serveren. */
        $.ajax({ 
	    success: function(serverdata) {
                callback(myapp.model.createAll(
                    myapp.models.person, 
                    serverdata));
            },
            ........
        });
    }
};
 
/* Bruk */
myapp.api.person.all(function(people) {
/* “people” er her et array av person-instanser. */
});

Dette kan virke som mye kode for enkle operasjoner, men etterhvert som applikasjonen blir større er det fint å ha alt som har med serverkommunikasjon og datamodeller skilt fra resten av applikasjonen. La oss nå se hvordan disse datamodellene kan kobles sammen med rendring av HTML.

View-modeller med Handlebars

View-modellene knytter data sammen med HTML. Disse modellene holder på dataene som trengs for å vise en side, representert av datamodellene. I tillegg legger view-modellene på oppførsel, animasjoner og hendelser på siden-, eller delen av siden de representerer. Dette kan for eksempel være ting som skal skje når brukeren klikker på en link, flytter på elementer eller vil lagre eller endre data.

Poenget med å bruke view-modeller er å abstrahere bort alt som omhandler hvordan HTML skal produseres og oppføre seg. På samme måte som datamodellene innkapsulerer alt som har med entiteter og server-kall, tar view-modellene seg av all JS-kode som manipulerer DOM-en direkte. Målet er som alltid å ende opp med veldefinerte og klart avskillte moduler med hver sine oppgaver. Her er et eksempel på en view-modell:

myapp.view.people = myapp.model.create(myapp.model.viewmodel, {
    compile: function() {
        return { people: this.people };
    },
    apply: function() {
        $("#people li").click(function(event) {
            alert($(this).text() + " clicked!");
        });
    }
});

En view-modell jobber i to faser og trenger to forskjellige metoder. For det første har vi compile-metoden, som returnerer alle variabler som skal kunne brukes fra template-filen. Deretter har vi apply-metoden, som kalles etter at template filen har blitt renderet.

Den første metoden gjør altså klar variabler som skal brukes, mens den andre tar seg av all DOM-manipuilasjon etter at HTML-en er rendret. Apply-metodene til view-modellene er altså de eneste stedene i applikasjonen JS-kode jobber direkte med HTML-elementer, noe som gjør det hele svært ryddig. Se eksempelapplikasjonen på GitHub [g] for mer av koden som jobber med view-modeller.

View-modellen jobber med en eller flere template-filer, som spesifiserer strukturen på markup-en til den aktuelle siden. Her er et eksempel på en slik template-fil:

<div id="content">
{{ >search }}
    <ul id="people">
    {{ #each people }}
        <li>{{ name }}</li>
    {{ /each }}
    </ul>
</div>

I Handlebars bruker man Handlebar Expressions til å hente ut objekter ved å skrive {{ objektnavn }}, eller {{{ objektnavn }}} når man ønsker å un-escape. people er definert av view-modellen og brukes direkte i template-filen. name er definert av data-modellen for person-entiteten, som også brukes direkte i dette templatet.

I templaten har vi også en partial komponent, kalt search. Partials vil bli brukt der man ønsker å dele opp templates og lage gjenbrukbare deler som kan brukes på tvers av andre templates. Partial-templaten vil også ha direkte tilgang til view-modellen og dens innhold, men vil som oftest tilhøre en egen view-modell.

I tillegg til å kunne hente ut objekter og kjøre funksjoner, kan man bruke såkalte Block Expressions. Block Expressions gjør det mulig å kjøre Block Helpers som er hjelpefunksjoner for å eksempelvis gjøre operasjoner med lister og sjekke verdier med if/else spørringer. Handlebars kommer med ett sett innebygde helpers, men man kan også lage sine egne om dette skulle være nødvendig.

Her er et eksempel på en Block Helper, som kjører en loop inntil et visst maksimalt antall ganger:

/* Definering av en egen hjelpemetode kalt “until”. */
Handlebars.registerHelper('until', function(context, block) {
    var max = block.hash.max;
    var ret = "";
    for (var i = 0, j = context.length; i < j; i++) {
        if (i >= max) { return ret; }
        ret = ret + block(context[i]);
    }
    return ret;
});

/* Bruk av denne hjelpemetoden i en template-fil. */
{{ #until persons max="3" }}
    {{ name }}
{{ /until }}

En annen interessant mulighet man har i Handlebars er å gjøre kall mot parent-objektet til det objektet man jobber med. Her er et eksempel hvor vi bruker notasjonen “../” til å aksessere en variabel som tilhører parent-objektet til det vi looper gjennom:

/* Variabel definert i view-modellen. */
this.family = { surname: “I skogen”, members: [
    { name: “Hans”, age: “90” },
    { name: “Grete”, age: “100” },
    { name: “Ulven”, age: “120” },
]};

/* Bruk av variabelen i template-filen. */
{{ #each family.members }}
    {{ name }} {{ ../surname }}
{{ /each }}

Dette er selvfølgelig bare noen få av muligheten man har med Handlebars, men de viser hvordan komplekse templates kan spesifiseres i template-filer som jobber direkte mot en view-modell. Dette sørger for praktisk innkapsulering av alt som dreier seg om HTML og DOM-elementer i applikasjonen.

La oss nå se hvordan det hele kobles sammen ved hjelp av controller-ene og Sammy.

Controllere med Sammy

Controller-ene er selve limet som holder applikasjonen sammen. Disse beskriver hva som skal skje når en bruker besøker en URL. Controlleren bruker datamodellene til å hente data som trengs på den aktuelle siden, og rendrer HTML ved hjelp av de tidligere nevnte view-modellene og deres representative template filer. Vi trenger både routing og template-rendring, altså er dette en perfekt oppgave for Sammy.

Vi ønsker å bruke Sammy-spesifikk kode utelukkende i controller-ene, og ikke i andre deler av applikasjonen. På denne måten vil minst mulig av applikasjonen bli avhengig av dette rammeverket, i tilfelle man skulle ønske bytte det ut på et senere tidspunkt. I tillegg blir applikasjonen enklere å teste, spesielt på enhetsnivå, da vi ikke trenger å bry oss om Sammy annet enn i controller-ene.

Her er en kodebit som kjøres når brukeren gjør en GET-request mot URL-en “/#people”:

/* Jobb på HTML-elementet “#page”. */
$.sammy("#page", function() {
    /* Bruk Handlebars-plugin. */
    this.use('Handlebars', 'hb');
 
    /* Start routes. */
    myapp.route.person(this);
}).run();
 
 
/* Route for person-listen. */
myapp.route.person = function(app) {
    /* Definer en route. */
    app.get("", function(context) {
        /* Gjør et kall mot serveren. */
        myapp.api.person.all(function(people) {
 
            /* Definer hvilken template-filer som trengs. */
            var template = "template/person-list.hb";
            var partials = { searchbox: "template/shared/searchbox.hb" };
 
            /* Instansierer view-modellene */
            var search = myapp.model.create(myapp.view.shared.searchbox);
            var list = myapp.model.create(myapp.view.people, { people: people });
 
            /* Bytt ut innholdet i "#page" med ny HTML. */
            context.renderAll(template, partials, [list, search]);
        });
    });
};

Den første kodebiten sier at Sammy skal jobbe på HTML-elementet med ID-en “page”, definert i den initsielle HTML-filen. Del to tar tak i URL-en ved hjelp av en route-funksjon. En route består av et verb, en sti, og en callback-funksjon. Verbet er et av de velkjente HTTP-metodene POST, PUT, GET eller DELETE. Stien kan enten være en vanlig URL, eller en hash-basert URL som i dette eksempelet.

Hver Sammy-rute tar inn et context-objekt som inneholder mye informasjon om tilstanden til applikasjonen. Dette objektet inneholder også mange nyttige hjelpefunksjoner. For at applikasjonen skal holde seg modulær er det viktig å kunn bruke dette objektet i controllerene. Hvis context-objektet blir med til datamodellene eller view-modellene, vil disse bli avhengig av Sammy-logikk, som igjen vil komplisere testing og vedlikehold.

Det meste skjer i context.renderAll-metoden. Denne rendrer et template, et sett partials og en samling view-modeller ved hjelp av Sammy’s context-render-metode:

context.helpers({
    /* En hjelpefunksjon for å rendre sider med mange view-modeller. */
    renderAll: function(tmpl, partials, models) {
       	var context = this;
       	this.render(tmpl, myapp.model.compileAll(models), function(html) {
            context.swap(html);
            myapp.model.applyAll(models);
        }, partials);
    }
});

context.render tar først inn stien til template-filen man vil bruke. Det neste argumentet er dataene man vil bruke til å rendre template-filen, i vårt tilfelle representert dataene av en view-modell. Denne view-modellen vil da være tilgjengelig for template-filen når den rendres av Handlebars-pluginen til Sammy.

Callback-argumentet context.swap tar imot ferdig rendret HTML, og bytter ut hva som allerede er i elementet som jobbes på (“#page”) med den nye HTML-en.

Det siste argumentet, “partials”, er et objekt som kan inneholde flere deler som hovedtemplaten er avhengig av, for eksempel en topp, meny og bunn. Render-metoden cacher template-filene, uten å laste de på nytt hver gang, slik at operasjonen blir kjappere andre gang denne kalles.

En fin måte å organisere disse Sammy-routene på er å ha én JS-fil pr side (hvis det gir mening i applikasjonens sidestruktur, vel å merke). Metoden $.sammy kan brukes på tvers av filer uten problemer. Hver side får ofte flere routes for forskjellige operasjoner, for eksempel:

/* settings.js: routes for én side. */
 
$.sammy(“#page”, function() {
    // Vise innstillinger
    this.get(“#/settings/profile”,  function(context) { … });
    this.get(“#/settings/friends”,  function(context) { … });
 
    // Lagre innstillinger
    this.put(“#/settings/profile”,  function(context) { … });
    this.post(“#/settings/friends”, function(context) { … });
});

Med controllerene på plass er applikasjonens struktur komplett:

• Datamodellene innkapsulerer alt som beskriver entiteter og serverkall.
• View-modellene innkapsulerer alt som beskriver HTML-en og oppførselen til DOM-elementer, og kobler dette med datamodellene.
• Controllerene tar det hele i bruk og bruker datamodellene og view-modellene til å rendre flott HTML når brukerne besøker forskjellige URL-er.

Oppsummering

Selv om en struktur som den presentert her kan virke overdrevet i starten av et prosjekt, vil det hjelpe etterhvert som kompleksiteten og kodemengden øker. Det viktigste er å starte med et godt utgangspunkt, og deretter kontinuerlig forbedre og utvikle arkitekturen.

Det er selvfølgeilig ulemper med tunge JS-applikasjoner. De setter store krav til nettleserens JS-motor, og til utviklernes testing på tvers av mange nettlesere. Språkets frie natur gjør det enkelt å skrive lite vedlikeholdbar kode, og det er sjelden klare svar på hvordan noe bør gjøres.

Til syvende å sist krever komplekse JS-applikasjoner mye av disiplin innen struktur og testing, men denne friheten betyr også at JS-programmering er veldig spennende. Med gode biblioteker som Sammy og Handlebars blir det hele enda morsommere.

Dette handler om mine subjektive erfaringer med forskjellene fra tiden med SVN. Jeg kommer ikke til å skrive noe om hvordan vi migrerte til Git eller om tekniske forskjeller på de to versjonskontrollsystemene. Dette finnes det masse gode ressurser på allerede. Dette innlegget kommer til å handle om de forskjellene som faktisk har vært med på å endre min hverdag.

Branch og merge

Det er umulig å komme utenom den uovertrufne støtten for branching og merging i Git. Med Subversion opplevde jeg branching og den påfølgende mergingen som tungvint og vanskelig. Med Git er det lett å lage og håndtere flere branches. Github gjør veldig enkelt å holde oversikt over status på hver enkelt branch ved hjelp av verktøy som for eksempel network graph og branch view.

Dette har for oss vist seg å være en god støtte for å øke hyppigheten for produksjonssettinger. Når det er lett å håndtere branches er det enkelt å holde master-branchen helt ren, slik at vi kan produksjonssette når vi ønsker.

READMEs

En av de tingene som – kanskje overraskende – har vist seg å være mest nyttig er READMEs på Github. Github støtter en rekke markup-språk. Selv om det i utgangspunktet er en veldig enkel sak å skrive dokumentasjon for alle prosjektene og legge det et sted, har det vist seg svært kraftig at dette er så nært koden som mulig – og så synlig som mulig. Her har Github sin løsning vært utmerket for oss! Her legger vi instruksjoner om hvordan man kommer i gang med utvikling fra scratch (nye folk inn på prosjektet), tips til utvikling, informasjon om hvordan man deployer og så videre. At dokumentasjonen er så kodenær og synlig oppfordrer også til scripting og automatisering, som det har blitt mer og mer av.

Sosial versjonskontroll

Github kaller seg sosial versjonskontroll. Selv om dette er noe som opprinnelig ble lagd med fokus på open source prosjekter, gir det muligheter som også passer utmerker til vanlig enterprise-utvikling. Å ha en side man kan besøke for å se statusen til kildekontrollen veldig nyttig.

Sosiale features på GitHub som vi benytter oss hyppig av:

• Diskutere commits – helt ned på enkeltlinjer om ønskelig.
• Følge med på ulike branches (hvor mange commits de er bak/foran master).
• Sende pull requests på ferdige feature branches

Pris

Github har en hyggelig prismodell – hvertfall hvis man sammenlikner med andre enterprisy tilbydere av versjonskontroll. Standardprisene deres gjelder ved hosting av data i skyen (hos Rackspace). Hvorvidt det er aktuelt å hoste koden sin hos en tredjepart varierer naturligvis fra prosjekt til prosjekt. Dersom cloud hosting ikke er aktuelt finnes det et enterprise-alternativ.

Snill læringskurve

Git er et avansert versjonskontrollsystem. Likevel har det i utgangspunktet en veldig snill læringskurve. De første månedene brukte jeg Git omtrent akkurat som jeg tidligere brukte SVN. Først ved behov og lyst begynte jeg gradvis å ta i bruk mer og mer avansert funksjonalitet – funksjonalitet som jeg nå bruker omtrent hver dag.

Tilgjengelighet

Siden Github er hostet i skyen kan man få tak i det fra hvor som helst i verden, uten å måtte bruke VPN. De har også veldig god oppetid: vi har opplevd nedetid én gang på godt over ett år. Det er veldig sannsynlig at et internt hostet versjonskontrollsystem vil ha adskillig mye mer nedetid i løpet av et år enn det Github vil ha. Sikkerhet og tilgangskontroll er ivaretatt ved bruk av SSH-nøkler for hver enkelt utvikler.

Konklusjon

Git og Github har hos oss vært en revolusjon som ikke har føltes som en revolusjon. Ved å være litt bedre på så godt som alle aspekter av versjonskontroll har det fjernet masse små irritasjoner hos oss utviklere – og dermed git oss mulighet til å fokusere mer på kundens krav. I tillegg har det store antallet nyttige småting i kombinasjonen Git og Github gitt oss de verktøyene vi trenger til å endre prosessen vår til å møte kundens behov bedre.

Når man tar med i vurderingen av kostnaden for å gå over er ganske lav, er dette egentlig en no brainer for meg: Jeg anbefaler Git!

Personlighet

Ved siden av å kunne bruke følelser som psykologiske fellesnevnere i emosjonell design (som vi snakket om i mitt forrige innlegg), kan vi jobbe med den emosjonelle komponenten som ligger oppå følelsene, nemlig personlighet.

I denne sammenheng er det møtet mellom personligheter som er interessant. Personligheten til brukerne er selvsagt til stede, så den komponenten det må jobbes med her er systemets personlighet. Dette kan kanskje høres litt rart ut, men husk at det er først i møtet mellom personligheter at følelser oppstår! I boka snakker derfor Aarron om å jobbe med å gi systemet personlighet.

Alle kjenner til hvordan personligheter opererer i det vanlige liv, og alle vet at disse kan være uforutsigbare, og at av og til er det full krasj! Det kan derfor føles litt risky å introdusere noe som er så åpent for tolkning i våre dyrebare systemer, og det er lett å forstå hvorfor mange kan stille seg litt skeptisk til dette.

Nå har det seg imidlertid slik at vi kanskje bare må innse at tiden har kommet. Tidligere, da nettet var ungt og fortsatt i stor grad ble oppfattet som (og i noen tilfeller var!) useriøst og farlig, føltes det viktig å virke streit og veldig seriøs i sin fremstilling. Mange siter ble veldig like, og man kunne i stor grad skjule seg bak en generisk, flat og forretningsmessig fasade. Dette henger i stor grad igjen selv om nettet har modnet, og gjør at nettet er fylt med et mye flatere persongalleri enn verden ellers! Tiden har kommet for å skille seg ut i mengden ved å vise litt mer av seg selv!

Å finne sin personlighet

Men hva skal så denne personligheten være? Man skal selvsagt ikke finne opp en personlighet til systemet sitt sånn helt uten videre – falske personligheter fungerer sjelden! Det man velger å vise av personlighet må være ekte, og virkelig være det systemet står for og det bedriften bak virkelig er. Mange kjenner sikkert til teknikken “personas”. Personas brukes vanligvis til å beskrive personligheten til brukere i systemets målgruppe, slik at man kan bruke dette som en styrepinne for å treffe målgruppen. Aarron foreslår at man drar dette enda lengre, og faktisk utvikler en persona for systemet eller til og med brandet. Det er rett og slett “mannen i maskinen” som skal beskrives, slik at brukerne møter nettopp dette; en mann heller enn en maskin. Først når dette er på plass kan de gode møtene mellom brukerpersonligheter og systempersonligheter oppstå!

Aarron tilbyr en mal for hvordan å jobbe frem en brand- eller sitepersona på sine nettsider.

Suksess!

Det finnes en mengde gode eksempler på systemer som har fått til treffende og ekte personligheter. Et eksempel er MailChimp, et mailprogram som fremstår som lekent og hjelpsomt, og som til og med går så langt som å ha en liten maskot-ape. Apen har en solid kropp og et sympatisk fjes – noe som hinter om et solid system med en vennlig overflate!

For de systemene som bruker litt humor i sin personlighet er dette “omvendt-håkkisveis” prinsippet viktig; vi kan godt ha party in the front, men vi må vise at vi mener business in the back! Apen blander seg nemlig aldri inn i arbeidsflyen, og kommer aldri med tips eller kommentarer til selve arbeidet (som var der den beryktede bindersen til Microsoft i sin tid feilet – han kom med irrelevante og forstyrrende tips…), men han endrer seg stadig og sier morsomme og forfriskende ting. Folk får rett og slett lyst å arbeide seg gjennom for å se hva han gjør!

Nå er det slett ikke meningen at alle skal ha en maskot og bruke humor for alle penga, og i noen tilfeller fungerer ikke humor og lettbenthet i det hele tatt, f.eks ville det vært vanskelig å se for seg hos Kirkens Nødhjelp. Da er varme og personlige historier ofte en god vei å gå. Poenget er uansett at gjennom å gi noe med mer personlighet og ektehet, er man et steg på veien mot å knytte emosjonelle bånd.

Da har du fått mye bakgrunn for hvordan emosjonell design kan anvendes. I tillegg er det alltid kjekt med noen helt konkrete praktiske veier å gå, og disse kommer i mitt neste innlegg.

For 25 år siden ble det utgitt en bok Peopleware – Productive Projects and Teams. Dette er en klassiker, og jeg synes det er sunt å minnes på de prinsippene som den omhandler. I tillegg til hardware og software er det en viktig del som vi kan kalle peopleware. Det er det menneskelige aspektet ved utvikling. Det er bare én måte å få frem de systemene og løsningen som vi utvikler, og det er gjennom mennesker. Dette er smarte, høyt utdannede mennesker med en driv for teknologi.

Disse folkene er katalysatoren for det vi lager. Hvordan oppnår vi da de beste resultatene? Svaret er ikke kynisk eller maskinelt. Peopleware er fortsatt utrolig relevant, og det er ikke til å kimse av etter hele 25 år. Årsaken er at folk fortsatt er folk. De har de samme behovene, motivasjonene og relasjonene. Det er lett å fokusere på hvor raskt vår bransje utvikler seg teknologisk. Men folkene bak, de som gjør det hele mulig, de som skaper selve verdien. De er like menneskelige som før.

Det er en utbredt illusjon i databransjen, at det vi jobber med er high tech. Vi jobber med avanserte, kompliserte tekniske systemer. Det er teknologi på sitt ypperste. Datamaskiner er noe av det mest imponerende og kraftige mennesker har utviklet. Og nøkkelen til å lykkes er å forstå og benytte den mest avanserte, den høyeste, teknologien. Når de teknologiske grensene pushes går vår verden fremover, og fremskritt og konkurransefortrinn blir mulig.

Mennesker vs. teknologi

Men tilfellet er at databransjen ikke er high tech. Dette er ikke rakettforskning. De fleste systemer har ikke behov for eller berører avansert datavitenskap eller teknologi. Mange prosjekter er avarter av create, read, update og delete, eller handler om å vise data som allerede finnes på en ny måte til brukeren. Det er som oftest ingen fysikk eller matematikk bak systemene vi lager. Selv om hardwaren er avansert og datamaskinen fundamentalt kompleks, så kan vi ikke lure oss selv til å tro at vi er i high-tech-bransjen. Det er fristende å tenke slik. At å løse de tekniske, teoretiske problemene er nøkkelen til suksess. Det er på en måte en “enkel” løsning. Det er mer håndterbart å finne den optimale algoritmen enn å forstå hvorfor Arne ikke jobber produktivt. Men suksessfulle prosjekter og effektive team handler ikke om teknologi. Det handler ofte om menneskene bak. Vår bransje er teknisk, men det er ikke teknologien som skaper suksess. Om det bare hadde vært så enkelt.

Har du noen gang vært på et dream team? Fått følelsen av at dere sammen jobber nær optimalt og har høy produktivitet? Har du noen gang jobbet i det motsatte? En samling mennesker som ikke får utrettet store ting. Et team på papiret, men ikke i praksis? Resultatetene fra et dream team er ikke basert på teknologien de bruker, men heller av dynamikken mellom menneskene i teamet. De utfyller hverandre. De kommuniserer godt. De vet hvor de har hverandre, og hvordan de kan bruke hverandre. Teamet er støpt. De har høy suksess med sine prosjekter, og grunnen er at de kan bruke all innsats på å løse prosjektets problemer og klientens behov, i stedet for andre ikke-verdiskapende utfordringer.

Hva kjennetegner et slikt team? Et tegn er at de er kvalitetsorienterte. De vet hvilke kvalitative ting som gjør prosjektet vellykket, og de fokuserer på dem. Kvalitet i datasystemer ses ofte på som en kostnad, og noe man oppnår ved å ofre andre ting, som for eksempel penger og tid. Men the dream team oppnår suksess med kvalitet som en drivfaktor. Kvaliteten gir to verdier: Man unngår bortkastet tid på å “rydde opp” om man gjør det ordentlig fra første stund. Og kvalitet er en motivasjonsfaktor i seg selv.

I stedet for å “cut the corners” vil the dream team gjøre det ordentlig. Det man oppnår med dette er en jevn fremgang uten skitne overraskelser som for eksempel at man ikke har noen enhetstester, eller at man har hardkodete verdier som senere ønskes å endres. Progresjonen blir kanskje lavere enn et forhastet team, men den er forutsigbar uten teknisk gjeld og andre overraskelser.

Jeg ble engang forsøkt rekruttert av et større IT-selskap. Jeg spurte dem rett ut: Hvorfor bør jeg jobbe hos dere? Svaret deres var: Fordi vi er den beste aktøren i markedet og har de mest fornøyde kundene. Vi er de beste og mest suksessfulle. Rekruttererne tenkte nok at dette var imponerende, men jeg tenkte “what’s in it for me?”. Folk har lyst til å realisere seg seg selv, og sine behov. Ikke bedriftens behov og finansielle målsetninger. Heldigvis finnes det en synergi her. Ved å oppfylle arbeidernes behov, kan bedriftens mål nås. Kvalitet er en motivasjon og drivkraft i seg selv. Forteller du et team at kvaliteten i det de gjør ikke er så viktig, så vil selvrespekten og moralen følge derhen. Mennesker har en iboende kraft til å realisere seg selv, å lage ting som er så bra som de har kraft til å få til.

Et slikt støpt team utvikler elitiske holdninger. Det er et godt tegn. De er stolte av seg selv, og har tro i sine evner. Slike team vil også tendere mot å være selvledende. Siden motivasjonen er høy, og de ønsker å nå organisasjonens mål vil de selv ta grep for å få dette til. Fra et manager-perspektiv er dette en drømmesituasjon; og bør være et mål i seg selv.

Miljø

Mennesker er i høy grad et produkt av omgivelsene rundt en. Disse omgivelsene kan løfte en frem og få det beste ut av en, eller de kan stikke kjepper i hjulene. Har du noen gang jobbet på kontoret sent på kvelden eller i helgen? Kontorlandskapet er tomt, det er stille og øde. Der sitter du, på din sedvanlige plass. Har du lagt merke til at man ofte er høyst effektiv i dette miljøet? Man har kanskje satt av en liste med oppgaver man må få ferdig. Det ble ikke plass til dem i den vanlige arbeidstiden, så man setter opp en økt på kvelden eller i helgen. Man pløyer gjennom de oppgavene. Man går hjem med følelsen av at i dag var jeg effektiv. God progresjon i dag, godt jeg tok meg tid til den ekstra økten.

En viktig årsak er nok rett og slett at du fikk være i fred. Det er en tendens for åpne kontorlandskap i vår bransje. Fra åtte om morgenen til fire om ettermiddagen er det folk rundt deg. Disse folkene skaper støy, uro og avbrytelser. På grunn av den innebygde forsinkelsen vårt sinn tar for å komme ordentlig i gang med en mental oppgave kan disse forstyrrelsene hindre produktiviteten. Vi jobber i en kunnskapsbransje, og tankekraft er essensen i produktene vi skaper. God konsentrasjon er avgjørende, men til dels ikke mulig i et støyende og kollektivt kontorlandskap. Det er en kontradiksjon egentlig; vi har høy utdannelse, jobber med kompliserte abstrakte konsepter som ikke har noen fysisk manifestasjon. Men allikevel er en lukkbar kontordør en luksus bedriften ikke tar seg råd til.

I Peopleware foretok de en programmeringsøvelse hvor et spesifisert system skulle implementeres. De gruppene som gjorde det godt ble sammenlignet med de som ikke nådde milepælene på samme tid:

Resultatene er kanskje ikke overraskende. De som gjorde det best hadde avlukkede kontorer som de delte med 0, 1 eller 2 andre. De svakeste jobbet i åpne områder. Mange kan nok si seg enige i at kollektive rom hemmer konsentrasjonen. Men har du kvantifisert hvor mye plassbesparelsene koster i produktivitet?

Management

Hva er jobben til en manager? Han driver ikke direkte med verdiskapningen. Det er det utviklerne som gjør. Det er de som løser kunden og brukernes problemer. En av managerens viktigste oppgaver er å få de under ham til å gjøre en god jobb. Den beste jobben gitt deres forutsetninger. Det finnes mange ulike synspunkter på hvordan man får dette til. En viktig management-oppgave er å sette deadlines. Slike frister kan brukes som et virkemiddel i seg selv. Parkinsons “lov” sier at arbeid utvider seg selv til å fylle tiden det er satt av til. Vi kjenner alle godt til rasjonalen bak. Om man har press på seg skynder man seg. Om noe ikke haster kan man ta seg bedre tid. Dette leder til en logikk som er mye brukt i management. Tighte, kanskje urealistiske deadlines virker motiverende og øker produktiviteten. Bare pass på å ikke avslør at deadlinen er kunstig tidlig!

I praksis fungerer det ikke. Utviklerens produktivitet og arbeidsmetode er avhengig av deadlines, men en urealistisk deadline kan være høyst demoraliserende. En undersøkelse ble foretatt blant flere titalls prosjekter. Det ble sett på hvem som utførte tidsestimatetene, og hvor høy produktiviteten var for hver oppgave. Hvor utvikleren gjorde estimatet var produktiviteten 8. Dette er så klart et relativt tall. Hvor utviklerens sjef gjorde estimatet var produktiviteten 6.6. Haha, tenker man så klart. Dumme manageren tror han vet bedre enn gutta på gulvet!

Men i tilfeller hvor en ekstern system-analytiker gjorde estimeringen var produktiveten enda høyere med 9.5. Hva er grunnen til dette? Det kan være at systemanalytikeren er en profesjonell estimerer med god erfaring fra tilsvarende implementasjoner. At hans estimater er nærmere det egentlige innsatsbehovet kan være motiverende i seg selv. Realistiske deadlines er gir dermed høyst produktivitet. Et interessant resultat oppsto i oppgaver hvor intet estimat i det hele tatt var gitt. Her var produktiviteten 12, og dermed høyest. Dette kontradikterer helt tydelig Parkinsons lov, og setter i tvil dens effektivetet som management-verktøy.

Dream manager

Et dream team krever en dream manager. Men hva kjennetegner en slik manager? Det er kanskje ikke hva en tradisjonelt forbinder med ledelse. Et dream team har en iboende egenskap å gjøre det godt, og en dream manager enabler dette. Det er ikke så lett å måle en managers evne til å enable sitt team, men det er allikevel en av det viktigste egenskapene. Det motsatte ville vært defensivt management. En defensiv manager stoler ikke på sine “undersåtter”. Han er opptatt av sitt eget bilde, og forsvarer det mot eventuelle utfordringer. Han ser på seg selv om drivkraften bak teamets progresjon og suksess, og underminerer deres evne til fatte de riktige avgjørelsene selv.

Et godt motivert og fungerende team er en drivkraft i seg selv. En god manager vil utnytte disse kreftene og enable og løfte teamet. Hindre i veien elimineres, og byråkratiske eller organisatoriske problemer løses. Manageren er oljen i teamets maskineri. Disse egenskapene er ikke alltid like lette å observere på overflaten. Kanskje manageren virker overflødig på grunn av teamets selvstendighet og effektivitet. Men nettopp dette kan være resultatet av en managers dedikerte arbeid bak kulissene.

Folkevare

Data og systemutvikling er tilsynelatende en teknologisk, komputasjonell bransje. Men faktum er at det er menneskene som jobber med dette som er drivkraften. De teknologiske utfordringene er interessante og nyttige som et minstemål. Men løsningene bunner alltid ut i mennesker som jobber sammen. Mennesker med sine behov, sine mål og sine motivasjoner. Disse endrer seg ikke i samme takt som prosessorkraft og minnestørrelse.

Det er ikke like lett å analysere sosiologien bak utvikling som det er å drøfte teknologien, men x-faktoren i systemutvikling er menneskene bak. Mens maskinvare og programvare skyter fremover, er det fortsatt de samme type mennesker som jobber med disse tingene. Kun ved å forstå disse temaene kan man få det meste ut av teknologien og lykkes i sine prosjekter.

// Returns "null" if no partner
Person partner = customer.getPartner();
 
// Potensial NullPointerException
doStuff(partner.getName());
 
// Safe use - ugly code
if(partner != null) {
  doStuff(partner.getName());
}

De fleste kodebaser på Java-prosjekter har mange null-sjekker, og de får gjerne fler etter at man oppdager NullPointerException på steder man ikke hadde forutsett. Dette gjør koden stygg og uoversiktlig. Og enda verre blir det hvis man har flere nøstede objekter:

if(partner != null) {
  Name partnerName = partner.getName();
  if(partnerName != null) {
    String partnerFirstName = partnerName.getFirstName();
    if(partnerFirstName != null) {
      doStuff(partnerFirstName.toUpperCase());
    }
  }
}

Hvordan kan man løse dette problemet i Scala? Jo, ved å ta i bruk Option-typen. Den har enten verdien None hvis det ikke er noen verdi, eller Some[T] hvis det er noen verdi. Selve verdien kan hentes på en rekke forskjellige måter. Det som er fint er at None også er et objekt med metoder, slik at man slipper exceptions om man ikke eksplisitt sjekker om verdien er satt.

Hvis vi selv skriver koden kan vi la verdien returnere en Option av typen i stedet for null/typen direkte:

// Returns Option[Person] instead of Person directly
val partner = customer.getPartner
 
if(!partner.isEmpty) {
  doStuff(partner.get.getName)
}

Dette så jo ikke spesielt kult ut. Hvis vi fortsatt må sjekke om verdien er satt kan vi jo like godt sjekke for null? Men siden vi har masse funksjonelle godsaker tilgjengelig trenger vi ikke gjøre det. Metoden foreach vil bare la være å gjøre noe om verdien er None:

partner.foreach(doStuff(_.getName))

Det nøstede eksempelet løses fint med metoden map:

partner.map(_.getName).map(_.getFirstName).foreach(doStuff(_.toUpperCase))

Eller tilsvarende med for-comprehension om man synes det blir rotete med alle metodene (mindre-enn tegnet blir dessverre feil her):

for {
  name <- partner.getName
  firstName <- name.getFirstName
  upperCaseName <- firstName.toUpperCase
} {
  doStuff(upperCaseName)
}

Option løser altså problemet med null-sjekker. En siste liten detalj er at Some(null) er None. Det vil si at om du bruker et eksisterende Java-API som kan returnere null kan du bare pakke rundt med Some og slippe null-sjekk uansett. For eksempel om man henter parametre fra en http request, metoden getOrElse lar deg sette en default verdi hvis verdien er None:

// Typical http request in Java-servlet-api
val name = Some(request.getParameter("name")).getOrElse("empty-name")

Konklusjonen er at bruken av null som default/ukjent verdi i Java utgjør et problem for de som skal benytte koden. Dersom man programmerer i Scala kan man bruke Option for å vise ta verdien ikke nødvendigvis er satt, i tillegg til at man tillater funksjonell bruk uten eksplisitt sjekking av verdien.

Må man skrive kode i Java kan det være lurt å ta i bruk en egen klasse for å representere slike verdier. For eksempel en av disse implementasjonene:

• https://github.com/npryce/maybe-java
• http://blog.tmorris.net/maybe-in-java/

Hva er innovasjon?

Vi i BEKK har en enkel formel for innovasjon. Vi kaller det ”Innovasjon = Kreativitet x Gjennomføringsevne”. Med kreativitet mener vi evnen til å identifisere og beskrive de riktige idéene. Idéer som kan komme fra interne og eksterne gjennom fysiske og digitale arenaer. I gjennomføringsevne ligger evnen til å velge, videreutvikle og realisere de beste ideene. Gjennomføring innebærer blant annet å etablere prosesser, sammensetning av tverrfaglige team, utarbeidelse av implementeringsplan og definering av evalueringskriterier.

Det finnes utallige andre definisjoner av innovasjon der ute, noe som i sum er med på å skape flere myter om innovasjon.

Myter om innovasjon

Myte 1: Innovasjon handler bare om å generere idéer.

Vår erfaring: Som vår definisjon over viser må idéer bli realisert for at de skal kunne kalles innovasjoner. Innovasjon handler derfor i like stor grad om å velge ut og realisere idéene som å generere de. I tillegg er det ikke tilstrekkelig å generere idéer – idéene må være riktige i forhold til virksomhetens fokus og strategi for å gi reell verdi. Vår erfaring er at en omforent innovasjonsstrategi på tvers av organisasjonen er med på å skape en felles forståelse for hvorfor, på hvilke områder og hvordan virksomheten skal jobbe med innovasjon.

Myte 2: Vellykket innovasjonsarbeid dreier seg bare om å samle organisasjonens idéer.

Vår erfaring: Å la de ansatte komme med, og utforske, egne idéer er først å fremst viktig for å få tilgang til de gode og riktige idéer. Dette fordi de ansatte ser og forstår virksomhetens problemstillinger og kontekst . I tillegg bidrar denne involveringen til å skape engasjement og deltagelse fra de ansatte. Vi ser allikevel at i de tilfellene hvor det er et mål å oppnå større/mer radikale innovasjoner er det ofte hensiktsmessig å kombinere den medarbeiderdrevne innovasjonen med en mer fokusert FoU- organisasjon og -prosess.

Myte 3: Innovasjon handler bare om å endre et helt marked gjennom radikale og grensesprengende produkter.

Vår erfaring: Innovasjon kan handle om å gjøre noe helt nytt, men kan også handle om å gjøre noe man allerede gjør bedre for å øke lønnsomheten og/eller kvalitet uten å endre markedet. De fleste virksomheter fokuserer på prosess- og produktinnovasjon, men statistikk og vår erfaring tilsier at det er innovasjon av forretningsmodellen og kundeopplevelse som gir størst verdi. Forståelse for at ulike typer innovasjon krever ulike typer prosesser, verktøy og kompetanse er essensielt for å lykkes.

Myte 4: Gjennomføring av innovasjonsprosjekter gjøres internt i det enkelte forretningsområde eller avdeling

Vår erfaring: Mange inkrementelle forbedringer kan gjøres av det enkelte forretningsområde eller avdeling, men for større prosjekter er det viktig med en tverrfaglig teamsammensetning. Et viktig moment ved gjennomføring av innovasjonsprosjekter er å først identifisere hvilken kompetanse og ferdigheter som trengs for å kunne realisere idéen. Deretter settes et team sammen med personer som innehar disse egenskapene på tvers av organisasjonen. I mange tilfeller er det også hensiktsmessig å inkludere ekstern kompetanse og perspektiver. Dette dedikerte teamet må underveis i gjennomføringen samarbeide tett med aktuelle forretningsområder og ressurser, som vil få ansvaret for gevinstrealiseringen.

Myte 5: Innovasjon innebærer stor risiko og mye ressurser.

Vår erfaring: Mange virksomheter bruker i dag betydelige ressurser på innovasjonsinitiativ uten å se de store resultatene. En utfordring for mange av disse virksomhetene er at prosjekter ikke fanges opp og stoppes tidlig, om det viser seg at satsningen er feilslått. Effektivt innovasjonsarbeid innebærer å jobbe strukturert og iterativt. Risikoen knyttet til innovasjon er liten om man ved å bruke litt – lærer mye i hvert enkelt prosjekt. Det å gjøre hyppige evaluering underveis basert på trender og utvikling (fremtid) og ikke bare data (fortid), vil det være mulig å omdisponere midlene til innovasjonsinitiativ på tvers av prosjekter. Det må samtidig påpekes at det å bruke litt – lære mye ikke betyr det samme som å gjøre noe halvhjertet, og balansen mellom de to er krevende å finne.

Dette var et utvalg av de mytene vi møter når vi jobber med våre kunder. Kanskje kjenner du deg igjen i disse, eller kanskje har du andre myter som kan diskuteres?

Hvordan å få til emosjonell design er selvsagt et godt spørsmål, og her har Aarron dessverre ikke noen ut-av-boksen fasit. (Som alle andre ting i designverden er anvendelsen veldig avhengig av kontekst, brukere osv.). Det som imidlertid er klart, er at det finnes en del triks man kan benytte seg av, og disse deles i to kategorier. Den første kategorien, som vi skal se på i dette innlegget, kan vi kalle psykologiske fellesnevnere. Den andre, som vi skal ta for oss i mitt neste innlegg, er personlighet.

Vi er like på bunnen!

Heldigvis er det slik at vi mennesker har en god del psykologiske fellesnevnerer, og følelsene våre er én av disse. Man kan godt si at følelser er morsmålet til alle mennesker helt fra vi er født, og det finnes noen ting man kan jobbe med som vil utløse positive følelser hos mennesker nesten samme hva!

Det gyldne snitt

Alle mennesker har det til felles at vi prøver å se oss selv i alt rundt oss, for å kunne knytte oss til det. Et kjent eksempel her er “the babyface-bias” som gjør at mennesker får positive følelser mot alt som ligner på ansikt, og spesielt baby-ansikt. Dette betyr ikke at man skal dekke siden sin med happy baby-fjes, dette stikker nemlig dypere, og her kan man være mer sofistikert enn å kjøre på med babyer.

Du har sikkert hørt om Det gyldne snitt, men visste du at Det gyldne snitt faktisk finnes i våre ansikter? Dette fører til at når vi ser et maleri, en bygning eller en webside vi liker på grunn av balanse basert på det gyldne snitt, er det egentlig speilbildet av oss selv i det vi observerer som trigger oss! Dette betyr at design som inneholder det gyldne snitt har en stor sjanse for å vekke underbevisste, positive følelser. Twitter brukte dette aktivt i redesignet av sitt grensenitt.

Kontrast

Videre er det slik at vi underbevisst alltid leter etter mønster, rett og slett for å automatisk kunne plukke ut når det skjer noe uregelmessig rundt oss (= kontrast), slik at oppmerksomheten kan kobles inn og vi kan reagere. Som designere finnes det to typer kontrast vi kan benytte oss av; visuell kontrast og kognitiv kontrast.

Visuell kontrast er det ganske opplagt at må brukes i layout, farger og typografi (selvsagt med forsiktighet, hjerna kan få overload av kontrast!), og gjennom dette kan vi lede brukeren til det som er viktig på siden. Tumblr bruker dette aktivt i sitt sign-up-form.

Når det gjelder kognitiv kontrast, dreier det seg om at når noe skiller seg ut, blir dette oppfattet med en identitet heller enn som en del av massen. Dersom denne identiteten er positiv, har vi begynnelsen på et sterkt posisjonert brand. Designeren Richard Mestre bruker dette på sin portfolioside duplos.org – dette ligner ikke på så mange andre portfoliosider!

Aesthetics usability effect

I tillegg til det gyldne snitt og kontrast, har vi “the aesthetics usability effect”. Noen kan av og til komme i skade for å si at utseendet bare er “glasur på kaka”, men da kjenner de ikke sannheten. Det er nemlig slik at når noe ser fint ut, får vi positive følelser knyttet til det, positive følelser gjør oss mer kreative, og når vi er mer kreative løser vi problemer enklere (og da oppfatter vi systemet som lettere å bruke!). I tillegg er det vel ikke fritt for at vi dømmer etter utseende – ville du ansatt han med en glimrende cv dersom han møtte opp på intervju i en skitten pysjamas?

Videre er det faktisk slik at når “panseret” tydelig har fått ettertanke og er gjennomarbeidet, da får man følelsen av at det som ligger bak sannsynligvis også er samvittighetsfullt og skikkelig gjort, og det er mindre grunn til å tro at du vil møte noe som ikke henger på greip senere i prosessen.

Variable rewards

Til sist kan vi nevne “variable rewards”. Dette er en avhengighetsskapende tendens alle mennesker har, og det er trangen til å fortsette med en aktivitet i håp om at rundt neste sving venter den store gevinsten/ noe veldig morsomt/ noe spesielt og sjelden osv. Det er dette som gjør at vi kan utvikle spillegalskap, og selv om ikke det er noe mål, kan man som designer jobbe med de samme mekanismene for å få folk til å føle spenning og gi dem lyst til å bruke tid på systemet. MailChimp er et eksempel på et system som gjennom morsomme og varierende beskjeder og kommentarer til brukeren gir folk lyst til å fortsette gjennom sidene for å se hva som blir sagt rundt neste sving.

 Det var altså noen triks man kan bygge på som vil vekke følelser og oppførsel styrt av følelser hos så og si alle mennesker. Oppå dette minste felles multiplum av følelser som gjør oss til mennesker – der har vi alle en personlighet. Dette er en annen emosjonell komponent vi kan jobbe med, og denne skal vi ta for oss i mitt neste innlegg!

1. april 2011 lanserte Enonic sin CMS som open source i tillegg til sin standard Enterprise utgave. Enonic CE 4.6 (Community Edition) er det offisielle navnet. De har opprettet en egen sone på GitHub der all koden ligger og man kan samtidig følge utviklingen av versjon 5.0 som er under utvikling. Det mest spennende som er å finne på GitHub er pakkemalene. Her kan man plukke funksjonalitet som er gjennomtestet og som funker veldig bra som et utgangspunkt, og det vil også funke 100 % slik de allerede er på et mindre nettsted. Man trenger da kun å endre på designelementer og CSS’en.

Når du har lastet ned Enonic CE fra GitHub og du har installert den lokalt for testing står det veldig greit i dokumentasjonen om hvordan du kommer i gang.

Walkthrough

• Connect to WebDAV and upload the resources.
• Edit your site and set the Internal Resources to ‘/config/*’ where * contains a valid config.xml file
• Set the Public Resources to ‘/_public/themes/’
• Set Device Classification Script to ‘/libraries/resolvers/device-classification.xsl’

Start developing!

Etter du har logget deg inn i adminkonsollet kan du laste ned og konfigurere en del innholdstyper for å teste CMS’et. Eksempler på innholdstyper, som passer med pakkemalene du har lastet opp via WebDAV, finner du her. Disse xml-filene skal ikke lastes opp i WebDAV men du må gjøre litt god gammeldags cut’n'paste inn i konsollet. Når du har dette på plass kan du opprette mapper/kategorier i Innholdsarkivet og komme igang med litt innholdsproduksjon. Å produsere innhold er alltid tidkrevende og kan du i prosjektsammenheng definere innholdet på et så tidlig tidspunkt som mulig og før siten er ferdig kodet opp kan innholdsprodusentene få startet arbeidet sitt så tidlig som mulig.

Sett at du har en del testinnhold klart og skal begynne å implementere maler (xslt). Hvor skal man begynne? På hvilket nivå skal man tenke responsivt? Er det behov for responsivt design? Det er jo ikke helt sikkert at det er det. Hvis det er et eksisterende nettsted som skal lages på nytt kan det være lurt å ta en titt på besøksstatistikken og spesielt da forholdet mellom besøkende med og uten mobiltelefon eller tablet. Når man har en god oversikt over hvilke nettlesere og enheter som besøker siten må man se på målgrupper og strategi. Men det er utenfor scope av denne artikkelen så nå er det på tide å hoppe inn i malverket.

I Enonic CMS ligger det støtte for en device-detektor. Den hekter du på nettstedet ditt i adminkonsollet om du vil bruke denne som utgangspunkt. Det er lurt å ta denne i bruk uavhengig om du skal ha responsivt design eller ikke. Det er her informasjonen til hvilke breddeverdier de forskjellige regionene på sidene dine innehar. Dette brukes igjen til dynamisk skalering av bilder.

I pakkene som du allerede har lastet opp kan du starte med å titte på theme.xml. Denne xml-fila finner du på roten av siten din. Du finner den i dav’en her omtrent:

dav: /themes/<navn-på-demosite>/theme.xml

Når man jobber med denne fila er det greit å ha oversikt over designet som skal implementeres. Man trenger å vite maksbredder på bilder/grafikk i de forskjellige regionene som siden kan deles opp i. Vi tar en liten titt på xml’en

<theme>
    <region-prefix/>
    <accessibility>
        ...
    </accessibility>
    <device-classes>
        <device-class name="pc,unknown,mobile">
            <layout name="default">

                <area width="950">
                    <region name="north">
                        <width>950</width>
                        <margin>
                            <bottom>10</bottom>
                        </margin>
                    </region>
                </area>
                <area width="950">
                    <region name="center" role="main" element="section" class="wide">
                        <padding>
                            <right>30</right>
                            <left>30</left>
                            <top>30</top>
                            <bottom>30</bottom>
                        </padding>
                        <scalable>true</scalable>
                        <system>true</system>
                    </region>
                    <region name="single-sidebar" element="aside" role="complementary">
                        <width>180</width>
                        <margin>
                            <right>10</right>
                        </margin>
                    </region>
                    <region name="east">
                        <width>180</width>
                        <margin>
                            <left>10</left>
                        </margin>
                    </region>
                </area>
                <area width="950">
                    <region name="south">
                        <width>950</width>
                    </region>
                </area>
            </layout>
            <image>
                ... bilder
            </image>
            <styles>
                ... css-filer
            </styles>
            <scripts>
                ... js-filer
            </scripts>
        </device-class>
        <device-class name="pc,unknown,mobile">
            ...... ipad spesifikk kode
        </device-class>
    </device-classes>
</theme>

Strukturen er oversiktlig nok når man er vant til malverket til Enonic men det er regionene her som er interessante.

<region name="single-sidebar" element="aside" role="complementary">
<region name="center" role="main" element="section">

Det er støtte for html5-elementer i malverket og man kan definere det enkelt ved å bruke dette oppsettet her. Dette er da tenkt som globale elementer i html-kilden. Strukturen settes opp her og støttes videre med global css slik at rammeverket sitter dønn selv uten innhold på siden. Det er fint å kunne teste siten så tidlig som mulig.

Disse navnene på regionene, hhv. single-sidebar og center, blir nå hardkodete navn som må gjenspeiles i sidemalen som til slutt skriver ut html-koden på sidenivå. Denne fila heter page.xsl og den finner du på samme nivå som theme.xml. Når du senere skal lage flere siter er det fint å klone disse filene, opprette ny mappe under /themes/, dumpe filene her, opprette nytt nettsted i Enonic og deretter koble de nye malene på nettstedet og sidemalen og du er i gang med å lage site nr 2. Gjenbruk er gull.

Hvis vi tar en titt på page.xsl ser man kjapt hvor regionene defineres

<!-- regions -->
  <xsl:param name="north">
    <type>region</type>
  </xsl:param>
  <xsl:param name="single-sidebar">
    <type>region</type>
  </xsl:param>
  <xsl:param name="center">
    <type>region</type>
  </xsl:param>
  <xsl:param name="east">
    <type>region</type>
  </xsl:param>
  <xsl:param name="south">
    <type>region</type>
  </xsl:param>

Disse navnene må være like som i theme.xml. Når det er på plass kan man starte utviklingen. I theme.xml har jeg satt opp 960px som bredde for standardoppsettet mitt. Hadde jeg konfigurert nettstedet også for tablet og smartphone ville jeg lagt på to device-classes og definert breddene som f.eks. 768px og 320px eller eventuelt ytterpunktene med høyest oppløsning i landscape-modus. Dette vil da være størrelsen som bilder som skrives ut i de forskjellige regionene vil ha. Alt skjer via dynamiske funksjoner som man kan laste opp fra pakkene og bruke fritt i malene. I en artikkelmal kan man tenke seg at man kaller på et bilde slik:

<xsl:call-template name="image">
	<xsl:with-param name="size" select="'wide'"/>
	<xsl:with-param name="image-path" select="image/@key"/>
	<xsl:with-param name="class" select="'list-image'"/>
</xsl:call-template>

Her sier jeg til bildefunksjonen at den skal skrive ut bildet med full bredde i widescreen-format og samtidig legge på en klasse med navn “list-image”. Hvis man bruker standardoppsettet uten noen som helst form for tweaking blir dette en fast størrelse på bildet og ikke så skalerbart. Nå gjelder det å ta en titt på include-fila som skriver ut bilder. Den heter image.xsl og den finner du her: /libraries/utilities/image.xsl

Se etter templaten som heter “image.display-image“. Den er stor og kompleks og du trenger ikke endre så mye her, bare kommentere ut bredden og høyden til bildet som til slutt skrives ut. Se etter:

<xsl:if test="$width">
	<xsl:attribute name="width">
		<xsl:value-of select="$width"/>
	</xsl:attribute>
</xsl:if>
<xsl:if test="$height">
	<xsl:attribute name="height">
		<xsl:value-of select="$height"/>
	</xsl:attribute>
</xsl:if>

Når dette er kommentert ut er det bare å styre bredden til bildene enkelt via css slik:

img {
	max-width: 100%;
	height: auto !important
}

Ganske enkelt egentlig. Nå er det opp til deg og dine CSS-Ninja-egenskaper for å gjøre resten, men husk, vær smart og bruk device-detektoren i malene og scope hva slags enhet du jobber mot. Det vil optimalisere ytelsen og farten på siten. Du kan også justere innholdet og tilpasse siten på en mye enklere måte. Du kan gjøre dette helt ute i rammeverket og inne i portletene. Lag sjekker på device og tilpass bildet ditt. Ikke noe vits i skrive ut et 960px bilde for så å skalere det ned til 320px på en iPhone. Da er det bedre å bruke dette opplegget og skrive ut et bra skalert bilde fra serveren som passer til den devicen du har i målgruppen din. Malverket til Enonic baserer seg på XSLT og er du god på XSLT, XHTML og CSS er det bare moro herfra og frem til siten skal lanseres.

Lykke til.

Så, bortsett fra ønsket om å være den o store kokken som har laget en nydelig, ikke bare spiselig mat, eller den o heldige kunden som får spise dette (ref. pyramiden i mitt forrige innlegg) – hvorfor skal vi bry oss om emosjonell design? Er ikke dette med emosjonell design bare litt glasur og moro på toppen for designere som vil ha det gøy eller brukere som vil rote bort tiden på noe annet enn jobb? Nei, slik er det definitivt ikke – det går mye dypere enn som så.

“Emotional design is not about nice-to-have warm fuzzy experiences, it’s central to daily life and the decision-making process for consumers. The more effectively you can apply emotional design in your site, the better conversion rates and sales will be.”

Det har seg nemlig slik at opplevelser vi knytter følelser til (“emotional engagement”) faktisk lager dype inntrykk i langtidsminnene våre. Når vi opplever noe bra, settes en mental post-it i hjernen vår, som gjør det mulig for oss å fremkalle minnet av den gode opplevelsen. Når vi gjør dette får vi ikke bare lyst på mer av samme gode opplevelse, vi blir også mer tilbøyelige til å tilgi når ting går galt, og til og med til å snakke varmt om opplevelsen til andre!

(Hvorfor er det slik, spør du? Vel, dersom vi ikke satt disse mentale post-itene på ting som fremkalte betydelige følelser, ville vi ikke kunne gledet og over gode minner, og heller ikke kunnet lært av ubehagelige opplevelser. Vi ville vært dømt til å prøve og feile oss uendelig gjennom livet -uff!)

Som designere kan vi ha god nytte av dette – her har vi mulighet til å posisjonere både et brand og et system ganske hardt hos brukeren gjennom å trigge de rett følelsene. Når kundene vil ha mer blir de trofaste brukere som bruker mer tid og penger hos oss, og når de skryter av oss til bekjente blir de en ambassadør vi måtte betalt ganske mange marketing-kroner for å matche! Med andre ord – emosjonell design kan få uttelling rett på bunnlinja!

Da har vi noen gode argumenter på plass for “Hvorfor?”, og i mitt neste innlegg skal jeg gå inn på “Hvordan?”. Følg med!

Boka er en kjempefin intro til design og psykologi, og dersom du er spesifikt interessert i emosjonell design, vil jeg absolutt anbefale at du begynner hos Aarron – boka er ypperlig for dem som lurer på, eller trenger skyts til, hvorfor emosjonell design er et aktuelt tema!

Dersom du vil ha en enda kortere intro enn boka eller bloggpostene, eller kanskje du trenger noen andre eksempler, da kan du lese blogginnlegget av Aarron på ThinkVitamin.

Hva er emosjonell design?

Så, hva er emosjonell design? Her har Aarron en figur som er veldig konkret og som lett kan knyttes til en velkjent design-hverdag, og han har også noen gode forklaringer rundt emosjonell design. (Figuren har forøvrig vært nevnt før i forbindelse med Aral Balkans foredrag på konferansen The Big M).

For å begynne med figuren; Denne sammenligner interface design med Maslows velkjente behovspyramide. (Navnet interface design er ikke så viktig her, man kunne likegodt sagt interaction design eller noe annet; i denne sammenheng er det ikke er så viktig akkurat hvor bredt eller smalt man ser på dette). Prinsippet i en slik pyramide er at behovene i en lavere del av pyramiden må være dekket før man kan klatre seg oppover i lagene, og en høyere del av pyramiden kan aldri komme på bekostning av en lavere!

De nederste lagene i interfacepyramiden er functional, realiable og usable. Disse sikter til at systemet har de funksjonene brukerne trenger, at systemet er til å stole på med tanke på f.eks oppetid og at det ikke mister data, og at systemet er brukervennlig. Å ha en solid base i pyramiden er selvsagt ekstremt viktig og her kan bl.a kognitiv psykologi hjelpe oss, men når vi skal begynne å klatre i pyramiden er det den emosjonelle delen av psykologien vi skal spille på lag med.

Aarron påpeker at hittil, i interface designets barndom, har vi for det meste hatt nok med å kave rundt i de nederste nivåene. Det har vært utfordrende nok å komme seg opp på usable-nivået, der brukervennlighet ligger, men nå som vi er på vei inn i ungdommen holder faktisk ikke dette lenger; vi må vekk fra hygienefaktor-designet og opp i toppen av pyramiden! (Jeg er så enig, så enig!)

Det er nemlig på toppen vi finner de opplevelsene som er “pleasurable” – det er her man har ting som delight, joy og fun! Og det er jo dette vi alle drømmer om å både bruke og lage – skikkelig digge opplevelser som bare har D-E-T!

Så over til forklaringen. Emosjonell design er ikke en spesifikk type design, heller en angrepsvinkel for oppnå det vi alle drømmer om å bruke og lage. Emosjonell design kan ikke masseproduseres, og når man lykkes med emosjonell design, vil det føles som om det er en person man interagerer mer, ikke en maskin.

“Emotional design uses psychology and craftsmanship to create experiences for users that make them feel like there’s a person, not a machine at the other end of the connection”

For å utdype dette sier Aarron noe smart, han påpeker nemlig at Human Computer Interaction (HCI) er et forferdelig og utdatert ord. Det får det jo til å høres ut som om vi etterstreber at det skal merkes at det er en maskin med i bildet, heller å strebe etter at interaksjonene føles så “pleasurable” som en god samtale kan være. I det vi tar steget opp i de høyere delene av pyramiden burde vi samtidig slutte å snakke om at det er en computer med i samtalen!

Da har du fått en liten intro til temaet, og jeg håper du titter innom mitt neste innlegg også! Dette vil komme første uka i januar, og vil gå mer i dybden på “Hvorfor bry seg om emosjonell design?”

More than once have I come across projects and software which have their database schema defined in a single SQL file. Ok, sometimes there are several, one for each database vendor. This, often big, master SQL file is updated by the developers for each release/revision/sprint and shipped with the software.

This approach often result in projects/software creating their ad-hock schema management system for rolling out new schema releases. Some use manual procedures, others use Perl, Shell og Python scripts, some use various procedural languages and yet others use specialized tools from the database vendor. In my previous company I ended up using a combination of Pyhon scripts, PL/pgSQL and home grown code generators to manage the schema.

After being fed up by having to maintain my own custom code for schema management, I started searching for an alternative. To my excitement a friend of mine came across Liquibase. And since then that’s what I’ve been using….

Liquibase is a small Open Source tool implemented in Java that summarizes its purpose with a great question: “You never develop code without version control, why do you develop your database without it?” The Liquibase homepage has decent documentation and even some introduction videos for getting started.
Note that Liquibase also easily be set up to integrate with Ant, Maven, Spring or even directly in a Java Servlet container for more automation than the basic command-line.

But, if you are like most programmers, you’re probaly not happy until you reach perfection and total enlightenment, so here are some other alternatives:

• If you are fed up with Java tools using XML for configuration or you just have a case of general XML-allergies,
  I suggest having a look at Migrate4J
• First released the 2010.04.20 Flyway isn’t that old, but worth checking out.

I have not tried these on a real-life project yet so feedback will be much appreciated!

Så, når min frustrasjon tidvis når nye høyder hender det jeg tar enda en kikk på Scala. Alt skal jo være enklere i Scala!
Nå sitter det sikkert en og annen leser og er litt oppgitt, enda en bloggpost med “java bashing” tenker du kanskje? Vel, jeg skal være ærlig, det var det som var utgangspunktet, men da jeg begynte å gjøre litt “research” fant jeg ut at Java fortsatt kan henge med i svingene….

Getters and Setters”

Så, hva skal man med disse get’erne og set’erne i utgangspunktet? Vel, intensjonen med disse funksjonene er å oppnå såkalt “encapsulation” slik at implementasjonen av klassen og dens felt er uavhengig av det eksterne grensesnittet. Dette er en veldig bra tanke i teorien, men i praksis er det ofte ingen forskjell på klassens interne felt og og det eksterne grensesnittet!
Vi vil heller ikke aksessere feltet direkte (ingen “encapsulation”), men vi ønsker heller ikke intetsigende get’ere og set’ere i koden når vi ikke har behov dem. Samtidig vil vi ha mulighet til å lage/endre på klassens interne representasjon av et felt uten å forandre på klassens eksterne grensesnitt.

Java “løste” dette opprinnelig med Java-Bean “standarden” som vi alle kjenner, men her har Scala overgått Java:

Scala og “accessor methods”

I Scala genererer kompilatoren såkalte “accessor methods” for alle felt. Dette betyr at når man definerer følgende Scala klasse:

/* MyScalaClass.scala */
class MyScalaClass {
var stringField: String = _
}


Genereres følgende “accessor methods”:

// Getter:
stringField()

// Setter
stringField_$eq(stringField : String)


Og hva så med muligheten til å endre på klassens interne representasjon samtidig som man beholder grensesnittet? Det gjøres enkelt ved å eksplisitt definere “accessor” metodene:

/* MyScalaClass.scala */
class MyScalaClass {
var modifiedStringField: String = _
def stringField() = modifiedStringField

def stringField_= (stringField: String) {
modifiedStringField = stringField
}
}


Her er en enkel Junit test skrevet i Java som viser hvordan Scala “accessor metods” ser ut fra den siden:

/* MyScalaClassTest.Java */
@Test
public void MyScalaClassTest() {
MyScalaClass myScalaClass = new MyScalaClass();
myScalaClass.stringField_$eq("foo");
assertEquals("foo", myScalaClass.stringField());
}


Her er tilsvarende test med scalatest:

/* MyScalaClassSuite.scala */
test("Test accessors ") {
val mc = new MyScalaClass()
mc.stringField = "foo"
assert("foo" == mc.stringField)
}


“accessor method” != JavaBean Getter/Setter

Alt er rosa og fint i Scala-land, men igjen bør vi løfte blikket og ta en titt på den virkelige verden. Hvis vi vil bruke scala er sannsynligheten høy for at vi må integrere enten med eksisterende Java kode/bibliotek (for eksempel Hibernate eller JAXB). Og denne Java koden forventer sannsynligvis JavaBean get’ere og set’ere ikke og “accessor methods” har lite for seg.
Men igjen har Scala løsningen: @scala.reflect.BeanProperty. Denne annoteringen gjør akkurat det du forventer: genererer JavaBean get’ere og set’ere:

/* MyScalaClass.scala */
class MyScalaClass {
@scala.reflect.BeanProperty
var stringField: String = _
}



/* MyScalaClassTest.Java */
@Test
public void MyScalaClassTestWithBeanProperties() {
MyScalaClass2 myScalaClass = new MyScalaClass2();
myScalaClass.stringField_$eq("foo");
assertEquals("foo", myScalaClass.stringField());
myScalaClass.setStringField("bar");
assertEquals("bar", myScalaClass.getStringField());
assertEquals(myScalaClass.stringField(), myScalaClass.getStringField());
}


Java klamrer seg fast

Jaja, fint for de som har muligheten til å kode i Scala tenker du kanskje…. Men vent, det finnes løsninger for Java også! Se bare på koden under:

/* MyJavaClass.Java */
@Setter
@Getter
public class MyJavaClassMinimal {
private String stringField;
private Integer integerField;
private Date dateField;
}



/* MyJavaClassTest.Java */
@Test
public void MyJavaClassTest() {
MyJavaClass myJavaClass = new MyJavaClass();
myJavaClass.setStringField("foo");
assertEquals("foo", myJavaClass.getStringField());
}


Så hvor kom disse magiske @Setter og @Getter annoteringene fra? Ta en titt på Project Lombok!
Personlig barberte jeg vekk over 6000 linjer “boiler plate” Java kode fra nåværende prosjekt ved hjelp av “Lombok”, så dette er verd å bruke noen minutter på!

Men dette er jo ikke en del av Java språket tenker du kanskje. Og du har helt rett “Lombok” er et separat bibliotek, men det kan hende vi slipper dette i Java 8 Abbreviating getters and setters proposal for Java 8?

Det å være “effektiv” handler om å få gjort mer arbeid innenfor den tiden du har til rådighet. Har du ikke tid til å lese hele bloggposten? Da tar vi produktivitetstipsene med én gang:

1. Hold oversikt over antall oppgaver du har pågående
2. Begrens antall samtidige oppgaver, fokuser på å fullførere eksisterende oppgaver fremfor å starte opp nye
3. Sett av tid til “isolerte” arbeidsstunder på 25 min for å rydde unna rutineoppgaver

Disse rutinene fungerer som regel godt, men de fungerer ikke likt i alle sammenhenger. La meg forklare litt om tankene bak.

Typisk prosjekthverdag

Jeg er prosjektleder og jobber med store og små systemutviklingsprosjekter. I løpet av en vanlig arbeidsdag bruker jeg mange timer på å arbeide i team og på å arbeide med team. I et godt team “dyttes” man til en viss grad fremover av hverandre, i en kjede av regelmessige og uregelmessige hendelser.

Når arbeidssituasjonen endres…

For en stund siden startet jeg i et nytt prosjekt, men til forskjell fra “vanlige” systemutviklingsprosjekter er jeg inne i en tidligere fase. Vi etablerer prosjektet, vi arbeider med selve fundamentet. Vi ser på forretningsverdien og på hvordan det nye systemet vil fungere i organisasjonen og påvirke hvordan folk jobber. Vi spør: “Bør prosjektet i det hele tatt startes opp?”. Dette er en annerledes situasjon å være i, for ofte er beslutningene tatt og vurderingene gjort (eller faktisk ikke gjort) når vi begynner å bygge løsningen.

Arbeidet er spennende og utfordrende, men jeg jobber mye mer på egenhånd enn jeg gjør i min normale prosjekthverdag. Det krever selvdisiplin. Det er større fokus på at “jeg” skal levere enn at “vi” skal levere. Dette førte til at jeg ikke lenger følte meg like produktiv som jeg ønsker å være. Ingen faste prosjektdeltakere (utenom meg selv), men mange i organisasjonen involvert på deltid og på forespørsel. Her er det ingen kjede av hendelser som “dytter” prosjektet fremover.

Det er riktignok ganske vanlig at en konsulents arbeidshverdag forandres. Nye prosjekter startes opp, og prosjekter avsluttes. Vi starter å arbeide med nye kunder, og relasjoner må bygges på nytt.

Når arbeidssituasjonen endres kommer man fort ut av det som er normal arbeidsrytme. Da tar det gjerne litt tid før man får strukturert ting, finner tilbake til den gode følelsen og klarer å utnytte det produktive potensialet. Jeg har opplevd disse endringene et utall ganger og er blitt opptatt av å skaffe meg gode arbeidsvaner og lære meg teknikker som gjør at jeg raskt finner igjen balansen og blir produktiv.

Personlig Kanban kombinert med Pomodoro

De siste månedene har jeg benyttet en personlig Kanban-tavle, en digital sådan, der jeg holder styr på oppgavene mine og flytter disse mellom kolonnene backlog, denne uken, pågående og utført.

Hva er de forskjellige kolonnene?

• Backlog: Oppgaver jeg skal gjennomføre eller følge opp.
• Denne uken (“This week”): Oppgaver jeg har plukket fra backlog som jeg skal gjennomføre inneværende uke. Som regel plukkes disse fra backloggen kun én gang i uken, dvs. at oppgaver som ligger i backloggen er oppgaver som trygt kan ligge til neste uke. Oppgaver som dukker opp fortløpende, og som må utføres relativt raskt, legges som regel direkte inn i denne kolonnen.
• Pågående (“Doing”): Oppgaver jeg arbeider med eller følger opp akkurat nå. Dukker det opp en ny oppgave jeg må starte på med en gang går den rett inn i denne kolonnen.
• Utført (“Done”): Fullførte oppgaver, tømmes ukentlig.

Eksempel på en enkel personlig Kanban-tavle 

Ser du spesielt godt etter på skjermbildet, vil du se at det er en WIP-begrensning på 4 oppgaver i pågående-kolonnen. Dette betyr at jeg har satt en begrensning på antall samtidige oppgaver som kan ligge i denne kolonnen. Årsaken til denne begrensningen er at det øker fokus på å fullføre oppgaver, slik at jeg unngår problemer som peak attention. Denne fremgangsmåten har fungert veldig godt lenge, men til tross for dette følte jeg meg ikke like effektiv som vanlig i denne nye arbeidssituasjonen.

I min kontinuerlige søken etter å bedre effektiviteten kom jeg over denne artikkelen. Her beskrives en kombinasjon av personlig Kanban og Pomodoro-teknikken- altså en potensielt god match for meg siden jeg allerede benytter personlig Kanban.

Kort fortalt er Pomodoro en teknikk der du definerer en oppgave som kan utføres i løpet av 25 minutter, stenger omverdenen ute og arbeider fokusert kun med denne oppgaven inntil tiden er ute. Oppgaven skal da være fullført, deretter kan du ta 5 minutters pause (hente kaffe, svare på e-post, e.l.).

Hva som får deg til å arbeide mest mulig effektivt, med færrest mulig avbrudd, avhenger nok både av situasjonen og personlige preferanser. Noen bør sette seg på et stillerom og fjerne tilgangen på alle fristelser (e-post, Twitter, eller kanskje internett generelt). For min del blir jeg sittende i det åpne kontorlandskapet, tar på meg headsettet og spiller musikk jeg kjenner godt fra før.

Konkret har Pomodoro-teknikken, kombinert med min personlige Kanban, ført til at jeg har opprettet en egen Pomodoro-kolonne på tavlen min. Denne ligger etter pågående-kolonnen og har en WIP-begrensning på én. Har jeg tid eller behov for en svært fokusert arbeidsstund flytter den utvalgte oppgaven over til Pomodoro-kolonnen. Merk at jeg da minimerer pågående-kolonnen, slik at fokus kun ligger på den ene oppgaven jeg skal fullføre. Oppgaven er av en slik størrelse at den kan gjennomføres på 25 minutter. Er den større splittes den opp i mindre deler før en av deloppgavene flyttes over i Pomodoro-kolonnen. Når den er ferdig flyttes oppgaven videre over til utført.

Personlig Kanban-tavle med egen Pomodoro-kolonne. Pågående-kolonnen er minimert.

I tillegg til at dette visualiseres på min personlige Kanban-tavle, teller jeg antall Pomodoro-økter jeg får gjennomført hver arbeidsdag. Dette ligger lett synlig på arbeidsplassen min, slik at jeg stadig får en påminnelse om at én eller flere Pomodoro-økter kan hjelpe meg til å få ryddet unna enkelte oppgaver.

Visualiseringen av antall Pomodoro-økter ligger lett synlig på arbeidsplassen.

Det er ikke noe mål i seg selv å gjennomføre flest mulig Pomodoro-økter, dette avhenger i stor grad av tid og sted, men visualiseringen er likevel viktig slik at jeg får en påminnelse om muligheten:

Erfaringer?

For meg fungerer Pomodoro-teknikken veldig bra sammen med personlig Kanban. Jeg har klart å øke fokus på å fullføre oppgavene mine ytterligere, og jeg opplever et skikkelig produktivitetsløft på visse typer oppgaver – spesielt rutinepregede oppgaver.

Det å estimere størrelsen på en oppgave er (som alltid) svært vanskelig, og jeg klarer ikke alltid å fullføre oppgavene innenfor avsatt tidintervall (25 min). I blant må det både to og tre Pomodoro-økter til før jeg blir ferdig med en oppgave, men jeg merker at jeg blir stadig flinkere i å splitte oppgavene opp i hensiktsmessig størrelse. Klarer jeg ikke å avslutte oppgaven i tide er ikke dette utelukkende negativt heller – dette motiverer meg enda mer til å ville fullføre oppgaven.

Det er generelt vanskelig å endre måten man arbeider på, men jeg tror en bevisstgjøring av måten man arbeider på alene kan hjelpe på effektiviteten. Dessuten øker nysgjerrigheten på å finne ut av hvordan man kan bli mer effektiv.

Teknikken jeg har beskrevet her fungerer godt for meg akkurat nå, men det er ikke sikkert du kan bruke denne teknikken på nøyaktig samme måte. Finn din egen stil og legg deg til en vane med å prøve ut nye teknikker.

Hvilke grep tar du for å arbeide mer effektivt?

Man finner ofte eksempler på repeterende kode som gjør tilnærmet det samme, men med litt variasjon. Det kan være enkelt å se mønsteret, men vanskelig å trekk det ut for gjenbruk. Det finnes mange måter å løse dette på i Java, men ofte ville det vært enklere med higher order functions. Vi skal se på hvordan slike problemer kan løses i Scala.

Dette blogginnlegget viser kort hva higher order functions er og hvordan syntaksen for disse er i Scala. Deretter vises et praktisk eksempel på programmatisk transaksjonshåndtering i Spring med Scala og higher order functions.

Høyere enn hva?

Higher order functions, eller høyere ordens funksjoner, er funksjoner som tar inn én eller flere funksjoner som parametre eller returnerer en funksjon. Disse finner man i funksjonelle språk og andre språk som behandler funksjoner som “first class citizens” som betyr at funksjoner kan opprettes, tilordnes til variabler og sendes som parametre.
Et vanlig bruksområde for higher order functions er å samle gjentagende kode på ett sted for gjenbruk. Scalas collection-API inneholder mange eksempler på bruk av higher order functions:

I dette eksemplet er map en higher order function. Den tar inn en funksjon som blir kalt for hvert element i listen og resultatene returneres som en ny liste. Traversering av listen er altså felleslogikken som er trukket ut i en gjenbrukbar funksjon. Den som bruker apiet trenger kun å konsentrere seg om hvordan hvert element skal transformeres.

Din egen higher order function i Scala

Et enkelt eksempel på en higher order function er følgende funksjon som skriver ut en tekststreng formatert av en annen funksjon:

Funksjonen print tar to argumenter: text som er av typen String og decorate som er av typen funksjon fra String til String. Altså en funksjon som tar en String som parameter og som returnerer en String. Selve implementasjonen kaller decorate-funksjonen med text som argument og skriver ut resultatet. Det er altså println-kallet og formateringen av teksten som er funksjonaliteten som kan gjenbrukes med print-funksjonen. I eksemplet brukes Scalas kompaktnotasjon for anonyme funksjoner der parameteret brukes kun én gang: "<html>" + _ + "</html>. _ (underscore) brukes her for å referere til tekststrengen som funksjonen tar som parameter. Det er ikke nødvendig å deklarere typen da Scala kan utlede den fra deklarasjonen av print-funksjonen. Eksemplet nedenfor viser hvordan en navngitt funksjon med full signatur kan sendes som argument til print:

Eksempel: Programmatisk transaksjonshåndtering med Spring

Spring tilbyr flere måter å håndtere transaksjoner på: Via aspects definert i xml, annotations og programmatisk. Jeg har ofte endt opp med å bruke annotations fordi det er relativt enkelt å sette opp og det fremgår ganske tydelig i koden hva som kjøres i en transaksjon. Likevel er ikke annotations så fleksibelt og enkelt som det burde være. Noen ulemper:

• Feil oppdages ikke før runtime
• Man må (bør) vite en del om den underliggende implementasjonen
• @Transactional krever en no-args default constructor hvis man ikke har et interface på klassen. Kjedelig hvis man bruker constructor-basert injection og ikke har behov for interfacet i koden
• Man kan ikke gjøre interne kall mot en metode med @Transactional fra samme klasse. Dette medfører noen ganger uheldig oppdeling av klasser

Når man ønsker litt mer kontroll, er programmatisk transakasjonshåndtering et godt alternativ. Med TransactionTemplate er det enkelt å eksplisitt kjøre kode i en transaksjon. Jeg skal vise hvordan man ytterligere kan forenkle dette med Scala og higher order functions.

Java

Eksemplet viser hvordan man kaller TransactionTemplate sin execute-metode med en anonym implementasjon av interfacet TransactionCallback. Dette er i praksis en higher order function i Java. Men siden Java ikke støtter å sende en metode som parameter til en annen metode må metoden, her doInTransaction, wrappes i et interface. Slike en-metodes-funksjonsklasser er ganske vanlig i Java. Ulempen med denne løsnigen er:

• Unødvendig mye boilerplatekode
• Koden blir mindre lesbar
• Mindre fokus på hva som er oppførselen til funksjonen
• Man må ha ulike funksjonsinterface for å støtte ulikt antall parametre

Scala

Med scala kan vi lage en egen higher order function som en wrapper for TransactionTemplate sin execute-metode. Denne definerer vi som følger:

def doInTransaction[T](action: (TransactionStatus) => T): T

Vi ønsker at funksjonen skal kunne returnere en vilkårlig type så vi bruker et type-parameter T. Funksjonen tar ett parameter: action som er av typen (TransactionStatus) => T, altså en funksjon som tar inn TransactionStatus og returnerer T. Dette er identisk med TransactionCallback.doIntransaction som har signaturen:

T doInTransaction(TransactionStatus status);

Vår nye doInTransaction-funksjon kaller TransactionTemplate.execute på samme måte som i Javaeksemplet:

Funksjonen kaller action inne i transaksjonen. Vi har dermed trukket ut all boilerplatekoden i en gjenbrukbar funksjon. Javaeksemplet vil nå kunne skrives (i Scala) som:

Konklusjon

Higher order functions er et kraftig konsept som gjør det mulig å organisere koden på en mer effektiv måte og dermed redusere behovet for boilerplate og repetisjon. Scalas kompakte syntaks og støtte for higher order functions gir oss muligheten til å forenkle måten vi programmerer mot kjente Java-apier som Springs TransactionTemplate, JdbcTemplate og en rekke andre.

Kildekoden til eksemplene, samt oppsett av maven for Scala, Spring og transaksjoner, er tilgjengelig på GitHub.

Oj, vi skal til London!

Forventningene var høye når Christian Holthe og Mari Torgersrud Haug deltok på Usability Week 2011 i London forrige uke. Konferansen ble arrangert av Nielsen Norman Group, startet av Jacob Nielsen og Don Norman. Det skal sies at vi ble noe “starstruck” da Jacob Nielsen ruslet inn på forelesningen første dag for å ta bilder av kollegaer og seminardeltakere.

NN Group jobber blant annet med å forske på designtrender, så de sitter på mye statistikk om forbrukere og atferdsmønstre på nett. Visste du for eksempel at:

• vi bruker 70 % av tiden på å se på venstre halvdel av en nettside
• vi ser bare på 42 % av bildene vi kommer over på nettet
• at multitasking egentlig er umulig for oss mennesker
• vi mennesker ikke klarer og lagre mer enn 5 til 7 ting i korttidshukommelsen vår – Millers magic number 7 +-2
• lojale kunder tenderer til å kjøpe 4 ganger mer enn førstegangsbesøkere på nett
• vi bruker kun 10 sekunder på å bedømme om en nettside er interessant eller ikke

Hvordan tenker vi nettbrukere egentlig?

NN Group har gjennom sin årelange forskning funnet flere mønstre på bruk av nett. Bannere og seksjoner som ligner reklame ser vi rett og slett ikke på, fordi vi er vant til at dette ikke er relevant for den informasjonen vi søker. Og vi liker å ha kontroll! Nettsider med lyd eller video som starter automatisk når vi laster en side, gjør at vi instinktivt ser etter måter vi kan slå av dette på. Det samme med bildekaruseller. Vi ønsker å ha mulighet til å velge det vi synes er relevant, og slippe å sitte og vente på at noe automatisk kommer rullende tilbake i synsfeltet vårt. Så tipset er å tilgjengeliggjøre funksjonalitet som lar brukerne styre bildekaruseller, lyd og video etter eget ønske. Det skaper både tillit og troverdighet, som kan bety mye for konverteringen og salg.

Multitasking og design av brukergrensesnitt

Vi mennesker liker å tro at vi kan multitaske. Sannheten er at ingen mennesker faktisk kan gjøre to ting nøyaktig samtidig. Noen er gode til å ta opp igjen tråden på påbegynte oppgaver raskt, men mange glemmer fort hva de egentlig holdt på med. I vår hverdag er det mer og mer vanlig at vi sitter med flere programmer, nettsider og enheter samtidig. Det er derfor nyttig at vi legger til rette for denne type bruk. Ved å vise hvilket søkeord som ble søkt på, (ja, noen glemmer faktisk dette) og markere besøkte linker legger vi til rette for at nettbrukere lettere skal huske hva de egentlig holdt på med. I tillegg bør vi fortelle brukerne hvor de er i nettstedlandskapet ved hjelp av brødsmuler og hvilket steg de befinner seg på i en bestillingsflyt.

Mennesker og mentale modeller

Hvilke forventninger vi har til et ett nettsted eller brukergrensesnitt bygger på tidligere opplevelser, vår kultur og vår hukommelse. Ting vi lett kjenner igjen og har brukt tidligere, krever mindre kognitiv anstrengelse når vi skal ta det i bruk.

Jacob Nielsen snakket om hvordan nye design patterns raskere blir standard i dag enn tidligere, fordi vi er mer mottakelige for nye ting. Mye av dette bygger på vår trang til og utforske og leke, som har fulgt oss siden barneåra. Når det er sagt, er det viktig at vi ikke tøyer grensene, og en gradvis introduksjon til nye og mer moderne design patterns er fortsatt å anbefale.

Kanskje noe av det viktigste Marieke McCloskey konkluderte med, som også snakket litt om mentale modeller. Var at det sjelden er match, mellom en designers mentale modell og en ordinær brukers mentale modell. Det er derfor svært viktig at vi samler inn data og analyserer tidlig i alle faser, slik at gapet mellom hva vi lager og hva brukere forventer blir minst mulig.

Du trenger ikke finne opp hjulet på nytt

Standard komponenter og konvensjoner vil fungere best i 90 % av tilfellene på nett, hevder Jacob Nielsen. Vi ser automatisk opp i høyre hjørnet når vi ikke finner det vi leter etter og vil prøve å søke etter informasjon. Blå understreket tekst er fortsatt beste måten å fremstille en link på. Og fitt’s law er fortsatt like gyldig i dag som for 20 år siden. Det var mye av dette vi forventet å høre etter å ha sett på websiden hans, useit.com.

Det er mye Jacob Nielsen sier som begynner å bli “common sense”, og som er gammelt nytt for oss som jobber i denne bransjen. Men det er få selskaper i verden som gjør så mye forskning på bruksadferd som NN Group. Forskningsresultatene gir oss verdifull kunnskap, som vi bør ta med oss videre inn i prosjekter og i vårt tankesett når vi designer løsninger.

Vi er i fremtiden

Don Norman holdt konferansens keynote med tittelen “Vi er i fremtiden”. Inntrykket av Don Norman er at han er meget oppegående, og fremstår som en slags bestefarfigur som man automatisk får mye respekt for. Denne mannen har mye og komme med. Norman snakket om at vi befinner oss i et univers av teknologi. I det daglige blir vi konstant konfrontert med ny teknologi som gjør at hverdagen vår blir litt enklere og mer praktisk. I bilen, i huset, på bussen, på jobben. Overalt er det ny teknologi, og vi tilpasser oss mer og mer en teknologi drevet hverdag. Norman trakk spesifikt frem appen SIRI, nylig lansert på iPhone, og hans kommentar var ”Artificial intelligence actually works”.
I kjent Don Norman stil hadde han noen spådommer rundt mennesker og teknologi. Vi har plukket ut de viktigste punktene.

• ”Smarttelefoner, nettbrett og pc’er vil smelte sammen og bli uniformt”
• ”Det kommer mange flere enheter som vil forandre markedet”
• ”Touch gestures vil bli mer vanlig for andre typer enheter som eksempelvis i hjemmet”
• ”Se opp for ASIA. De er i sterk vekst både økonomisk og innovativt”
• ”Det største fremtidige problemet for teknologien vil være knyttet til sikkerhet, brukskvalitet og personvern”
• ”Websider kommer til å bli APPS, og webdesignere blir APP designere”

Var det verdt å delta på Usabilty Week?

Usability Week er ikke konferansen du drar på hvis du ønsker å vite hva som er nytt på teknologifronten eller du søker inspirasjon til å tenke nytt. Usability Week er en konferanse som baserer seg på forskningsresultater og erfaringer av hva som fungerer over tid. Foredragsholderne er proffe og det er også deilig å slippe presentasjoner hvor halve tiden går med til å reklamere for et firma eller produkt.