On Benefits – Letter 1

By Lucius Annaeus Seneca

I’m thinking of reading each of these letters and putting them out as a podcast. If you’d like me to continue, please let me know in the comments section.

Source – Gutenberg.org

Letter 1

Among the numerous faults of those who pass their lives recklessly and without due reflexion, my good friend Liberalis, I should say that there is hardly any one so hurtful to society as this, that we neither know how to bestow or how to receive a benefit.

It follows from this that benefits are badly invested, and become bad debts: in these cases it is too late to complain of their not being returned, for they were thrown away when we bestowed them. Nor need we wonder that while the greatest vices are common, none is more common than ingratitude: for this I see is brought about by various causes.

The first of these is, that we do not choose worthy persons upon whom to bestow our bounty, but although when we are about to lend money we first make a careful enquiry into the means and habits of life of our debtor, and avoid sowing seed in a worn-out or unfruitful soil, yet without any discrimination we scatter our benefits at random rather than bestow them.

It is hard to say whether it is more dishonorable for the receiver to disown a benefit, or for the giver to demand a return of it: for a benefit is a loan, the repayment of which depends merely upon the good feeling of the debtor. To misuse a benefit like a spendthrift is most shameful, because we do not need our wealth but only our intention to set us free from the obligation of it; for a benefit is repaid by being acknowledged.

Yet while they are to blame who do not even show so much gratitude as to acknowledge their debt, we ourselves are to blame no less. We find many men ungrateful, yet we make more men so, because at one time we harshly and reproachfully demand some return for our bounty, at another we are fickle and regret what we have given, at another we are peevish and apt to find fault with trifles.

By acting thus we destroy all sense of gratitude, not only after we have given anything, but while we are in the act of giving it. Who has ever thought it enough to be asked for anything in an off-hand manner, or to be asked only once?

Who, when he suspected that he was going to be asked for any thing, has not frowned, turned away his face, pretended to be busy, or purposely talked without ceasing, in order not to give his suitor a chance of preferring his request, and avoided by various tricks having to help his friend in his pressing need? and when driven into a corner, has not either put the matter off, that is, given a cowardly refusal, or promised his help ungraciously, with a wry face, and with unkind words, of which he seemed to grudge the utterance. Yet no one is glad to owe what he has not so much received from his benefactor, as wrung out of him.

Who can be grateful for what has been disdainfully flung to him, or angrily cast at him, or been given him out of weariness, to avoid further trouble? No one need expect any return from those whom he has tired out with delays, or sickened with expectation.

A benefit is received in the same temper in which it is given, and ought not, therefore, to be given carelessly, for a man thanks himself for that which he receives without the knowledge of the giver.

Neither ought we to give after long delay, because in all good offices the will of the giver counts for much, and he who gives tardily must long have been unwilling to give at all. Nor, assuredly, ought we to give in offensive manner, because human nature is so constituted that insults sink deeper than kindnesses; the remembrance of the latter soon passes away, while that of the former is treasured in the memory; so what can a man expect who insults while he obliges? All the gratitude which he deserves is to be forgiven for helping us.

On the other hand, the number of the ungrateful ought not to deter us from earning men’s gratitude; for, in the first place, their number is increased by our own acts. Secondly, the sacrilege and indifference to religion of some men does not prevent even the immortal gods from continuing to shower their benefits upon us: for they act according to their divine nature and help all alike, among them even those who so ill appreciate their bounty.

Let us take them for our guides as far as the weakness of our mortal nature permits; let us bestow benefits, not put them out at interest. The man who while he gives thinks of what he will get in return, deserves to be deceived.

But what if the benefit turns out ill? Why, our wives and our children often disappoint our hopes, yet we marry—and bring up children, and are so obstinate in the face of experience that we fight after we have been beaten, and put to sea after we have been shipwrecked. How much more constancy ought we to show in bestowing benefits! If a man does not bestow benefits because he has not received any, he must have bestowed them in order to receive them in return, and he justifies ingratitude, whose disgrace lies in not returning benefits when able to do so.

How many are there who are unworthy of the light of day? and nevertheless the sun rises. How many complain because they have been born? yet Nature is ever renewing our race, and even suffers men to live who wish that they had never lived.

It is the property of a great and good mind to covet, not the fruit of good deeds, but good deeds themselves, and to seek for a good man even after having met with bad men. If there were no rogues, what glory would there be in doing good to many? As it is, virtue consists in bestowing benefits for which we are not certain of meeting with any return, but whose fruit is at once enjoyed by noble minds.

