Keeping things in perspective

When my dad immigrated to America from Hong Kong, he carried everything he owned in his suitcase. By day, he was a college student. By night, he worked a night shift at the Ramada Inn. If he was lucky, he would squeeze in a few hours of sleep before the start of the next day. He would go from door to door, inquiring about work. Any work. Whatever the job was, he was ready to do it. Mowing lawns. Washing windows. If he didn’t know how to do it, he was willing to learn how. For him, work wasn’t about finding the best perks or a company whose mission he believed in. It was about surviving in a foreign world still rampant with racism where he played the role of the outsider. He would eventually work his way to becoming a city planner. He had lofty notions of giving back to the community that he had come to know as his home, but he found that workplace politics created a different reality than he expected. He held a very respectable job, but though he had come so far from when he first arrived, his work was the source of many frustrations. The day he retired was a day of relief.

When my mom immigrated to America from Cambodia, she had a hundred dollars to her name and the only family she had was her sister. The two of them were taken in by a pastor and his wife in Stockton. She studied at the University of the Pacific, and while she was there she met my dad through a mutual friend. Her dream was to be a teacher. She tried to follow this dream, but the only work she was able to find was that of a substitute teacher–hardly a sustainable career. My dad recommended she choose another line of work instead, and so she became an accountant. Being an accountant wasn’t her dream, but maybe it would help her achieve another dream of hers: the dream of providing a better life for her children.

Because of my parents’ hard work and sacrifices, my sister and I were able to grow up and get a good education at a prestigious university. I am now employed in an industry where I am regularly solicited by companies to work for them. Companies compete to provide the most attractive benefits to lure one of the most highly sought after contingents of this country’s workforce, of which I am a part. My biggest worries about work usually involve what kinds of things I’d be most interested in working on. I say this not with a sense of entitlement, but in awe of the options available to me.

One day, my parents were reminiscing about the past. My mom looked around at the house–at her life–and said, “I can’t believe how lucky we are.”

It’s good to keep things in perspective from time to time.

Advertisements

Be specific

Originally posted on medium.com.

Fill in the blank: eval is ________.

If you’ve been working with Javascript for any substantial amount of time, there’s probably no thought required in this task. For those who are new to Javascript, the completed phrase is: eval is evil. The phrase originates from Douglas Crockford, the Javascript guru whose words many regard as scripture. You can read more about the eval function on its MDN page.

The bad taste that eval leaves in the mouths of Javascript developers is so ingrained that the reaction is almost Pavlovian. Let’s parse this motto to uncover the real meaning behind such a powerful phrase.

Except we can’t. The only meaning we can extract from those three words is that the usage of eval is a no-no. While Crockford’s other recommendations are accompanied by rationale—some keywords result in confusing code, some coding practices produce evasive bugs—the admonishment of eval comes with no such explanation other than the decree of its nefariousness.

Until the machines rise up against us—and it’s only a matter of time before they do—I can’t seriously consider a programming keyword evil. The reasons for avoiding the eval function are well-known and fall into three main categories: security, performance, and maintainability. Perhaps Crockford’s well-known slogan could have been: “eval is an overly powerful function which produces code that is difficult to debug, with serious security and performance implications, commonly misused by many, for which there is almost always a better alternative.” I’ll concede that this phrase isn’t as pithy, and it doesn’t roll off the tongue in quite the same way, but it would have provided more information for the betterment of developers everywhere. I’m actually not opposed to the “eval is evil” phrase. It’s really easy to remember, as evidenced by the readiness with which it is recited, and gets its point across succinctly. I wouldn’t be surprised if there’s a tattoo out there of “eval is evil.”

Most Javascript developers already know why the use of eval is discouraged. But let’s face the facts: Javascript developers aren’t the only people who write Javascript code. A lot of non-Javascript programmers have written some Javascript at some point in their lives, due to its de facto status as the programming language of the web. And when these programmers are learning how to write clean, secure Javascript code, it’s in everyone’s interests to be upfront about the why’s behind the do’s and don’ts.

