DEV Community: i. welch canavan

The Simplest Possible Docker Setup For PostgreSQL

i. welch canavan — Mon, 30 Nov 2020 19:47:18 +0000

Recently I was working through Xiaoru Li’s excellent tutorial on Next-Auth and I needed a Postgresql database quick. My search got a lot of results that were similar, but different enough for me to lose confidence in any given solution. I spent a little time searching for a simple configuration and this is what I came up with. For those of you in a rush, copy and paste away:

version: "3.8"

services:
  postgres:
    image: postgres:13-alpine
    restart: always
    ports:
      - "5432:5432"
    environment:
      POSTGRES_USER: username
      POSTGRES_PASSWORD: password
      POSTGRES_DB: postgres
    volumes:
      - ./data:/var/lib/postgresql/data\

Now, for the rest of you who aren’t even sure why this is necessary or aren’t sure why there are so many suggestions when you search for this problem, let’s dig in.

Why Docker at all?

In my career, it has been immeasurably beneficial to make sure that the low level technologies and languages I am relying upon are “insulated” from the computer I am developing on. By insulated, I mean it is best to use Docker or a version manager (e.g. rbenv, pyenv, nvm, ...) rather than installing a technology directly on to your operating system.

For example, when you use an already installed language (like python on MacOS) you run the risk of breaking how your OS functions. When you install a language directly (e.g. brew install python on MacOS) you run the risk of packages conflicting.

Using a version manager allows you to easily reset the installation of a language if anything goes wrong. Presuming your configuration and package manifests are intact you should have an easy time getting back up and running. Using a version manager also helps you run different version of a language or database for different projects so you can easily switch between them.

Running your DB inside of docker can be thought as the ultimate version manager, it not only keeps different versions separate from each other, it keeps each version isolated in its own virtual machine.

Docker-compose vs `docker run`

When looking for a “minimally viable” way to get Postgres running the results were fairly evenly split between suggestions using docker run and suggestions using docker-compose. docker run is a way of running commands inside of a docker container, if the container does not exist it will create it before running the command. docker-compose prompts docker to run a variety of commands (up, down, stop) relative to a docker-compose.yml configuration file. There are a lot of differences between the two methods, but syntactically you can think of the difference between them as the difference between passing all of your eslint options as flags in the command line and running eslint in conjunction with an .eslintrc file.

Using a docker-compose.yml file is the easier route, as it is the more legible of the two options.

Exploded `docker-compose.yml`

What is the docker-compose.yml file doing? Let's go line by line.

version: "3.8"

The docker-compose.yml API has different versions, this is something to be keenly aware of while researching and creating your configuration. It is typically best to use the latest version. You should also check what version of Docker Engine you are running.

services:
  postgres:

A typical docker-compose.yml in a professional environment will have several services configured to work together. For our purpose we only need the one. The key for your service is arbitrary, you could name it db or banana, but for organizational purposes it makes most sense to match the key to the Docker image you are relying upon.

image: postgres:13-alpine

This is the image tag, the list of available options is available on Docker Hub. postgres refers to the Docker image you would like to use. 13-alpine is a tag of the image with 13 referring to the version of Postgres you would like to use and alpine denoting a flavor of linux that is stripped down to be as small as possible. You can always specify simply postgres or postgres:latest if size or version doesn't matter to you.

restart: always

What it says on the label! Always restart this container when docker engine starts.

ports:
  - "5432:5432"

This forwards the Docker containers ports to your machine's ports. 5432 is PostgreSQL's default port. You should only need to change this if you have a conflicting process using the same port.

environment:
  POSTGRES_USER: prisma
  POSTGRES_PASSWORD: prisma
  POSTGRES_DB: tabata

While there are other environment variables available for your PostgreSQL container, this is all you need to get the container running. If the container and database do not yet exist docker-compose up will create a database with this name, user, and password.

volumes:
  - ./data:/var/lib/postgresql/data\

