DEV Community: Jonathan Cass

The Shoemaker's Children: A Developer Allegory

Jonathan Cass — Wed, 14 Mar 2018 13:38:33 +0000

It was a simple plan: give my personal website a makeover and write a blog post about the process.

I had built my website shortly after learning about UI frameworks, and while my Bulma-based site was nicer than some, I wasn’t in love with it. Here's the "before" picture:

Additionally, I’m a bit embarrassed to admit that despite my love of CI/CD, the “release” process for my personal page was to ssh into a server and perform a git pull. Not exactly state-of-the-art.

I started researching static-site frameworks, and thought maybe I would use Gatsby to build my site and deploy it with Netlify. With Gatsby I could even blog directly on my own site! Surely this was the modern, best-practice way to develop my page. Then I read this post by @flexdinesh , and my plans came crashing down. His post showed off an elegant developer landing page that he open-sourced, along with instructions on hosting it on GitHub pages. I was initially reluctant to use his project, because I felt like I should build my own page, but ultimately I realized that it did exactly what I needed and would help me craft a much more interesting post than “here’s how I built my website”. So I present to you: A Developer Allegory.

If you’re not familiar with "the shoemaker's children go barefoot", it’s an expression meaning that people often forget professional expertise in their personal lives. This was certainly the case with my personal website - I was neglecting development best-practices left and right. The four that I’m going to talk about in this post are:

Continuous Deployment (CD)
Keep It Simple, Stupid (KISS)
"Not Invented Here" Syndrome (NIH)
Don’t Repeat Yourself (DRY)

Continuous Deployment

In continuous deployment, a suite of tests is run every time you commit code to your project’s master branch. If all tests pass, the new build gets deployed. This allows you to get feedback on changes very quickly, and makes releasing code (which is often a risky endeavor) a non-event. There are many ways to add CD to a project, including Travis, Circle, Jenkins, and Netlify.

As mentioned above, one of the reasons I wanted to redo my website in the first place was to improve my “release process”. There were a couple of problems with my old process. The first problem was that it was cumbersome: each time I committed changes to my GitHub repository, I had to perform extra steps to get those changes into my “production environment”. The second problem is that those extra steps included a git pull, which can have unintended consequences as documented here. I wanted to install a continuous deployment pipeline to make the process simpler and less error prone.

Keep It Simple, Stupid

While Netlify (and the other CI/CD pipeline tools) could certainly handle my simple static-site requirements, they were overkill. I don’t have a test suite to run, and I don’t have complex assets or a build process. I just needed my code changes to be reflected on my website, which, as I learned from @flexdinesh 's post, is precisely what GitHub pages does.

Somewhat mean-spirited in phrasing, KISS (Keep It Simple, Stupid) implores us to avoid complexity. It also shows up in extreme programming as YAGNI (You Aren’t Gonna Need It) and in design via a quote from Antoine de Saint Exupéry: “perfection is finally attained not when there is no longer anything to add, but when there is no longer anything to take away”. By keeping code, processes, and UI simple, there are fewer places for bugs to hide, and fewer sources of confusion for users and developers alike.

"Not Invented Here" Syndrome

I was excited to learn about GitHub pages when I first saw @flexdinesh ’s post, and I thought his landing page looked fantastic. Despite that, I made excuses for why I couldn’t use his framework: it won’t be easy to list and link to my projects, I won’t be able to incorporate a blog, there’s nowhere for me to put info about myself, my “how I built a portfolio website” blog post will be redundant with his. I was exhibiting "Not Invented Here" Syndrome.

There can be many reasons for this reluctance to use an existing external implementation: cost, pride, fear of the unknown. However, NIH is completely counter to Open Source culture. In Open Source, rather than forcing each developer or team to reinvent the wheel, we can build off of each other's solutions, and ultimately create something greater than any of us could have managed alone. Once I recognized NIH in myself, I was able to fight against it.

Don’t Repeat Yourself

With Dinesh’s project, I abandoned my plans to publish blog posts on my site, showcase specific projects and apps that I had worked on, and list qualifications and career experience there. The more I thought about that, the more sense it made. I already have dev.to for blog posts, GitHub to showcase my projects, and LinkedIn and a resume to list qualifications and career experience. Why should I duplicate all of that on my website, requiring me to make updates in multiple places whenever any of these changed? I also learned that GitHub allows you to choose which projects you want to showcase on your GitHub profile ("customize your pinned repositories"), which sealed the deal for me.

This realization that I had been duplicating information reminded me of the DRY principle in programming. DRY eliminates the need to perform a single update in multiple places, which saves time and prevents errors. Of course, DRY can be (and, in my experience, often is) taken too far. To remove repeated code, developers often create an abstraction layer, but if the repetition was more coincidence than equivalence, this can be dangerous. You can read more in Sandi Metz's post duplication is far cheaper than the wrong abstraction.

Wrap Up

I'm very pleased with the final product, also viewable at www.joncass.com:

As in the shoemaker’s children aphorism, my personal projects often don’t get the love and rigor that I apply at work. While that’s fine for some projects, especially early on when I may not continue with them, I wanted my “web presence” site to have a little extra care put into it. I’m more likely to keep it updated if it’s easy to do so (thanks CD!). I think my new simple (shout-out to KISS) and uncluttered (nice and DRY) page lets me put my best foot forward on the web, even if it was Not Invented Here :).

Questions or comments? Leave them below!

A big thanks to @flexdinesh for open-sourcing his dev-landing-page project (and writing about it).

Moving faster with REPL

Jonathan Cass — Sun, 25 Feb 2018 20:16:55 +0000

Introduction to REPL

