Passwords in Source Control

This weeks blog is from John Resig, creator of jQuery.  He writes about a tip from his friend on the problem of how to store encrypted files in source control.  Normally, he, and most people I'd say, would simply not store it at all.  Instead it would remain blank and if you needed it, would email the person and get it that way.

Here he proposes a new solution, store an encrypted file and provide a way to decrypt and encrypt it.  He uses OpenSSL, specifically CAST5 in order to perform this.  He wraps this all within a nice makefile and boom, he has an easy way to perform the (de)encryption.  For the exact specifics, check out the link.  The makefile itself is very short and the main work is done all within the single openssl call.

Gittip

I recently read an article about Gittip.

Link

I've never heard of it before, but essentially it's a way of giving a tip to all your favorite open source contributors.  I love this idea.  As a contributor, the whole spirit of open source is to write knowing that you won't get monetarily compensated, but you're giving to the community to make it better.  I love this altruistic mentality.  But would't it be nice to have a way to say thank you?

It's awesome to be able to get something in exchange for your hard work.  Having actual money is nice, but also having something as a way of knowing that your work is really appreciated and that the community wants you to continue.  And with the money, being able to continue, assuming that it's providing you some kind of supplemental income to be able to give up long stretches of time to contribute.

At the end of the day, it's about saying thanks.  There are other ways to say thank you, like finding the person and baking their favorite cake (might be creepy if you don't actually know them) or sending them that t-shirt they've been talking about (again I wouldn't recommend if you don't know them personally).  But giving a small tip is another simple gesture that goes a long way (and a better alternative if you don't know them).

Sassy Structure

Let's face it, everyone structures their css slightly differently.  Or worse yet, they don't structure it all and it's just a mess of files all over the place
causing a sort of treasure hunt to try and find the freakin styling that's causing your div to float right (of course what I really mean is to use an inspector like the one in Chrome and see what style is causing the behavior).  That's why I really liked this article:

http://thesassway.com/beginner/how-to-structure-a-sass-project

I liked how he layed out his sass files in a neat organized way.  So a little backgroud, if you don't know what sass is, it stands for Syntactically Awesome St
yleSheets.  It, along with some other competitors (namely LESS) provide a language that is a supserset of regular CSS.  So you get all the stuff you're used to
 in CSS, along with powerful constructs like variables, nesting, mixins, and inheritance, just to name a few things.

What I really like about John Long's project setup recommendation is the clarity and organization of how he lays out his files.  If you need to change somethin
g, you pretty much know exactly which file to look in; no more hunting.  And while developing, if you need to add a new style, you have a pretty good idea wher
 you should add it.

Same goes for his really large project structure as well.  He basically just copied what he did for the single project and divided it up into smaller 'sub-proj
ects' that all duplicate his basic directory structure.  The only thing I'd add here is perhaps a 'common' directory that has shared styles that can be used ac
ross all sites.

So take a gander and see if it looks like you're project.  The key here is organization and clarity.  My personal belief and motto is that "coding is communica
tion".  On one hand, you are communicating to the computer what you want done, and on the other you are communicating to other developers and future maintainer
s what your intent was.  Your goal as a developer is to maximize this clarity so that there is no ambiguity and your intent can be immediately understood.
~                                                                                                                                                          

IP Address to Location

There are a bunch of sites out there that all translate ip address to location, but I needed a simple and easy to use API so I could do it programmatically.  I found this little guy:

http://freegeoip.net/json/50.202.78.174

Instead of json you can also use xml or csv and the last bit is the ip address what you want to translate to location.  I love it, stupid simple.

Callback versus Promises

I like Node.  I like the callback mechanism.  I find the approach to multithreading very interesting.  That being said, I should preface that I also like Java's Futures/FutureTasks.  I guess what I'm trying to say is that I like things where I don't have to think about forking and joining (I'm ok with Java7's ForkJoinExecutor because again, I don't have to do it myself).  Just do it for me and give me the result when you get it.  In the meantime I'm going to make myself a sandwich, or whatever else I'm going to do while you're out fetching me whatever it is I asked for.