Volumes allow your data to persist in-between bringing your container up and down. This tells docker where to store that persisted data and links it to the location within your container.

You know something I don't?

If you've made it to the end and you see a way to make this configuration even leaner, please let me know!

I published my first Ember Addon

i. welch canavan — Wed, 19 Feb 2020 03:53:33 +0000

Originally published at welchcanavan.com

TL;DR: a new ember-fullcalendar addon based on Fullcalendar v4 is released this week. Here is some of my process and experience.

Backstory

My day job is working on a large SaaS application at Mariana Tek. We help boutique gyms with their business operations, which means our application serves a lot of purposes: point of sale, time clock, class scheduler, and a lot more. Having to write all this functionality from scratch would be difficult if not impossible, so I'm grateful for plugins in general and Ember's painless addon system in particular.

While our application is on an earlier version Ember 3, we're in the process of a long walk to the exciting Ember Octane. Part of this process has been gradually updating our addons. Our application, which is over four years old, had accrued some addons that are now abandoned. Most of these were easy to address, with one big exception - Fullcalendar. Fullcalendar is a fantastic tool that allows the user to provide a fully-featured scheduling calendar (e.g. Google Calendar) with minimal code. The Ember Fullcalendar addon hadn't been updated in over a year and I really didn't want to write a calendar from the ground up. The writing was on the wall; I was going to have to write my first Ember addon.

Well, not quite...

In actuality, my first inclination was to see if I could chip in with the current Ember Fullcalendar plugin, but I found that Fullcalendar had done a major upgrade moving from version 3 to version 4; having removed jQuery and Moment as dependencies, and updated their API. If I wanted to fully get rid of jQuery as a dependency in our app it seemed I would have start from scratch.

Inspiration

If I couldn't improve the current addon or use it as a guide for my new addon then what could I look at? For the Ember side of things I went to Ember Observer, a great resource for finding quality addons. I read through some of the popular addons that provide a similar service (bindings to a popular Javascript UI utility). This provided some hints and ideas for structure, but I still needed some ideas for the Fullcalendar side of things. I thought I'd take a peek at the fullcalendar-react package and was pleasantly surprised to find that it barely breaks fifty lines of code.

fullcalendar-react provided the idea to avoid explicit bindings for each property or attribute and simply batch updates and pass them along to Fullcalendar. componentDidMount() becomes didInsertElement(), while componentDidUpdate() becomes didUpdateAttrs(). This makes the addon easier to maintain as I can upgrade its Fullcalendar dependency version with minimal updates to the addon's code. The Ember best practice of Data Down, Actions Up aligns well with React's philosophy and if you account for differences in each framework's API many patterns are easily transferable.

Try it out

The addon can be installed using ember install @mariana-tek/ember-fullcalendar. You can find further instruction in the documentation.

Please feel free to check out the source code or report an issue. Enjoy!

Acknowledgement

Thanks to my employer for the support in making this! If you think you'd like to work on a kind and supportive team that talks Ember, React, and—above all—Javascript, please check us out.

Why I Lint Everything

i. welch canavan — Sun, 17 Nov 2019 23:09:51 +0000

Originally published at welchcanavan.com

I lint everything. No, really. If I'm working on a project—personal or professional—that I believe will outlast the day, installing linters is one of the very first steps I take. If you're unfamiliar with linters, they're a tool that help web developers (or any programmers) avoid bugs, errors, and anti-patterns while enforcing consistent style.

Linters have helped me become a better developer and they have helped me stay a better developer. They can help you do the same. Aside from their stated intentions they can also help you learn best practices as well as how to function on a team.

Linting to challenge yourself

First off, I pick an aggressive linter. If I am writing Javscript I tend towards Airbnb's configuration, if I am writing CSS I use stylelint's standard configuration over their recommended configuration. For writing JSX I throw an a11y accessibility configuration on top of the heap as well.

