As a software developer your work is never complete unless someone is using what you have done.
Author Archives: frostfang83
Reordering Lists
‘OMG how do we reorder this list in an efficient way…’
One nifty little tip I picked up reading CouchDB: The Defeinitive Guide but never used (until now) was to use a float / decimal instead of an integer when you need to store an order of some sort (… get it…sort… don’t hate).
The reason for doing this is is when it comes to reordering the items in that list and eventually saving the changes.
Say you have a list of objects with a display order as an integer:
...
[
{ name: 'Mary', order: 1},
{ name: 'Tanya', order: 2},
{ name: 'Mel', order: 3},
{ name: 'Jan', order: 4}
]
...
Lets say you move Mel from position three to position one so in affect Mel has order = 1.
...
[
{ name: 'Mel', order: 3},
{ name: 'Mary', order: 1},
{ name: 'Tanya', order: 2},
{ name: 'Jan', order: 4}
]
...
Then when we commit to storage we are going to need to adjust the order field for some (if not all in more complex examples) meaning we will be touching many records instead of just the one record we essentially moved.
Enter the float.
Lets change the order data type from an integer to a float:
...
[
{ name: 'Mary', order: 0.2},
{ name: 'Tanya', order: 0.3},
{ name: 'Mel', order: 0.4},
{ name: 'Jan', order: 0.5}
]
...
Now lets Jan from position four to position two.
...
[
{ name: 'Mary', order: 0.2},
{ name: 'Jan', order: 0.5},
{ name: 'Tanya', order: 0.3},
{ name: 'Mel', order: 0.4}
]
...
Now when we need to redefine the order fields but in this case we don’t need to touch every record, just the one we moved. How we achieve this is by looking at the surrounding records of our new position and from those we find the median of the two order values.
(0.2 + 0.3) / 2 = 0.25
And viola we have our new order value and when we commit this to storage we are only touching one record.
...
[
{ name: 'Mary', order: 0.2},
{ name: 'Jan', order: 0.25},
{ name: 'Tanya', order: 0.3},
{ name: 'Mel', order: 0.4}
]
...
If you are moving the item to the start of the list you can use 0 as your first value and if moving it to the end of the list you can use 1 as your second value in the above formula.
Please note that we are working with complete lists here. If you are only seeing a portion (or page) of the list then you need to take this into account when you move an item to the start or the end of your portion. I’ll let you decide how to do that.
However…
As you may have guessed if you are constantly reordering the list then your values may get a little crazy (0.123332324522333395 etc…). This isn’t a bad thing but eventually your precision might be affected. So it might be worth scheduling a routine that takes the complete list and redefines the values to something more civilised. Food for thought.
Happy coding.
Link
Replacing the Performance Appraisal
The managers letter really hits home for me. I feel like i say things to my manager but then it disappears into the ether.
Macarons #Zumbo style
Someone got the toilet roll
Link
I’m sure it rings true for some people.
Big day #tired
Too much fun for two puppies
Scope in JavaScript (Learning is fun)
What would you expect when you ran the following code JS snippet ?
if (true) {
var x = 69;
}
alert(x);
Today I found out some interesting things about scope in JavaScript. At the moment I’m reading the book Secrets of the JavaScript Ninja and in the chapter I’m reading they are going back through the fundamentals of functions.
Here is one of the points made is around variables, functions and their scope:
- Variable declarations are in scope from their point of declaration to the end of the function within which they’re declared, regardless of block nesting.
- Named functions are in scope within the entire function within which they’re declared, regardless of block nesting. (Some call this mechanism hoisting.)
- For the purposes of declaration scopes, the global context acts like one big function encompassing the code on the page.
The code at the top will actually alert 69 when run. This came as a bit of a shock for me because from my background of C# / Java I have always assumed x would have been out of scope due to the block level context of how those languages work. When executed i expected to see a healthy null alerted.
This whole time I have made the assumption that these same rules from my experience with C# applied with JavaScript. This realisation that part of the fundamentals of what I have learnt is a little flawed is a little humbling but it really opens your eyes to what you are re-learning and quite honestly it’s awesome.
I can’t believe I have been using JavaScript for so long and have never picked this up. I guess the situation never came up in anything I’ve written (or it has and no one has found it yet). Sure the situation would rarely come up and it’s not like what you are doing is wrong, you just don’t feel like an expert anymore and that’s the humbling part so it’s bitter-sweet.
The great thing is at the moment i feel like Neo (Matrix Movie) when he’s in the chair and Link just ran the procedure to push Kung Fu 1.0 into his head, this will definitely change the way i write JavaScript.
I guess its another notch on the sword on the way to ninja status….
Or maybe I’m just holding the sword the right way round now :)
Understanding design patterns in JavaScript
understanding design patterns in JavaScript
An interesting read and useful if you are coding anything large in JavaScript.
