I’m John K. Paul
an engineering manager
and a speaker

found on

contact at

john@johnkpaul.com

about me

Often an engineering manager, with many more interests than that

Subscribe to the Monthly Newsletter

powered by TinyLetter

Tonic, a JS Bin With Npm Attached at the Hip

- - | Comments

Tonic is a new service/tool for web developers that I’ve been playing with for a couple of days. It’s very similar to an IPython notebook, but completely through a web interface. It’s very interactive, and allows you to fluently write, test, and play around with Node.js code. You can test things out very quickly, just like JSFiddle, JSBin, CodePen or Plunker, but it is backed by npm which makes it much nicer.

This is their marketing copy. They say that Tonic removes friction. I was very surprised by how true that was.

NPM is first class

Any require statement is automatically parsed, and the dependency is added to the implcit package.json file that backs every “Notebook”. You don’t have to fiddle around with the JSON yourself, but rather just add var request = require('request'); and you automagically have the current version of request. There’s also some special additional syntax to use in your requrie statement if you do happen to require specific versions.

Endpoints are first class

The killer feature of this tool though is not the npm integration, but rather its ability to create on the fly APIs. I’ve been looking for something like this from a lot of other tools. I have wished there was a way to create a one liner API and deploy to Heroku as an endpoint by only using the web. Until now, I haven’t had anything like that. Now, not only do I get an API in 2 clicks and 3 lines of code, but it also supports CORS!

Creating a new http endpoint is as easy as clicking on compose in gmail. Clicking on new Notebook, and then writing this code, got me a passthrough to a non CORS, but open endpoint in < 5 minutes.

No more needing to spin up node on my VPS just to CORS enable APIs!

This is basically a two liner (of not boilerplate) to get my own Duolingo profile. In case you don’t know, I’m extremely addicted to Duolingo and many of my side projects are tools to remind me to practice learning languages every day. Tonic is going to make that tool writing so much easier! I don’t need node proxies anymore, I can just build my apps in JS Bin, calling to this new Tonic-built endpoint and be done in minutes!

I’m really excited about this; I’m sure you can tell. See you in the comments!

The Blog Post to Understanding Ratio

- - | Comments

As a programmer, you might be familiar with acronyms such as MTTR (Mean Time To Repair) or MTTF (Mean Time To Failure). Today I’m introducing a new metric called the Blog Post to Understanding Ratio or the BPUR. This new metric is pronounced as “beeper” (ˈbipər for the IPA fans) - you might remember these from folklore of the 90s.

The idea behind the BPUR is that some programming language concepts take many readings of many blog posts and other resources in order to fully comprehend. On the other hand, there are many topics that are much more readily digested. A high BPUR means that I need to consult with many resources in order to grok something, whereas a low BPUR is something that we can pick up without significant intentional thought. It helps me frame how complicated the topic is and how fast I can expect myself to understand a new topic.

For example, if someone was to start learning JavaScript from scratch, at some point they’d definitely need to understand the idea of assigning to a variable. Most developers are familiar with the typical C family of programming languages. The ideas are fairly straightforward; assignment statements have equal signs in them and I already understand the semantics of a variable assignment. I would set the BPUR for how to assign a variable in JavaScript very very low.

However, being able to understand something like prototypal inheritance and that there are actually two distinct, albeit similar, uses of the word “prototype” takes much more time. Prototypal inheritance has taken me dozens of blog posts to really understand. Many years ago, I had to Google, find some blog posts. Read them. Feel like I really didn’t understand after reading them. Then go back, read more. Then wait a couple of days. Let the whole concept sink in a little bit. Still not understand. Rubberduck a little bit with myself by thinking about it out loud. Then go to Google again, read some more blog posts. Then finally, that knowledge coalesced and then I understood prototypal inheritance. This is a topic that I would say has a very high BPUR.

