Better explaining the CAP Theorem

Today, I thought a lot about how to examine different databases. Choosing a database is often a daunting task. There's a lot of confusion, a 'theorem', and more than all, the immortal proverb 'not one size fits all'. As if it helps.

One of the first things that you realize, when examining NoSQL distributed databases (and how could you not)is that these days databases are like cars: they're all good. Old fashioned SQL databases can scale in and out, horizontally sharded over several machines to achieve high availability. NoSQL systems claim to be consistent. What difference then does it make what database would you choose?

The Availability and Consistency that I mentioned comes, of course, from the misunderstood CAP theorem, that - so people say - states that you can only choose 2 out of the 3

• Consistency: every read would get you the most recent write
• Availability: every node (if not failed) always executes queries
• Partition-tolerance: even if the connections between nodes are down, the other two (A & C) promises, are kept. 

Usually its depicted in a nicely equilaterl triangle, as this one from Ofirm:

There's a nice proof and explanation of it in this 4 minute video here. But if we think about it, and also see some of Brewer's (the theorem author) later remarks, we'll see that the 2 out of 3 is really 1 out of 2:

It's really just A vs C! 

And this is simply because:

1. Availability is achieved by replicating the data across different machines
2. Consistency is achieved by updating several nodes before allowing further reads 
3. Total partitioning, meaning failure of part of the system is rare. However, we could look at a delay, a latency, of the update between nodes, as a temporary partitioning. It will then cause a temporary decision between A and C:
1. On systems that allow reads before updating all the nodes, we will get high Availability
2. On systems that lock all the nodes before allowing reads, we will get Consistency

That's it! And since this decision is temporary, it exists only for the duration of the delay, some may say that we are really contrasting Latency (another word for Availability) against Consistency.

By the way, there's no distributed system that wants to live with "Paritioning" - if it does, it's not distributed. That is why putting SQL in this triangle may lead to confusion.  

My javascript inheritance journey

I wanted to delve a little on the Javascript instance-based, prototypical inheritance.

The journey is not a short one.
 
The first point of contact was the 'new' keyword great and short explanation.

Then went on to try and understand John Resig's simple inheritance library. Well, I didn't. Not only that, it didn't work easily with require.js framework, which I'm using to separate the code into modules.

After reading some good posts by Ben Nadel and other introductory material, I stumbled upon the great DailyJS simple inheritance scheme. This was really simple.

And it worked. Almost. More on that later.

I had to use it in real life scenarios, which led to some experiments. Here's one.

function Base () {
    this.modules = [];
    this.name = "Base";

    return this;
}

Base.prototype =
{
    initModule: function () {

        // init on all the modules.
        for (var i = 0; i < this.modules.length; i++)
            this.modules[i].initModule();
    },
};

function Derived(name) {
       this.name = name;
}

Derived.prototype = new Base();


var derived = new Derived();
derived.initModule();

and it works!

as I see it, we have here inheritance by using the "Derived.prototype = new Base();" line. The prototype of Base is copied to the prototype of Derived. When derived.initModule is called, Derived does not have this module so it is taken from the Base. when running the initModule, 'this' is still the variable 'derived'. initModule can refer to the this.modules array without a problem.

Does it mean that the variables instantiated at the constructor function are put into the prototype?

No. 

It means, as the venerable Daniel Howard put it, that "It executes the constructor function, using the newly created object whenever this is mentioned."

So, the modules variables belong to Base. initModule belongs to Base.prototype. Exactly as the code is written.

So, what didn't work?

Well, consider the Derived overrides initModule with a different one:

Derived.prototype.initModule = function () {
   
    // NOT WORKING YET calling base class functionality
    //this.prototype.initModule();
    
} 

I'm trying to call base class method, from a derived class instantiation. The reason it does not work, is that Derived.prototype was never assigned to. So it is 'undefined'.

