For hardcore Javascript developers

[Happy birthday to jtdiii!]

I strongly commend the new blog by Jan Kassens, one of the more serious and interesting MooTools developers. It's only been running a couple of days, but it already demonstrates some of the extraordinary power of the MooTools toolkit, with articles showing things like how to make event binding suck less, and how to build high-level pseudo-DOM elements in MooTools.

Very neat stuff, which continues to remind me why MooTools is the most essential piece of my Javascript tool belt -- it continues to be less about cool widgets, and more about constructs that really unleash the raw power of Javascript. (Which, despite being a problematic language, is a lot more powerful than it's often given credit for.) Of the three articles posted so far, two are likely to get used directly in CommYou when I find the time...

For hardcore Javascript developers

[Happy birthday to jtdiii!]

I strongly commend the new blog by Jan Kassens, one of the more serious and interesting MooTools developers. It's only been running a couple of days, but it already demonstrates some of the extraordinary power of the MooTools toolkit, with articles showing things like how to make event binding suck less, and how to build high-level pseudo-DOM elements in MooTools.

Very neat stuff, which continues to remind me why MooTools is the most essential piece of my Javascript tool belt -- it continues to be less about cool widgets, and more about constructs that really unleash the raw power of Javascript. (Which, despite being a problematic language, is a lot more powerful than it's often given credit for.) Of the three articles posted so far, two are likely to get used directly in CommYou when I find the time...

The many-core future

If you're not already following it, I commend today's post in Ars Technica about the upcoming changes to hardware. It's not precisely new, but it does underline what I've been saying for the past couple of years: the time of Massively Multicore is upon us.

Everybody's getting used to having two or maybe even eight cores in a computer, and you can almost kind of ignore that in most cases -- after all, you're just writing one process among several on the machine, so if you're limited to one core it's not a big deal. You might even tweak the program to use a few threads. But Intel is now talking seriously about architectures that range from dozens to *thousands* of little cores working together. You can't ignore that if you're going to be doing any kind of serious programming.

There's a message here, and it's an important one if you're in the field: if you're not already good at multi-threaded programming, you need to *get* good at it. There are probably deep changes to programming coming soon -- they're hard to predict at this point, but the root message is that you're going to need to understand threading pretty well. Or you're going to need to learn the languages that are inherently threadsafe, like Erlang. Or both. If not, you risk confining yourself to the limited subset of the field where threading can be ignored. (Eg, the simpler forms of web-server programming, but not the really interesting bits.)

It's exciting stuff -- we may be looking at the most dramatic changes to the *art* of programming (rather than just its uses) in decades. But if you are seriously in this field, you need to be paying attention to it, and making sure your skills are up-to-date, or you risk dead-ending your career...

The many-core future

If you're not already following it, I commend today's post in Ars Technica about the upcoming changes to hardware. It's not precisely new, but it does underline what I've been saying for the past couple of years: the time of Massively Multicore is upon us.

Everybody's getting used to having two or maybe even eight cores in a computer, and you can almost kind of ignore that in most cases -- after all, you're just writing one process among several on the machine, so if you're limited to one core it's not a big deal. You might even tweak the program to use a few threads. But Intel is now talking seriously about architectures that range from dozens to *thousands* of little cores working together. You can't ignore that if you're going to be doing any kind of serious programming.

There's a message here, and it's an important one if you're in the field: if you're not already good at multi-threaded programming, you need to *get* good at it. There are probably deep changes to programming coming soon -- they're hard to predict at this point, but the root message is that you're going to need to understand threading pretty well. Or you're going to need to learn the languages that are inherently threadsafe, like Erlang. Or both. If not, you risk confining yourself to the limited subset of the field where threading can be ignored. (Eg, the simpler forms of web-server programming, but not the really interesting bits.)

It's exciting stuff -- we may be looking at the most dramatic changes to the *art* of programming (rather than just its uses) in decades. But if you are seriously in this field, you need to be paying attention to it, and making sure your skills are up-to-date, or you risk dead-ending your career...

Like stepping on the scale after being good about one's diet

Refactoring is a pain in the ass, and even with a good test suite it's kind of scary to rip apart the most central functions in the system.

But man, now that I'm done it is delightful to be able to add just one line to the JabberManager:

m_ConvMgr.createConversation(sender, null, text, -1);

and *poof*, you can now start simple conversations directly from IM, just as you can from the Web page. Makes the whole process worthwhile...

Like stepping on the scale after being good about one's diet

Refactoring is a pain in the ass, and even with a good test suite it's kind of scary to rip apart the most central functions in the system.

But man, now that I'm done it is delightful to be able to add just one line to the JabberManager:

m_ConvMgr.createConversation(sender, null, text, -1);

and *poof*, you can now start simple conversations directly from IM, just as you can from the Web page. Makes the whole process worthwhile...

Sometimes, the Architect wins

Continuing on from the previous thought...

It really is rather strange, being a nearly one-man shop. In particular, being *both* the CEO/Product Manager and the Architect/programmer requires a strange sort of schizophrenia to do well, because of the enormous tensions between those roles. The Product Manager wants "now", and the Architect wants "good". And the CFO (also in there for the time being) insists on "cheap". As any decent programmer knows, you don't get all three, at least at any given moment. So there are these loud arguments playing out in my head pretty much every day, which mostly show up as lost sleep.

I've been tending to let the Product Manager win for the moment, on the grounds that I need to figure out exactly *what* I'm building here before I spend a lot of time making the code beautiful. (Indeed, both sides engaged in a detente last week, agreeing that I need to stop worrying so much about scalability for a while. If I can get people going, "y'know, this is pretty cool", *then* I need to pause and figure out the fine details of how to scale it up correctly. But first I've gotta get the ideas straight.) So the Architect has spent a bunch of time steaming over the fact that there's a good deal of code here that I wouldn't be willing to show as a coding sample.

That said, there are reasons for the code-then-refactor discipline, and I just hit one: getting this thing really talking to *both* Facebook and Jabber requires a lot of code cleanup. This morning, the Architect put his foot down and declared that it's time to take a couple of days out for a massive refactor; the CEO is sulking, but agreed that, if it's the only way to get the features he wants, he'll live.

After the first day of refactoring, it's quite suddenly looking like something I'm willing to have on my resume again. The enormous and ornate CreateConversation() method that had been living up at the API tier has been shoved down into the system core, and all the cruft has been broken out into properly-decoupled listeners, each in the right basket. Having gotten the structural changes done through that, I expect to be able to clean up the rest of it tomorrow; after that, getting the rest of the initial Jabber functionality in should be easy.

It's not final yet, of course -- it's all still in-process, so there are still big changes to come when we do scale it up and make it internally cross-process and API-based. But the Architect part of my brain is feeling happy for the first time in weeks, so the CEO can suck it up for a while in the interest of peace in the company...

Sometimes, the Architect wins

Continuing on from the previous thought...

It really is rather strange, being a nearly one-man shop. In particular, being *both* the CEO/Product Manager and the Architect/programmer requires a strange sort of schizophrenia to do well, because of the enormous tensions between those roles. The Product Manager wants "now", and the Architect wants "good". And the CFO (also in there for the time being) insists on "cheap". As any decent programmer knows, you don't get all three, at least at any given moment. So there are these loud arguments playing out in my head pretty much every day, which mostly show up as lost sleep.

I've been tending to let the Product Manager win for the moment, on the grounds that I need to figure out exactly *what* I'm building here before I spend a lot of time making the code beautiful. (Indeed, both sides engaged in a detente last week, agreeing that I need to stop worrying so much about scalability for a while. If I can get people going, "y'know, this is pretty cool", *then* I need to pause and figure out the fine details of how to scale it up correctly. But first I've gotta get the ideas straight.) So the Architect has spent a bunch of time steaming over the fact that there's a good deal of code here that I wouldn't be willing to show as a coding sample.

That said, there are reasons for the code-then-refactor discipline, and I just hit one: getting this thing really talking to *both* Facebook and Jabber requires a lot of code cleanup. This morning, the Architect put his foot down and declared that it's time to take a couple of days out for a massive refactor; the CEO is sulking, but agreed that, if it's the only way to get the features he wants, he'll live.

After the first day of refactoring, it's quite suddenly looking like something I'm willing to have on my resume again. The enormous and ornate CreateConversation() method that had been living up at the API tier has been shoved down into the system core, and all the cruft has been broken out into properly-decoupled listeners, each in the right basket. Having gotten the structural changes done through that, I expect to be able to clean up the rest of it tomorrow; after that, getting the rest of the initial Jabber functionality in should be easy.

It's not final yet, of course -- it's all still in-process, so there are still big changes to come when we do scale it up and make it internally cross-process and API-based. But the Architect part of my brain is feeling happy for the first time in weeks, so the CEO can suck it up for a while in the interest of peace in the company...