That high BPUR means that I can’t expect to immediately go in and understand this. For me, thinking in this metric allows me to reset my expectations around speed of learning. I don’t want to be demoralized or frustrated by thinking that I should understand this in 30 seconds. Some topics are more complicated than that and it would be okay if it takes me a week, or even a couple weeks to fully understand and to fully grok. That’s okay. It has a high BPUR.

As I’m spending more and more time learning programming languages for fun, this is a very helpful way for me to think. It keeps my morale up and it allows me to keep persisting to learn new things. The only thing that’s missing is an understanding of what the BPUR is for all concepts in all programming languages.

This is something that I am currently thinking about how to fix. I’d love a chart like this for every programming language and every topic within it:

I’d love to hear all of your ideas and thoughts about this metric. I don’t think that 10 is necessarily the correct high BPUR, but that’s going to be something that I continue thinking about. I am going to be working in future posts on how to document and distribute information like this. Maybe we can crowdsource a shared library of BPURs for every concept in every programming language.

Comments are below and there’s always twitter for 140-character discussion!

Why React Is Functional. It’s Not the Virtual DOM

- - | Comments

We live in a life filled with the exciting world of buzzwords. There are tons of them around us on any given day as a JavaScript developer. In software engineering as a whole, there are even more. There’s big data, web components, transpiling, build systems and so much more.

While even I have the tendency to roll my eyes at some of these things, I want to also mention that buzzwords typically do have some actual reason to exist. All of the items that I listed earlier are actually very valuable and interesting technologies, even if talking about them might make some of us want to throw up in our mouths, just a little bit. I try to make sure that I discount some of the zeitgeist, but also consider how I can apply these buzzwords practically.

Now, let’s shift gears into the two buzzwords that are still on the tips of everyone’s tongue.

The Virtual DOM and functional programming!

The Virtual DOM

The Virtual DOM, as a concept, is extremely popular across many JavaScript development tools and mythologies. It is a very valuable tool that is inspring performance optimizations in many frameworks and libraries. At its core, the Virtual DOM is a performant, in-memory tree diffing algorithm.

Take for example, these two trees.

From the left tree to the right tree, there is one single difference. As a human, this is a bit difficult to spot, but as a machine, especially using the Virtual DOM algortihm, it’s really fast. The Virtual DOM can figure out, very quickly, that one leaf node has switched to a different parent.

Functional Programming

I’m not going to try to explain, nor pretend to understant the rigors of category theory or mathematics in the post. What I’d like to do, instead, is take you back to when functions were first introduced to you. Back in Algebra 1, you didn’t think of functions as composable, discrete units of referential transparency and purity. You just thought of it as f(x).

Do you remember seeing something like this?

How straightforward is that! Given one input value, a function produces one and only one output value. This is the crux of the functional programming buzzword and philosophy that I’d like you to keep in your head throughout this post.

React’s big win

Compared to the other popular frameworks, it’s not the Virtual DOM that sets React apart. What really makes React special is the fact that you can use it to think about your application as simply as a function.

Using React, your DOM is a function of all of your state. If there were a single high-school-reminiscient formula for what React does, it would be this…

This is very special in the single page web application landscape. Typically, using Backbone listeners, or Ember observers or Angular watchers, we end up with something a little more complicated…

Focus on the word “try” in there. That’s the key. React doesn’t try to keep data and view in sync. The view is always a function of the data, so there is no extra work needed to keep everything in sync.

Unidirectional Data Flow

In React, you never need to directly create any DOM. React creates DOM for you and updates the DOM for you. All you have to do, as a developer, is specify what the DOM should look like for any given state of your application. This allows you the freedom to only need to think of any one view as a whole instead of having to think through everything that needs to change when your data changes.

This concept is called “Unidirectional Data Flow” in React. Your data changes in only one place, and whenever that data is changed, the view is updated accordingly.

Want to learn more?

I gave a talk form of this post, in much more detail at React Rally and NationJS last year. Click play below if you’d like to learn more.