Category Archives: Programming

Cooperative vs Collaborative

Cooperative sounds good, right?

Life has been humming along; work has stabilized after a period of seismic activity; for all I knew we were doing things right. I could have happily gone on with my life, leading a culture of cooperation within my team, had I not scrolled past this interesting table by John Spencer:

Respect v. Trust

I love this because as I read the left side, it mirrored my thought process of thinking “yea! Cooperation is sweet.” Immediately when I got to the first line of the Collaborative column, I was thinking “Ahh, but this is better!” Without saying anything negative, he shows us that you can run an organization either way, that you need both, but there is a distinction.

Continue reading Cooperative vs Collaborative

Roadmap for Planeshift’s Developer Community

This morning a question blossomed into my head, prompting me to check out an old game named Planeshift. It is an MMORPG that differentiates itself by asking players to roleplay in character and not break the illusion. They’ve developed a deep and colorful backstory – all taking place inside of a hollowed out stalactite! By elevating story-writing and art as equal importance to coding new features, they’ve built a wonderful alternate universe.

I decided that I’d like to come back to this game, which remains exactly as lovable as I remember 6 years ago when I volunteered 3d models, and contribute in a different way. Publicize it, share it, optimize their Customer Acquisition Funnel and build a pipeline of new players into the game. There are a few hurdles for them to overcome first and as a thought process I will list them out here.

Roadmap

Remove Barriers to Contribution:
Think about how quickly someone can go from hearing about the project, to seeing the code, to submitting a change to fix a typo or comment. This should be minutes.

Unfortunately with Planeshift it is weeks. This is problem is compounded by the fact that active development is happening in a private branch that potential contributors don’t even know exist. This is a big no-no for two reasons. First, it makes the project look dead to outsiders, and second it literally prevents first-time contributions.

Continue reading Roadmap for Planeshift’s Developer Community

AWS Loft – Skopenow and Privacy

Code Happy

NYC AWS Pop-up Loft Pitch Event

Yesterday I had the pleasure of visiting Amazons Pop-up loft in SoHo, and listen to five startups pitch their ideas to a crowd of fellow engineers, entrepreneurs and VC investors. Each presentation had something unique to offer and many triggered interest from the crowd, but one of them in particular stood out.

Only one of them made me forget I was standing, forget my surroundings and get lost in the swirl of ideas and possibilities. It was Skopenow, a service which crawls the internet to compile profiles for people. Ultimately generating a report which is someones digital identity. They interestingly avoid the stickypoints of privacy litigation by not storing data themselves and instead aggregating it live from other companies and services.

Continue reading AWS Loft – Skopenow and Privacy

Announcing Office Hours

This Tuesday I will be hosting my first office hours!

This is an opportunity for anyone in the world to have 15 minutes of time to chat about javascript, web development, or computer science in general.

I will gladly give you my ear, my time, and my best effort to help you figure it out.

There will be four Skype slots, on August 4th.

August 4th, 7:00 – 7:15pm EST — Booked
August 4th, 7:15 – 7:30pm EST — Booked
August 4th, 7:30 – 7:45pm EST
August 4th, 7:45 – 8:00pm EST

For more info, read my post here.

Optimizing Webpack build size

Optimizing File Size

I decided to tackle file size as a fun side project at the office. After our big refactor for JW7 we finally had a modular, clean(er) codebase – so now the fun begins. Let’s squeeze it down as small as possible!

With this kind of task it’s always best to set some goals, pluck the low-hanging fruit and then re-evaluate. Our current player size was 232 kb minified, and as a team we established a goal of reaching 200kb.

To identify targets for refactor, I enabled verbose reporting on WebPack. This causes the compiler to output the size of each module independently. I piped that into a file and deleted everything above and below the modules list.

$ cat modules.txt | tr -s ‘ ‘ | cut -d’ ‘ -f3-5 | grep -v “bytes” | sort -g -r -k2,2

 

This command takes the modules output from WebPack, trims out the extra spaces, takes the substring between the 3rd and 5th space, removes all rows which are measured in bytes instead of kB and then sorts.

The results

../jwplayer/src/js/providers/html5.js 25.6 kB
../jwplayer/src/js/utils/helpers.js 24.7 kB
../jwplayer/src/js/controller/controller.js 23.7 kB

Continue reading Optimizing Webpack build size

Unexpected trials on the road to Colemak

 

I want to take a moment to jot down a list of trials I didn’t see coming. They accumulated to the point that after 4 months, I wanted to quit. However it was too late, and I am -for better or worse- too impatient to use QWERTY.

Unexpected difficulties with Colemak

  1. When computer boots, I need to type my password in QWERTY mode until app loads (true for mac and windows, not true for ubuntu)
  2. I need to install software inside my virtual machines, as well as on the computer
  3. How frequently I type on other peoples computers, especially when training new hires
  4. After learning the keys, my muscle memory for timings would be slightly off
  5. Key-bindings in video games (StarCraft 2) are demolished
  6. Colemak isn’t necessarily the best, there are new trendy ones showing up daily

 

With these being noted, I still think it’s worth giving up QWERTY. For a new adopter I’d suggest viewing a few other alternatives as well, including the Workman, Norman and maybe others too.

One idea for the future that would make life a lot easier would be an app which detects your keyboard layout as you type and swaps them automatically. When my friend types “google.com” into my laptop, and the computer sees “tlltuk.c;m” it will figure it out and just swap back to QWERTY.

 

