It's good to be reminded that you're shit. Today Fabrice Bellard released jslinux - a 32 bit CPU emulator which loads a fully-functional linux kernel: including Emacs, and a C compiler. Holy Poopsmith.
Seeing as I now had a JavaScript-powered coding environment handy - and being inspired by Fabrice's unrelenting productivity - I decided code up a command line utility I've been intending to make for quite some time: howami.
There's no room for hacking and learning with Apple. You don't dare waste their time working on projects... from now on you work on products and products only.
If you aren't incentivizing and monetizing your down-time then you don't deserve to be using Apple's next-level code enabler, Xresource4.
It's been a while since Slashdot was my regular hang out - so perhaps the demographic has swung radically - but I was amused (and a little bit incredulous) to see a stack of mis-informed javascript hate in the comments of an article talking about Harmony (TC39), the proposed next version of ECMAScript.
In the last few years or so, JavaScript has come out of the closet and revealed itself as a powerful (though, like any good hero, slightly-flawed) functional language. Many people still haven't taken to it and choose to continue writing in an OOP style that they were told was good and enterprise-y. That's not a bad thing - that C/C#/Java coders can force JavaScript to behave mostly-but-not-exactly like their familiar ol' imperative friends is testament to it's flexibility: JavaScript can easily pretend to be imperative, because it can do anything.
"Code so good, you'll base your unit tests on it - that's my promise to you!". At least that's how I'm going to look at it. I was hunting up some info on QtWebKit (the Qt port of WebKit, obviously) and I noticed a new version had just been released. To my surprise I noticed a few references to my Parcycle canvas demo, including screen shots!
Canvas radial gradient fixes
Blur filter performance
Ha ha! Before and after pics featuring my particle madness. Made me giggle. Ok, back to it...
Yesterday had me basking in the internet glory of #1-on-Hacker-News. "This fame will last forever", I pronounced confidently. Alas, like all fleeting glory - it was fleeting. Thankfully, I've come up with a plan to ensure perpetual future success: I turn my fleeting glory into my very own Hacker News botnet!
All I've to do is smuggle some code into the guts of the main file of the bookmarklet. The hordes of Hacker News user who are now hopelessly addicted to the script will unknowingly run this every two minutes! It's not like anyone's going to be watching my commits... But what should I add? How 'bout this...
HTML5 means one thing, and one thing only: games! Okay, that's not true at all. Not even close, but heck - we are seeing stacks of fantastic games emerge, and the buzz that surrounds even the more mediocre efforts is considerable. So where's the love in the HTML5 spec for us game makers? When it comes to defining the appropriate uses for web technologies it's definitely a case of Internet. Serious Business.
I've had a few queries about some of the code in my Hacker News bookmarklet - which makes use of some JavaScipt 1.6 & 1.8 features: map; reduce; filter; and forEach (sorry, no love for some or every this post). Superficially these are just array methods that take a function and apply it to each element in the array. More profoundly however, they provide the means to break up wildly different problems in similar ways - encouraging code reuse, providing flexibility, and (arguably) enhancing code clarity.
It does this by establishing an abstraction: creating a language that can be used to describe our requirements. If we think about (or re-think) our problems in terms of this language then it becomes easier to decompose and "mix and match" component parts as needed. It turns out that you can restructure a lot of your code using this simple language.
The map/reduce (and their friends filter, each, flatten etc) paradigm provides a general way to manipulate lists and streams. This is particularly well suited to web work - where we spend most of our days playing with lists of DOM elements. Recent versions of JavaScript give us the tools to do this work natively but before that we had to roll our own, or use a library. jQuery has had some similar features since way-back-when, so today we're going to do a bit of "compare & contrast" on the map function: jQuery vs jQuery vs JavaScript!
Map iterates over a collections and applies a function to each element - returning a new, usually modified, list. Our tests will examine jQuery's "inline" map with it's global $.map map, and JavaScript's native map function. The object (no pun intended) is to see how each implementation varies in terms of the parameters and the value of this we get each iteration, and how they handle weird arrays.