So little influence ought this to have in restraining us from doing good actions, that even though I were denied the hope of meeting with a grateful man, yet the fear of not having my benefits returned would not prevent my bestowing them, because he who does not give, forestalls the vice of him who is ungrateful. I will explain what I mean.

He who does not repay a benefit, sins more, but he who does not bestow one, sins earlier.

The 12-Factor App – Notes and Reflections

What follows are my own notes and summations after reading what makes a 12 factor application. Reading this has been a great glimpse into why we do certain things.

I’m currently working with a friend (Ginger Nomad) on building a web app. He is the expert so I follow his lead even though it seems needlessly complex at times.

After reading this, I get it. Why obfuscate the config.js file and the .env files with these additional node modules? Because it’s smart. This document helped me get off the, “Why are we making this so complex”-train.

That’s the why. Here are my notes.

I. Codebase

A deployment is a running instance of an application. This of a deployment like a play. Trey and Matt wrote the Book of Mormon, but the Eugene O’Neill Theatre puts an instance of the play on when they perform it.

Each application should have a single codebase. If multiple apps make up a software project, that isn’t an app. It’s a distributed system made up of apps. Each app that makes up a distributed system should be a 12 factor app on it’s own.

II. Dependencies

A 12 factor app doesn’t depend on system-wide packages. When building a 12 factor app, I should be able to send a new developer the project and they should be able to run it with a working version of node and a simple npm install XXX command.

III. Config

12  factor apps should contain everything that is likely to vary between deploys in a single place. This is often the .env file for us NodeJS developers. This file will include things like:

  • Database Connection Keys – URI, Username, Password, etc.
  • External service credentials – API keys for example
  • Canonical values like hostname – We use path – npm

When we build NodeJS apps, we use the env – npm package to put all the config information in one place.

They warn against storing config variables as constants across the whole application. I’m unsure if this is for security reasons, or if it’s because they just want all the config variables in one place. When deploying multiple instances of an application, it makes sense to have all that data in one place for easy (or algorithmic) editing.

IV. Backing Services

There should be no distinction between local and third party services. To me, this means the app should be able to swap a local MongoDB with a database hosted on mLab, for example, without changing the codebase.

Other backing services could include Amazon S3, Google Maps, Twitter, and Postmark to name a few.

Why? Imagine you’re running an instance of your application and the server gets hit by a bus. That would cause the server to stop working and the database to explode into an inferno. How would you clean it up?

Well, because your backing services are all connected the same way, you would just adjust the config file and create a new instance of the database from backup. You could be back up and running in 10 minutes.

V. Build, Release, and Run

12 factor application development calls for separated build, release and run stages.

  • Build Stage – Where you transform a code repo into an executable bundle. This is where the server fetches dependencies and compiles the assets.
  • Release Stage – Combined build procedure with deploy’s config resulting in a release which can actually be run by humans.
  • Run Stage – Here you run the app by running it’s processes against a selected release. Otherwise put, you use it. Click away brave soldier!

VI. Process

The document calls for executing the app as one or more stateless processes. These processes should be stateless and share-nothing. All persistent data should be stored in a backing service like a database.

To be honest, I don’t entirely get this. I relate it to the way Redux adjusts state in single bursts, but I’m unsure if that is a worthwhile comparison (let me know in the comments below if you know more about this).

VII. Port Binding

12 factor apps should be self-contained and should not rely on runtime injections of a web-server into the execution environment.

I don’t know what self-contained means exactly. It’s possible that NodeJS was built to be self-contained so I’ve never experienced this problem. When building a Node application, one of the first steps is to set the port for the server to listen from.

VIII. Concurrency

Processes are first-class citizens.

In 12 factor apps, the processes share nothing and are horizontally portionable so adding concurrency is simple and reliable.

To me this is like… returning books at the library. The application is the library and it can put a box out to collect returned books. If the library has an especially busy day of book collection, they can just put out an additional box. That way the two boxes are accepting books at the same time, but they books aren’t getting mixed up or returned out of order….

Does that make sense? If you have something to add, please do so in the comments below.

IX. Disposability

Robustness in applications is maximized with graceful shutdowns and fast starts. Therefore, 12 factor apps should be able to be stopped and started at a moments notice.