Why I decided to try Colemak

 

Like most engineers, I am a huge fan of lifehacks. Why not improve HOW we work? Well the latest experiment I tried was switching from the dated QWERTY keyboard layout to Colemak.

Context

When I switched to the Code Keyboard, I was very inclined to love it. I wanted to adore it, it was designed for me; it was beautiful, nerdy and well designed. Unfortunately over the first week the joints in my fingers began to ache- I believe due to the resistance of the cherry MX Clears. I wasn’t ready to give up on the keyboard so I did some research into reducing the strain of typing. It turns out QWERTY is known for being inefficient; lo and behold, there was a readymade solution in the form of overhauling the keyboard layout.

So I declared to the world that I was making the switch.

Why?

  1. Hopefully eradicate finger pain
  2. Improve my typing performance (speed, accuracy)
  3. Be an early adopter of what I believe to be an important movement

I do expect to be making some sacrifices, such as

  1. Decreased productivity during learning curve
  2. Need to install software on my machines

 

Backbone Relational vs Backbone Associations

The challenge

We were recently looking for a way within Backbone to elegantly handle event delegation from sub-models. For example a house has many rooms, and each room has one or more desks. In this case each stage is a model which owns and should be able to monitor changes to its children. For example, a house may want to monitor if there is a change to the ‘occupied’ attribute of any desks inside it. I was tasked with comparing two plugins which solve this problem: Backbone Relational andBackbone Associations.

1. The documentation – in my humble opinion the documentation should be responsible for three things. Describing the problem, describing the solution and explaining how it wants to be used. That’s it. Skim over it, try to see which assumptions they are making but come to your own conclusions. It’s tempting to look at all the nice features but that doesn’t mean you should jump on board.

2. Source Code – Read every line, and then don’t use a plugin that you couldn’t write yourself. If it doesn’t read smoothly and you find yourself questioning their decisions than you need to back away.

3. Favor the simpler solution – Brevity is elegance. Extra features are added complexity, and you want the bare minimum that works for you. Complexity will come over time as you start adding domain logic, which is why you want your building blocks to be as concise as possible.

4. Be wary of dependency chains – This hasn’t been a problem for most plugins I’ve viewed, however it isn’t uncommon in real applications.

5. Check out the community – is this something that’s up & coming (like angularJS today) or something on the decline (mootools). How often are non-primary developers contributing and how active is the owner? The facts are easily available on Github and give you a real sense of how the plugin will stand the test of time. You don’t want to be the last person on the bus, nor do you want to be the first. *BONUS*– Send a message to the developers and see if they respond.

Okay, but what about these backbone plugins?

1. The Relational documentation follows the format of underscoreJs.
2. Equal
3. Associations was much shorter / more elegant
4. Equal
5. At this point I already made up my mind, but I did shoot a message to dhurvey on Twitter and he responded within a day. Reliable guy!

The primary selling point for me was that it was a fourth of the size of Relational. It was significantly easier to read and was more specialized (it didn’t solve problems I don’t have like many-to-one relationships). Admittedly Relational had a larger user-base and it’s community was a bit stronger, I messaged it’s owner on twitter and got a response within a day. The rest was about the same. I knew I could re-write it if I needed to whereas I didn’t think I would want to re-write relational. Finally they had the same API which makes the transition between them easy if we change our minds later.

After realizing that I had a strong preference for Associations I prepared my argument. I stated the maintenance benefits of choosing a smaller solution, and I bragged about its code legibility, but what got everyone’s attention was when I mentioned its performance benefits. Backbone Associations was nearly twice as fast for very large objects as compared to Relational.

Resisting the Big Submit

I’ve seen it too many times – a submission into Version Control with a description which is the laundry list of fixes and changes that happened to be bundled together. When changes lose their focus and do more than one thing, it is incurring an organizational debt that will be paid later. Whether it comes in the form of having to roll-back, do a complex merge, or even by camouflaging a change when someone looks through a files history.

It wouldn’t be fair to ask if you have ever submitted a change which fixed more than one issue. Sure you have, we all have, we love fixing things, but suppose you fixed one bug and you also wanted to tidy up some white-spacing issues at the same time. This natural tendency to neaten things up as we go is awesome and probably the sign of a conscientious team member, but it isn’t quite right. It is a micro-example of the same issue.  It will still make diffs harder to read, and has the potential to slow down merges depending on which software you are using. Life is easier when we have thousands of simple diffs where each has only a single purpose.

In practice this isn’t so easy.

  • It is inconvenient to keep opening a file for edit, making a small change, submitting and writing a description
  • We face bugs which have side-effects, which raises the question: does it make sense to fix the bug and its side-effects separately?
  • Some people are wary of bloating the change-history for a specific file (although they shouldn’t be)

It all comes down to workflow. If you want to convince an entire team to work with a similar style, it has to make their life easier. If it takes a minute to submit a white-space change then there is 60 seconds a developer is wasting his time, when he could have just lumped it into something else for free.

So why not let him lump the solution together, and then submit them separately? This is possible with Git (by using the “s” option you can separate out the changes within a file into multiple chunks). However this is impossible with CVS, SVN and Perforce which each operate on a per-file basis.

This denotes the importance of choosing a proper source control. The system sets the tone for every interaction between the engineers and their codebase. If you want to encourage good habits and make your developers happy, then you need to make it easier than the alternative bad practice.