The “eval is evil” phrase is just one example of how criticism frequently tends to be too general. I’ve been guilty of giving overly general criticism myself, and I’ve been making a conscious effort to be more specific when giving feedback. There are benefits to giving specific:

  1. You demonstrate that you actually know what you’re talking about.
  2. You’re in a better position to suggest ways to improve the thing you’re criticizing.
  3. You seem less like you’re whining. Or, you’ll seem less like an ass.

If you can’t articulate why you dislike something, or if you have no suggestions for improving the thing you’re criticizing, you’re in no place to criticize it. Even when you’re giving positive feedback, being more specific is always more valuable for the party receiving the feedback. In general, talking in specifics is the easiest way to start having more constructive discussions.

How to start working on side projects

This post was written for a technical audience, but its core ideas can also be applied to other fields. Originally posted on medium.com.

There are many reasons for a software developer to work on a side project. It’s a good way to keep a pulse on technologies that are currently trending in the industry. It helps you keep your programming skills sharp. And it’s fun! Or, at least it should be.

But then there’s that thing we call “life” which can make it difficult to start a side project, let alone finish one. We’re often spending so much time trying to stay afloat in our hectic schedules that it can seem impossible to squeeze a side project in.

I started working on my first side project two years ago, so I am no expert on this matter by any means. During these past two years, I’ve made observations about how I got started on the side projects I’ve started and why I was able to finish some and not others. What follows is neither particularly groundbreaking nor an official guide to working on a side project, but merely the aforementioned observations I’ve made which you may find helpful.

Work on something that interests and excites you

I hesitate to write something that sounds so painfully obvious, but it’s very important. A side project should be something that you get excited about working on. When you wake up on Saturday and you start to go through your agenda for the day, what is your gut reaction when you consider the idea of working on your project? If your thoughts begin with the words “I should probably…”, you’re not off to a great start. If they begin with, “I get to…” or “I finally have time to…”, then that’s starting to sound a little better!

Take breaks

Your project should be many things. It should be fun. It should be something you look forward to working on. What it should not be is a chore. If you’re working on your project and you’re not enjoying it anymore, hit Save, get up from your keyboard, and go exercise. Play video games. Go shopping. Whatever it is you do to unwind, do it. Don’t come back until you feel ready to work on your project again, whether it takes a day, a week, or a month.

On finishing a project

The level of importance for completing a side project varies from person to person, and even from project to project. Some side projects serve as a means for experimenting with new technologies. It’s completely fine to leave those experimental projects unfinished. For the rest, however, having a goal to finish can be very beneficial. The desire to finish your project adds motivation to working on it, and it’s also a nice bonus to be able to show your work to others once you’re done.

