Devember 2016 – Day 2

Day two is complete. Continued work on the stuff I was doing yesterday.  Streamed it live to no one. That’s fine.  Overall, I’m happy with the progress I’ve made tonight.  Handled outputs, both from defining the API along with the context of the request.

I think tomorrow I might want to tackle parallel commands.  So, if I wanted to fetch multiple pieces of data at once, I could do that.  Maybe I can do something more real tomorrow, such as have something that requests someones Twitter and GitHub feed at the same time.  I could do that.

Devember 2016 – Day 1

Day one is complete. I’m working on something completely different, but it’s started.

I want to build a system where APIs can be built using Node.js in a way that allows you to piece together different methods.  I realize there are systems out there like this, but I couldn’t find anything that meets my goals.  Besides, I wanted to build it.  Today was a longer day.  More than an hour, mostly because I didn’t want to leave it in a half state.  I can continue tomorrow where I left off with a working system and clear next steps.

I live streamed the entire session using Twitch.  There was one point where I was dealing with an error that I could not figure out.  Here is the moment I discover the very simple error. At some level, it’s fairly embarrassing to have that live on video.  But things like that do happen.

Most of this is being designed as I go along.  I’m not so concerned about performance at the moment.  Mostly it’s about getting it working.

Devember 2016

I, Jason Lotito, will participate to the next Devember. My Devember will be programming a game. I promise I will program for my Devember for at least an hour, every day of the next December. I will also write a daily public devlog and will make the produced code publicly available on the internet. No matter what, I will keep my promise.

My goal is simple.  I’m mostly following along with Handmade Hero and I’d like to continue on through the month.  I might do other things, and I’ll update that as I go along.  The goal is to get back in the habit of coding nightly and learn new things as I do it.

  1. Day 1

Scripts in Confluence are an anti-pattern

Scripts in Confluence are an anti-pattern.

If you are going to take the time to document something out, then make an effort to take the time to script it out.  Even better, add it to something like Jenkins or Rundeck.  Maybe automate it.

This is true even if you have a list of steps in your documentation.  Run step 1, then step 2, then check for this, and if it’s true, do step 3, otherwise continue to step 4.  You are literally writing the program in English.

Scripts in Confluence are an anti-pattern. It’s not documented, it’s lazy.

Ninety percent of everything is crap

I repeat Sturgeon’s Revelation, which was wrung out of me after twenty years of wearying defense of science fiction against attacks of people who used the worst examples of the field for ammunition, and whose conclusion was that ninety percent of SF is crud. Using the same standards that categorize 90% of science fiction as trash, crud, or crap, it can be argued that 90% of film, literature, consumer goods, etc. is crap. In other words, the claim (or fact) that 90% of science fiction is crap is ultimately uninformative, because science fiction conforms to the same trends of quality as all other artforms.

Theodore Sturgeon, Venture 49, September 1957

Lessons

So much to say. I think the core lessons are: be patient, don’t give up, and always be learning. You can turn even the most crappy situation into valuable lessons. Teach them to others. Be happy with what you have yet always strive to improve things. Don’t let people flatter you into playing their games. When things get weird, keep a log. Love and respect good people. Learn to keep the assholes at a distance. Don’t get hung-up on the past. Be nice to people, even those trying to hurt you. Speak up when things are bad, and tell the truth. Trust your emotions yet check where they come from. Don’t be afraid of taking risks, and learn to identify and manage risks. Solve one problem at a time. Be generous. Teach others whenever you can. Remember Sturgeon’s Law.

Confessions of a Necromancer

bind

There are those times I come across an article that are so amazing simple and obvious that it immediately changes the way I write code. Understanding JavaScript’s Function.prototype.bind is one such article. It’s one of those articles that talks about something I always knew, but never really thought about it that way before.

I’ll let the article speak for itself, but I want to give you the pattern I enjoy now. I want to show you how it makes itself easy to approach and use.

So, let’s say we have this bit of code.

Buckets.prototype.add = function(data)
{
  var stopEarly = ! (this.options.stop_on_match === true);

  _.each(this.bucketConditions, function(c){
    if(c.test(data)){
      this.buckets[c.name].push(data);
      return stopEarly;
    }
  }.bind(this));

  return this;
};

This is part of a buckets node package I’m finishing up. Now, I want ‘data’ to be whatever they pass in, so this could be an object, an array, or whatever. Because of that, however, I need to create another function that allows the user to enter in a list of data.

Buckets.prototype.addList = function(data, cb) {...};

Obviously, I want to reuse the ‘add’ function already created. So I add this:

Buckets.prototype.addList = function(data, cb)
{
  var that = this;
  async.each(data, function(v){
    that.add(v);
  });
};

We’ve all seen code like that. However, the article mentioned above reminds you about .bind, and its special ability to bind the function to a certain object as context. This means instead of writing the above code, I can do this:

Buckets.prototype.addList = function(data, cb)
{
  async.each(data, this.add.bind(this), cb);
};

This is so much easier, and so much more elegant. I highly suggest reading the above article. It’s wonderful.

Keeping SSH connections alive

It’s actually fairly simple. In your SSH config file, you add this:

Host *
    ServerAliveInterval 240

The * after the host can be whatever host you want it to apply to, and *simply means to apply this to all hosts. So you could also apply it this way:

Host example.com
    ServerAliveInterval 240

Also, if you aren’t sure where your SSH config file is, on a UNIX based system, it’s generally in ~/.ssh/config.