By CrypticSwarm

First Talk

A while back I wrote about joining meetup groups. Well I finally took the plunge last November and gave my first talk. I gave the talk at the STLJS meetup group on a project that I have been working on the previous couple of months. The project is a JavaScript debugger written in JavaScript that runs in a web-browser. The folks that run the meetup (@michaelsbradley @theablefew) were kind enough to film it and post it online.

JavaScript Control from Saint Louis JavaScript Meetup on Vimeo.

I learned quite a bit giving my first talk. The first thing learned is I need to spend more time preparing the actual talk. I spent much more time working on the project itself rather then prepping for the talk. I ended up creating the slides during the presentation before mine on strataJS. I thought it might be a good idea when I was making the slides to show really weird code and use the debugger to show what the code is actually doing. I decided to have a weird setup to make my claim on what the code is doing more believable before using the debugger to show what is actually happening. In retrospect I don't think that was such a good idea. Since the slides weren't about the actual project and were not so great I'm not going to be releasing these slides.

During the beginning of the talk were I set up this bad code I really struggle. This is likely due to the fact that I threw in this intro as I was making the slides. After some initial stumbling it seemed to smooth out some.

By CrypticSwarm

The Identity of Operations

People perpetually take in, shed and change molecules. Regardless of the length of the person's hair, their location, or whether they are viewed from the front versus the side they remain the same person. That is to say their identity didn't change. People are usually pretty good at this type of identity association. Computers on the other hand don't make identity association on their own. Being able to associate identity with a change becomes especially important when there are many computers interacting. Programmers tend to send absolute values rather than relative ones which makes it easy to clobber other changes. However, this is usually not the intended consequence. One technique for making smoother computer-to-computer communication is called Operational Transformation.

By CrypticSwarm

Meteor's impact: Changing How to What

Meteor, Firebase, and Light Table have showcased innovative ways that help a programmer create more efficiently by blurring the lines between code and data.

In computing there is often a distinction between data and code. Does blurring the lines between code and data buy us anything? To answer that lets make a distinction of what we mean by code and data in terms of a programming language. Data defines facts and code defines processes. So in other words Data is what? and Code is how?. By not making the distinction between code and data we can turn a how into a what. The more the lines between code and data can be blurred the easier it is to create abstractions.

Code typically uses, modifies, and creates data. Many languages the code is not written in a data format that the language natively understands. In languages such as Lisp dialects, however, the code is written as a data structure of the language. This allows the language to treat the code as data directly without lexing/parsing. The programmer imbued with the ability to easily write code that manipulates their code.

Closures allow programmers to use the data associated with the lexical environment that the function was defined. This makes it so that variables don't need to be explicitly passed to a function. It allows programmers to keep code DRY and not need to maintain several very similar but slightly different versions of the same thing. In many situations this reduces the cognitive complexity as well as the amount of code.

OO paradigm takes a stab at blurring the lines between code and data. Classes are data that specify properties about objects. With OO code is grouped together with data. Inheritance, and interfaces make it so that data is specified to exist, but which code is used is often decided at runtime. The programmer doesn't need to think about how to tell the computer which concrete implementation to use, because that is hidden behind the data exists.

In fact type systems are just one way that the programming environment uses data for code. Using data that we specify to help tell us if our program is correct. It can even help optimize runtime code.

Monads are another way that programmers turn the focus on how into what. In a monad comprehension, you want to chain some functions together. The plumbing on how to chain these functions together are hidden behind by the monad. (A pretty good article on monad comprehensions in clojure) As a programmer can focus on what they need to do, rather than how to do the chaining.

Pattern matching is sometimes useful for representing a complex set of conditionals. The user of such constructs doesn't need to know if the implementation optimizes the search tree or not. Pattern matching can also have more to it than just conditionals. For example it could also do variable capture and unification. One of the nice things about this is that the underlying implementation can change without needing to refactor the code. For debugging purposes when trying to find if some data matches a set of patterns a debug messages could be given specifying which pattern matched or why they failed.

When blurring the lines between code and data we change hows into whats. One common result is that this often shields the programmer from seeing or needing to think about certain aspects of the program. The cognitive complexity is generally reduced. Refactoring becomes easier.

