WebGL

This is a new spec that’s being developed by the Khronos Group (the group behind OpenGL) to expose OpenGL to browsers through the canvas element.

Why is it exciting? Three words: Javascript. Hardware. Acceleration. Damn, I need three more: In. The. Browser.

The concepts should speak for themselves, but if you still need some convincing follow the steps below and be sure to take a look at your CPU usage while running these demos. (Hint: CPU usage will be very low because you’re riding your GPU).

• Grab the latest nighly of Chromium here if you are not already running it.
• Start Chromium via the command line:
  • Windows: chrome.exe --no-sandbox --enable-webgl
  • OSX: Chromium.app/Contents/MacOS/Chromium --no-sandbox --enable-webgl
  • Linux: ./chrome --no-sandbox --enable-webgl
• Follow this link to some examples of WebGL in action.

Again, check your CPU usage while running the demos. It should be very low (if you have a GPU) as the demos should be hardware accelerated.

Web Sockets

Comet? Long-Polling? Forever Frame? In two years we will all be sitting around a trash barrel fire laughing about the days of yore when we had to use such hacks.

Why are we huddled around a trash barrel fire? Because it’s post-apocolyptic New Zealand, the last bastion of humanity. Anyways, that’s another “In This Decade” blog post…

From websockets.org:

[The Web Socket Interface] defines a full-duplex communications channel that operates over a single socket and is exposed via a JavaScript interface in compliant browsers

Here’s the spec in case you want to read it… haha, me neither.

Again, the concept here should speak for itself. Two-way communication with web servers in an easy-to-use interface.

var websock = new WebSocket("ws://www.websocket.org");

websock.onopen = function(evt) {
  console.log(evt)
  websock.send("Hello Web Socket!");
};
websock.onmessage = function(evt) {
  console.log(evt)
};
websock.onclose = function(evt) {
  console.log(evt)
};
websock.close();

Fortunately, there are already many projects implementing the web sockets protocol. To name a few,

• node.websocket.js
• em-websocket (Ruby)
• pywebsocket

One thing to note is that the web socket protocol will adhere to the cross-domain security restriction that XHR has. The good news is it will ship with support for server-side origin discretion using the same Origin headers in CORS.

It’s all about the gaming, stupid

I’m going to predict that in 2 years, we will see current A quality games developed in-browser ontop of these two technologies. Don’t get me wrong, AAA quality console and PC titles won’t be disrupted like the music and print industries any time soon. But, the “casual” label on browser games will go away.

This is what has me really excited about being a web developer in this decade. Parity with desktop development is inching closer, and all ontop of open technologies.

No plugins. No corporate owner.

Win. Win.

Enabling your server app is as simple as including a few extra headers when you detect a cross origin request. How do you know it’s a cross origin request? You’ll see the Origin: header — all CORS requests will have it. From there, response headers depend on the specifics of the request, but I won’t go over those here — check out the Mozilla Developer Center treatment for in-depth information.

I’ve been working with Sinatra a lot lately, so I put together an extension for Sinatra that makes enabling Cross Origin requests even easier.

sudo gem install sinatra-cross_origin

There are two ways to use the extension: globally or per-route.

Global

For when you want to share all your endpoints cross-domain.

require 'sinatra/base'
require 'sinatra/cross_origin'

class MyApp < Sinatra::Base
  register Sinatra::CrossOrigin

  enable cross_origin

  get '/' do
    "This is available to cross domain javascript requests automatically"
  end
end

Per Route

For when you want to share only some of your routes cross-domain.

require 'sinatra/base'
require 'sinatra/cross_origin'

class MyApp < Sinatra::Base
  register Sinatra::CrossOrigin

  get '/' do
    cross_origin
    "This is available to cross domain javascript requests"
  end
end

Configuration

You can mix and match app-wide config and request specific config.

require 'sinatra/base'
require 'sinatra/cross_origin'