SIGTERM is the signal from a process manager which should be able to shut down your application.

Idempotent – A property of an operation that means the operation can be applied multiple times without changing the result beyond the initial application.

In the article they mentioned a database technology called CouchDB. I’d like to return to it one day. I love the idea of idempotent operations.

X. Development and Production Parity

Development, staging and production should have similar execution environments. Also, they time distance between a developer making a change and the production side of the app seeing that change should be short.

No more working on code for six months and launching it once. Continuous development is an important characteristic for 12 factor apps.

XI. Logs

12 factor apps should treat logs as event streams. Therefore a 12 factor app should not be concerned with routing or storing it’s output stream.

XII. Administrative Processes

Administration processes should be one-off processes.

Administration code should also ship with the application code and run against a release using the same codebase and config process.

12 Factor App Checklist

  • Does your application require a single code base?
  • Are all required external dependencies loaded into the app? Can a new node developer run ‘npm install’ and get it working?
  • Are all your config variables and settings in a single file?
  • If you pushed your codebase to an open source repository like GitHub, would your config information be automatically hidden?
  • Does your codebase interact with backing services without editing the codebase?
  • Are your build, release and runs stages strictly separated?
  • Are your application’s processes stateless? Do they share nothing with other processes? Is your backing service stored in persistent backing services?
  • Does your app NOT require injections of a webserver?
  • Have you bound processes to a specific port?
  • Does your app NOT daemonize or write PID files?
  • Can your app be started and stopped at a moments notice without losing important data?
  • Are the development and production environments similar?
  • Does your app not care if it’s storing logging output streams?
  • Does your admin code ship with the application? Is the admin code connected to the release number, the codebase and the config file?

If you answered yes to tall the above questions, it seems you have a 12-factor app. Please let me know what it is in the comments below as I’d like to see what you’re working on.

Learn HTTP – My Notes

I’m trying to write a server/API that interacts with client side API. To do that, I need to learn HTTP in depth. These are my notes from doing a deep dive into how HTTP works.

I wish there was a good tutorial where someone teaches you how to write a bunch of server integrations using HTTP requests quickly. I love to learn using muscle memory, but information related to HTTP is always very technical and dense.

My goal is to write a web app where server side Express code speaks with a SurveyJS based client side front-end efficiently.

Learning HTTP is an important step to achieving that.

WebDev Cave

HTTP Explained (Video)

It was helpful to watch this video closely before moving onto the more dense TutorialsPoint HTTP tutorial. It’s a bit boring, but we learn some important things and it preps the learner to go deeper. Specific valuable notes include:

  • HTTP is the most used protocol in the world
  • HTTP = The internet’s Postal Service
  • TCP/IP based protocol
    • To me, this means HTTP is just a checklist for communication across the internet
  • Connectionless protocol – The request for information and the response are not part of a single connection. Each request and response is a fresh connection between client and server.
  • The most reliable way to move data on the web

Request – Response Cycle

The user generates a request (HTTP Message). The request is sent to the server. The client then disconnects and waits for a response.

The server processes the request, prepares the response, establishes the connection again with the user and sends back the response in the form of a HTTP message. The server disconnects after the HTTP message is sent.

What an HTTP Message Looks Like

HTTP Request

Start line

  • METHOD – describes what to do.
    • GET | POST |DELTE | UPDATE (See below for what these all do)
  • URI – This describes where the resources we want are are.
  • Version – This tells us what version of HTTP to Use (e.g. HTTP/1.0)

Header – Key value pairs that describes language, host and the media type we are using. For example:

  • Host = www.example.com
  • Accept-language = en-us
  • Accept: text/html (image/gif, text/html etc…)

HTTP Response

Start line

  • Version – This tells us what version of HTTP to Use (e.g. HTTP/1.0)
  • Status Code – How the connection faired. See below for a more in depth description of status codes. (e.g. 404 = fail or 200 = success)

Header – Key value pairs that describes language, host and the media type we are using. For example:

  • Host = www.example.com
  • Accept-language = en-us
  • Accept: text/html (image/gif, text/html etc…)

Body – A path to where the response data is. An example would be __dirname + /events

Tutorials Point HTTP

TutorialsPoint HTTP

This HTTP tutorial is very helpful because it lays out the specifics of the technology. HTTP is actually quite simple.

HTTP Status Codes

