This post is several weeks overdue. Weeks ago, a friend of Lindsay and myself was generous enough to invite me to her podcast to talk about my experience changing careers. The whole being recorded thing was a new experience for me, and one I am curious about moving forward.

Here is a link to the podcast on the career clarity website. It is also available wherever you listen to your podcasts searching for Career Clarity. I encourage anyone who stumbles on this to listen and read my additional comments below for some brutal honesty. Thanks again for the opportunity Lisa, I look forward to following Career Clarity and cannot recommend her or her company enough.

It is funny the things you say when you are put on the spot sometimes. I don’t know that the microphone contributes much, but I am sure it plays a part. As I listened back, there were a couple of points where I was uncomfortable with how I presented my situation:

• I presented my foray into the blog platform business as something I financed myself. My dad gave me cash to explore this idea (I want to say 10k). He always played these games with money, some fruitful, some not. During this time, the game was keeping small sums of cash out of banks to avoid higher tuitions on the FAFSA. This money went primarily to legal fees (people posting content on YOUR site can land you in jail quickly without some terms of use documents), domain expenses, and some other expenses (some stupid as I look in hindsight). My dad has always fixated on helping my sister and I pay off our student loans, so I think he saw the money as an investment in either me or the business. Hopefully, I can make this one of his best investments even though the corporation is no more.
• I also presented this as something I came to myself. The idea itself is not novel, providing a content platform that returns ad revenue to its members. What made me take “the leap” was the people I had around me. I had a friend (Alex Eisenach) who was confident in his ability to deliver the technology in a short time frame if I could remove business hurdles. We both learned an immense amount. He put in tons of hours to build something fun; maybe we will get it back out there one of these years.
• I presented my year off as being one which I was primarily able to finance. While this is true, I had the support of my family in a few key ways. First, my grandmother was near the end of her life and spreading money to her grandchildren and children legally in increments each year. I probably benefited to the tune of 10–15k during the period of attending school and working for next to nothing for a startup, making this a more comfortable experience.

Link to Career Clarity

Link to Lisa Lewis on LinkedIn

Originally published at https://prying.io on September 5, 2020.

Are you overworking your database? Are you paying for each query? Are you returning the same payloads again and again? It might be time to think about caching and Elixir and Erlang make this easy with several in-memory options. I learned about the 2 Erlang options at ElixirConf 2019 and felt compelled to write this post, so a big thank you to all those who shared!

There are four different standard methods for temporarily storing and accessing data in a simple Elixir application. This article compares those methods, provides usage examples, and offers my personal opinion on when to use each tool. Here are those 4 simple strategies of storing data for quicker retrieval than going to a database:

If you wonder why this matters, here is a benchmarking test comparing the time it creates a table, set 100 key-value pairs, and remove 100 key-value pairs. The results show that :ets is significantly faster than Agent (and therefore GenServer).

Using Agent

Example:

Agent.start_link(fn -> %{} end, name: :us_state_abbreviations)

-> {:ok, #PID<0.102.0>}

# or to clarify the first argument and show a namespace error

initial_state_callback = fn -> %{}

Agent.start_link(intial_state_callback, name: :us_state_abbreviations)

-> {:error, {:already_started, #PID<0.102.0>}}

# Accessing all Agent data

Agent.get(:us_state_abbreviations, &(&1))

-> %{}

# Checking for a certain value, in the lookup

key = "OH"

Agent.get(:us_state_abbreviations, fn(states) -> Map.get(states, key, "N/A") end)

-> "N/A"

# Updating Agent data

updated_state = %{"OH" => "Ohio"}

Agent.update(:us_state_abbreviations, fn(_) -> updated_state end)

-> :ok

# Confirming the updates

key = "OH"

Agent.get(:us_state_abbreviations, fn(states) -> Map.get(states, key, "N/A") end)

-> "Ohio"

Pros: Agent can be accessed from anywhere in the application, provided the requester has the name used to register Agent. If a single process crashes, Agent state persists. Agent is very lightweight to implement and use.

Cons: If your entire application crashes, Agent state is lost.

Opinion: In most cases, Agent is reimplementing given behaviors of GenServer state management. If you find yourself sharing cached data between modules of your application, that is a sign of an architecture design problem. Agent under the hood is a simple GenServer you don't manage, so in most situations, it is better to build your own.

Using GenServer

Example: I am not going to rewrite the hex documentation, so please look here(https://hexdocs.pm/elixir/GenServer.html) for information about GenServers. The quick summary is that GenServers maintain state through their return values, and each function called through a handle_cast, handle_call, or handle_info includes the current state as an input. A queue of internal messages is maintained, and the state updates sequentially as the servers process this call stack.

Pros: GenServers easily integrate into your supervision tree, with built-in hooks to manage and recover state. If you need to consume data from a GenServer elsewhere in your application, you implement accessor methods on the GenServer.

Cons: Requires more direct and considered state management, meaning more work to set-up, configure, and test your module.

Opinion: Leaning on GenServers for caching, recovering, and managing state is the best method for caching in Elixir. While it does feel like more work is required, this work gives the additional control developers need to lock down their data flows.

Using ETS

Example:

# create a lookup table

:ets.new(:us_state_abbreviations, [:set, :public, :named_table])

-> table_ref

# lookup a value when it doesn't exist

:ets.lookup(state.table_ref, key)

-> []

# lookup when it does

-> [{key, value}, ...]

# how to handle these responses

def lookup(module \\ __MODULE__, key) do

GenServer.call(module, {:lookup, key})

end

def handle_call({:lookup, key}, _from, state) do

# good practice to save the ets table ref in state

case :ets.lookup(state.table_ref, key) do

# match against key for corelated value

[{^key, value}] -> {:reply, {:ok, value}, data}

[] -> {:reply, {:error, :not_found}, data}

end

end

# insert a record

:ets.insert(state.table_ref, {key, value})

-> true

# nuke table

:ets.delete_all_objects(state.table_ref)

-> true

Pros: Persists past process crash, but not past an application crash. Fast reads, fast writes. It is a simple key-value store of tuples ({key, value}).

Cons: Requires more parsing of responses. Less flexible lookup. There are extensions for :ets which allow for searching by Ecto structs which I will post about in the future.

Opinion: For most applications, using GenServers is sufficient for performance. Often, GenServer state contains business logic, and the :ets state contains distilled information for external consumption. I think of this as the external cache whereas the GenServer state is primarily an internal cache. A typical pattern is attaching these returned table references to a GenServer state.

Using Persistent Term

Example:

:persistent_term.put("OH", "Ohio")

-> :ok

:persistent_term.get("OH")

-> "Ohio"

Pros: :persistent_term has much faster read times, even than :ets. Data persists past an application crash, meaning it is an ideal place for certain nuggets of information. Shared across all nodes in a cluster.

Cons: Slow write times since updates sync across all nodes.

Opinion: I haven’t found the right use for this yet in any of my applications, but it seems useful for isolated problems at scale.

Summary

In summary, you should probably use GenServers instead of Agent in most situations. Agent is a lazier GenServer with more default behaviors. For performance and flexibility, use both :ets and a GenServer. In GenServer state, store a reference to :ets tables and use GenServer calls to lookup against this table because :ets is more performant. If you are operating a cluster, and aren't updating these read values as frequently, consider using :persistent_term. It updates across all connected nodes in a cluster (using a HashRing library like ExHashRing), so while this is powerful, it is also expensive to write data through this system. Read of this data is faster, and more persistent, than even an erlang call like :ets.

Originally published at https://prying.io on September 1, 2019.

Between Node v10 and Node v11, the behavior of Array.prototype.sort() changed. Previously in Node v10, this method accepted a boolean as a return value. Starting in Node v11, functions returning a boolean will not sort an array as expected.

Here is a guide for setting up nvm on macOS if you would like to play around with this for yourself.

Simple Demonstration of Changes

In Node v10:

var array = [ 3, 2, 1 ];
array.sort((a,b) => a > b);
[ 1, 2, 3 ]

In Node v11:

var array = [ 3, 2, 1 ];
array.sort((a,b) => a > b);
[ 3, 2, 1 ]

// instead, return a 0, negative, or positive value
array.sort((a, b) => a - b);
[ 1, 2, 3 ]

What I Learned

After seeing this, I had to go back and check on some other projects which had the same misuse of the Array.prototype.sort() method. I realized through this experience that it is my job as a developer to be proactive. Being proactive as a developer means staying on top of the latest information relating to technologies I am using as well as making an effort to get in front of those potential problems in applications.

Originally published at prying.io on April 6, 2019.

In my opinion, Redux is overkill for most projects. You can create a simple store through a root component’s state that is far easier to manage, understand, and implement.

If you are building something that you intend to be a production application, it is probably worth implementing React/Redux. It makes debugging easy since you have a log of all actions and state changes. It makes testing easy since you have explicit methods managing state.

The most important principle with Redux is to keep state flat. Avoid nesting objects when you can reference ID’s and create a separate store for an item. For example, if you have a company with has employees, this is the wrong way to represent your state.

--company
	-id
	-name
	-employees: [ employee_1, employee_2 ]

These nested objects can lead to javascript reference errors. The most common way to copy an object is with Object.assign({}, state, { changes }). Unfortunately, this creates reference issues for any employees since Object.assign only applies first level properties.

Instead, we can flatten our state and reference those employees by their id.

--employees: [ employee__1, employee__2 ]
--company
	-id
	-name
	- employees: [1, 2]

Now, we can import employees only into the components which need them. The more you can avoid passing extra data around, the better.

In order to get redux set-up and implemented, we need to follow 3 simple steps. First, install dependencies. Second, create a basic redux store. Third, access that basic store in your components.

Install Dependencies

npm install --save redux  react-redux redux-thunk

I would also recommend installing the Redux Devtools extension on whatever browser you use for development. It provides a visual representation of state as well as a log of events making debugging a breeze.

Create a Basic Redux Store

mkdir store
touch store/configureStore.js

// in configureStore.js
// import redux methods, compose is used to combine redux
// applyMiddleware implements redux-thunk
import {createStore, compose, applyMiddleware} from 'redux';
import rootReducer from '../reducers/rootReducer';
import thunk from 'redux-thunk';

export default function configureStore() {
  return createStore(
    rootReducer,
    compose(
      applyMiddleware(thunk),
      window.__REDUX_DEVTOOLS_EXTENSION__ && window.__REDUX_DEVTOOLS_EXTENSION__(),
    )
  );

compose from redux is necessary to add multiple libraries to your redux store, like middleware and dev tools. createStore used to take more than 2 values, so many tutorials online will not include compose. Latest versions require using compose. Redux-thunk will prevent async issues associated with a centralized data store.

Now, we need to create a rootReducer. As a rule, you should have a reducer for each thing in your application. For this example, we will only have a blogs reducer. The rootReducer will pull in a blogs store. The configureStore.js file will instantiate that store. Let’s create our reducers.

mkdir reducers
touch reducers/rootReducer.js
touch reducers/blogReducer.js

// in rootReducer.js
import {combineReducers} from 'redux';
import blogs from './blogReducer';

const rootReducer = combineReducers({ blogs });

export default rootReducer;

Now, we have to create the blogReducer.

touch reducers/blogReducer

// in blogReducer.js
export default function blogs(state = [], action) {
  switch (action.type) {
    default:
      return state;
  }
}

Nothing fancy here. Our default state is an empty array. All we are doing is returning in that default scenario. This is all we need to set-up a store with blogs: [].

Now, we need to pass that store into our root component. Up until now, everything we have been doing has been using redux or redux-thunk. Now, we will include react-redux in the fun. In your root component rendering your application, wrap your application in the Provider component.

// in index.js
import React from 'react';
import { render } from 'react-dom';
import { Provider } from 'react-redux';
import App from './containers/App';
import configureStore from './store/configureStore';

const store = configureStore();

render(
  <Provider store={store}>
    <App />
  </Provider>,
  document.getElementById('app')
);

If you start your application and open your redux dev tools you should see your blogs: [] store!

The last step is connecting your redux store to a component.

To connect our blogs store, we will use a sample SimpleTable component. Replace this with any component in your library.

import { connect } from 'react-redux';
...
// at the bottom of SimpleTable.js

SimpleTable.propTypes = {
  ...
  blogs: PropTypes.array.isRequired,
  ...
};

function mapStateToProps({ blogs }) {
  return { blogs };
}

export default connect(mapStateToProps)(SimpleTable);

You should now be able to access this.props.blogs from within your component. If you are unsure, console logs are your friend.

If you are also using React Router, I would advise configuring your routes and components inside an App.js component and setting up Redux in an index.js file.

I hope this helps someone get started! I will have a follow-up post about using actions and types.

Here is a link to the original post on prying.io.

ESLint is bumper lanes for your project. Text editor extensions are useful while coding, but ESLint can enforce norms accross developers and remove the unpleasant discussions about syntax. Agree to syntax norms once and move forward. If individuals have issues with particular rules, they can present a coherent argument as to why they want to change that rule.

npm install --save-dev eslint babel-eslint eslint-plugin-react eslint-watch

Next, lets create a basic .eslintrc file in the root of your directory. Eslint will work without this, but I would encourage customizing rules for your project. Here is a basic config file for react@16.

{
    "plugins": [
        "react"
    ],
    "parser": "babel-eslint",
    "parserOptions": {
        "ecmaVersion": 6,
        "sourceType": "module",
        "ecmaFeatures": {
            "jsx": true
        }
    },
    "env": {
        "es6":     true,
        "browser": true,
        "node":    true,
        "mocha":   true
    },
    "extends": [
        "eslint:recommended",
        "plugin:react/recommended"
    ],
    "rules": {
      "semi": [2, "always"],
      "indent": ["error", 2],
      "object-curly-spacing": ["error", "always"],
      "no-extra-parens": "error",
      "max-len": ["error", { "code": 100 }],
      "no-multi-spaces": "error"
    },
    "settings": {
      "react": {
        "version": "16.3"
      }
    }
}

Running the linter

The linter can be run against a single file using the node_module binary.

./node_modules/eslint/bin/eslint.js index.js

It is better to configure NPM scripts to do this for you. Here are what mine look like for a basic react starter project.

// in package.json under scripts
...
"lint": "eslint ./index.js ./containers/*.js ./components/*.js",
"lint:fix": "eslint --fix ./index.js ./containers/*.js ./components/*.js",
...

A few notes on the syntax there. The *.js refers to any file in that directory with a .js extension. If I had folders with components in my /components folder, I could test all folders and files within components like this ./components/**/*.js.

...
"lint": "eslint ./index.js ./containers/*.js ./components/**/*.js",
"lint:fix": "eslint --fix ./index.js ./containers/*.js ./components/**/*.js",
...

The fix option is your best friend. It will fix basic linter errors for you. Anyone who has had to do this manually for basic rules will appreciate what a help this is.

Example Outputs

If this ran correctly, you should see an output like the following.

> eslint ./index.js ./containers/*.js ./components/*.js


/home/david/blogbank.com/components/EnhancedTable.js
   65:4   error  Unnecessary semicolon                          no-extra-semi
  126:1   error  Expected indentation of 8 spaces but found 10  indent
  127:1   error  Expected indentation of 8 spaces but found 10  indent
  128:1   error  Expected indentation of 6 spaces but found 8   indent
  130:1   error  Expected indentation of 8 spaces but found 10  indent
  131:1   error  Expected indentation of 8 spaces but found 10  indent
  132:1   error  Expected indentation of 6 spaces but found 8   indent
  154:28  error  Unnecessary parentheses around expression      no-extra-parens
  158:13  error  Unnecessary parentheses around expression      no-extra-parens
  166:28  error  Unnecessary parentheses around expression      no-extra-parens
  172:13  error  Unnecessary parentheses around expression      no-extra-parens
  313:33  error  Unnecessary parentheses around expression      no-extra-parens

/home/david/blogbank.com/components/SearchAppBar.js
   5:8  error  'IconButton' is defined but never used  no-unused-vars
  10:8  error  'MenuIcon' is defined but never used    no-unused-vars

/home/david/blogbank.com/components/SimpleTable.js
  24:5  error  'id' is assigned a value but never used  no-unused-vars

✖ 15 problems (15 errors, 0 warnings)
  12 errors and 0 warnings potentially fixable with the `--fix` option.

Now, we can fix those errors using our npm run lint:fix script. Without doing anything, 12/15 errors are auto-fixed.

> eslint --fix ./index.js ./containers/*.js ./components/*.js


/home/david/blogbank.com/components/SearchAppBar.js
   5:8  error  'IconButton' is defined but never used  no-unused-vars
  10:8  error  'MenuIcon' is defined but never used    no-unused-vars

/home/david/blogbank.com/components/SimpleTable.js
  24:5  error  'id' is assigned a value but never used  no-unused-vars

✖ 3 problems (3 errors, 0 warnings)

That is it! Go forth and play nicely with other developers instead of arguing about syntax!

Here is a link to the original content on prying.io.

I am a big believer in not over-engineering solutions to problems. Before spending money on a website, check to see if a free option through Github would suffice.

Markdown syntax is accessible to less technical users. Everything else is just configuration.

To get started, install Ruby, Bundler, and other dependencies until your terminal doesn’t scream at you when you follow the Jekyll tutorial.

Choosing a Theme

Themes aren’t as easy to swap in and out as you are led to believe. Each has different layouts they provide. To minimize configuration, start with a theme which works for you. Here is a list of themes supported by GitHub pages.

There are two factors to consider when picking a theme. First, does the navigation suit your needs? For a blog, you would want a landing page which showed previews of your latest blog. For a simple page for a software download, you want the landing page to be a page. Think about your navigation and URL structure. Second, does the theme offer all of the layouts you need? Slate, for example, doesn’t have a ‘home’ layout. A site which worked on ‘minima’ won’t necessarily work with another theme. What matters is that a theme offers various layouts for flexibility.

When you create a page in markdown, you put metadata at the top about how you want Jekyll to handle the page.

 — -
layout: post
title: “Setting Up a Jekyll Blog”
date: 2018–12–03 18:15:05 -0700
categories: technical
 — -

The layout referenced must exist in your `_layouts` directory. Themes provided through gems will hide these layouts.

To overwrite them:

• create your own `_layouts` directory in the root of your project
• copy and paste the file from the source code
• make edits

Customize your CSS

To avoid looking too basic, take a moment to customize your CSS. Choose a different font, change a header color, anything to make your site look less than boilerplate. Simple is good. Too simple is lazy. Configuring CSS is the same in concept as customizing layouts.

To configure CSS for most themes:
* create your own `assets` directory in the root of your project
* create a file `main.scss`, ideally just importing your theme
* make edits

 — -
# Only the main Sass file needs front matter (the dashes are enough)
 — -

@import “minima”;

.site-header {
 background-color: red;
}

.site-title, .page-link {
 color: white !important;
}

Adding Additional Pages

To add additional pages to your root navigation, create files in the root of your project. The `about.markdown` file in the root of most themes is an example of this working.

Jekyll is made for rendering simple pages. It is capable of much more, but spending too much time trying to make it work for your specific need is a mistake. In my opinion, Jekyll should be used for standard site templates; blogs, personal sites, and informational pages.

Other Notes

Starting Jekyll should be as simple as `bundle exec jekyll serve`.

Depending on your machine, you might have to configure the port in the `_config.yml` file. The default is port 4000.

port:3999

Some configuration is done in `_layouts`, some configuration is done in `_includes`. The `_includes` directory contains reusable HTML fragments which are *included* in layouts.

If you want to update your `header.html`, for example, you would:

• copy the source file from your theme into the `_includes` directory
• start editing

In summation, my experience getting started with Jekyll was a positive one. Github has stellar documentation for pages, themes, and Jekyll. Jekyll’s documentation is slightly more cryptic but also helpful for understanding the basic concepts of the framework.

Here is a link to the original post on prying.io.