The first install resulted in a black screen (perhaps it went into standby and did not respond to mouse or keyboard presses), but a restart continued the installation successfully. Further OS setup was straightforward and simple. I thought about creating a /home partition but as I was happy with my migration process I decided to go with the convenient default.
The first app to install I had to get from FlatHub, which is nicely integrated. This first flatpakref loaded on the second try and installed using the integration included in the OS.
Syncthing’s introducer feature allows a device to introduce shares to connected devices and this helps setting up the shared folder containing my new-device scripts. It’s important to untick “Receive only” so that it’s a two way sync.
This post will be updated as more thoughts become available.
Say we want to create a symlink to app/config.yaml. If we are familar with the cp command we would incorrectly do this:
$ ln -s config/config.yaml app/config.yaml #this is incorrect
Here, we’re asking ln to create a symlink in app/config.yaml that points to app/config/config.yaml because the ‘source’ parameter is relative to the link being created, not the current working directory. As that file does not exist the command fails!
$ ln -s ../config/config.yaml app/config.yaml #this is correct
$ cd app; ln -s ../config/config.yaml config.yaml; cd - #this is clearer
The first correct example can be difficult to comprehend unless we’re familiar with this concept: From the perspective of the app/config.yaml file, we need to first go to the parent directory then into the config directory.
This is clarified by the third example: by changing into the destination directory, we align the current working directory with the path to the source.
If we create absolute symbolic links by providing the full path to the source file, this is avoided, however these links are more fragile. For example when syncing links the absolute path to the source is likely different on another device.
So shell login can be slow if you installed node versions using nvm and used nvm to set a default interpreter. The solution that helped me was to unset the default node but that means that there’s no node executable unless you manually first run nvm use node or setup .nvmrc in projects… If limited to the former solution, that means PHPStorm might complain node is missing.
I had success installing node from nodesource as the “system node” fallback. weird flex but ok. Some node is better than the right node.
Often I share a screen recording so that others can follow along with tips, processes and generally shared knowledge. However the screen recordings produced by macOS are huge! Here’s how to share smaller recordings, using the command-line version of HandBrake and Hazel:
By default new recordings are dropped on the Desktop. Create a new Hazel rule monitoring new files in the Desktop directory:
If all of the following conditions are met:
Name starts with “Screen Recording”
Extension is “mov”
Size is less than “500 MB” (this excludes large recordings)
Do the following to the matched file or folder:
Add tags “Red” (to indicate the file is being processed)
Run shell script “embedded script” (see below)
Move to folder “Trash” (delete the original)
handbrakecli --preset="Web/Gmail Large 3 Minutes 720p30" -i "$1" -o "$1.mp4"
My last 48 second recording clocked in at 408KB, not bad.
The main problem with accessibility is the term itself. What we are actually talking about here is a universal user experience.
The industry needs to stop selling accessibility as a checkbox and we need to stop viewing it as something extra to do. Inherently every feature and decision we make is already more or less accessible — it is not an on/off switch.
By applying the inversion principle, we should look at what barriers are preventing people from using our websites to the fullest extend, and code all future solutions with these lessons learned.
Aiming for anything less than universal access also makes little economic sense. Let’s ask ourselves: why make a theme and then make it hard to use on purpose? Why make a theme and only allow a subset of people to use it? Do you only allow people with a first name in the first half of the alphabet to log in to your site? Let’s not artificially limit the versatility of the web.
A universal experience should be expected now, and when someone cannot use your site it is a bug. Your site is not inclusive when people cannot use it.
Enjoy the WordPress fun while it lasts folks, I’ve seen the light, and I am worried.
Because, while everyone is looking to the left at SquareSpace and Wix, trying to figure out how to improve the publishing workflow, on the right Alejandro Crosa builds an iOS app that publishes notes online by simply saving them. It abstracts the whole publishing process. Similarly to how Dropbox abstracted the filesharing site, a native app removes the web editor. In. Three. Weeks. Using Rails and Swift!
In 3 weeks he did a (subjectively) better job for this use case than the WP app and the WB mobile experience. Just look at it collectednotes.com and it’s blog — the latter which is written using the service itself!). Yes it does less, but it’s about the job to be done. Gutenberg does less than Word 97 and Dreamweaver. The point is, that’s fine.
WP is currently deciding whether the REST API should be open to third party editors. It’s mission is to democratise publishing, but somehow this is up for discussion. However it turns out the best experience is a native one. Should WP forego the admin interface, change Gutenberg’s full site editing into the theme editor, and restructure itself for what’s to come? WP has a lot of moving parts, and consensus isn’t easily reached. It seems to me that the web will experience will refocus on reading documents, with content creation in apps.
If Apple ever adds a backend service to Pages to sync with a static site generator, or someone goes 10% further than iA Writer’s web-publishing feature in a ‘writing app’ than the whole WP ecosystem is sherlocked.