Status codes always confused me, though after reading the tutorial, they make a lot more sense. Here’s how they break down.

  • 1xx: Informational – Status codes that begin with 1 tell the developer that things are fine and the code is just providing us information.
  • 2xx: Success – Status codes that begin with 2 tell the developer that something has been accepted, received or understood.
  • 3xx: Redirection – Status codes that begin with 3 tell the developer that further action needs to be taken before the request can be completed
  • 4xx: Client Error – Status codes that begin with 4 tell the developer/user that the request is written incorrectly or that the request cannot be fulfilled.
  • 5xx: Server Error – Status codes that begin with 5 tell the developer/user that the server failed to do something, despite the request being a valid one.

HTTP Methods

  • GET – This retrieves information from a server based on the given URI. This should only retrieve data and have no effect on the data stored within the server
  • HEAD – This is GET but without the entity-body.
  • POST – Used when the client wants to send data to the server.
  • PUT – Requests the server stores something included in the HTTP request. The server stores the data and sends a response back tot he client saying the data has been created.
  • DELETE – Requests the server deletes a file at a specific location based on the URL. The server will delete the file and will then send a response to confirm deletion.
  • CONNECT – Used to establish a connection to a server. When the client does this, they receive a response based on the current configuration.
  • TRACE – This echos the contents of the HTTP request back to the requester. This is used for debugging purposes during development. When the server processes the request, it will send a message in response to the request.

Conclusion-ish

Ok so HTTP requests are not that complex. It’s just a computer system of interaction where the process of information is exact singular. Make a request, close communication. Create a response, close communication.

The part I’m really struggling with is how the HTTP requests are sent around using ExpressJS. That’s what I’ll focus on tomorrow.

Thank you for reading. Leave a comment below if you have some quality insights I’ve missed here. If you found this helpful, please let me know below as well.

Now | The Summer in Reno, Software and Looking for a Bus Location

At this point, I’m deciding between contributing to the WordPress core, or to continue to build a web app with some friends around event organization.

Software development is fairly hard so I’m spending as much time as I can studying and writing code at Beacon CoWork

This is a photo series of my walk from our apartment in downtown Reno, Nevada. It’s quite beautiful in the summer.

We are seeking a place to get the bus up and cash flowing again. I just find software to be far more interesting, and beneficial in the long run.

Needed: Three (+) Way Audio Recording Software

We are looking for a three-way (or four-way/five-way/etc…) audio recording software which provides individual tracks for each person on the recording.

Splitting all the tracks is empowering for podcast editors, but I won’t get into why in this article.

Today we ran a test with this other companies software and the results of our three person recording was as follows:

This doesn’t solve the split track recording because all three voices are on the same track. Also, the track is stereo for reasons I don’t understand. Why not just make it mono when both sides of the track are the same?

I used Audacity to generate an example of what we are looking for:

This assumes that we aren’t interrupting/ speaking over each other. If we were speaking over each-other, the wave lengths (bumpy blue lines) would be on the same vertical.

That’s the problem folks! Anyone know software that solves it?

Applying to Automattic

In this article I tell the story of when I was applying to Automattic. They are, in my opinion, the coolest technology company in the world.

Step #1 – The Application

I applied via email with a resume attached on June 25th, 2018 at 15:13 PST. The specific position I was after is ‘Code Wrangler’. The email functioned as what would be traditionally called a ‘cover letter’. In the email I answered the following questions:

  • Tell us some details about an interesting programming problem you’ve worked on. What made it interesting?
  • How do you use our products or their competitors’? How would you improve one of them?
  • What questions do you have for us?

I sent the email and a moment later I received what must be an automated response.

The email explained that Automattic receives a lot of applications so I should not expect to receive a response swiftly. They provided some links to learn more about WordPress. They linked to:

Step #2 – The Additional Questions

On  July 4th, 2018 I received an email from one of the hiring folks at Automattic with additional questions.

  • Why did you apply to Automattic?
  • What do you like about software development?
  • How did you get into it?
  • What’s your favourite thing you’ve worked on? What experience do you have with testing (unit/integration/regression)?
  • Can you share a story about a time you’ve worked with someone to solve a problem
  • How did you approach it and who did what?

Though the questions were attached in a .txt document, the next step was to go to their greenhouse.io document site and fill in my responses there.

I’m fairly confident that I filled my answers into that greenhouse.io document that day, but I didn’t hear back for a while.