Second, I install the linter almost immediately, usually before my first commit. This is typically an infuriating experience. If it is my first time using a language or framework and a new linter I find I can scarcely write a line of code without making the linter angry and provoking lots of glaring red warnings in my text editor. For every linter message I do not understand, I visit the accompanying documentation page and read it top to bottom until I understand. If that fails, I start searching for other people who encountered the same message under similar conditions.

While this makes for a slow start, I am much more productive once I am over the initial learning curve. For example, I do not waste nearly as much time as I used to banging my head against the idiosyncrasies of a new framework's API.

Linting to become a better collaborator

You will never be on a team that is completely aligned on best practices. Part of being a great team member is setting your ego aside and recognizing that it is much more important to agree on a standard than your standard.

If you are already employed it makes the most sense to grab an off the shelf solution and avoid wasting time bikeshedding. Bespoke linting configurations tend to lead to a hodgepodge of individuals' preferences that cannot be easily unraveled as team members inevitably join and leave.

If you have not had the opportunity to work on a team yet linters are a great way to learn how to compromise ahead of joining a team. I do not always agree with 100% of the configuration in a linter, but reading the documentation helps me to get a sense of how other people think about code, and I am often compelled to change my mind.

How to get started linting

There are a lot of ways to lint code. The linter can be run during your CI step using a tool like Circle, Jenkins, or Gitlab. The linter can be run via a Git pre-commit hook (there are integrations for most popular languages like Node or Python). My preferred method is to lint live in my text editor or IDE. An internet search should find a plugin for your preferred text editor and a popular linter (e.g. ESLint for VSCode). Linting in your editor will provide you with real time feedback on your code, and a good code editor will provide you with a link directly to the documentation for that rule. Additionally, there are lots of guides to get you started.

Conclusion

It's probably clear that this approach will not work for everyone; I’m sure this level of overhead would be too much for many people and get in the way of a creative spark. All the same, I encourage you to give it a shot and see if this process works for you. I’ve gained a lot of knowledge and patience through this practice and I’m certain others could too.

I Made A Package Lock Inspector With React Hooks, Ramda, and Deepdash

i. welch canavan — Mon, 11 Nov 2019 03:01:51 +0000

Originally published at welchcanavan.com

I have been having a hard time at work getting to the bottom of a dependency issue. As a result, I have spent far more time than I would like to manually parsing package-lock.json. Eventually, I thought "someone has to have made a tool for this" and someone did! William Wong's lock-walker was very helpful while trying to debug my problem. However, there were some improvements I thought I could make on the tool:

Ability to navigate using the browser's history
Ability to have more than one tab or window open
A faster filter

I'm not going to go very deep in to how I wrote the app, as I learned a lot of disparate things on this project, but I do want to touch on some of the tools that helped me solve the problem.

Goals 1 and 2 were easily accomplished using hooks. With useHistory and uselocation from React Router I was able to set the URL when searching and get the URL whenever it changed to trigger the filter. With useLocalStorage from react-use I was able to persist the uploaded packages.

This was my first project using React Hooks and they are satisfying to say the least. I got a lot of mileage out of them useDebounce and I also used useMeasure to power my project's element queries.

Simple Element Queries With React Hooks

i. welch canavan ・ Nov 5 '19 ・ 3 min read

#javascript #react #hooks #css

The third goal, making the filter faster, was the most challenging part of the project. I had to figure out how to filter the package dependency tree down to matches and their parents, excluding irrelevant children and siblings. Thankfully, I found Deepdash—a tree traversal extension for lodash—which took care of a lot of the heavy lifting. Deepdash's reduceDeep with leavesOnly set to true allowed me to visit every childless node, trim the path if necessary, and collect it in the final filtered tree. Ramda's set and lensPath came in handy setting new values on the reducer's accumulator in a performant and immutable fashion.

Package Lock Inspector is live now and you can also view it's source.

Simple Element Queries With React Hooks

