February 2012

There were 6 posts published in February 2012 (this is page 1 of 1).

Javascript Quicksort implementation with dynamic comparator.

[javascript]
Array.prototype.swap=function(a, b)
{
var tmp=this[a];
this[a]=this[b];
this[b]=tmp;
}

function quickSort(array,comparator) {
qsort(array,0,array.length,comparator);
}

/**
* NOTE: the comparator is a dynamic function you will define
like so comparator(a,b) {
if (a > b) return 1;
else if (a < b) return -1;
else {
return 0;
}
}
* it is up to you to determine the comparison logic between the elements.
* it’s particularly useful if you’re comparing objects and different properties
* inside them.
*/
function qsort(array, begin, end, comparator)
{
if(end-1>begin) {
var pivot=begin+Math.floor(Math.random()*(end-begin));

pivot=partition(array, begin, end, pivot, comparator);

qsort(array, begin, pivot, comparator);
qsort(array, pivot+1, end, comparator);
}
}

function partition(array, begin, end, pivot, comparator) {
var piv=array[pivot];
array.swap(pivot, end-1);
var store=begin;
var ix;
for(ix=begin; ix<end-1; ++ix) {
if (piv!=undefined && comparator(piv, array[ix]) < 0) {
array.swap(store, ix);
++store;
}
}
array.swap(end-1, store);

return store;
}
[/javascript]

The Painter that learned to meditate

It was almost 3:30am and his eyes had just opened from a short 10 second nap he didn’t foresee coming, The painter was exhausted

All day he was working on a very intricate painting, with hundreds of details to keep track off, he was a perfectionist and as he went to bed and lay in bed with his eyes closed, he was still planning the strokes he would take the next day to finish another portion of his painting, when all of a sudden he realized he was no longer in bed, he was in a dream, and he could remember being fully conscious and that this place wasn’t real.

It was almost as if he was holding on to a line used to send information from both sides of a black hole, only that this one doesn’t suck light, it sucked consciousness.

It seemed that in either of these states of consciousness the amount of information that was being processed by his brain was so much that it could hardly work in parallel, his dream state was borrowing enough brain power to render the graphically detailed context only the mind of a painter could render, he realized this was the reason his dream state of mind was more like a movie on which he had no control of what was going to happen next.

The painter thought of all this, and thought of how every time he was curious to try and see what meditation was about, it all seemed to him like a croak of shit, just a voice telling him to imagine all these things and to somehow feel them, that was too hard to achieve, at least for him it was.

But this, this was the real deal, so he would practice every night this self-taught form of lucid dream meditation, he’d just try to focus on something really hard just waiting for his body to give up and go to sleep, yet his conscious mind would end up in the dreamworld where he’d find all sorts of answers to life, nobody had to explain anything.

Licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License by Gubatron http://gubatron.com

How to shuffle a List (or Array) in Javascript

[javascript]
/**
* Returns number starting from offset up to n-1
*/
function getRandomWithOffset(n,offset) {
return Math.floor(Math.random()*n+offset);
}

/**
* Returns random integer from 0 to n-1
*/
function getRandom(n) {
return getRandomWithOffset(n,0);
}

/** Fisher–Yates shuffle algorithm O(n) */
function shuffleList(list) {
for (var i=list.length-1; i>0; i–) {
var j = getRandom(i+1);
var buffer = list[i];
list[i]=list[j];
list[j]=buffer;
}
}

/** Usage example:
var myList = [1,2,3,4,5,6,7,8,9];
shuffleList(myList); //after this the list has been shuffled.
*/
[/javascript]

Note: This is a simple linear algorithm to shuffle. If you need to do some serious shuffling, say you’re creating a poker game or something where it’s crucial where nobody can predict the order of the cards DO NOT USE this algorithm, go for something more complex.

The tables are turning

The internet already allows for zero cost content distribution to large amounts of people with technologies like BitTorrent.

As the time goes by, labels will be lucky if they’re still getting artists signed, sites like Bandcamp and YouTube empower artists to go directly to their fans.

The tools at hand no longer create barriers for non popular genres to reach their audiences, the adoption and advance of smartphones and mobile networks will make it even easier to distribute content to your fans, right to the palm of their hand.

I believe the long tail of music taste is a far bigger market than the one the big labels have been focused on all these years, and that long tail is very reachable today by anybody with internet access (which is starting to spread massively on mobile devices).

When most content creators in the planet realize this, the attention of file sharers will be scarce and I think it will come to a point on which they’ll be willing to pay to reach the very audiences that will care about their work, at that point they will pay to share (think Google Adwords for content). Relevant discovery and recommendation tools are be very important for the massive amount of independent content being created every day.

Bands already want to share, Creative Commons licenses are here to show us what copyright should be like on the internet, The tables are turning and the channels are here and getting better and better.

Now extrapolate to every form of content.

5 Object Oriented Programming Principles learned during the last 15 years

It was about 15 years ago when I first created my first class.

I went from thinking of Object Oriented programming as this awesome paradigm I should know about, I remember having all these mental models of what objects where and learning all this new vocabulary that I really didn’t fully grasp until years later when I was designing and implementing bigger more complex systems.

At first I remember looking at objects as a collection of functions that kept a common reference to keep internal states and missing out on all the great features of inheritance and abstract classes. Looking at “interfaces” and using them like a recipe without really knowing their true power, I look at the past and I was so limited, hopefully I’ll look at this post 15 years from now and think the same.

There’s lots of books out there on best programming practices you should follow, on this short post I’ll share with you 6 principles that I follow that I promise you will make your code behave really well, less bug prone, simple and elegant when it comes to Object Oriented design. This advice will probably apply better if you code in a language like Java or C#, I’m not sure if you can say these principles will apply 100% to other OO languages (for instance those that allow multiple inheritance)

1. DRY principle.
This is one of the most preached ones, and I will also preach it. DO NOT REPEAT YOURSELF. Really, don’t. It ALWAYS comes to bite you in the ass if you have repeated code. Only repeat yourself if it’s too hard to not do so or if you’re absolutely sure that you won’t repeat yourself a third time, but I promise you that third time will come if it’s not for you for the next guy maintaining that code.

The obvious benefit of not repeating yourself is that you get to maintain code only in one place, the added benefit will be that your code will almost start being written by itself like a perfect equation as it grows. DRY code will be reusable, maintainable and the other principles I’ll talk about are related to the DRY principle in one way or another.

2. Keep the scope at the minimum, be as private as possible.

Keep your variables as close to your local scope as possible. This will save you many headaches, will protect you from bugs in logic because you did something to a variable in place where it shouldn’t have been in the first place, and it will keep things simpler.

This also tells you that your classes should expose as little as possible. Keep your variables local, if they can’t be local, try to keep them as private members, if they have to be used by extending classes keep them private, only use public when you really know it’s ok to make something public and that nobody is going to break the behavior of your object if they play with things at any point in time.

Keeping scope at a minimum can also prevent issues on longer lived objects like singletons that might be accessed by different objects. If you abuse the use of object properties you could have one object changing the internal state of the object while another tries to do something and you’ll get unexpected behavior, this tends to happen a lot in multithreaded environments where programmers are not careful and forget objects might be accessed by different threads/clients at the same time, tight scopes will protect you.

3. Be functional
Sometimes you’ll be tempted to be lazy and not pass parameters on a method and think that you’re so clever by changing an internal property of an object so that another function in the object will then get it. Big mistake buddy. This can be equivalent to that advice from functional programming languages where you’re told that using global variables are a bad idea.
Yes, we have object properties for several reasons, but if the logic of a method depends on the state of a variable, you might as well be explicit and pass it in the method.

This is in a way related to keeping scope at the minimum, and to some extend related to the advice some give of keeping your objects as immutable as possible.

4. Only abstract classes are worth extending.
If you have control over the class you are about to extend (if it’s in your codebase) before you extend that class take a look and make sure that it’s an abstract class. Abstract classes are MEANT to be extended, so you can be safe that you’re doing the right thing here.

If you’re extending a non abstract class, you should probably be composing it instead. If you don’t have access to the code of the class you are extending, things could not behave as expected when you extend, not all programmers are as thoughtful as you are.

5. Keep Object lifetime as short as possible.
This goes back to keeping scopes tight and trying to avoid singletons as much as possible (as convenient as they might be), in the case of java the JRE has a better time collecting garbage and will save you from memory leak headaches. Put those factories to work.

Feel free to disent and share your favorite principles, If you’ve coded long enough I’m sure you tend to think about these things too and I’d love to learn from your experiences.