Aaron Eaton

Archives for November 2017

Hey, Focus!

by Leave a Comment

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.

Screenshot of Focus settings

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.

Screenshot of Focus schedule settings

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.

Using remote XDebug with Visual Studio Code

by Leave a Comment

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.

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:

Gif of debugging working in VS Code

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!

The Stillness of Hunting

by Leave a Comment

Photo of landscape from a deer stand. A still pond on the right.

Even when you come back empty-handed the time has not been wasted. Hunting provides us with so much more than meat.

In the stillness of hunting you have time to stop, to listen, and be present with yourself and the great outdoors.

Accessing React refs in React-DnD

by Leave a Comment

My team and I at OptinMonster are in the process of building a true drag & drop solution for the campaign builder.
This represents the biggest improvement to the platform in over a year.

We landed on using the excellent React DnD to power the user
interactions. It provides some high-level components to make use of the HTML5 Drag & Drop API which significantly
speeds up our development.

One problem I’ve run into is accessing a child of the drop target element to calculate some hover interactions. The
React DnD docs suggest using findDOMNode(component) but performing the DOM tree searches during the hover callback
(which fires seemingly every 10ms) can bring the browser to a standstill with any significant number of nodes.

So instead I found React refs are accessible from within the React DnD callbacks with component.decoratedComponentInstance. This is a significantly faster method of pulling data out of the DOM and provides
access only to the DOM elements you really need. Here’s how to make use of the refs:

/**
* Set `this.targetEl` to your desired element.
*/
class MyComponent extends React.Component {
// ...
render() {
    return (
        <div className="parent">
            <div className="child" ref={el => this.targetEl = el}>Content Here</div>
        </div>
    )
}
// ...
}

/**
* And in your drop target spec `targetEl` will be available.
*/
const dropTarget = {
  hover: (props, monitor, component) => {
    // Get the target bounding rectangle
    const hoverBoundingRect = component.decoratedComponentInstance.targetEl.getBoundingClientRect();
    // ... 
  }
}

Have any questions about React, drag & drop, or OptinMonster? Let me know on Twitter!