By CrypticSwarm

Developer Stagflation

Developer stagflation eats at the life-force of many projects. It saps the energy of developers. Destroys projects leaving them orphaned.

Developer stagflation is one of the worst things that can happen to a project. It is that point where the project doesn't obey the programming law of conservation of project momentum. The project doesn't seem to do anything like a deadlocked process. Memory of the code fades like lines of COBOL. The frustrated users slowly disband.

By CrypticSwarm

How I Hacked My Compsci Class

In my senior year of high school I hacked my AP Computer Science class competitions. It was the first year the school taught Java. The teacher wanted to get everyone excited about programming by introducing weekly competitions. A class favorite was the Robocode competitions. We paired off into groups of two to build robot AIs. We all looked forward to the Friday classes where we had a 1 on 1 single elimination tournaments. This went smoothly for the first couple of weeks. I felt excited to watch the robots evolve from week to week.

One Friday competition it took a turn. A few of my classmates found that they could take open source robots from the internet. They won by a gigantic margin, so naturally other students followed suite. This behavior spread virally throughout the class, and soon the Friday competitions turned from building the best robots that you could, to finding the best robots that someone else made. My partner and I refused to poach someone else's robot. We were determined to win by our own efforts. We continued to build our robot, but we soon realized that the internet had far better AI skills than we did.

By CrypticSwarm

The Hardest Thing About Teaching: Knowing When to Lie

After Watching Bret Victor's Inventing on Principle I read several comments on a mailing list on why they are not convinced this is a good thing. Arguments were in the vicinity of this will just make it so that people won't know how programming actually works, and it will only work because of trial and error.

I think one of the main take-aways here is that we as people need input in order to form a mental model of how things are work. If we can get that input quicker we can form the mental model quicker. The point wasn't to make developers unthinking blobs, but rather to give developers tools to develop a model on how thing work quicker. This can be used as a 'gateway drug' to push prospective developers deeper down the computing rabbit hole.

Anyone can tell you that if you hold a book up in the air and let go that it will fall to the ground without needing to see it happen. This is because we on Earth have seen things fall to the ground enough times to form a mental model. After we form a model describing how things fall to the ground we anticipate the effects even if we don't know the specifics on how gravity works. Given at some point our mental models could and probably will break down and need to be refined. (Drop a book while in orbit. Doesn't fall to the 'ground' (ie. the floor of the inside of the shuttle) => refine that mental model)

By CrypticSwarm

Join Meetup Groups

In the last several months I've been attending more meetup groups and getting in touch with local development communities. Getting involved in these types of communities has introduced me to a lot of great people and plethora of ideas. Recently I've been up and running full force on an idea that I would never have had the chance to work on if I didn't start reaching out.

There are many ways to find local development communities. Looking at places like allows you to find some. Once you get to know some of the people that are already in the local communities they can usually introduce you to more meetups.

One of the huge benefits is networking with people. If you freelance these meetups are a good way to find leads. It's a good way to find job opportunities. Even better place if you are looking to hire people, because its a good way to scout out local talent.

By CrypticSwarm

Variables Now and Later

In @raganwald's Captain Obvious post he explains that: (value) {
return parseFloat(value);

Could be written as:; 

As an extension of the Captain Obvious post let us look at reasons why you might want to use the former rather than the latter. (besides reasons stated in that article).

Most of you can probably figure out what x, and y equal after the following code.

var x = 23,
= x
= 45

After this runs x would be 45 and y would be 23. This is because we assign the value of x to y at that moment and not what x will be in the future. Of course this will also work if the values are functions. Below is some jQuery code that will do something on click depending on some outside data.

