a little neat thing about git gui

I just learned about this neat feature in git GUI.

When you click on filenames, you can see the diffs on the right side on the window. Nothing new here.

The neat thing is that instead of clicking on the icon beside a file to stage all the changes in it, we can click on the file to see its diff, and then right-click on a particular diff line and choose "stage hunk for commit". There's also one for single lines of changes. What that feature does is it lets you commit only parts of the file, which is great for .NET Web.config files and for those times when you only want to commit the one character fix and not the 100 lines where you merely changed indentation.

Conversely, you can stage the whole file; then, right-clicking on a change on the diff panel will show "unstake hunk from commit", which means that change won't be committed.

For the keyboard people, the command line version of that is git add -p.

"Ajax calls don't render in IE"

Yesterday, one of my co-workers ran into an issue where ajax calls would simply refuse to render in IE. You could see the call returning a 200 from Fiddler, but it just wouldn't render any HTML (we were using Prototype's Ajax.Updater, btw).

It's a really puzzling bug but as it turns out, that exact same bug had happened to a different co-worker a few months ago. The ugly thing about this bug is that it only shows up when a project is rather complex (this particular one has a few dozen branches, hundreds of thousands LOCs and maybe 10 people working on it at any given time). What's worse is that as far as I know there's no one tool that will tell you what's wrong.

So I'm here to share an idea that may spare you from quite a bit of grief.

The problem turns out to happen because there are lots of reusable modules and things that include things that include things (yes, as in PHP include() or require_once()). Because of the complexity, a view with a form ended up being inadvertedly ajaxed into another form. That is obviously not valid markup, but it will still render in Firefox. The problem is that IE won't render it, and it won't throw any errors either. The W3C validator won't help much either, unless it happens to occur to you to copy and paste the full generated source from Firebug into the validator (does anyone ever do that?).

tl; dr: un-nest your forms.

A neat pattern

This neat javascript pattern just came to my mind. Consider this class constructor:

var Base = function(o) {
  for (var i in o) this[i] = o[i];
}

Pretty basic constructor, right? This class can have a prototype and we can subclass it like so:

Base.prototype = {a : 1};
var Sub = new Base({b : 2});
var sub = new Sub();
sub.a == 1; //true
sub.b == 2; //true

It just occurred to me that since a constructor is a function, it can also be call()'ed, like so:

var A = function() {};
A.prototype = {a : 1};

var B = function() {};
B.prototype = {b : 2};

Base.call(B.prototype, A.prototype); //class B extends class A

var a = new A();
var b = new B();

Base.call(b, a); //instance b extends instance A
Base.call(b, A.prototype); //instance b extends class A
Base.call(B, A); //static B extends static A

I've seen the extend() pattern pretty much everywhere but I haven't come across anything that uses this same Base function as a class constructor as well as an general purpose "extend()" / "clone()". I wonder if anyone uses it like this.

Ripple - a simple js REPL tool

I wrote a quick tool last night to help me teach people about javascript's prototype-based OOP. It's up on github (MIT licensed). Suggestions welcome.

Demo here

LLVM-Lua

I should take a peek the source code when I get some time.

Eye of God

Looks really cool. For some reason, there are people selling that same image.

One shot from Hubble.

Redis

A key-value database.

Funny, I was actually thinking about implementing some of the architectural features (namely, the async io) for my pet project.

Object relationship oriented programming

Lately, functional programming seems to be getting a lot of attention (so much so that OOP no longer looks like the cool kid on the block). But, at least for me, OOP is still very much alive and is useful to organize code.

What I have noticed about my code as I read more about FP and play with languages like clojure is that I now try to make objects represent not objects, but generic concepts that encapsulate relationships between objects.

The main difference between thinking in terms of relationship containers and how I used to think about OOP is that methods that deal with more than one thing don't live within one of the objects that it applies to; it lives in a separate object where the interaction happens.

For example, instead of

person.feed(dog);

I'd now call a feed function from an object where both person and dog are part of. The hard part is figuring out what this object should be. It depends on the application. Maybe I could have written it this way:

class CountrySideLife extends Lifestyle {
  public void feed(Person person, Animal pet) {}
}

Maybe that's overkill and I can get away with "class Main", since this is a throw-away example.

The point, though, is to not think so much in terms of object x does y, but function y happens in x.

The downside of thinking about relationships is that you don't always have a clear cut idea of what they are (especially if your business requirements change a lot), so designing the relationship classes prematurely could mean shooting yourself in the face.

The upside is that code written like this looks top-down and is easy to read and understand.

Of course, the old paradigm of object x does y still has its place. Sometimes a self-contained class just makes sense. But for higher level code paths that deal with a lot of objects and relationships, the paradigm of function y happens in x helps me organize code when I'm not sure which object should encapsulate what function.

Intro to compilers (Python)

Looks like a nice resource.

"Why" doesn't help me

Lately, I've been running across a gazillion blog posts with a title that starts with "why".

The funny thing about these types of articles is that if you search enough you can find a bunch of them that say roughly the same things, give or take a bullet point. But when you search for how someone fixed a particularly nasty bug in some particular API, you're lucky if you find one obscure blog post (usually 2+ years old). And in news aggregation places? Forget about it.

Why don't people blog about implementation woes more? Are they too busy coding, or not coding enough? I wonder.