Execute yarn. Do not go git checkout --theirs ... and git reset ... and whatever else people might suggest. Just type yarn and press enter. Yarn has an automatic conflict resolution built into it, it will detect that the yarn.lock file has conflicts, and use its internal algorithm to figure out what to do. This was a public service announcement.
Some libraries, tools, and technologies that have made a lasting impact on me in 2018.
And it's a terrible mess, and nobody should use it until this is fixed. Yeah I said it. The internet is already full of "5 reasons async/await blows Promises away" and "How to escape callback hell with async/await", only thing they all fail to mention is that is that it will lead to errors that are missing crucial stack trace information.
If you have been using Dropbox on a filesystem other than ext4, you have been probably getting annoyed by the following warning, in the past 2 months:
Move Dropbox location. Dropbox will stop syncing in November.
According to Dropbox, this is intended, and their official response is:
Hi everyone, on Nov. 7, 2018, we’re ending support for Dropbox syncing to drives with certain uncommon file systems. The supported file systems are NTFS for Windows, HFS+ or APFS for Mac, and Ext4 for Linux.
We’ve updated our desktop requirements accordingly here.
A supported file system is required as Dropbox relies on extended attributes (X-attrs) to identify files in the Dropbox folder and keep them in sync. We will keep supporting only the most common file systems that support X-attrs, so we can ensure stability and a consistent experience.
Which is the corporate bullshit version of saying "sorry we run into some obscure problems with some filesystems, so we only have the capacity to support one for now", but that is a big marketing and sales no-no, so instead they sell it as a "consistent experience" and "stability", and some random bit about xattrs, which every filesystem supports. Here's a workaround.
Slack has decided to remove the XMPP and IRC gateways, they will cease functioning on May 15th. It's a real shame, because these were the only usable interfaces to slack, both the web UI and the desktop app hog memory like a separate browser session, but there are still some solutions you can use to avoid using them.
If you are running kubernetes on google cloud, you probably run into the issue that it's not so straightforward to connect to a cloudsql instance from within the cluster. The official best practice is to run cloudsql proxy as a sidecar container in your pods, and connect through that. There are two problems with this, and I will address both.
About one and a half year ago, I wrote about the shortcomings of the python package manager, pip. Finally, there is now an officially recommended package manager, called pipenv, that solves all of the problems mentioned there, and providers a few extra goodies too.
I set this up 2 years ago, but today I had to add another Slack network to add, and it took me an hour to figure out. The connection to ZNC was working fine, but when ZNC was trying to connect to the Slack server, I always got "Invalid user name or password" from slackbot. Slack doesn't explicitly tell you, but the username it gives you is supposed to be your nickname, and your ident, and you have to set this up before making a connection attempt.
I had some troube setting this up, because most of the google hits that come up are for older windows versions, which are using the old MBR/non-UEFI method, show examples for grub1, outdated, or just plain wrong.
The package manager for python, pip has some shortcomings, and we will look at solving the biggest two: not being able to record only the top level dependencies in a project (the dependencies of the dependencies also get lumped together), and finding a way to record only dev dependencies.