The most salient points of the talk are probably the "defense in depth" mechanisms we built for scalability and fault tolerance, and the business results, like -85% full page load time, -65% speed index, or +50% iOS app traffic.
The "Go internals unofficial wiki" on goin.wikispot.org used to be a valuable resource for developers interesting in the internal operation of the Go runtime, but disappeared when wikispot.org went down in 04/2014.
I spent a couple of hours this morning to restore and reformat its contents to the Golang section on the Audean wiki.
Enjoy... but responsibly : its content was fresh in 2014, not last week...
When GoLand is upgraded from one version to the next, the deployment process adds a new set of configuration, cache, and log directories. But it does not remove the versions associated to the previous versions of the IDE, to ease rolling back to the previous version if an upgrade happens to cause an issue.
So after some time, removing these now-unused folders will regain some disk space, possibly more than 1 GB. Here are their respective locations and content on macOS:
The problemIn a GoLand 2018.3 EAP run configuration, a Makefile run configuration finds the
gobinary on macOS, but not on Ubuntu, causing make targets like this one to fail:
# Building WASM
GOARCH=wasm GOOS=js go build -o client/test.wasm client/main.go
/usr/bin/make -f (some edited path)/Makefile client/test.wasm
/bin/sh: 1: go: not found
make: *** [client/test.wasm] Error 127
Simple enough to fix...
When working on compositions in a multi-member band (currently 5 in AnotherDay, each member tends to create their own Guitar Pro files to avoid overwriting the previous versions created by other band members. And
.gp files tend to accumulate for the same song. At which point I start to wonder: "I know there's this riff in one of the versions, but which one ?" or "Are these two files really different or could I just merge them by editing a few notes, or remove one altogether ?"
In 2014, I created a PHP version of the Munin plugins for Beanstalkd introduced by AirBnB, but originally created in Python.
Fast forward four years, and after being adapted for compliances with the PHP-FIG PSR1, PSR2 and PSR12 standards, as well as the Zend coding standards, and with extra documentation, I published the first "stable" version 1.0.0 of the package today under the Apache APL-2.0 license.
As you may have noticed if you are a regular here, I just refreshed the theme on this site to a custom theme built on Bartik. And since Chrome had just been updated, I took the newly updated performance audit.
What more to say ?
While converting the old-style functional tests in the MongoDB project from
BrowserTestBase, I stumbled upon a problem: after following the drupal.org instructions to run PHPunit tests from PhpStorm, doing step-by-step debugging in the IDE worked nicely, but then stopped at the first
$this->drupalLogin(); call, returning a 404 after a very long delay, although the same call running without debugging worked normally. What could be going on ?
When trying to run PHPUnit tests on the MongoDB contrib module for the soon-ready 8.2.0 version, I recently starting encountering this error:
PHPUnit testing framework version 6 or greater is required when running on PHP 7.0 or greater.
Run the command 'composer run-script drupal-phpunit-upgrade' in order to fix this.
OK, no big deal, let's just run that command.
# From $PROJECT/web/core directory
$ ../../vendor/bin/composer run-script drupal-phpunit-upgrade
In RunScriptCommand.php line 89:
Script "drupal-phpunit-upgrade" is not defined in this package
run-script [--timeout TIMEOUT] [--dev] [--no-dev] [-l|--list] [--]  ...
Hmm, so I need that command but it is not defined in
composer.json. So where is it ?
When using MySQL from the CLI, the
-e flag comes in handy to execute MySQL commands directly in bash, like
mysql -uroot -p -e "SHOW DATABASES;". Which gives nicely formatted output like: