Picture of Michael Lee
:wave: Hey hey, I'm @michaelsoolee! I'm a full-stack developer, maker of one too many side projects and dad.

Unregistering service workers in Firefox

Written on July 23, 2019

Not too long ago I downloaded an open source Rails application to my machine to see if I can contribute to it. One of the features that it has is a service worker. So that if and when a user’s Internet connection is lost, the service worker kicks in and provides for a branded experience.

Because the application was a Rails app, the service worker was registered on localhost:3000. What this led to was a bunch of error logs because whenever I fired up a different Rails application, Firefox — the browser I frequently use to do development — would think the service worker was for that particular application.

You would think the solution to fix this issue would be located in the developer tools, but it turns out it’s a browser setting.

  1. Type in about:debugging#workers in Firefox’s address bar
  2. Scroll down to the section labelled Service Workers
  3. Find the service worker you’re looking to unregister and click on the button Unregister

Better product creation through design collaboration :anchor:

Written on July 10, 2019

My buddy, Shaun has written a really informative article about design collaboration and how it can be used to yield better products. I’ve had the pleasure of working with Shaun in the past and his approach to collaboration and providing feedback was always a positive experience for me. I’m glad he was able to share some insights in how he and his team at Savvy utilize it to create products for their clients.

Collaboration with customers is as important as collaboration with other designers and team members. At Savvy, we keep our customer involved throughout the creation of their product. We take our time to explain options and have discussions with the customer to make sure we understand their thoughts.

This enables us to get buy-in from customers early on and work from clear beginnings and ends. Larger reveals aren’t big surprises, and no one gets to the point where they’re seeing work for the first time.

Looping in customers and having them part of the design conversation is a crucial step in the product creation process. I’ve found that by doing this, you don’t have a lot of surprises and there is less thrashing overall. Feedback is also easier to take.

Often, during a conversation with others, we think more about what we are going to say next rather than what others are saying. This impacts the feedback process, especially in design, because we often know what we want to say before hearing another opinion or solution.

When you choose to listen first and react second, it allows you to fully understand the feedback someone else is presenting and sets you up to go deeper — what is the perspective they’re using and the place they’re coming from?

One of the key skills I had to learn when joining an agency that works with multiple clients is to listen. I’ve found that often listening to a client’s problem allowed me to get to the real reason for their ask. From time to time I learned that what they ask for isn’t what their business needs and so it allows me to then respond with a solution that aligns with solving problems for a business goal.

If you work in an environment that is made up of teams of people across various disciplines, I recommend giving Shaun’s article a read.

Compile a site with Jekyll without installing Jekyll using Docker

Written on June 10, 2019

My current choice for running my site is Jekyll, a static-site generator written in Ruby. Since I ditched Wordpress back in 2013, I’ve been using Jekyll exclusively. It is a lot easier to get up and running on Jekyll instead of setting up Wordpress, it does still have some road blocks in getting it up and running.

Since 2013, there’s been numerous times that I’ve had to set up a new computer, which meant getting Jekyll up and running from scratch. That usually means installing Homebrew, rbenv, Ruby and then Jekyll and crossing my fingers and hoping that everything runs the first time. Not to mention also getting git configured so that I could commit back to the Github repo that has all the files for the site.

Last week I started taking another look at Docker. Docker is a technology that lets you run your application in containers all from a configuration file. This is mighty powerful because it allows you to avoid the old dev adage of, “It worked on my computer”.

With Docker I discovered that I could compile or even serve my Jekyll site locally without going through the entire fuss of getting Jekyll up and running on my local machine. Although you don’t have to install any Jekyll dependencies, there is the need to install Docker to get Docker running. But I’ve found it really straightforward because they provide an app which provides the CLI and setup.

Building your Jekyll project with Docker

Once Docker is installed and set up on your machine, you can build your Jekyll project by running this command from the command line within the project folder,

docker run --rm -it --volume="$PWD:/srv/jekyll" --volume="$PWD/vendor/bundle:/usr/local/bundle" --env JEKYLL_ENV=production jekyll/jekyll:3.8 jekyll build

What this command does is:

  • --rm automatically removes the container when it exits
  • --volume="$PWD:/srv/jekyll" takes the current directory indicated by $PWD and map it to the directory at /srv/jekyll within the container so that it could build it
  • --volume="$PWD/vendor/bundle:/usr/local/bundle" this option maps the contents of the current directory’s /vendor/bundle and maps it to /usr/local/bundle. The reason for this option is so that gems could be cached and reused in future builds
  • --env JEKYLL_ENV=production in various parts of my Jekyll project, I’ve designated for it to only render if it’s for production. For example analytics shouldn’t be muddied up by my local development. This sets the environment variable for JEKYLL_ENV to production
  • jekyll/jekyll:3.8 this tells it to use the jekyll:3.8 tagged version of the Jekyll container
  • jekyll build runs the build command for Jekyll

If you’re running this command for the first time, the image for this container won’t be on your system, so it’ll grab it from the Docker registry first before it runs the container.