i. welch canavan — Tue, 05 Nov 2019 01:55:00 +0000

Originally published at welchcanavan.com

During the interminable wait for element queries it is difficult to not run ahead and experiment with their immense potential. Though there are a few options for using them in your CSS today, the two primary options (EQCSS and CSS Element Queries) have differing APIs with no clear winner. I try to avoid committing to fluctuating syntaxes in my projects, as I prefer solutions that are more explicit. I've written a few iterations of custom solutions in a few frameworks, but haven't been very happy with them so far. While working on a side project recently I found that React Hooks provide a concise and satisfying solution.

The Component

I'm going to presume a general familiarity with React Hooks for this article, but if you would like to familiarize yourself with them you would be hard pressed to do better than Dan Abromov's introduction. While you could write a custom hook relying on ResizeObserver directly or element-resize-detector (if you need broader browser support), I'm relying on the useMeasure hook from react-use. If you haven't come across react-use it is a collection of battle-tested and crowd-sourced React Hooks that address common use cases.

This example also relies on the classnames package. You could absolutely write a version of this that uses CSS-in-JS, but I've got this crazy hangup about legible code, so my example is written with classnames and Sass.

Here is a contrived example of what a React functional component conditionally styled by width could look like:

import classNames from 'classnames';
import { useMeasure } from 'react-use';

function MyComponent() {
    const [ref, { width }] = useMeasure();
    const containerClasses = classNames({
        container: true,
        'container--md': width >= 800,
    });

    return (
        <div className={containerClasses} ref={ref}>
            {/* All of your cool component stuff */}
        </div>
    );
}

The styles

The accompanying styles can be written like so, working up from small to large. Again, the following code is contrived, but the sky is the limit in terms of potential.

.container {
    background-color: red;

    &--md {
        background-color: blue;
    }
}

I've found that element queries can be very powerful with CSS Grid and grid-template-areas, allowing you to drop a component in to any layout and have its contents arranged logically.

.container {
    &--md {
        display: grid;
        grid-template-areas:
            "A A"
            "B C"
        ;
        grid-template-columns: 1fr 1fr;
    }

    &--lg {
        grid-template-areas: "A B C";
        grid-template-columns: 1fr 2fr 1fr;
    }
}

Keeping it DRY

To provide your app with some consistency you could write a utility function like so:

const generateWidthClasses = (containerClassName, width, sizes) => Object
    .keys(sizes)
    .reduce((sizesObj, size) => {
        sizesObj[`${containerClassName}--${size}`] = width >= sizes[size];

        return sizesObj;
    }, {});

You could then use that utility function across many components:

const containerSizes = {
    sm: 600,
    md: 800,
    lg: 1000,
};

function MyComponent() {
    const [ref, { width }] = useMeasure();
    const containerClasses = classNames({
        container: true,
        ...generateWidthClasses("container", width, containerSizes)
    });
    // ...
}

All Together Now

If you'd like to explore this idea further, here's a working example:

The web development community has only scratched the surface of element queries' potential, I can only imagine what people will come up with once element queries are easier and more common. If anyone builds on this idea, I'd love to hear from you!

DEV Community: i. welch canavan

The Simplest Possible Docker Setup For PostgreSQL

Why Docker at all?

Docker-compose vs docker run

Exploded docker-compose.yml

You know something I don't?

I published my first Ember Addon

Backstory

Well, not quite...

Inspiration

Try it out

Acknowledgement

Why I Lint Everything

Linting to challenge yourself

Linting to become a better collaborator

How to get started linting

Conclusion

I Made A Package Lock Inspector With React Hooks, Ramda, and Deepdash

Simple Element Queries With React Hooks

i. welch canavan ・ Nov 5 '19 ・ 3 min read

Simple Element Queries With React Hooks

The Component

The styles

Keeping it DRY

All Together Now

Docker-compose vs `docker run`

Exploded `docker-compose.yml`