On July 23rd, I followed up via an email to double check that the Automattician had actually received my responses. It had been 19 days and I hadn’t heard anything. That email didn’t get responded to either. After I didn’t hear back for a week, I assumed I had made a terrible error in my response questions and would never hear back from them again.

Luckily, I did hear back….

Step #3 – Slack Chat

I heard back from Automattic 35 days later on August 8th, 2018 via email. The Automattician explained that based on my answers, they would like to set up a Slack chat within the week. In the email there was a link to another greenhouse.io web application with a calendar.

The Automattician lives in Australia so the avaliable times were between 5pm and midnight. This works great for me because I like to stay up late and work.

I selected a few times that worked well for me. Again, I didn’t hear back until the last day of the three days that I selected. None-the-less, I’m excited to experience the Automattic Slack chat.

The Slack Chat Happened

Our Slack chat happened. Here are some details of what happened…

I asked,  “From what you’ve seen in my response to the technical questions, what would you suggest I dive into learning next? Is there a book or specific resource that you think would be good for me to dive into?”

Cpt. Automattican suggested the following resources:

I’ve always had the intuition that this was the best way to get a job at Automattic anyways.

They are a company that is growing quickly and need people who know how to do the work. Contributing to WordPress means doing that work. Therefore, people who do the work get hired.

On a final note, there was an ominous message calmly relayed by Cpt. Automattician. He mentioned, “we aren’t in a position to take on junior or mid-level developers, which is something I am working on changing, but that limits us.” This was in response to me asking, “what is the bottle neck in Automattics capacity to scale?” I’m guessing I’d be generous to call myself a mid-level developer at this point. With luck, I don’t know my own power!

Stand-by fellow reader! Cpt. Automattician has promised to get back to me within the next day or two.

The Interview Follow-up

“Thank you for taking the time to chat with us. After carefully reviewing your application and our interview, we will not be moving forward to the next stage. We don’t think that your skills and experience are a match for this position at this time.”

This isn’t a huge surprise for me. I’ve become moderately good at computer programming over the past few years, but I have a long way to go.

Of course, I’ll never give up. A few months from now, I’m confident my new skills will bring me to a new opportunity. 

For now… that is the end of this chapter. Thank you for reading. Let me know your thoughts in the comments below.

How to Create a Website with HTML, CSS and JavaScript

When I was learning to code, I often struggled with fundamentals like connecting the index html file to the JavaScript and CSS files that went with it. I made the following tutorial to help beginners write quick applications.

Potentially helpful things a young coder will learn in this tutorial:

  • How to use the terminal to:
    • Create new files
    • Move and rename files
    • Create new directories
    • Navigate folders and files using the terminal
  •  Create a new HTML5 document and format it correctly
  • Link CSS files to compliment the HTML5 document
  • Link JavaScript files to create functionality for the HTML5 document
  • Use Google Chrome’s developer tools to test functionality

Open Source – Just get the Code

If you’re planning on building a really simple website and you don’t feel the need to retype everything in this tutorial, you can copy the code from the following open-source repository:

A Blank Website with JavaScript, CSS and HTML Functioning.

Thank you for watching. Please let me know if you found this useful, or if there is something you would like to add.

Today I Deployed my First Web Application

For the past few years, I’ve been focused on learning full-stack web development. It turns out that writing a web application is hard. Here’s the result:

My First, Running Blank Web Application

first full stack web application

If you think this web app is just a box that adds to a list, you’re right. It’s ridiculously simple in it’s functionality, but it’s also a fascinating collection of web technologies.

This application serves a page from a hosting service (Heroku) takes data from a user (via web browser), writes it to a database on a separate services (hosted with mLab), reads from the database the updated list of forests and finally serves a page with the updated data to the user.

This is a big day for my career as a builder of web application. A full-stack developer is a person who can make programs on every level from the JavaScript that runs the server to the css which styles the page.

There is a lot I will never understand. Node and V8 go from C++ to JavaScript which I don’t understand. The C++ that runs the database is all written by the MongoDB community. The NPM list of packages is a giant hairball that I don’t understand. Just ‘”npm install” and pray’.

But aside from being in the dark on all of that stuff, I now have a little experience building a full-stack web application.

I’ve open sourced my work so it’s free for anyone to copy this code and use it to write their own web application. You can clone the repository via this link:

Express Skeleton Mongoose Handlebar – Blank App

What is Next?

Now it’s time to write more complex applications.