Unable to find image 'jekyll/jekyll:3.8' locally
3.8: Pulling from jekyll/jekyll
e7c96db7181b: Pull complete
622c94c90cb1: Pull complete
5ab26e9d8a17: Pull complete
830997f3d72a: Pull complete
1956a4eaab3f: Pull complete
36a9759f9f2f: Pull complete
Digest: sha256:deb267df3f6c2b7604b0d5a5aabcb394eec1452a053e4297cf2fb13b125e0bcf
Status: Downloaded newer image for jekyll/jekyll:3.8

One thing I ran into was this warning,

Error: could not read file /srv/jekyll/vendor/bundle/gems/jekyll-3.8.5/lib/site_template/_posts/0000-00-00-welcome-to-jekyll.markdown.erb: Invalid date '<%= Time.now.strftime('%Y-%m-%d %H:%M:%S %z') %>': Document 'vendor/bundle/gems/jekyll-3.8.5/lib/site_template/_posts/0000-00-00-welcome-to-jekyll.markdown.erb' does not have a valid date in the YAML front matter.
       Invalid date '<%= Time.now.strftime('%Y-%m-%d %H:%M:%S %z') %>': Document 'vendor/bundle/gems/jekyll-3.8.5/lib/site_template/_posts/0000-00-00-welcome-to-jekyll.markdown.erb' does not have a valid date in the YAML front matter.

To fix this I had to modify my project’s _config.yml file. Within your project if you’ve got an excluded section defined, add vendor to it.

  - "package.json"
  - "README.md"
  - "publish.sh"
  - "vendor"

Now running the docker run command from above should work and you should see your site built within the _site folder within your project. If you’ve got your project versioned with git it’s probably also a good idea to now add the vendor folder to your .gitignore file.

Serving your Jekyll project with Docker

Instead of compiling if you’d like to instead serve your Jekyll site to do some local development, you can also do that using Docker by running this command,

docker run --rm --volume="$PWD:/srv/jekyll" --volume="$PWD/vendor/bundle:/usr/local/bundle" --env JEKYLL_ENV=development -p 4000:4000 jekyll/jekyll:3.8 jekyll serve

The only difference between the serve command versus the build command above is that I pass it an environment variable of JEKYLL_ENV=development, as I mentioned this is because I have certain sections of my site set up to build only in a production environment.

Upon running the command above, you’ll see the same output as if you had Jekyll locally installed on your computer,

ruby 2.6.3p62 (2019-04-16 revision 67580) [x86_64-linux-musl]
Configuration file: /srv/jekyll/_config.yml
            Source: /srv/jekyll
       Destination: /srv/jekyll/_site
 Incremental build: disabled. Enable with --incremental
                    done in 19.698 seconds.
 Auto-regeneration: enabled for '/srv/jekyll'
    Server address:
  Server running... press ctrl-c to stop.

Only difference is now, your Jekyll project is being generated and served from the Docker container and you can point your browser to localhost:4000 and see the Docker served site.

First step to making your website responsive

Written on June 5, 2019

The very first step on making your website responsive after putting together content is to add a meta tag with the name attribute set to viewport between your site’s head tags.

The meta tag should look like this,

<meta name="viewport" content="width=device-width, initial-scale=1">

What this meta tag does is to tell the browser to set its viewport to be scaled to fit the screen of the device you’re viewing it on.

In your site’s head tags, this is what it should look like,

<!DOCTYPE html>
<html lang="en">
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <meta http-equiv="X-UA-Compatible" content="ie=edge">
  <title>Hello reader!</title>


Adding this single line to your HTML file will set you up in the right direction to make your website responsive.

Precompiling Rails assets for production

Written on June 3, 2019

If you’re deploying your Rails application to a production environment, it’s ideal to precompile your assets. To do this, you’ll want to run,

RAILS_ENV=production rails assets:precompile

RAILS_ENV=production tells Rails to compile the production version of the assets.

assets:precompile is a Rails provided rake task that has instructions for compiling the assets.

Access iCloud Drive quicker in Terminal by creating a symbolic link (symlink)

Written on May 31, 2019

Accessing iCloud Drive isn’t so obvious from the Terminal because Apple uses this weird path.

~/Library/Mobile\ Documents/com\~apple\~CloudDocs

Fortunately you can use a symbolic link or a symlink so that you could easily access your documents in iCloud Drive from the terminal with something like this,


You can do this using the link command or its alias ln from Terminal. So let’s say we’ll want to create a symlink to iCloud in your home folder ~. You’ll want to run this command,

ln -s ~/Library/Mobile\ Documents/com\~apple\~CloudDocs ~/iCloud

-s in the command above is the option according to man link the manual pages, is to create a symbolic link.

Then we pass the source folder and then pass in the desired destination folder, which in this case I used ~/iCloud.

So now from the command link, I can easily get to my notes folder in iCloud by typing in this in Terminal,

atom ~/iCloud/notes