In the last few months, I’ve interviewed a lot of front end developers. I’ve also sat on the other side of the table, interviewing for new roles of my own. So I’ve lately thought a lot about how this process works – and how both sides often miss each others’ perspectives. In the next few posts, I want to give developers looking for new roles an insight into my perspective as a hirer. In this one: what happens when you send your CV, and what happens when I read it.
I’ve recently had some fun writing a browser quicksort.
In my last post, Testing Knockout.js Web Applications, I explained how to unit test a simple viewmodel using Karma and Jasmine, so you could validate the values and methods on the viewmodel bound to the DOM.
This is all very well and good, but what happens when we want to bind our model data to the document in novel ways? If we can’t use the standard Knockout bindings, we need to write our own. Using custom bindings to handle view concerns is a good pattern for keeping viewmodels manageable and making view code reusable. But how can we test them?
I’ve been working with Knockout.js for a few months now. I’m impressed, but one thing I’ve found lacking is much community documentation on how to test Knockout apps. I thought I’d write an introductory post on testing Knockout.js applications for those new to the idea – like I myself was, a few moons ago.
I’ve been working with Knockout.js on a commercial project for a couple of months now and think I have a decent sense of its capabilities. However, I’ve never worked with any other web application frameworks before and wondered how others felt Knockout compared to them.
So far I’ve been really impressed, but I’m not certain how much that is to do with Knockout and how much that is to do with not having to use jQuery to perform templating and update a ‘model’ that’s actually just a bunch of scattered global variables. Obviously, I’d been trying to keep a model – view distinction even with just jQuery, but the data binding alone is extremely onerous when you’re doing it manually.
It looks as though the original host of the excellent pSX PlayStation One emulator – psxemulator.gazaxian.com – has gone down. The site hadn’t been maintained in a while and I fear it may have been forever abandoned. As such, I’ve added the most recent version of the emulator to this site. You can find it here.
Besides being easier to configure than ePSXe, pSX comes with a rather handy MIPS R3000a debugger that’s very handy in reversing work. I used it extensively in writing my Long range enemy attack mod for Final Fantasy VII.
I’ve been using Knockout for the first time on a new project and have been pretty impressed. Recently, I had a need to implement a simple ‘group checkbox’. The Knockout documentation already provided an example of a ‘select / deselect all’ checkbox, but the behaviour I wanted was slightly different. I wanted a checkbox that would be unchecked when its children were disabled, checked when any were enabled and would select / deselect all if I toggled it. With a little research into ‘computed properties’, it turned out this is quite easy to do.
If you have a vector line path in Raphael.js and would like to style part of it – highlighting a section of a line graph, for example – you can achieve this easily using the
path.getSubPath() interface to get part of your path, then adding a new shape on top based on that pathstring.
Are you a programmer? Do you want to blog about your ideas, but want it to be as simple as possible? Octopress might be the tool for you.
As a software engineer working on a particular problem or technology, you probably find yourself making observations about what does and doesn’t work. But what happens to these insights? Writing them down in blog format can help consolidate your ideas, and it allows you to show your engagement to future potential employers. I want to talk a little about the blogging solution that I use, Octopress, and why I think it’s a great choice for software engineers in particular.