Page 1 of 53

The Gutenberg Experiment

I resisted the move to Gutenberg for quite some time — and this was largely because it failed to work when I installed the test plugin. It took me quite a bit of digging into my theme’s functions file to figure out the issue, but it was related to the removal of the wp-embed.js file that I never really understood the purpose of for my own theme.

Well, here we are, and I’m writing this today using Gutenberg, and I cannot wait until I can move some of the more powerful features into production on my personal site. At the moment I am not injecting my site’s styles into the backend as Gutenberg’s defaults seem to suffice. The biggest issue for me will be how I handle post formats moving forward — particularly with my older content — and how to handle what will become a custom post type for portfolio content.

The future is incredibly interesting with WordPress and Gutenberg in terms of advancing the publishing capabilities we’re seeing, but what I’m most curious to see is is how well this will translate to the CMS it is commonly used as. Even now I have a few pages that are more hand developed and not utilizing the included content editors.

Let’s see what the future holds.

In discussing truth and photography, we are asking whether a caption or a belief — whether a statement about a photograph — is true or false about (the things depicted in) the photograph. A caption is like a statement. It trumpets the claim, “This is the Lusitania.” And when we wonder “Is this a photograph of the Lusitania?” we are wondering whether the claim is true or false. The issue of the truth or falsity of a photograph is only meaningful with respect to statements about the photograph. Truth or falsity “adheres” not to the photograph itself but to the statements we make about a photograph. Depending on the statements, our answers change. All alone — shorn of context, without captions — a photograph is neither true nor false.

Errol Morris

Current Mood

This is an old one, but it sure described my day about 5 years ago.



And of course, the code I wasted some time writing to get this ridiculous result.

function howIFeelToday() {
    var d = new Date(),
      h  = d.getHours(),
      hh = (h > 12 ? h - 12 : h),
      m = (d.getMinutes()<10?'0':'') + d.getMinutes(),
      a = h < 12 ? ' AM' : ' PM',
      time = hh + ':' + m + a,
      feeling = "";

    switch(h) {
        case 8:
        case 9:
        case 10:
        case 11:
            feeling = "Damn, it's only " + time + "!";
        case 12:
            feeling = time + ", yeah, lunch time!";
        case 13:
        case 14:
        case 15:
        case 16:
            feeling = time + "...this is the longest day of my entire ever-loving life...";
        case 17:
            feeling = time + "! Finally. :)";
            feeling = "Probably not at work.";
    return feeling;

var currentmood = howIFeelToday();

Fluid Type for Better Responsive Text

I’ve been playing around with fluid type for a while and happened upon a pen by…I don’t remember who. I forked it a while ago, but in essence we’re simply attempting to scale type based on viewport size.

In the instance highlighted here, let’s say we want a bold header in a hero space to essentially always have that bold feel no matter what screen size we’re viewing items at:

See the Pen Scaling Text with Viewport Units by mikemattner (@mikemattner) on CodePen.

Not a bad solution, but if you’re not careful that can scale infinitely and in a way that is just a bit too in your face. My suggestion is to set–at the very least–an upper bound to that scaling. I’ve done something similar on this very site.

My minimum size is set at 14px, plus a half a percent of the viewport width with a line-height set based on 1.1em plus a half a percent of the viewport width. This will scale up infinitely, but I found that that maximum font-size I wanted was closer to 20px. Through a little viewport resizing and code inspection, I found the viewport width where this formula would generate a nominal 20px size and set that as my upper bound:

html {
  font-size: calc(14px + 0.5vw);
  line-height: calc(1.1em + 0.5vw);
  @media (min-width: 1200px) {
        font-size: 20px;

Not too bad of a result as far as I can tell. The rest of my typographic sizing builds on this initial sizing and seems to work out fairly well for my purposes.

Easy technique.

Adventures in Dotfiles

I accidentally ran into a bit of laziness during my development process that turned into a productivity boon, and should prove to be absolutely essential during the setup of any new Mac I might purchase in the future.

Let me preface this by saying I am not a native of the command line–by any stretch. I find it to be cumbersome and annoying to remember commands and all of the possible flags that might apply to them. Even something as simple as showing hidden files on the Mac can be obnoxious:

# Show hidden files
--- ~ » defaults write AppleShowAllFiles -bool true && killall Finder

# Hide hidden files
--- ~ » defaults write AppleShowAllFiles -bool false && killall Finder

What if I could just type show or hide and be done with it? This is where aliases come in. This was a concept I was keenly aware of already–seeing that most of the helper plugins I used in my ZSH installation provide plenty of helpful aliases–but I figured, why not create some that I could use for operations I performed frequently? Or to find a way to easily navigate to directories I regularly used?

At first I created a simple .aliases file and started to add what I needed:

# Show/hide hidden files in Finder
alias show="defaults write AppleShowAllFiles -bool true && killall Finder"
alias hide="defaults write AppleShowAllFiles -bool false && killall Finder"

# Hide/show all desktop icons (useful when presenting)
alias hidedesktop="defaults write CreateDesktop -bool false && killall Finder"
alias showdesktop="defaults write CreateDesktop -bool true && killall Finder"

# Disable Spotlight
alias spotoff="sudo mdutil -a -i off"
# Enable Spotlight
alias spoton="sudo mdutil -a -i on"

#Git commands
alias gnb="git checkout -b"
alias gmsg="git commit -m"

I sourced it in my .zshrc file and called it good.

But then I wondered what would happen if I lost everything on this system? I started doing a little research and discovered that there were plenty of people working on ways to bootstrap their development environments for situations like this.1

I found one particular repo by Mathias that I was able to gather some items from, as well as an installation process that could get me started with everything I used. Now all I need to do is navigate to my cloned repo and type:

--- ~ » source

I follow a few prompts and install what I need to get up and running. I can share my dev environment between machines fairly easily this way.

If you’re interested, feel free to browse my repo for reference, or fork it if you want to build on it. Keep in mind, there are more repos available with more sophisticated setups than my own if you’re looking for something more robust, but if you’re knew to this level of customization on this level, this is a good start.2

View Project on GitHub

  1. Getting Started with Dotfiles. Accessed May 23, 2018.
  2. GitHub does dotfiles. Accessed May 23, 2018.