function handler(ev) {
switch(getCurrentState()) {
case 'up':
//do up state...
case 'down':
//do down state...

Assume we have code that will change what function a variable called handleState held when the state changes. We could refactor the code so that each state is a separate function.

var states = {
: function up() {
//up state
: function down() {
//down state
var handleState = states.up

Well... Not so fast. We run into a problem when we drop handleState in directly like this. After we change what function handleState refers to, the event click handler is still the original. Much like y was still 23 after changing x. However if we were to do the following:

$('#element').click(function() {
return handleState()

We can lookup the current value of handleState when the element is clicked.

There are other techniques for doing this same type of code. Such as How to avoid switch-case syndrome. However that is not the point of this article.

By CrypticSwarm

Integrating Node's REPL with VIM

Slime.vim allows you to send sections of a vim buffer to a named screen session. Open a repl in that screen session and you get instant feedback from the repl while still working within your editor. It also allows you to send code from multiple vim buffers to the same repl session. This allows the possibilities to interactively pick apart and explore someone elses code without modifing it.

By CrypticSwarm

Argument Against Comma First

On and off for a while now I have seen articles where people discuss the validity or faults of comma first style in JavaScript. I personally have been using comma first style for quite some time. For me one of the largest aspects of programming style is that it should make spotting errors as easy as possible. The arguments that I've seen against it don't seem to hold much water. Arguments tend to be in the form of "That looks dumb" or "I already use JSLint". JSLint does catch this type of error, but commas last doesn't make it so you can see that it is correct while you write it. Another argument is that it breaks when you do this on a return statement. This is also not really true. It is the same either way. As long as you start on the same line as the return statement than you won't have a problem. Illustrated below.

By CrypticSwarm

Why are JavaScript Generics so Specific?

This is a thought expermiment on writing code that is easier to read

In JavaScript you can access properties of an object using dot notation (or square bracket notation). When you call a function that is the property of an object (method) the left hand side will be implicitly passed to the function as the this of the function. If the function returns a value you can then access properties and even call functions on the returned object immediately instead of saving it in a temporary variable. Recently in JavaScript there has been extensive use of method chaining.

In a language that had functions that acted on objects but need to have the object explicitly passed in might look like the following.

The method chaining approach pulls the most important parameter out of the function call so it is before the function. This has the effect of making it read from left-to-right instead of inside-to-outside. Many people find the left-to-right much easier to read.

JavaScript has the concept of generics. To clarify a generic version of a method would be a function that as the first parameter you pass the object that you want acted upon. In essence this is the exact same as the previous example, except instead of top level functions they are attached to the constructor function for the objects.

Libraries such as underscore provide both a generic version and one that supports method chaining.

By CrypticSwarm

Canvas API Renders Native Application

My quest: to forge a path for web developers to take greater control over configuring and customizing their work environment. One way to do this is to use web technologies to enable people to integrate with their computers.

TJ Hollowaychuk created node-canvas, which uses Cairo graphics library for rendering. Cairo has many backends for rendering its surfaces and just so happens to have one for XCB. One very convenient thing that Cairo allows is copying from one surface to another. Each surface can use an entirely different backend. In node canvas' case it uses the Image backend, but we want to render to the screen. To do that just copy the node canvas surface directly to the surface that represents the XCB window. Consequently this also cuts out any flickering due to the screen being updated before the image is completed. This technique is called double buffering, and is used quite a bit in graphics applications. The main rendering is down in an offscreen surface and then copied to the screen when complete.

Lets take a look at what the useage would look like.

By CrypticSwarm

Almost Maybe Monadic

The other day I tried testing how far I could push Harmony Proxies. See the following blog post for an intro to harmony proxies. One of my first experiments was to try to implement the Maybe monad with proxies. This would make the following code possible.

If you are familiar with CoffeeScript this would be similar to the soak operator. Haskell it would be the Maybe monad. Below is the code for my attempt at making the Maybe monad.

The Maybe function is the type constructor that either returns a Just proxy or the Nothing proxy. A Maybe proxy's get trap acts like the monads bind function. This is convenient because it makes the . operator act similar to Haskell's >>= operator.

By CrypticSwarm

Harmony Proxies Introduction

I spent the last day learning about Harmony Proxies. Proxies are a new type of JavaScript object that have hooks that allow you to customize how they act when certain things happen. These hooks are called traps. There are two types of Proxies: Object Proxies, and Function Proxies. The proxies have a set of fundamental traps and a set of derived traps. The fundamental traps have no default implementation whereas the derived traps are implemented in terms of the fundamental ones. The docs suggest at the least that implementations for the fundamental traps should be provided, because if they aren't and they get hit, then a type error is thrown. When new tools come about it takes time to push them to their full potential. Proxies give developers a lot of power, but just how much? I imagine that there are still many techniques that incorporate proxies to be discovered. So let us get started experimenting.

Proxies are available in FF4 and higher. In Chrome it is hidden behind a compiler flag. To use with NodeJS you can use node-proxy. npm install node-proxy to install. Firefox doesn't need special treatment to get started. To use node-proxy we need to require it before using: var Proxy = require('node-proxy').

The example will focus on Object Proxies. To create an object proxy you do Proxy.create(handler, proto). handler is an object that contains the traps that are handled. proto is the proxies prototype. Note that a common usage might be to proxy to an object, but that isn't always true. A proxy could potentially proxy to multiple objects. That is why there isn't an object to forward to in Proxy.create. To forward to a particular object the handler would be from a closure that has access to the correct object.

The above example is not very exciting since the proxy itself doesn't really do anything. However, it shows how a proxies handler can have access to forward to a single object. The example overrides some of the derived traps so that they don't use the fundamental traps.

When I got started I wanted to keep things as minimal as possible and explore. I found the get and set traps to be the most interesting, so I wanted to start hacking from there. Both of those traps are derived traps. As long as you know that a trap won't get hit with what you are doing then it isn't required to be implemented. Of course that won't fly in production code, but to keep examples simple I will be keeping the traps to a minimum. The tricky part is actually knowing which traps are getting accessed. This tripped me up a few times. Lets take a look at an example of using a proxy A that proxies to another proxy handler B. In symbols we have A -> B. Before A forwards it prints out which of Bs traps it is forwarding to.

In the example Log is A and forwardHandler is B. The Log proxy forwards to the forwardHandler, but before it does it prints out which trap is being accessed. In this way all of the forwardHandler trap accesses pass through the get trap of the Log. Essentially Log just notifies us which traps are hit on the forwardHandler. The only trap that will be accessed Log is the get trap. I use the forward proxy implementation from the proxy proposal page, but with a few minor tweaks. I changed what had been marked with not in ES5, and also removed all of the derived traps. Removing the derived traps allows us to investigate which traps are hit based off of the default implementation of the derived traps. From what I have seen, the node-proxy implementation (shown as output above) is different from what I get in FF7.

Be careful when you inspect the receiver of a trap (the first parameter sent to the trap). I decided to send the receiver to console.log which then hits the same trap again and set it spinning out of control till it hit the stack limit.

I found that implementing the get, set, and enumerate traps to be enough to get simple experiments that get and set on a proxy and print in both Firefox and NodeJS.

Expect another post soon on some more advanced examples of usage of proxies. For a sneak peek check out this code that almost implements the Maybe monad.

By CrypticSwarm

Introducing XCBJS

XCBJS is an early stage project that I have been working on in my spare time for NodeJS. It provides JS bindings to XCB (X C Bindings) for use to make native applications in JavaScript for any platform that X runs.

For a while now I have wanted to make a window manager in NodeJS. At the beginning of August I finally made the plunge and started working on one. My main reason for starting this project is to develop a way for a web developers to easily take control and modify the window manager and the way their windows look without needing to learn a whole new set of technologies. I use Linux which means that for my computer, I am making use of the X protocol. I looked at the various libraries that were already made to work with X11 protocol: XLib, and XCB. Both libraries are written in C. XLib is a bit older than XCB. XLib will block when making a requests that generate a reply whereas XCB won't. Since XLib blocks on requests and I decided to use XCB.

When I started I knew next to nothing about how the X protocol actually works. I initially wrote the bindings by hand. That turned out to be extremely tedious. After doing some research I found that the XCB people had made an xml file that describes the X protocol. Using this information I created a JavaScript program that generates C++ so that I can use the X protocol in JavaScript. Since the protocol bindings are generated all of it can be changed very easily. For example adding or removing type checking in the C++ code. Inserting REPL docs, and probably many other ideas that come along in the future.