dotjoe

[dotjoe]

Posting over here now: https://dotjoeblog.wordpress.com/

[dotjoe]

[dotjoe]

Pragma Prefixing the devtool option in Webpack

The Vue.js example webpack config prefixed the devtool option with a hashmark (”#”), I hadn’t seen that before. 

devtool: '#eval-source-map',

Apparently it enforces a pragma style. It’s documented in the old Webpack docs.

Prefixing @, # or #@ will enforce a pragma style. (Defaults to @ in webpack@1 and # in webpack@2; using # is recommended)

[dotjoe]

RegExp.exec and String.match are the same, right?

In JavaScript RegExp.exec() and String.match() should be interchangeable so long as the inputs are the same. Right?

const pat = /(dog).*(bird)/g; const str = 'dog cat bird'; const foo = str.match(pat); const bar = pat.exec(str);

Right, so why are foo and bar different?

foo is an array containing the original string. That's it. Not what I was expecting;

['dog cat bird']

bar contains the expected, complete RegExp result:

['dog cat bird', 'dog', 'bird', index: 0, input: 'dog cat bird']

What happened?*

That little g flag at the end of the RegExp? It completely changes the behavior of String.match. From MDN's String.match docs:

If the regular expression does not include the g flag, str.match() will return the same result as RegExp.exec(). The returned Array has an extra input property, which contains the original string that was parsed. In addition, it has an index property, which represents the zero-based index of the match in the string.

If the regular expression includes the g flag, the method returns an Array containing all matched substrings rather than match objects. Captured groups are not returned. If there were no matches, the method returns null.

In 21 years of JavaScript, I never saw that before now.

String.match might be a bit too quirky for me, I'll be sticking to explicit RegExp methods.

[dotjoe]

Check Chrome memory usage

Open chrome://system/  then click Expand... Chrome seems leaky, I’m curious to see this after a few hours or days. 

[dotjoe]

Flexbox weirdness: invisible pseudo elements

If you ever end up converting a boostrap v3 row div to flexbox, be sure to remove the :before pseudo-element or you might waste a non-trivial amount of time wondering why flexbox wasn't working right.

Some things that might happen (These seem especially common on Safari, macOS and iOS)

justify-content: flex-start doesn't touch the start (because there's a hidden element in the way)

flex-wrap: wrap might appear to wrap too soon, leaving an odd number of elements on the first line. It's working right, it's just adding the hidden element into the caclulation.

The solution is to remove the pseudo-element from the document by overriding its style with content: none;:

.flex.row { display: flex; } .flex.row:before { content: none; }

[dotjoe]

Adobe CEF Helper

1.29 GB Real Memory for a background process. This blew up over the past few hours, I already killed the process once today.

Update: Now in my crontab:

56  *   *   *   *  killall 'Adobe CEF Helper'

[dotjoe]

For something that works really well once it's working, I can't believe how much time I've blown fighting with PHP namespaces and autoloading.

me

[dotjoe]

diskutil resizeVolume disk2s2 500G

❤️

Thought I still needed the old Disk Utility app. Was wrong.

[dotjoe]

Lots of out-of-date WordPress documentation floating around. wp_title has been deprecated (or at least zombied) and does nothing on WP installs since v4.4.

[dotjoe]

That site’s so old it’s already mobile optimized.

me (the page was contained in a single 600px wide table)

[dotjoe]

I could easily see switching to Prettier once it’s more established, but for now here’s the ESLint config I’ve been using.