My name is Carl, I push bits.

Knowledge is a framework that experience bends.

I'm just a learning-fool, looking to master the art of solving problems through writing code, and yelling at computer screens.

48620748960

DOM Futures vs Custom Events

Maybe I just don’t get it yet, but it seems like the interest around “DOM Futures” (e.g. promises) is growing, and is becoming a proposed spec for future javascript engines. What DOM Futures is is another way to handle asynchronous flow in your javascript apps. Currently you can use nested callbacks, which are probably the most common, or you can use custom events (like Backbone, jQuery, or any other publish/subscribe framework).

While I see that DOM Futures / Promises could cut down on lines of code, I’m not sure what else it truly gives me as a developer. But, I may not fully grok it yet.

I’ve put together two examples of a ficticious javascript app that needs to get a user’s posts via ajax. Below you’ll see each example via DOM Futures and via custom events.

What am I missing?

DOM Futures

From the WHATWG spec. This example makes a JSON ajax request, and then returns a promise object that has the “.done()” method on it, that will asynchronously call one of two callbacks depending on the response of the json call.

fetchJSON("/user/posts").done(showPosts, showFailcat)

function fetchJSON(url){
    // create json request, wrap in a promiseObject
    return promiseObject;
}

function postsSuccess(data){
}    

function showPosts(data) { 
    postsSuccess(data);
    //...
}

function showFailcat(error){
    //...
}

Custom Events

A similar example using some custom event framework, that attaches/subscribes using “on()” and triggers/publishes to an event using “trigger()”.

$.getJSON("/usr/posts",onPostsSuccess,onPostsError)

function onPostsSuccess(data){ 
    // let's just say we have two events we want fired
    trigger("posts:success",data); 
    trigger("posts:show",data); 
}

function onPostsError(error) { trigger("posts:error",error); }

function postsSuccess(posts){
}

function postsShow(posts){
}

on("posts:success",postsSuccss);
on("posts:success",postsShow);

function postsError(error){
}
on("posts:error",postsError);
47897188327

IdentityCache: Improving (ActiveRecord) Performance one Cached Model at a Time

Seems like a stupid-simple way to work with a Memcached layer. Love the simple solutions.

47896150945

Douglas Crockford: Principles of Security

(Source: youtube.com)

47835476303

Trying out Firefox v20 full-time (from Chrome)

I was a Firefox user long before I was ever a Chrome user. But it was probably four years ago that I made the switch to Chrome because of the speed of the browser, plus the more-than-adequate developer tools at the time that later became powerful and second-nature to me.

With the recent improvements to the integrated developer tools in Firefox 19/20, I decided to give it an honest shot as my default browser once more. I imported all my bookmarks, added the 1Password extension and away I went.

What I liked

It’s fast. Some 2D canvas apps that used to run a bit sluggish in Firefox now run just as smooth as Chrome.

The developer tools that come with Firefox have come a long ways. It has a beautiful interface, and the style editor’s animations as you change styles was a nice touch.

I also enjoyed the “Responsive Design Mode” button that lets me see the current page in a variety of viewport sizes instantly.

The Scratchpad editor, for javascript coding / executing is a nice touch, but I don’t have a lot of need for it right now.

The Javascript debugger is nice in that it shows you a great deal of context on each breakpoint or as you are stepping through code.

What I have yet to like

No dedicated network tab. Yes, you can see it in the console, but I’ve grown very fond of how Webkit Dev Tools shows a nice waterfall chart of all the requests. Combining the console with that network view is crowded for my day to day JS hacking, and network optimization workflows.

Lack of hover-over context windows in the debugger. When debugging, I’ve gotten used to exploring an object’s properties by hovering over it to see the values. Having to look off to the side for the currently scoped variables, or adding something to the watch is something I’ve grown out of with Webkit because of the ease of just hovering over values. Persisted watches of course have their place, but I find that most of the time I just want to inspect an object at this moment in time, and hovering over the object to check its properties is just easier because my eyes and mouse can be in the same place to do that process.

Where’s the stack-trace in the console? The console will show you the errors you receive, and a file name an line, but it will not help you debug an issue that happens deep within let’s say jquery.min.js. You can assume the problem was not a jquery one, but an iD10t error, but how do you debug it if you aren’t always given the stack?

What now?

I’ve already reverted back to Chrome, and it saddens me. I want Firefox to be my default, but I switched to Chrome all those years ago for a reason:

  • Faster (or at least perceived faster by my brain)
  • One process per tab (isolation)
  • Out of the box dev tools superiority/familiarity
  • Default interface is more streamline, less cluttered, and buttons more pronounced e.g. the FF refresh button is tiny, almost hidden at the end of the address bar. I don’t click it often, but when I’m hunting for it, I have to look carefully. I’m sure this is due to muscle memory w/ Chrome.
47001171074

How I Removed Friction in Running my Tests locally

Problem: Sometimes I forget to run tests before deploying to staging (oops)

Yes, “bad dev!” indeed. In the midst of quick-fire releases, sometimes my own standards for due-dilegence falls through the cracks. The friction comes with my having to remember to run all my tests before pushing code off my machine, and to a shared environment (git repo, staging build server).

What I am good at remembering to do is to commit the smallest possible changes to my local git feature branch. Because I makes mistakes, and the easier it is to isolate those changes/mistakes, the easier it is to cherry-pick them away, or create a fixing commit.

Solution: Remove the friction and bring the continuous integration locally

Continuous Integration (CI) / Continuous Delivery (CD) are a must-have for your company’s projects to take away the hassles of running tests, bundling and deploying your code to their production or staging endpoints/servers.

Because of my commit small hunks, and commit often, I decided to install a CI server locally that listened to all my local commits across all branches, and then build the code, run all the unit tests and deploy the app locally for UI testing.

Now, I can be sure that all my changes have not broken any existing test, and I can keep plugging away while the server handles the rest.

On a multi-monitor setup my main display is for coding, and my secondary is for watching the build server alerts and refreshing the locally-deployed site in a browser.

I’ve found having this configuration and workflow actually helps enforce good practice. Knowing that each commit fires a build keeps me doing it in small amounts, and I get the added benefit of tests and deployments while I keep my mind in the context of the problem.