Testing, Refactoring, Patterns

I'm going to invent new abbreviation now. Testing, Refactoring, Patterns or TRP. The holly trinity of any good programmer and I'm going to talk about this things today, because many young programmers "those days" don't get the sake of the things right.

First things first. Testing.
I'm pretty much sure that you've heard this, but I'll repeat, that there's no excuse to not use tests. I know, many people think that it takes quite a big overhead and so it's boring, etc. I myself used to think like that, but believe me, once you start testing you won't stop. Think about it, do you know anyone who used to be a good TDD adept and then gave it up? I don't know any.

There's an edge which you should step over in order to become a good programmer and it's testing. The first time it will disturb you and you'll feel annoyed but then you will like it. Remember there are the things which you should get used to.

But keep in mind, many people do write tests, they madly covers each line of the code with tests, then write tests for tests and still produce a crap. And there's a reason, you should not concentrate on the tests themselves and make any kind of cult on it. Testing have it's own meaning and this is not an abstract safety, that's an ability to make your code better. Yes sir, you may write a good bunches of tests on your code and feel yourself safe but if you don't make your code better then, you was just wasting your time writing the tests.

Tests provides you an ability to improve your code safely. Once you have written some tests you may change your code, make some research, try this and that, find new tricks and do it safely. And once something went wrong you can easily see where and how it happened. Tests will teach you to write better code, and once you'll start to change your code you'll came to the second part of TRP.

Refactoring.
And this is the knowledge about how to change your code. Mr. Fowler had written an excellent book on this and invented a good system of "bad smells", the system which will point you at problematic parts in your code.

Yes, you may learn refactoring without tests, but then you will only suffer and won't ever open for yourself a truly power of the instrument. Refactoring needs practice, you should do it over and over until you instinctively will avoid problematic code pieces.

Once you will becoming better and better in refactoring you'll came to understanding of bigger parts of code and then you'll need the P of TRP.

Software Design Patterns.
It is said that patterns are for architects and team leaders only. But not in really. Patterns are trusted and many times rechecked software design solutions. They tell you how good people do it.

Once you started to practice refactoring you will need patterns, to not change your code blindly. Having patterns in your mind you'll do refactoring more consciously and more important you will try to make your code more standard, more understable for another readers and yourself first.

And yes again. You may start learn patterns separately of testing and refactoring but it won't give you much, case you won't be able to use it effectively without an experience in code refactoring.

Conclusion
TRP - Testing, Refactoring, Patterns. Those three things are wired tightly in reality and each one helps two another. You cannot be seriously good in any of those separately and should grow them up all together.

And do not be religious about the things, remember only the quantity separates venom out of cure. Teach yourself to feel the measure and you'll be gold.

Firefox 3 tries

Have installed FF 3-beta (Gecko/2008021416 Firefox/3.0b3), what can I say? Looks promising, they have revised many gui stuffs, now it looks quite nicer. And yes, as they had been promising, now it works with Cairo and renders native gtk widgets. That's cool.

But unfortunately, just as it was with FF 0.9 -> 1.0, FF 1.0 -> 1.5, FF 1.5 -> 2.0, all my plugins screwed up. No firebug, not firefox-webdevelop, etc. 8(

By itself FF 3, looks quite stable, had no problems so far, no crashes etc.

That's it. Will waiting.

Charged php-mode recharge

PHP is like a gangsta-rap. Everyone know that it's a bullshit, but from time to time do it for living.

So, as I had to support one of my customers with an old php-project recently, I've done some fixes in the charged php-mode. There are only minor fixes of highlighting issues, like the broken methods calls highlighting, $this_ calls lack, etc.

Get It Here

discovery.com seems to have nice round hole in their security

I was trying to register on their forum and accidentally found myself logged in under another user.

How did I do so:

1) Hit the Login/Join button
2) Proceed to the registration form
3) Feel it as they wish to
4) Enter instead of the desired username a username of an existing user
5) Press submit.

That's it. I've received the confirmation email and found myself under the user which was registered several years ago and have some posts. I even managed to create a post and now having the discussion.

Epiphany updates look well

Have switched source tags from feisty to hardy on my laptop's ubuntu yesterday. And found that epiphany now, similar to knoqueror in kde, follows the gnome look'n'feel theme.





