What is JSONP?

Let’s say you serve up a page to the client and, in addition to the data your server generates, you want to include some data from weather.com.  Weather.com has an API limit, though, so your server can’t request that data more than a handful of times in a given period.  To get around that limitation, you offload the task to the client; it (attempts) to issue an AJAX request to the weather.com API and now (you hope) you have a million clients hitting the weather.com API with a couple of requests, rather than one server hitting weather.com with two million requests.  

Frustratingly,  you’re going to bump into a major browser limitation that is the result of an ill-conceived security measure:  your browser isn’t allowed to access resources from outside of the domain you’re currently visiting.  This is called the same origin policy. Your AJAX request won’t work.  

The good news is that someone already figured out a way to get around this limitation.  Its called JSONP, short for javascript object notation with padding.  It works like this: 

Rather than issues an AJAX request, the client dynamically generates a script tag and appends it to the DOM.  The script tag has a callback parameter, specified in the querystring at the end of the url. Your script tag will look something like:  

<script src=”http://weather.com/jsonp?callback=myCallback13425”></script>

If weather.com supports JSONP,  the script it sends back will have the effect of appending the JSON data you requested to your client’s window on the object you specified: myCallback13425.     What’s with the random digits at the end of the callback?    A random string is always appended to the callback names so that, in the event of multiple JSONP requests to weather.com,  subsequent requests don’t overwrite the data your original requests sent back.   Make sure you don’t add those digits to the beginning of the callback, though; variable names beginning with numbers are not allowed in javascript! 

There are a few more things to do here:  you should remove the script tag after your data is loaded and run whatever callback was passed into your JSONP function.  But beyond that,  you’ve basically gotten the gist of implementing JSONP.: Add a script tag, load your data, and get around the (ineffective) security policies the browser tries to implement.  

Side note: If the weather.com server has been compromised, it could easily inject malicious javascript into your client.  For this reason, JSONP should only be used with secure, trusted domains. 

var isPowerOfTwo = function(n) {return n.toString(2).match(/1/g).length === 1; };

— 

My (clever?) solution to a power of two test.

update:  the better solution is: return !(n & n - 1)

Surfing the internet is so hot right now. 

Week 4: Bring it on!

Week 3 is in the bag!  Here is a quick list of the topics we covered: 

• Backbone.js - Client-side MV* framework
• CoffeeScript - A clean, easy-to-read, language that transcompiles into Javascript.
• Node.js & HTTP -  communicating with server-side JS over the web

Since a bulleted list of frameworks or languages isn’t all that interesting, here are the key takeaways from each: 

• Working with Backbone (and perhaps you could extrapolate this to any opinionated framework) is like swimming in a fast-moving stream: swim against it and you’ll get nowhere.  Swim with it and it will carry you unexpectedly far, unexpectedly fast. 
• Coffeescript is awesome, but not awesome enough. Coffeescript syntax makes for clean, readable, and compact code.   Unfortunately, if you want to do any real debugging, you’ll still need to dig into the compiled .js source files.  Coffescript syntax is a huge plus, but not quite enough of a plus to net out the minus that is the its incremental debugging complexity. 
• Node.js is everything I wanted in server-side javascript.  If you can 1) write a RESTful API in two dozen lines of 2) non-blocking asynchronous code which is perfect because 3) your rich-client app is built to sync with a simple API anyway, why would you ever use anything else?

It’s Already Week 3!

Here is what you missed in week 2: 

• Algorithms (N-queens), Complexity analysis, Big O notation 
• AJAX & REST (using the Parse API as an example) 
• Classical inheritance in Javascript 

Also, I used part of my day off yesterday to provision an EC2 instance, install make, npm,  git, and node via the command line and successfully deployed an Express application the cloud. 

Communication is Everything

When we code, we do it in pairs.  The workflow goes something like this: the broader class gets an assignment in the morning, we break off into twos, and we spend the next couple days getting as far as we can in the assignment and extra credit.  During this time we each have our own keyboard and trackpad that share control of just one computer.  Everything we do has to be done together; nothing is achieved without collaboration.  

So, what makes someone a good pair?  Is it their encyclopedic knowledge of algorithmic complexity?  What about their in-depth understanding of data structures?  Perhaps they’re already familiar with node.js and can tell you everything you’d ever want to know about the API?  Nope; those things might help, but what really makes someone a great partner is their ability to communicate. 

When we talk about objects in the physical world we have the benefit of a language that was built to describe tangible things.  In meatspace, ‘that one, over there’ helps us refer to an object without naming it specifically.  Its position relative to ours helps us to single-out one of many like objects.  But the language conventions that serve us well in the real world become our undoing when writing code.  What is the ‘thing’ you’re referring to?  ’Over’ where? Everything is compressed onto a two dimensional screen.

The ambiguity of a loosely constructed sentence increases by orders of magnitude when code is the topic of discussion.  When stepping through recursive algorithms or imaginary data structures, it is so easy for that one ill-conceived pronoun to completely change the way someone else interprets your words.  ’First it does this, then it does that’ is a recipe for confusion and miscommunication.  Soon enough, your partner won’t have any idea what you’re talking about.  