class MyApp < Sinatra::Base
  register Sinatra::CrossOrigin

  configure do
    # Comma separate list of remote hosts that are allowed.
    # :any will allow any host
    set :allow_origin, :any

    # HTTP methods allowed
    set :allow_methods, [:get, :post]

    # Allow cookies to be sent with the requests
    set :allow_credentials, true
  end

  get '/' do
    # Only available to GET requests originating from
    # http://example.com.  No cookies allowed.
    cross_origin :allow_origin => 'http://example.com',
      :allow_methods => [:get],
      :allow_credentials => false
    "This is available to cross domain javascripts"
  end
end

Grab the source at Github: britg/sinatra-cross_origin.

What is scriptstack?

Well, if you’re like me you probably have 4 or 5 javascript files you include in just about every new project or site your start. jQuery. Tooltips. Lightbox. qTip. Or, you just put together a nice portfolio site for a client and you want to save that specific set of javascript plugins for the next time you do something similar.

Scriptstack aims to be an easy and social way to organize your “stacks” of scripts. You can:

• Upload scripts.
• Click and drag them into the order they should be loaded in the browser.
• Tag them with a few keywords to make them indexable for future search.
• Download the concatenated stack in minified or raw format.

That’s about it for now, haha. Release early, release often, right? I should note that there’s no permissions on the stacks. If you create one, it’s editable by anyone right now. I plan to add User accounts and ownership soon.

Warning: the site probably only works in Firefox.

Under the hood

I took this opportunity to expand my horizons as far as the technology under the hood. I’ll go in-depth on these as I continue to develop, but a quick rundown of the tech stack (pun intended but probably shouldn’t be):

• MongoDB (via MongoHQ)
• MongoMapper
• Heroku
• Sinatra
• Haml
• Compass

I also open sourced all the code that runs the site here incase you are interested in what poorly written Ruby looks like.

If you happen to check it out, let me know what you think! And as I said, I will expand on different parts of it here in the near future, so stay tuned.

In short, it aims to build a for-pay CV hosting and searching service on top of the success of Stack Overflow.

I have mixed feelings about Stack Overflow Careers.

No, I’m not questioning whether or not they should have built it, or whether or not they should charge money for it. I have no problem with Joel or Jeff using their interweb fame to make a buck like this guy seems to (Clarification: William’s beef isn’t with the for-pay aspect, but with the underlying system itself. See first comment.). If they want to, they should.

America++!

My quandary is whether I should make an effort to participate in Stack Overflow and Careers. I like the site and use it daily, but I don’t actually participate. I am a consumer, not a contributor. Should I eschew my natural introverted tendencies and force myself to contribute?

Maybe

The Stack Overflow group of programmers seem to “get it.” On the whole they are smart, pragmatic, and can communicate in complete sentences (skills listed in reverse order of importance).

As a freelance programmer, I would like to be attributed with those qualities when looking for work. That’s the true value in associating a job search with Stack Overflow and is the reason why they can charge programmers to list their CV. If you’re recognized as a member of that community, you’re much more valuable to job searchers that are Stack Overflow-aware.

Maybe there’s some value in participating in the site and quantifying my association with the Stack Overflow type of programmer?

Nah

But, ultimately what am I trying to accomplish? Sure, I want to be known as a competent and gets-stuff-done kind of programmer. Stack Overflow is an avenue to quantify that I have these skills; it isn’t the method by which these skills are obtained.

Joel Spolsky himself said,

The great software developers, indeed, the best people in every field, are quite simply never on the market.

He goes on to explain that if you’re a great developer, you’ll be recognized as such through your work.

I think this says it all. I shouldn’t force myself to participate in a contrived system attempting to quantify competence. Don’t get me wrong, if you enjoy interacting and contributing to Stack Overflow, more power to you! But for me, if I’m doing the right things to further myself as a developer, the rest will take care of itself. More do-ey, less talk-ey.