As such, this post got my attention:
http://blog.jcoglan.com/2013/03/30/callbacks-are-imperative-promises-are-functional-nodes-biggest-missed-opportunity/

James Coglan's basic assertion is that Node's decision to go with the callback mechanism was a mistake.  Before I go much deeper, I'm going to summarize a bit just in case you tl;dr it.  Essentially callbacks is at it's core an imperative construct while Promises (essentially FutureTasks) are more functional.  Why do we like functional versus imperative again?  Well because imperative tells the computer HOW to do something while functional tells the computer WHAT to do.  Imperative programming mutates state of objects as those objects are passed from function to function.  This means our programming is very dependent on the order of method invocations as well as the exact state of the objects over a given time.  Functional programming deals with values.  Arguments are values, and results returned from functions are values.  Nothing is holding state.  This essentially lets you parallelize a lot more because you never have fear or two threads potentially mutating the same object concurrently.  For any given input, you will ALWAYS get the same result.  1+1 is always 2.  But varX + varY could be 2 if varX and varY are both holding 1 at the time of execution.  But let's say this method then mutates varX.  Uh-oh, now depending on when you call this imperative method, you could get 2 or 3.  Get it?  Kind of?  Good enough.

So why did Node go callback?  Well because it's easier to understand.  Promises are much more abstract.

Callback
makeSomeBlockingCallWithCallback(callback);
This is easy to understand, you make some blocking call and when it's done, the callback method is called.

Promise

var promise = function() {
  var p = new Promise();
  var results = makeSomeBlockingCall(); 
  p.resolve(results);
  return p;
}
promise.then(callback);

I tried to do this with as little code as I could, but even without error handling, its longer than the callback example.  But let me explain what's going on here.  You create a promise object, run some blocking code, then shove the results of that onto the promise and return it.
We can chain together functions by using the then, which allows us to call our callback.

So what's the advantage of doing this?  There's a lot of extra code and the end result is the same, isn't it?  Not quite.  The first thing is that you avoid the infamous callback hell.  If you wanted to chain using the standard callback way, you'd have something like

makeSomeBlockingCall(function() {
  anotherLongCall(function() {
    yetAnotherLongCall(function() {
      console.log('im in callback hell!')
    });
  });
});

This happens quite a lot in node, think database work.  You open a connection, if it was successful write, after done writing, say you update a file or something.

For the Promise approach, you just have promises that all chain.

promiseForSomeBlockingCall
  .then(promiseAnotherLongCall)
  .then(promiseYetAnotherLongCall)
  .then(function() {
    console.log('less callback helly');
  });

So there's a slight improvement there in readability.  But if the only reason you're using promises is to reduce your callback hellness, you're missing the point of all this.  Remember what I said before about imperative versus functional programming?  The promises approach does not mutate the arguments.  Each promise does something and after it's done, returns a value into the next call in the promise chain.  If anyone of them fails, then the chain is broken (this is desired, if you can't connect to the db, you shouldn't write to it).

This is not the case with callbacks.  The only way data can get into a callback is via argument.  That means that all behavior is done as a result of a side effect (a side effect is when you mutate the argument).  You are no longer dealing with objects as values, objects now hold state that mutate over time.  This reduces what we can do concurrently as we are now very dependent on the order of method invocations and are extremely sensitive to the state of the variables as they change over time.

So how does this effect you?  Well jQuery now has Promises (http://api.jquery.com/promise/) and Deferred objects (http://api.jquery.com/category/deferred-object/).  A deferred object is like a promise but has no resolve or reject method (resolve is used to store the results, reject is used to break the chain).

Callbacks are great and easy to understand but let me just say on your next javascript project, you should go ahead and give promises a shot and see what you think.