Working on something you find exciting (point #1) is especially important for taking your project through to completion. If your project is even remotely substantial in size, you’ll be spending a great deal of time on it, and you may begin to feel fatigue from working on it after some time. The novelty of your project idea might diminish over time, and when that happens, you’ll want as much residual excitement to remain as possible.

One project at a time

While you work on your project, you may start to form other project ideas in your head and get the urge to work on them. That’s great! You can never have too many ideas. Write them down so you can work on them later, but don’t switch to another project until you’re done. Trying to work on two projects concurrently is the best way to ensure that you will complete neither. If you do switch projects, either have a concrete idea of when you’ll pick up where you left off with the original project, or acknowledge that you probably won’t finish the project.

By the way, it’s perfectly fine to end a project without finishing it. That just means that something about the project changed from the time that you started it. It might be technically infeasible. Maybe you’ve learned that your idea doesn’t make sense. Or maybe, for whatever reason, it’s just not fun anymore. Whatever it is, the important thing is to take that information and learn from it.

Find a time that works

Working a slot into your regular schedule is the best way I’ve found to sustain progress and motivation for a project. Make it a ritual. For me, it’s the first thing I do when I wake up on the weekends. I’ll go to my local coffeeshop for a couple of hours, sit and write out some code, and I’ll be done before lunch. This has worked great for me because there are very few social obligations that begin before noon. Furthermore, I’ve found that finding a reoccurring time where I work for a smaller chunk of time (one or two hours) has been more effective than finding those larger chunks of time (three to four hours).

Have fun!

If you’re not having fun, then there’s really no reason to be doing it. Creating something new should be fun and exciting, and when you do it right, it can be one of the best feelings in the world.

Setting up a Syte

Yesterday I set up a new Syte. It’s a web application for hosting a personal site with social integrations like Twitter, Github, Instagram, and more. It’s very well designed and makes it very easy for people with decent amount of technical expertise to set up a personal site.

The blogging platform that is supported out of the box is Tumblr. In the README, there was a note about plans to set up integration for WordPress as well. I took a look at the WordPress API to see how hard it would be. It turns out that the WordPress API doesn’t require an API key, making it really simple to integrate into Syte. It took me a couple of days to replace all of the Tumblr calls (post offsets and tags) with WordPress. But I think it’s working.

I chose to get started with Twitter, Github, and Instagram for now. While Twitter and Github setup was relatively painless, the Instagram integration took me much longer than anticipated to get working. The Syte README alluded to the Instagram OAuth setup being very particular about trailing slashes. The directions for the Instagram setup include the following lines:

For the OAuth redirect_uri enter http://127.0.0.1:8000/instagram/auth/ for now since we will get the access token while running it locally. The trailing slash is required for Instagram not to complain that the redirect_Uri is wrong.

So I entered the redirect URI exactly as specified in my Instagram developer application settings. When I navigated to http://127.0.0.1:8000/instagram/auth/ in my browser, I would still get errors saying “Redirect URI doesn’t match original redirect URI”. That was odd! Eventually, I got it to work by following the Server-Side Flow on the Instagram Developer documentation page. I’m not sure what the Syte server was doing at the when the browser redirected back to the /instagram/auth/ redirect path, but I knew it wasn’t working, so I did not have the server running when I went through the flow.

Step One: Direct your user to our authorization URL

https://api.instagram.com/oauth/authorize/?client_id=CLIENT-ID&redirect_uri=REDIRECT-URI&response_type=code

I entered this URL into my browser, filling in the client ID I got from my application registration process described in the README, and I used http://127.0.0.1:8000/instagram/auth/ as my redirect URI.

I then was directed to a page asking me to grant my app permissions to access my photos. So far so good! I clicked accept. and was taken to Step 2.

Step Two: Receive the redirect from Instagram

Once a user successfully authenticates and authorizes your application, we will redirect the user to your redirect_uri with a code parameter that you’ll use in step three.

http://your-redirect-uri?code=CODE

Now I was redirected to http://127.0.0.1:8000/instagram/auth/?code=123456789, but since I deliberately chose not to run my Syte server, no page was loaded. However, I had the code in the URL, which I would use in Step 3. Step 3 basically says to request the access token (the end goal of what we’re trying to do here!) by using the code provided in step 2. I requested the access token using the curl example on the site.

curl \-F 'client_id=CLIENT-ID' \
-F 'client_secret=CLIENT-SECRET' \
-F 'grant_type=authorization_code' \
-F 'redirect_uri=YOUR-REDIRECT-URI' \
-F 'code=CODE' \https://api.instagram.com/oauth/access_token

(If you’re on OS X or Linux, you can enter this command into your Terminal, substituting all the necessary variables.) I got a response back with my access token, plugged it into my syte_settings.py file and voila! It was working.

Again, I’m not sure what went wrong on the Syte side of things. A lot of Googling around got me nowhere so I decided to just follow the Instagram instructions. I hope this helps you if you’re going through something similar.

Feel free to check out my new site at www.gordonkoo.com!

Backbone’s hard dependency on jQuery

There have been a couple of posts on Hacker News recently about reducing page bloat by cutting out jQuery.

I thought about my homepage, which included Underscore, Backbone, and jQuery. I realized that the features of jQuery that I use could actually be replaced by simple vanilla Javascript. After all, I mainly use jQuery to add and remove classes, and Backbone’s only hard dependency is Underscore, right? I’m not so worried about IE6 users, since I can probably count the number of monthly visitors to my site on one hand—one of which is me—and I doubt that they use legacy browsers. So I decided to do some spring cleaning and get rid of the magic dollar sign.

As it turns out, Backbone relies on jQuery for quite a lot of its functionality as well. Maybe it was naive of me to think that Backbone implemented its own event delegation when jQuery had already invented that wheel. But let’s take a look at what Backbone actually needs jQuery for.

For RESTful persistence, history support via Backbone.Router and DOM manipulation with Backbone.View, include json2.js, and either jQuery ( > 1.4.2) or Zepto.

RESTful persistence

Backbone models and collections can be synced with the server via fetch, save, and destroy methods. These methods all delegate to the Backbone.sync function, which wraps jQuery’s $.ajax function and calls GET, POST, and DELETE methods for the respective Backbone model persistence methods. No big deal here. The only “model persistence” I really do is make a Posterous API call to fetch my blog posts via JSONP. I can just create a script element, assign the API URL in the script src attribute, and inject it myself.

History support via Backbone.Router

A call to Backbone.History.start uses jQuery to bind a popstate or hashchange event listener to the window object. Backbone.History.stop uses jQuery conversely to unbind these event listeners. No problem. I know how to add event listeners on DOM elements: window.addEventListener. Done.

DOM manipulation with Backbone.View

Here’s my beef with Backbone. The documentation understates the extent to which Backbone Views depend on jQuery. One of the new features of Backbone is that all Views, in addition to the regular el property which represents the DOM element associated with the View, also get a $el property which holds the jQuery object for that DOM element. That sounds reasonable enough. In the past, I’ve actually just assigned the jQuery object into the el object for convenience, so giving it its own property seems logical.

Since Backbone claims its only hard dependency is Underscore and that jQuery is only needed for DOM manipulation, I thought that it would check for the existence of jQuery and only create the $el property if it found that jQuery existed on the page. To my surprise, Backbone Views cannot be created without jQuery. The following code results in a Javascript error:

  <html>
  <head>
    <title>My Test Backbone App</title>
  </head>
  <body>
    <div id="test"></div>
    <script src="underscore-min-1.3.1.js"></script>
    <script src="backbone.js"></script>
    <script>
        var TestView = Backbone.View.extend({
        el: document.getElementById('test')
      }),
      test = new TestView();
    </script>
  </body>
  </html>

All I’m doing here is literally just creating a Backbone View attached to a div element. That’s it. Backbone complains because it blindly tries to set the TestView.$el property without checking if jQuery even exists on the page. The offending function is View.setElement:

// Change the view's element (`this.el` property), including event
// re-delegation.
setElement: function(element, delegate) {
  this.$el = $(element);
  this.el = this.$el[0];
  if (delegate !== false) this.delegateEvents();
  return this;
}

Not surprisingly, the first line of setElement will throw an exception with the message “undefined is not a function.”

You could make the argument that Backbone applications can consist of models, collections, no model persistence, no history support, and ad hoc DOM manipulation instead of Backbone Views. But that’s extremely far-fetched. I have no idea how many Backbone applications include Views, but my guess would be 99% or up. Backbone’s own description of the framework involves separating data from DOM elements by assigning responsibilities to Models and Views, respectively. So if Views cannot exist without jQuery, why does Backbone still claim Underscore as its only hard dependency? At the least, it seems disingenuous.

Under the hood of Socket.IO namespaces

I am working on a very simple game using NodeJS and Socket.IO. I decided to separate my game and chat communication into two namespaces in Socket.IO to make the logic a bit easier to follow. One problem I encountered was that I wasn’t sure how to broadcast to all connected clients in a specific namespace. If you’re not dealing with namespaces, it’s simple:

io.sockets.emit(...);

But what do you do with namespaces? I tried io.sockets.emit(...) as well as io.of('/chat').sockets.emit(), but neither of these attempts were successful. The documentation on the Socket.IO site also provided no clues.

While debugging my application, I decided to look into the source of Socket.IO. It’s actually pretty interesting to see some of the code behind how Socket.IO is implemented. I’ll go through a small sample of my code and explain what was going on behind the scenes. If you’re simply interested in the solution, feel free to skip to the bottom.

A very simplified version of some of my server code looks something like the following:

var express = require('express'),
    app = express.createServer().listen(8000),
    io = require('socket.io').listen(app),
    gameSocket = io.of('/game'),
    chatSocket = io.of('/chat');

Let’s break this down line by line.

var express = require('express'),
    app = express.createServer().listen(8000),
    io = require('socket.io').listen(app),
    gameSocket = io.of('/game'),
    chatSocket = io.of('/chat');

Nothing surprising here. I import the Express module, which is the web framework I am using.

app = express.createServer().listen(8000),

This line creates my Express web application. Since the focus of this post is Socket.IO, I don’t show the routes that I set up here, but there are plenty of examples at http://www.expressjs.com.

io = require('socket.io').listen(app),

There are two ways to create an instance of Socket.IO. The first is to allow it to create a native Node http server for you. If you call the listen() method on it without any arguments, it will default to a server listening on port 80. Otherwise, the server will listen on the port you specify.

The second way is to pass it an existing server. This is the way in which I’ve created my socket instance in the code example above, and probably the much more common usage of the library. Express is the example web server used in the Socket.IO documentation, but it would be interesting to see if it works just as well with other more obscure Node frameworks.

So what actually gets stored into the io variable? The call to listen() creates a Manager object, which manages a lot of the interaction with clients, including exchanging handshakes, generating sessionIds, and listening for heartbeats to detect when a client has disconnected. I did not spend too much time looking into these areas, however, since the part of Socket.IO that I was particularly interested in was the creation of namespaces.

gameSocket = io.of('/game'),
chatSocket = io.of('/chat');

This is where things get interesting. Remember that io is a Manager object. The of method takes a single string argument and creates a SocketNamespace object under that string or returns an existing one if it finds one.

The SocketNamespace object inherits from Node’s EventEmitter. Each client that connects to Socket.IO gets added as an event listener for the particular namespace through which the client is connected. Then, when the SocketNamespace needs to broadcast to all of its clients (or listeners), it emits the event and the clients’ event handlers are invoked. That is a 50,000 foot view of how Socket.IO works!

What happens if Socket.IO is used without any namespaces? If no namespace is specified:

// io.sockets is a SocketNamespace object
io.sockets.on('connection', function () {
  ...
});

then Socket.IO defaults to the empty string namespace, ''. The following would be equivalent to the previous code snippet:

// for the general namespace:
io.sockets.emit('newPlayer', playerName);
// or for a specific namespace:
io.of('/chat').emit('newPlayer', playerName);

After understanding what objects are being returned, I was able to figure out how to broadcast to all clients in a namespace:

// for the general namespace:
io.sockets.emit('newPlayer', playerName);
// or for a specific namespace:
io.of('/chat').emit('newPlayer', playerName);
This has been a very interesting experience in digging through the Socket.IO source. While I barely scratched the surface of this very useful module, the exposure to the source code has been more than enough to solidify my understanding of Socket.IO namespaces.

Falling In Love At A Coffee Shop

Started learning Landon Pigg’s song Falling In Love At A Coffee Shop today. Interesting exercise in playing triplets against half notes. And it’s a sweet song.