Saturday, February 28, 2009

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};, A.prototype); //class B extends class A

var a = new A();
var b = new B();, a); //instance b extends instance A, A.prototype); //instance b extends class A, 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.

Friday, February 27, 2009

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

Wednesday, February 25, 2009


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.


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

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.

Monday, February 23, 2009

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.

Friday, February 20, 2009

Friday, February 13, 2009


Reg Braithwraite wrote a bit of food for thought on productivity.

I think when people talk about productivity, they often set "high productivity" as goal to be achieved, when really, we can only measure the state of completion of individual tasks. Wrote a test unit. Check. Implemented form validation logic. Check. Designed wireframe. Check. Achieved high productivity. Huh? What does that even mean?

Notice how, despite being very measurable and sometimes even paramount to get a project out of the door, none of the tasks I mentioned can really be measurements of productivity:

  • Write a test unit. Pretty important in TDD. Not what you should be working on when you're putting up a prototype demo that will be used in a sales presentation that you've just been informed will start in 2 hours.
  • Implemented form validation. Anyone knows it's important, but rolling your own when the framework has a built-in function to handle the exact same case is sometimes a waste of time. The opposite can be true too: you might find that using a framework built-in helper to save 2 minutes wasn't worth the 2 hours you end up spending on it when the qa phase comes along and a bunch of cases are broken.

Etc. Etc.

If I don't know what your goals are, and you don't know mine and we have no idea what each other's teams can and can't do (because of knowledge levels, corporate constraints, programming languages, frameworks, workflows, whatever), how can we intelligently discuss productivity improvements? It strikes me as odd that people would go as far as preach a methodology or even a coding practice as "the one", when I think about it from this angle.

Besides, hasn't there been enough articles around the tubes saying how rewarding programmers based on their individual "performance" is a bad idea?

Why do we even talk about productivity?


Doomed. Doomed. Doomed.

What's up with people and this obsession with doom?

Thursday, February 12, 2009

How not to sort by ratings

Informative. Goes to show how good knowing statistics can be.

Wednesday, February 11, 2009

When can I use...

A list of upcoming standards and drafts and their level of implementation in various versions of major browsers.

My conclusion: use flash :)

Why you should be a good citizen online

Nice article talking about legal standards myths and how police can disrupt your life in case you get accused of doing something illegal online.

Look ma, I'm a prophet

I've been seeing a lot of jabs at how the newspaper industry should restructure now that they're reportedly not doing so great.

I keep wondering if these people actually run businesses on the models they are proposing or if they're just prophets full of themselves.

Monday, February 9, 2009

Cognitive bias on wikipedia

Cognitive bias. via. I know I'll forget the term Dunning-Kruger, so here it is for future reference.

Wednesday, February 4, 2009


Opera really does not sleep on the job. I wish it'd get more traction, I think it's a great browser.

Users don't always know what they want

Speed is more important than quantity, despite users' reasoning that more results are better, according to Marissa Meyer from Google.

Tuesday, February 3, 2009

Why debating CSS vs Tables is pointless

So some were recently saying CSS *should not* be used for layouts and others were saying CSS *should* be used for layout.

On one end, there are people who really have better things to do than spending the day typing up angled brackets and curly braces. Great for them. Whip up a quick layout in 10 minutes and you're on your way. Requirements? What requirements?

On the other end, there are people who need to maintain sites and people who have technically challenging requirements (you know, the print versions of the pages must look a certain way, layouts look and feel are to be revised and approved by the client, etc). Great, CSS to the rescue. Money pays the bills, life is nice. Brownie points if you improved yourself by learning something new about CSS on your journey to "front-end expertise".

Most people are usually somewhere in between the two extremes and their whereabouts in the gray area also depends on things like whether it's a job or a hobby project, or whether it's monday or friday-when-omg-we-need-to-get-this-thing-out-of-the-door-now. Or whether their boss is a technical evangelist or a sales person. Or whether they're lazy. Or stressed out. Or whatever. Whether kittens are blue.

The obvious but often forgotten thing about the teh intahblagz is that we don't know who's at the other end of the wire, let alone what their environment, priorities and workflow look like. So we read all of these "advices" about why this is the bomb and why that is THE way to do whatever, and in the end, we just do whatever happens to look like the best idea at the moment. Mind fap. </acid>