Developers like to "move fast and break things." Well, we like to move fast anyway. A "REPL" is a tool I've found that prevents me from getting bogged down working within the context of a large application. Of course, at some point, my new feature or bugfix has to be integrated into the codebase, but starting there adds friction and slows me down. In this post, you'll learn about what REPLs are, and how to use them to work efficiently.

A REPL is a Read-Evaluate-Print Loop. This concept was first introduced in the Lisp programming language, to allow quick experiments in Lisp. In Lisp, the following is an implementation of a basic REPL:

(loop (print (eval (read))))

Reading the commands from the inside out (which is how they are executed in Lisp), you can see where REPL gets its name!

Generally speaking, you invoke a REPL from the command line. When you start up a REPL, it will take you to a new interface, similar to a command line, but your instructions are interpreted in the language of the REPL. In fact, you can think of a command prompt as a REPL for Bash. Once in a REPL, you can run commands, define variables, write functions, etc. and see the results.

Examples: Python and Node

Both Python and Node come with fairly sophisticated REPLs when you install them. Here are some examples you can try!

Python

Start up the Python REPL, by typing python3 at your command prompt (in this case, user@comp ~$) and pressing enter. It will print out some information on your python installation, and leave you at the REPL prompt (the >>>):

user@comp ~$ python3
Python 3.6.1 (default, Apr  4 2017, 09:36:47) 
[GCC 4.2.1 Compatible Apple LLVM 7.0.2 (clang-700.1.81)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>>

From here, you can perform computations, define variables and functions, etc:

>>> 1+1
2
>>> greeting = 'hello world'
>>> print(greeting)
hello world
>>> def print_greeting(greeting):
...     print(greeting)
... 
>>> print_greeting('hello world')
hello world
>>> print_greeting('hello function')
hello function

Exit with ^d (ctrl+d)

>>> ^d
user@comp ~$

Node

Enter the Node REPL

user@comp ~$ node
>

Just like in Python, you can perform computations, define variables and functions, etc:

> 1+1
2
> const greeting = 'hello world';
undefined
> console.log(greeting);
hello world
undefined
> const printGreeting = (greeting) => console.log(greeting);
undefined
> printGreeting('hello world');
hello world
undefined
> printGreeting('hello function');
hello function
undefined

Exit with ^d (ctrl+d)

> ^d
user@comp ~$

The undefined that crops up in the Node example is the return value of each statement. If your statement has a defined return value, that will be printed instead, as in the 1+1 example. Note also that these REPLs have command history, so you can press “up” to view past commands, even between sessions.

Implementation

The REPL is just like any program that you run from your command line. When you run it, it gives some output and then waits for user input. When a statement is entered, it evaluates the statement, and prints out the result. In both Python and Node, there are built-in modules that can provide a REPL with some injected “context”. You can read @rpalo ’s excellent post here for how to make use of the Python library Code to create your own REPL. Here’s how to do it in Node:

// include the repl library
const repl = require('repl');

// start it up, with the desired prompt string
const r = repl.start('> ');

// inject a couple pieces of context
r.context.text = 'This is some text';
r.context.greet = (name) => console.log(`hello ${name}`);

We can save this as my_repl.js and then start it up and use it as follows (note that text and greet are already defined for you because they were injected into the context):

user@comp ~$ node my_repl.js 
>

> 1+1
2
> text
'This is some text'
> greet('Jon')
hello Jon
undefined
> const greetAndCompliment = (name) => {
...   greet(name);
...   console.log('nice code');
... }
undefined
> greetAndCompliment('Jon')
hello Jon
nice code
undefined
>

Everyday Uses

I find REPLs most useful when trying out a simple experiment. For example, instead of creating a test.py script to confirm that default parameters work the way I think they do, I can just fire up the REPL and confirm it:

>>> def print_greeting(greeting='hello world'):
...     print(greeting)
... 
>>> print_greeting()
hello world
>>> print_greeting('hello overridden default')
hello overridden default

Wrap Up

Now that you’ve learned about REPLs, you might also be interested in unit tests, and Test-Driven Development, or TDD. These increase developer velocity in a similar way, by shortening cycle time. They have the added advantage of increasing code quality. For further reading and REPLing, check out the Wikipedia page or repl.it.

Thanks for reading!

Help me validate blog ideas!

Jonathan Cass — Sat, 27 Jan 2018 17:17:06 +0000

I'm going to start blogging in 2018. I guess this post is a good start!

I joined the #BlogMore track in the #CNC2018 project. The pre-mission was to read about the three different categories of blog posts, and find a great post that fit each category. The three categories are tutorial, explainer, and project: a tutorial post walks the reader through accomplishing a specific task, an explainer post explains some general concept, and a project post describes a project that the author is working on. I turned that "assignment" in a couple days ago, and now have my first mission!

My first mission is to brainstorm ten ideas, narrow it down to five, and then get feedback from the community on these five ideas to narrow it down to the best three. I've narrowed my brainstorm down to five, but now I need your help to validate my ideas! Here are the five ideas I came up with:

Tutorial: GitHub
How to set up a new project on GitHub, including best practices for READMEs, licenses, git branching, etc.

Tutorial: React
Creating your first react app using CRA (create-react-app), and describing the advantages and disadvantages to using CRA.

Explainer: REPL
Defining a REPL (Read-Evaluate-Print Loop), giving examples of common ones, and why you might want to use one.

Project: Portfolio
Showing the current state of my personal "portfolio" site joncass.com, improvements I want to make, and walking through the steps I take to change it.

Project: Crystal Football
A few months ago, I released an app called Crystal Football to the Google Assistant directory. This post would explain that process, and walk through improvements that I would like to make or am making.

So that's it! I've also posted a poll in the CNC2018 Facebook group. I'd love your feedback on what you'd like to see and why - vote in the Facebook poll or comment below.

Thanks for reading!