Personal

Fixing Woodworking Mistakes

While making the tea light centerpiece I, of course, made some mistakes. Luckily, wood can be a forgiving medium. Here’s a little video on how to fix those mistakes.

Personal

First Woodworking Video

I made this tea light centerpiece for my wife on Mother’s Day 2019. This is the first project where I remembered to video the process, so enjoy!

Mistakes were made.

Development

Counting Gutenberg Blocks

This week I was tasked with performing a quick audit on an existing client site for WordPress 5.0 compatibility. The site had already made use of Gutenberg so we were curious just how many blocks were in use.

For those of you who don’t know, Gutenberg blocks are stored in the post_content field and look something like this:

<!-- wp:paragraph {"align":"center"} -->
<p>Now, this is a story all about how My life got flipped-turned upside down And I'd like to take a minute Just sit right there I'll tell you how I became the prince of a town called Bel Air
<!-- /wp:paragraph -->

Now, since every block begins with the same pattern, <!-- wp:, we now have something we can target in a SQL query. The trick is to count the number of times that pattern occurs in each post_content field.

After a lot of research and consulting my amazing colleagues over at WebDevStudios I finally landed on a query that will get a count of every Gutenberg block published on your site. Here it is:

SELECT 
    SUM( LENGTH( REPLACE ( post_content, "<!-- wp:", "}") ) - LENGTH( REPLACE ( post_content, "<!-- wp:", "" ) ) ) AS block_count
FROM wp_posts
WHERE post_status = 'publish';

Just copypasta that query into your favorite MySQL client (or the cli if you’re hardcore) and you should see the magic number.

Query Result

Personal

Hey, Focus!

It will come to no surprise for those who know me. I have a hard time focusing for any significant period of time. Of course, this issue does not mix well with a remote, full-time job.

Thankfully I’ve created systems to mitigate my lack of attention-keeping ability. Here they are.

Have a dedicated office

My family and I are fortunate enough to have an extra room in the house that we set aside as a dedicated office space. This provides several benefits, but my favorite is they psychological separation of work/play. After 3.5 years of working from home I have trained my brain to switch into work mode when I enter the office. A door that can lock from the inside is also a great benefit on the rare occasion I have to work when my family is home.

Keep devices out of the office

While I’ve disabled all but the most useful notifications on my phone, the mere presence can lead me to pick it up. Same goes for the iPad.

Blanket rule: No devices in the office unless they’re being used for testing.

Block distracting apps with impunity

This is my coup de grâce but it took a while to catch on. Too often I would leave my email open or forget to turn on DnD in Slack. I’d see a new message came in and before I knew it I was down a rabbit hole that almost always lead to some obscure Wikipedia page, subreddit, or StackExchange community. For a while I searched for an app that would not only block distracting websites (of which there are plenty) but also applications.

Finally I landed on Focus (aff. link). Focus fit both of my criteria. I could block all of those websites where I typically end up as well as quit any distracting applications. As soon as a focus session starts anything on the block list disappears. For me that means TweetBot, Spark (for email), and any games simply go away. All of this was good, but I needed to go further. I had to remove any chance that a moment of weakness would have me stop the focus session.

Enter Hardcore Mode

Hardcore mode does exactly what you think it does. Once a focus session has started, there’s no way to turn it off until the countdown or schedule is finished. This mode does allow for breaks but only to the limit you set below.

Hardcore Mode

Scheduling

Speaking of schedules, I’ve found that setting a focus schedule helps me get more done in just a couple of hours than I ever had in an entire day. Combined with Hardcore Mode I have no choice but to stay focused on the task at hand every morning. In case you were wondering, I do my best to reserve afternoons for meetings, communication and other miscellaneous tasks.

Schedule

Tying it all together

The feature that really sold me on Focus was scripting. This would allow me to get rid of every last distraction. You can create separate scripts for when you enter and exit a focus session. Here are mine:

Focus script:

# Set Slack DnD
export PATH="$PATH:/usr/local/bin" 
/usr/local/bin/slack snooze start 180

say -v Samantha get to work

Unfocus script:

# Turn off Slack DnD
export PATH="$PATH:/usr/local/bin" 
/usr/local/bin/slack snooze end

say -v Samantha done

Using a great bash utility I’m able to set my Do-Not-Disturb status for Slack as soon as my focus session starts.

Focus also provides a URL scheme to start & stop sessions from other apps. I made use of this by creating an Alfred workflow that would begin a 5 minute countdown before starting a focus session. This allows me to finish a conversation with a coworker or write up a quick email to a partner before getting back to my focused development work.

So there you have it! This is how someone with attention issues can thrive in a remote work environment. If you have any other tips to add I’d love to hear from you on Twitter.

Development

Using remote XDebug with Visual Studio Code

I was happy in Jetbrains land. Everything was familiar. Everything fit into my workflow perfectly. For 4 years every bit of development was completed in PhpStorm. Then things started to go sour. Constant re-indexing would bring my computer to a crawl. RAM usage far exceeded that of Slack (yeah). And that’s just the start of it.

A few colleagues of mine began extolling the virtues of Visual Studio Code in the first half of this year. Given my jaded history with Microsoft I was, at first, put off by the idea of using a Microsoft IDE. Their preachings were ignored for a while.

But they kept preaching. And FOMO kicked in.

In September I decided to give VSC a chance. The inagaural project was a fully drag & drop campaign builder for OptinMonster. The project is 100% JS so it seemed like a perfect fit. It was, but I still found myself sneaking back to PhpStorm for all of my backend development. There was just too much missing in VSC for me to go all in.

Over time I was able to close all of those gaps except one: remote debugging. I, like most PHP developers these days, run my development environments on virtual machines. This means our language interpreters XDebug run within the confines of the VM. Visual Studio Code does not support this configuration out of the box so I’ve written up everything I learned.

Prerequisites

You will need PHP 7+ with XDebug running on a virtual machine.

Install the necessary extension

Since VSC isn’t really set up for PHP from the get-go you’ll need to install the PHP Debug extension. This creates an adapter between XDebug and the built-in VSC debug functionality.

Make XDebug talk to the outside world

In your VM, open up php.ini and you’ll hopefully find a section for XDebug. Make sure the following settings exist:

[Xdebug]
xdebug.remote_enable = 1
xdebug.remote_autostart = 1
xdebug.remote_connect_back = 1

Don’t forget to restart PHP after making this change!

Create the debug config

Debug configurations in VSC are, like every other config, a JSON file. You’ll need to create a configuration for PHP. Open up the Debug panel in VSC, click the gear icon (should have a red dot) and select PHP as your environment.

Create a debug config

You should see a new file open up called launch.json.

Set up path mappings

The default PHP debug config will allow you to listen for remote XDebug sessions but you’ll likely need to tell VSC where to find your files on the server. Skipping this step really just renders the debug features worthless. Your config should look something like this:

{
    "name": "Listen for XDebug",
    "type": "php",
    "request": "launch",
    "port": 9000,
    "pathMappings": {
        "/app/public": "${workspaceRoot}"
    }
},

You should set up all of the necessary path mappings. Their format should be "/path/on/server": "${workspaceRoot}/local/path".

Start debugging

Now start a debugging session (F5) and create a breakpoint in your code. If everything has been set up correctly the next time you load your app you’ll see all of the debug info in the VSC sidebar. Here it is in action:

Debugging


So with XDebug working beautifully in Visual Studio Code I’ve removed my last hurdle to switching.

Have any great tips or extensions to share for VSC? Hit me up on Twitter!