How to set-up BankID

Today I had the pleasure of providing IT support for my father,

Well, let me describe the process to you.

Click login.

Click BankID.

Authentication failure, please download BankID.  

Download BankID.

Click login.

Authentication failure, please download BankID.  

realisation that they're talking about their BankID certificate

Click fetch BankID.

Please input your SS no and the 4 digit pincode.  

...What pincode?

Click no pincode.

A letter with a pin will be mailed to you in 6-8 weeks.

6-8 weeks later (today).

Click fetch BankID.

Input SS and pincode.

Please select method of delivery for one-off authentication code, 
SMS (instant) or 
Post (another 6-8 weeks)

Select SMS.

Authentication failure:
You have no cellphone registred with us, 
call support at -phonenumber-.

Call support.

To authenticate your number, please change your pin.

Change pin, fail, repeat, fail, repeat, fail, call support again, talk to human, bicker for half an hour, change pin, hangup.

Back to website.

Click fetch BankID.

Input SS and new pin.

Select SMS

After a few failed attempts and one lunch, get authentication code, approve terms of service and download certificate.

BankID program pops up and asks to provide PIN for certificate.
Try a number of variations.

Failure ref 10025.

Google ref 10025, find blog post consisting of mostly cursing about BankID and ref 10025, find specification for pin in comment to post (12-30 characters, at least 4 letters, at least one number).

Go through the fetching process again because the old one timed out by the time you found out how to do it.

Certificate downloaded, stored and password protected, ready to go.

Click login.

Enter the complex PIN for the certificate.

Select letter or SMS for one more authentication code.

Get code via SMS, click login.


...I need a drink.

Posted on in Rants
Tags: BankID Skandiabanken

How I stopped worrying and love the JavaScript.

If you would've told me ten years ago that I'd be advocating the use of JavaScript for anything other than the teeny tiniest bit of flair, chances are I would've punched you right in the muzzle.

Then again, ten years ago, JavaScript was a Terrible language, absolutely terrible. The current generation of JavaScript in use today is ECMAScript 5.1, which was released in 2011 (Internet Exploder excluded of course, they're still using ECMAScript 3).

While it's true that, in the beginning when JavaScript was first invented, it was designed as a shitty little scripting language (by the name of LiveScript) used to augment browser behaviour for Netscape users. JavaScript started out being an interpreted scripting language, with slow and inefficient interpreters. Today however, this is no longer the case, things have changed.

The JavaScript engine in Google Chrome, the V8 JavaScript Engine, is not an interpreter. V8 is a JavaScript compiler (actually a set of compilers, but that's not important right now).

Google's strategy for speeding up JavaScript was to compile it down to native machine code. And for JavaScript that has been optimized for use with V8, execution is almost as fast as code written in a "real" language such as C. So I'd call V8 a huge success, and it's still getting better. So the excuse of avoiding JavaScript and client side scripting because it's terribly slow and inefficient, is pretty much null and void at this point, it's a moot argument.

What about JavaScript as a language? Is it still a terrible experience to code in it?

Well, yes and no. It has it's fair share of quirks, still, but it has evolved a lot since the '90s. Short answer is, it's gotten better. And it's still getting better. I'm told that ECMAScript 6 is going to further improve the language's syntax, and add some features that are sought after. One can only hope that the adoption of ECMAScript 6 will be sufficiently fast.

Then there's the whole JavaScript eco-system that has evolved in the past few years. It's downright amazing how far it's gotten in a few short years. We have front-end scaffolding utilities such as Yeoman, task runners such as Grunt, and package managers such as Bower. It's gotten to the point where the front-end tooling is matching that of any other area of development.

We've had an increase in speed by several orders of magnitude (not even accounting for Mores law). We have a good set of tools, with more and better tools on the way. we have some amazing looking modern frameworks, such as Meteor. we have unit testing, we have virtually anything you can think of that you'd need to start developing a rich client side application today.

So go download Yeoman (requires Node.js) and start building your client side application today. It comes bundled with Grunt and Bower, so you can take a good look at the multitude of packages already available to you with % bower search.

Don't worry about whether or not JavaScript is fast enough, it is, and will only get faster. Or that it's a language reserved for rank amateurs, it's not, take a look at Gmail.

Posted on in Uncategorized
Tags: JavaScript

Re-learning everything.

A few weeks ago I started coding on a project for a client. While it is true that I've been doing web development off and on for the past ten or so years, there's one thing I've actively avoided; Javascript.

To tell you the truth, most of my work has been backend code. I've more or less ignored the entire frontend side of programming, regardless of environment. The user interface has always been secondary to me. That changed a few years ago, when I was reading about UI first software development.

In particular it was these words:

"When writing end-user software, UI design should really come first.
To the end user, the UI is the application."

This of course, made a whole lot of sense. The user doesn't give half a rats arse how pristine the backend is, or how flexible and modular the code is. If your UI is slow and ugly, your whole program is slow and ugly.

So what do you do when you need to make a snappy feeling web based application? Javascript. As a long time defender of the plain HTML, suddenly realising the need for Javascript is uncomfortable to say the least.

In Javascript's defence though, Javascript has come a long way in ten years. Javascript processing in browsers has increased by orders of magnitude. And with shiny frameworks such as JQuery, it's almost easy to use (if you don't need to do something advanced).

The project I'm currently working on however, required more than just standard JQuery. It called for a SPA architecture, which unfortunately means that it have to be built almost entirely with client side code, i.e. Javascript and CSS. Fortunate for me there are a lot of good frameworks on the market for client side development. So far I've gone for following:

Truth be told I'm feeling slightly overwhelmed. While I've used Bootstrap and JQuery in the past, this is really the first proper client side project I've worked on. It's a learning experience, to say the least. Learning to handle a half dozen new libraries at once is a bit of a mess, but the documentation is good. It's just a bit annoying having to spend ten times as much time reading documentation as I do actual programming.

In the end I've gotten most of things to work, next up on the todo list is to integrate Mustache and Knockout. Hopefully this will make it possible for me to split my HTML out in multiple template files. As it is, everything is in a giant file, because I can't figure out how to make Knockout load external template files...

Getting all of this to play together is a bit of a challenge, but who doesn't enjoy a good challenge?

Posted on in Projects
Tags: JavaScript KnockoutJS RequireJS Moustache SPA

Presenting: Augustus.

I figured it was time for me to get with the times and start one of them blog things that is so popular among the kids these days. And what better way to start a blog, than to write yet another blog engine?

I present to you, the worlds first blog powered by Augustus, a static page generator (that totally isn't a rip-off of jekyll) written in php 5.4.

So far it doesn't do much, and some features are somewhat broken. The few things that are done however are:

  • The testing server accessible via gusto run, courtesy of php 5.4.

  • The creation of new posts and pages.

  • Automatic indexing of tags and categories.

Some of the things that will be working, when I get some more time to work on the engine are:

  • Archive indexing.

  • Improved post management.

Regarding the name

I am a huge fan of animation. And Augustus, or Gusto, is the name of the character played by Rob Paulsen in Disney's Adventures of the Gummi Bears. Augustus "Gusto" Gummi. And that is a character that I still to this day think is a badass.

Posted on in Projects
Tags: project gusto blog engine