wilmoore

#!/usr/bin/node

/* butterfly state machine */

var Egg = function(species) {

    this.species = species;
    console.log("An egg");

    this.hatch = function() {

wilmoore

#!/usr/bin/env ruby
# Usage: gitio URL [CODE]
#
# Turns a github.com URL
#  into a git.io URL
#
# Copies the git.io URL to your clipboard.

url  = ARGV[0]
code = ARGV[1]

wilmoore

Today I gave a keynote at ACCU in Oxford.  In the midst of it I made two (count them) two statements that I should have known better than to make.  I was describing the late '70s, and the way we felt about the C language at the time.  My slide said something like: "C was for real men."  Emily Bache, whom I know and hold in high regard, spoke up and said "What about women?".  And I said something like: "We didn't allow women in those days."  It was a dumb crack, and should either not have been said, or should have been followed up with a statement to the effect that that was wrong headed.  

The second mistake I made was while describing Cobol. I mentioned Adm. Grace Hopper.  I said something like "May she rest in peace."  I don't know that any of the words were actually demeaning, but the tone was not as respectful as it should have been to an Admiral in the United State Navy, and one who was so instrumental in our industry; despite what I feel about Cobol.  

I am a 59 year old programmer who was brought up 

wilmoore

Latency numbers every programmer should know

L1 cache reference ......................... 0.5 ns
Branch mispredict ............................ 5 ns
L2 cache reference ........................... 7 ns
Mutex lock/unlock ........................... 25 ns
Main memory reference ...................... 100 ns             
Compress 1K bytes with Zippy ............. 3,000 ns  =   3 µs
Send 2K bytes over 1 Gbps network ....... 20,000 ns  =  20 µs
SSD random read ........................ 150,000 ns  = 150 µs

Read 1 MB sequentially from memory ..... 250,000 ns = 250 µs

wilmoore

There are good reasons to avoid the perceived elegance of dropping so-called "superfluous" var statements. The following are excellent reads on the subject:

• Varry var var
• Multiple var statements in JavaScript, not superfluous

wilmoore

{
    // --------------------------------------------------------------------
    // JSHint Configuration, Strict Edition
    // --------------------------------------------------------------------
    //
    // This is a options template for [JSHint][1], using [JSHint example][2]
    // and [Ory Band's example][3] as basis and setting config values to
    // be most strict:
    //
    // * set all enforcing options to true

wilmoore

@events =

  events: {}

  on: (topic, handler, context = this) ->
    (@events[topic] or= []).push {handler, context}

  trigger: (topic, args...) ->
    return unless @events[topic]?
    handler.apply(context, args) for {handler, context} in @events[topic]

wilmoore

@ChristinGorman gave this talk at JavaZone: https://vimeo.com/49484333  It's quite good, short, energetic, enthusiastic, 
intelligent, and completely misses the point.  

While it's true that the code she produces is much better than the original, and is quite easy to understand; it fails one 
critical test.  It's not polite.

Polite code is like a well written newspaper article.  It allows you to bail out early.  A well written article has a 
headline, a synopsis, and a set of paragraphs that begin with the high level concepts and get more and more detailed as you 
read through the article.  At any point you can decide: "I get it!  I don't need to read further."  Indeed, this is how most 
people read newspapers or magazines.  The articles are polite, because they allow you to get out quickly.

wilmoore

Avoid jQuery When Possible

jQuery does good jobs when you're dealing with browser compatibility. But we're living in an age that fewer and fewer people use old-school browsers such as IE <= 7. With the growing of DOM APIs in modern browsers (including IE 8), most functions that jQuery provides are built-in natively.

When targeting only modern browsers, it is better to avoid using jQuery's backward-compatible features. Instead, use the native DOM API, which will make your web page run much faster than you might think (native C / C++ implementaion v.s. JavaScript).

If you're making a web page for iOS (e.g. UIWebView), you should use native DOM APIs because mobile Safari is not that old-school web browser; it supports lots of native DOM APIs.

If you're making a Chrome Extension, you should always use native APIs, not only because Chrome has almost the latest DOM APIs available, but this can also avoid performance issue and unnecessary memory occupation (each jQuery-driven extension needs a separate

wilmoore

#
# This is the way I configured my ruby environment on ArchLinux.
# 
# I don't like the overhead of rvm, so I use chruby to switch between ruby versions.
# So first you need to install chruby from source: 
# 
# https://github.com/postmodern/chruby#install
#
# To build ruby from source I use ruby-build, so after chruby we install ruby-build:
#