So, what should you do if you want to be a highly-sought-after developer?  Learn the ins and outs of git?  Get really well-versed in application monitoring?  Nope; first your should learn how to clearly and concisely communicate your ideas to fellow programmers.  Trust me, it makes collaboration a hell of a lot easier.

My group’s solution to n-queens of 20.   Algorithm runs in about 15 seconds.  

Hack Reactor Week 1

Just finished the first six days of Hack Reactor.   I’m blown away by how much information I’ve been exposed to in such a short period of time.

The hours are significant, but what makes the class truly noteworthy is the rate at which information is being provided and -I hope- consumed.  This week we were given substantive introductions to: 

• Test driven developments and JS test frameworks like Mocha and Jasmine
• Data Structures including: stacks, queues, sets, linked lists, trees, and binary search trees.  
• Javascript fundamentals 
• Inheritance patterns ranging from simple maker functions to pseudoclassical inheritance simulated in JS. 

Listening is great but coding is better, so we: 

• Pair programmed unit tests to verify app functionality
• Wrote our own implementations of a binary search tree et al.
• explored .this and prototype in depth
• used Chrome’s CPU profiler to evaluate the performance implications of different types of instantiation.

That’s plenty to learn in one week, but I almost forgot to mention that we:

• implemented underscore.js’s core methods like _.map, _.reduce, _.each and others.
• created a recursive shim of the browser’s native getElementsByClassName
• created a Twitter clone

And we did it all as part of the pre-course curriculum. 

I’m excited by how much I’m going to learn in this program.   For now, I’m just looking forward to a day to rest up! 

rushdesign:

When a very important NAND gate fails just make one…

Love this.   At the end of the day, all code depends upon an arrangement of transistors.  Refreshing to see them as they might have existed half a century ago.  

Why I quit my job to become a developer

Some months ago I arrived at the conclusion that I should quit my job and learn to code.  What follows is a a brief explanation of why I chose to leave a well-paying job at a household name startup to become a junior developer.

First,  a bit about me: I’m 28 years old at the time of this writing.  I’ve always been interested in startups but I particularly fell in love with entrepreneurship after signing on as LivingSocial’s first business analyst.  In that role, I realized that I had a knack for identifying ways to increase revenue and profitability; I pitched upper management on LivingSocial’s ‘at Home’ business line.  It cleared seven figures in revenue in its first year.  Later, I advocated for and helped deploy a change to LivingSocial’s sales contracts which contributed $20MM to EBITDA in the 2H 2012 and 1H 2013.   

So, given some success, why leave?  At the core, the logic was pretty simple: I wanted a job that would allow me stay in startup land forever.  I love working with smart, hungry, scrappy people in a do-or-die environment; in my opinion, it’s the only way to get things done.  As far as I know, there are two ways to do this: operate or invest.  ’Operate’ means that you build and run things on a day-to-day basis.  ’Invest’ means that you work at a venture capital or growth equity firm and provide capital to startup companies. ’Invest’ can be a great option, but there are many who would argue that the venture capital world is both overcrowded and broken.  Those concerns notwithstanding, almost all of the VCs and company founders I spoke to before deciding on this career move felt that the best VC training is to launch a startup and drive it to a successful exit.  In other words, even if you want to invest, the first thing to do is to operate.

But why change careers; couldn’t you just work in finance / analytics / sales operations at another startup?  In short, you could, but you’d be late to the game.  

When a startup launches, it should be focused on essentially just two things: building the product and finding traction.  The game is to build a product that the market wants before cash runs out.  Not only is it not possible to do these things without engineers but, until the company finds traction and secures financing, any additional headcount you add only decreases your cash runway.  As a result, even if an employee can add tremendous value in sales operations, analytics, or finance, odds are that employee won’t get hired until well after the core developers do.  It’s the natural order of things; the product and market fit have to come first.  Not only do non-devs join later, they generally get less equity, too; if you subscribe to Paul Graham’s theory that the your stake in a company is approximated by 1 over n squared where n is the number of employees at the company before you join, employee fifteen has orders of magnitude less equity than employee five.  In short, If you work as a developer you’ll be in-demand earlier, you’ll get the chance to join the company at a more formative time, and you’ll have a greater ownership stake.

This leads me to my conclusion: if you want maximize your contributions to an early-stage startup, coding is an essential skill.  Not only can you build and test the product, you’ll have a deep and sophisticated understanding of the level of effort that any new feature or product requires.  Before you steer the ship in a new direction, you’ll understand very clearly the implications your decision has.  Coding is a useful skill in dozens of other ways, too:  need to create landing pages for A/B testing user acquisition?  Done.  Oh, you need to start taking payments now via integration with Stripe or Braintree’s API?  Check.  What about building an internal tool to cut 25% out of your company’s workflow?  Got that too.  

Choosing to leave a comfortable, impactful, job at LivingSocial was a hard thing to do.  But when I look at the things I enjoy professionally and what I want to accomplish over the rest of my career, learning to code is a no-brainer.