Looks quite nice. And note, it's on the gecko engine. Unfortunately Firefox, still renders the gray standard buttons.

Recursive Camelization

Felt myself not much well since wrote a non-recursive camelization example in the yesterday article. So, now I'm fixing the lack ;)

String.prototype._camelize = function() {
  var _pos = this.lastIndexOf('_'), suffix = this.substr(_pos+1);
  return _pos < 1 ? this : this.substr(0, _pos)._camelize()
    + suffix.charAt(0).toUpperCase() + suffix.substr(1);
};
alert('_camelize_me_pleaze'._camelize());

That's it.

Binded Callbacks with Prototype

This article is all about using of the functions binding in callbacks when you're coding with the Prototype JavaScript Library.

We all know, that Prototype have got the Ruby's Enumerable module port in JavaScript. The idea is pretty simple, you've got a method where you put your callback function and when an object iterates through its stuffs it calls the function. Like that

var foo = function() {
  var two = [1, 2, 3, 4].find(function(item) {
    return item == 2;
  })
};

That's fine, but there's a problem. When you write code like that, each such callback function creates an own scope and when you try to write a code like below it won't work

var proc = {
  make_it_double: function(list) {
    return list.collect(function(item) {
      return this.double_item(item);
    });
  },
  double_item: function(i) {
    return i * 2;
  }
};
alert(proc.make_it_double([1,2,3]));

it will say you that there's no double_item function, and that's right, case it won't look for the proc.double_item function, it will search for the double_item method in the scope of the function object which you've sent as the attribute into the .collect method. (Which in the case will be the window object).

For such cases in the Enumerable module of Prototype defined an ability to pass another, optional attribute which will represent the scope in which the callback function should be applied.

.................
    return list.collect(function(item) {
      return this.double_item(item);
    }, this);
    // ^
    // +---- here it is
...................

With such a change the code will work, and you'll get the [2,4,6] alert.

That's nice. But if say you're implementing your own function which accepts a callback, and you don't want to pass the scope attribute. Something like that.

var my_proc = {
  handle: function(elements, callback, something) {
    .............................
    for (var i=0; i < elements.length; i++) {
      var something = callback(elements);
    }
    .............................
  }
};
var my_starter = {
  foo: function() {
    my_proc.handle([1,2,3,4,5], function(item) {
      return this.update(item);
    },....);
  },
  update: function(item) {
    return item * 2;
  }
};

How can you handle that? That's easy. Prototype defines an additional method .bind(scope_object) for the functions, which returns another function which has the same interface but will execute the original function in the correct scope. Say you may write it like this.

................................
  foo: function() {
    my_proc.handle([1,2,3,4,5], this.update.bind(this),....);
  },
................................

Looks prettier, but this is not all again. What if you need not just to bind an existing method, but to make some additional handling, like that

................................
  foo: function() {
    var something = 'foo';
    my_proc.handle([1,2,3,4,5], function(item) {
      return something == 'foo' ? this.update(item) : 'bla';
    },....);
  },
................................

What if you want a dumn function, like you used to have it with blocks in Ruby? That's easy, and kinda beauty. You can do it with that trick.

................................
  foo: function() {
    var something = 'foo';
    my_proc.handle([1,2,3,4,5], (function(item) {
      return something == 'foo' ? this.update(item) : 'bla';
    }).bind(this),....);
    //  ^
    //  +------------ Here you go
  },
................................

That's simple and maybe strange looking but it's handy. You may bind your functions on fly, and this's a quite often case.

And if you look closer you'll see the idea is in calling construction like (function() {}), and actually you may go further and use it more like in the functional programming style. Say like that.

var caMeL = (function(str) {
  var parts = str.split('_'), camelized = parts.shift();
  for (var i=0; i < parts.length; i++)
    camelized += parts[i].charAt(0).toUpperCase + parts[i].substr(1);
  return camelized;
})('ca_me_l');

This is probably a quite dummy example and I should make it recursive to feel myself like a true hacker, but it shows the idea. You may apply functions on fly just in the time of their creation. Browse the Prototype's source code and you'll find lots of such tricks in there.