When I wrote my first C.V. coming out of university I used LaTeX since I had just written my thesis using it. You can create beautiful and professional documents with it but today I think things have moved on and your web presence is likely to be discovered and read first. So I decided to write it web first this time as a responsive web page. You can see an example of it here.

Initially I looked at both markdown-resume and strapdownjs and choose the latter to get the benefits of writing in markdown and omitting the build step. To get up and running quickly I started with bootstrap-sass and the minimal and typographic paper theme. However the more I customised the layout and formatting of my content the more markdown was replaced with HTML and CSS. There came a point where I realised it was easier and more powerful to complete it all without the markdown component.

I really like how fast gulp executes and the model for composing the build pipeline. Calling gulp sass will generate our CSS file which we can use on the website. You will also need to import the bootstrap-sass and any theme scss files into your main.scss file.

Hopefully you should have a c.v. page that scales nicely across different devices and ready to exporting to PDF.

Export a PDF with a custom style

To export the page we will use wkhtmltopdf which I find works extremely well. Please make sure you have the latest version, my machine had v0.9 which was plagued with layout and text kerning issues. The current version at the time of this post is 0.12.2.

You can adjust the margin and zoom for your own layout. The viewport-size is to generate the desktop responsive layout, so you can change this to suit your responsive media queries for the layout you want. We have added a dependency on a pdfsass task too so lets create that.

This will use my pdf.scss stylesheet to generate the CSS file for the page and is called before the generation happens. This will allow use to remove elements like the navigation bar and adjust the layout to better suit the PDF.

Mine is pretty straightforward and I only adjust the padding and navbar display, one of the benefits of keeping the page design simple and typographic.

Hosting on Github

Github gives you a User page which feels like an appropriate place to put your c.v. and its quite easy to get up and running. Github uses a convention for user pages so create a repositoty called username.github.io.

If you want a custom domain put into the root of your sites directory a file called CNAME and put in the domain name without the protocol. In mine I have:

naeem.khedarun.co.uk

You can now push your repository up to github and within 30 minutes your page will be available at http://username.github.io. If you are using a custom domain add a CNAME record pointing your domain to username.github.io.

All done!

I personally find that this approach works well for me and I hope you might find it useful too. All the source is at naeemkhedarun.github.io and feel free to clone and use it as you like.

When we started our html5 game Peter Acorn we were optimistic but cautious about the level of performance we could get from the platform on mobile. We started off with simple spritesheets which looped through our animations frame by frame and were extremely fast to execute. I will assume you either already have a MelonJS game setup or bootstrap yourself with one of the MelonJS tutorials to get up and running.

This was fast to get setup initially with good performance but there are limitations:

Getting smooth transitions between animations is difficult.

Using an image editor and scripts to structure and export the spritesheets takes time.

One major limitation which eventually broke the camels back with related to resolution and frame rate. If you want to increase the resolution of the game, then your sprite sheet gets much larger. To compound the issue if you want a smoother or more complex animation then adding extra frames to the sprite sheet exasperates the issue the higher the resolution is. You can offset this by having a square sheet but by now we had already seen Spine and wanted to try it.

We were skeptical about the performance of the javascript runtime especially on mobile but these concerns were not warranted in the end. First we had to find a way to get it integrated into MelonJS. You can find an example of this on Github and a big thanks to Aaron for adding this support to MelonJS!

You will want to load integration after both the melon and spine runtimes:

I have already added my chopped assets to Spine and created a few animations. I noticed that I needed to key all the bones otherwise I would get strange behaviour in-game and the animations would be totally out of whack as a result of bad relative co-ordinate data. So on the first frame of each of your animations select all the bones and make sure their rotation, translation and scale is keyed in. Take care especially on mobile to keep the number of bones, images and frames to a minimum to improve performance.

When exporting lets create an atlas which efficiently puts all the components parts of your character onto a single image.

Turn off rotation (which packs more efficiently) as the integration does not seem to support it, not a huge loss anyway. You can also adjust the scaling factor but if you choose to use this you will also need to adjust the animationScale parameter in the Spine.Entity settings. It does not map directly to the scale factor you plug into here so some experimentation is needed.

You will get three files as a result of the export. The png contains the images for your character. The atlas is the mapping between the images and the skeleton and the json contains the animation data.

The renderOffset adjusts where the sprite is rendered in relation to the characters position.

context.translate(x + this.renderOffset.x, y + this.renderOffset.y);

Once these are set you can call this.updateColRectToAnchorPoint() to set the collision box on your character. We can now configure the animations on our character. My character Peter will start off with the running animation with 0 delay and we’ll set loop indefinitely to true. We can also set animation mixing using setMixByName which will tween between the animations when they are changed and makes the transitions appear really smooth. The time the runtime takes to smooth between the animations is configurable and I’ve set them to 100ms. The longer this value is the smoother it can look but you will need to experiment to find the best value for your animations.

You can also set up a playlist of animations to run through using addAnimationByName. Once each animation is complete it will move onto the next one assuming you have queued one up. You will likely have one animation which will then loop indefinitely until a change in gameplay state forces a change. Using these animation queues you can create even smoother transitions than tweening alone.

If you are taking advantage of spine slots which allow you to change the images associated with the bones then you will need to call setSlotsToSetupPost when changing animation.

this.skeleton.setSlotsToSetupPose();

Lastly if you want to get the name of the currently executing animation you can use:

var animation = this.state.tracks[0].animation.name

Despite using the runtime we were still able to reach 60 FPS on mobile devices as old as 3 years ago like my Galaxy Nexus which is hugely impressive. We managed this using the CocoonJS container and we are looking forward to talking about our experiences with this in the future.

The Spine software is a pleasure to work with and putting together animations is great fun. The large amount of integrations for many game engines and platforms together with the great performance makes it a fantastic package. Highly recommended!

Here are the animations in action although I do not doubt that an experienced animator would be able to do better:

Recently were I work we had a PEN test on one of our applications and that highlighted that the federated authentication token for a relying party wasn’t being cleaned up correctly when logging out. After sitting down and working out what was cause for this problem I thought I would share my findings and the solution.

The problem

At work we use a custom session security token cache to store the token so we don’t have to pass around so much data to and from the client. When logging out from a replying party using a federated sign out e.g. “wsignoutcleanup1.0” the WIF code base should use the federation authentication module (FAM) and the “SignOut” method to get the session authentication module (SAM) and tidy up/delete the current session token. See the code example 1 below.

The session authentication module and its method “DeleteSessiontokenCookie” then checks that the property “ContextSessionSecurityToken” isn’t null before calling the actual code to remove the session security token from the persistent cache and the in memory one. See example 2 below.

Example 2

Now debugging the code and decompiling it I was able to work out that the session authentication module sets the “ContextSessionSecurityToken” when the “OnAuthenticateRequest” event is handled in the SAM. However, when signing out from the RP using “wsignoutcleanup1.0” this event is not fired or handled by the SAM if the FAM is defined above it in the web.config modules section (see below). No you read that correctly the order of the FAM and SAM in the web config appear to determine whether your token is cleared from the cache or not!

The fix

Now, I’m not certain but I do not believe an application should be dependent on the order of HTTP modules to function correctly. Am I missing something? A quick fix for us is indeed to switch the order of the modules in the web.config to get the “ContextSessionSecurityToken” to be set (See example modules below).

Additionally I can also add some code to the FAM to do manually set the property on the SAM (see below). Both approaches feel wrong to me in that they fix an issue in the underline WIF implementation. Well potential issue…