:(

Maybe something even simple? I tried Crockford's Prototypical inheritance. His explanation is great, but I felt (maybe wrongly) that his solution has its shortcomings,  as I mentioned in my question here. Got a pretty straight answer there...


What should I do now?

Now, once inheritance is (better) understood, I think I'll go and explore some inheritance libraries. 

Klass

I added klass.js By Dustin Diaz. Very cool. Definitely does the work - extension works miracles, and not only that, I can easily call the parent method by using this.supr();. To top that off, it adheres to the common.js AMD standard for inclusions. Since I'm using require.js to separate my code into modules, its easy to work with.

Only issue is that it impedes debugging. When inside any object, try looking at 'this', using the Chrome debugger. 'this' is very obscure: fn

and here's the dilemma. We need something better, but there's no time. Should we stay with klass? Build our own? Explore more?

I'll leave you at that.

Dynamic, widget based Web and SEO

In the movement to a dynamic, widget-based Web (meaning, no-page-base), one of the biggest risks is SEO. If your web site is one page, and its states differ only by a hash tag (a common technique) - will the different pages be indexed by Google, Bing and the other fellas?

Let's see. I've set up two slides using Google Doc presentations:

• Lior Messinger is cool: here
• Lior Messinger is uncool: here

This was done on October 19th, 2012 at 3PM. 

At 3:05, No results found for "Lior Messinger is cool".

Let's see how much time it takes Google to index it, given we've provided a first link to here from this blog.

Once it is indexed, we'll examine the hash tag access.

Stay tuned!

Update 1:
3:06PM: almost as soon as I saved this blog post, Google found it when search for "Lior Messinger is cool". No word on the presentation
No word on it on Bing

Update 2:
2 Days later: Both Lior Messinger is cool and Lior Messinger is uncool point to the first page of the presentation. This means, that hash tags ARE followed by the crawler. But - they are NOT shown in the Google results links

Ok.

And, to this day, a week later, neither Bing nor Yahoo picked up any of these pages.

7 Technical Management Techniques

Often it is the case, where team leaders and managers at software companies are ex-geeks that climbed the ladder to reach a managerial position. Well, "climbed the ladder" is really a misleading metaphor. First, who says managerial positions are higher, or better, than development positions? Some would argue the opposite. And indeed, in some companies, managers are offered optional rotations of management and hands-on R&D. Second, it is misleading since the less glamorous reality is that when companies expand, someone has to manage the newcomers, and those new managers where there at the right - or wrong - time.

Either way, geeks being geeks, social codes and human interaction were never their forte. How can they manage other people if they can't get a date without a facilitating website?

So, let me tell you some secrets. First off, the words 'Technical Management' in the title isnot what you think. You might think it's about management of technical people, but it isn't. It's really about the techniques of management. It's about knowing and using several technical and emotional rules, that would make the life of the manager geek (you?) so much easier, and would get results with less friction.

However, these rules and tips would not do the work for you. We are talking about Technical Leadership, but this post is more about the Leader part, and less about the Technical. The technical side deserves its own article, or maybe a book.

But there are some intersections. In your technical leadership, you can decide to follow either the Surgeon model or the Decider model. A Surgeon leader works as if he's a doctor operating a patient. He has a full staff - from nurses to residents - helping him do all the work by himself. The surgeon cuts, analyzes, takes a direction and on most cases, also stitches.

On the other side, a Decider (if I may quote someone) doesn't really have a concept or an technical ideology. It hears the opinions of the team, asks a lot of questions, and decides, this way or the other.

These are two well-defined extremes. As for you, you probably position yourself somewhere on this range - for better or worse.

When it comes to leadership, one needs to remember that management, as any other profession that deals with people, is highly complex and no recipes are to be found. One needs to understand the platform, the substrate for everything. And this platform is respect. This is what everyone is after. I think it's so important so I'll repeat it: respect is what everyone is after. Respect (self-respect included) cannot come without its sibling: humility. So if you have respect and humility, and you should, all other things will come easily. You will exert politeness, consideration and gratitude. You could give remarks and criticism without guilt and without being afraid of de-motivation. Most importantly, you will receive respect in return.

Now, after this short introduction, let's cut to the technicalities, to those techniques that would help you transfer this sought-after respect:



Technique 1: The Oreo

As Noel Coward once said, I love criticism just so long as it's unqualified praise. No one likes to be criticized. on the other hand, critique can be a gift someone receives as an opportunity for improvement. And you will need to criticize your guys since you are probably would have, sometimes, different ideas than them. So make them an Oreo sandwich: start with praises, put in the critique, and end with some more praises. Something like: the banner design is really cool. I think though the middle block should use Ajax, and not PHP as it is now. Still, overall the new node looks awesome!

Technique 2: No Buts!

But is a traitorous word. It tends to minimize whatever came before it, and sometimes simply nullify it. For example, when you say something like "listen, this piece of code is elegant, but the performance is bad". What the poor guy is left with is that the performance is bad. And thats taking a hit after investing so much thought in making it elegant (hey, elegance in code deserves another post altogether). Yes, she would survive, but why chip away in the motivation, if you could just use another word instead of the 'but'? What if you would just replace the 'bug's with an, say, and? Imagine now how the sentence would sound like, and tell me this is not a brilliant technique.

Technique 3: do you know the real meaning of assume?

Many a time we tend to think the other person is just an extension of our own self. This belief can be found in couplehood, as well as at work. And at those two places its exactly one of those beliefs that complicates matters. So here's the latest: The other person has different opinions, different priorities, different ideas. So when you assumed that she was going to do something in a certain way, your mistake was that you didn't convey this assumption to her and transformed the assumption into a discussion. Because when you assume, you make an Ass of U and Me. So Talk. Ask. Discuss. Just don't sit there at your desk and assume things will go right.



Technique 4: Praise in public (condemn in private)

With today's open space environment, the use for private areas is even more in demand. But dont make the mistake of using it for telling your man how much his work was good. Try to find any opportunity to praise him in public. And the opposite is true as well. Don't let him look like a fool. It's bad for him (or her), and it's bad for everyone else too: do you think they really believe its saved only for this poor guy? They are very much afraid for the moment it will get to them!



Technique 5: Responsibility goes with authority

Remember how they told us to delegate? well here's a quiz: how can you delegate and still be the manager? The answer, my friends, is that you can't. When you give someone the responsibility on a certain subject, he's the manager. And this responsibility must be accompanied by authority, too. The authority to make decisions, and the authority to make mistakes. Because those who don't make mistakes, are those who don't make anything. If you wan't to delegate, you should want that they will make some things.

Technique 6: Save the perfectionism for yourself

If I may choose only one technique, that would be it. Oh, how many managers did I see that thought their demand for perfectionism serves the cause. Here's a news flash: you aren't perfect. And your job, as a manager, is to understand that no one is perfect - but not to accept it. Remember: everything we have today, is a result of gradual improvements. So when the next engineer declares a done task, test it, compliment him, find the flaws, and continue to the next layer of improvements.

Technique 7 : Blame has three fingers pointed at you

This picture should be remember by everyone who feels the urge to blame:

As everyone can see, when you point a blaming finger and accuse someone for doing a stupid, stupid mistake, what really happens is that one finger does point towards the accused, one finger points up to bad luck, and three fingers pointing at you. Get that? you do the math.

Be humbler!

I think it's pretty amusing to see how many applications jump when you try to exit them and immediately ask you 'Are you sure?'. If you say 'yes' some would add 'Positive?' '100%?'

It's a clear case of developers' separation anxiety mixed with hubris. Guys:
a. Be humbler
b. Get a life!
If the user quits the application, it's most likely not by mistake. She really wanted to leave. So, you're not really helping the user by posing yet another message box, another movement of the cursor, asking for another click. Let her go and God Willing, she'll be back soon.

The charm of the bourgeoisie or: are we going backwards?

I'm not sure how wise to let the whole world know, but my favorite music recently has been Arabic and Italian. What a mix! Kudos to Last.fm. Their music collection and the radio stations they offer is just superb. Nagat El Shaghira is so cool!

So, it wasn't so surprising that when I saw Last.fm app offering on my XBox I clicked, installed, and immediately had all my beloved stations - Ya Habibi - on my Xbox. And from this simple experience, I have gathered several interesting insights.

First, that game consoles are becoming like the iPad (hey, it's Pad, not Fad) devices, and vice versa. The process of getting a Last.fm station was strikingly familiar to iPhone app installations. Select -> Install -> Run -> That's it. Hmm, and where is the keyboard? yes, the lack of a real one is also a surprising similarity. Oh, and what about the one-app-at-a-time concept? Wait a minute! there's something here. What's going on?

What has been going on is the second interesting fact. The Back To Basics movement has been with us for some time now. Operating systems, applications, and more than all, programming teams around the industry have started to focus again on Computer Science 101 - improving performance - and, God Forbid, on dropping features. Here, we see even a stronger tread backward: back to single-tasking operating system, back to primitive input devices, back to focus.

But this is only natural. And natural is the keyword here. Some of the user-facing people understood, finally, that computers has become too complicated. If not for us, then for our mothers. And it is our mothers, our girlfriends, and our kids, that they want to get a new market slice from. And for them, focus is one. They know, that they cannot drink and drive: they cannot multi-task. They can only do one thing at a time. They don't need 102 keys on the keyboard, if they only want to listen to some cool music. Just like when they flocked to google.com, it relaxes them - and me too - to see a single user interface control on screen. Simpler is super.

All of this is just another chapter in the inevitable journey of the PC from the home office into the living room. You have to make it friendly. Like the charm of the bourgeoisie, it is simply -- convenient. Simply friendly. As Nagat sings: Shabna, Shababna. Our friends, our youth. Friends must come easy -- and simple.

Forget performance. Let's add another feature!

Sometimes i think I'm a Benjamin Button kind of guy. As I grow older, I tend to do young, stupid things. For example, I have carelessly dumped my old Firefox in favor of a new Chrome browser. Then, I threw away my Palm Centro for an iPhone and reformatted my hard drive after my laptop slugged away for weeks. And as I done all this, I found out there's no turning back; and sometimes you feel you've lived your whole life in ignorance.

Google has marketed its browser as the fastest browser around today. Even if the performance is not as good as they claims, the minimalistic feeling certainly makes you feel this way. Apple didn't have to market anything. The amazing 3D effects in the iPhone's user interface and the smooth application performance market themselves. With current Vista performance I tried linux a few times although I quit it when gopc.net didn't allow me to install any applications.

All of these performance upgrades have one thing is common: out: new features; in: a lot of performance boosts. And here's the big question about all these performance upgrades. Where have you guys been all of those years? Have you forgot about us? Have you been deserted in the feature-land with all bridges burnt? Sometimes it makes me wonder. For years, Microsoft have added more and more and then more menu items on its Office applications - just enough to confuse you and obscure the real important ones. And who remembers the 'Offline pages' feature on early IEs? or the newsreader that came along with them?

I can't blame all those product managers who succumbed to the feature pressure. The "just throw more hardware at it" approach used to work on some situations, and was definitely enough sometimes. And Moore's law predicted that this trend will continue, maybe ad-infinitum. One might think, that it didn't reach the good developers. Well, you are right about the good ones. But all the rest - and more so, their managers - completely forgot to ask the right questions and never got the time to architect it right. Let's get it out there, fast, they said, and then let's get the next version, too.

But not any more. In a competitive environment, finally, finally, some companies are making products that at last gives me the feeling that I'm sitting next to a modern computer.
As we saw how Windows Vista is being actively cut back (can you imagine, features actually dropped); as we saw browsers like Chrome take off with an easy start; as the iPhone exploded with popularity, we knew: performance is back. And I hope it is here to stay.