Forem: Alvin Bryan

Tips to remember latitude and longitude

Alvin Bryan — Fri, 28 Oct 2022 11:03:05 +0000

I like coding maps, but I would always forget how to remember latitude and longitude. I would always mix them up. I tried some mnemonic techniques (like, latitudes = ladder) but none of them ever worked.

Here are a couple of tips to remember latitude and longitude.

1. X/Y coordinates

Tip #1: The simplest, but not the easiest, is to memorise this:

Latitude is y and longitude is x.

That’s it, Latitude is the y axis and longitude is the x axis.

I tried that but would still mix them up at times. So I came up with the next tip.

2. The long side of a world map

Tip #2: If you think of a world map, usually it’s a rectangle.

The long side (the largest side) is the longitude.

Orientation

The point at 0,0 is the intersection of the Equator and the Meridian of Greenwich. The greater the distance to them, the greater the latitude/longitude. East of the meridian gives you a positive longitude value, and west gives you a negative one. Same for north/south of the Equator.

For example:
Prague has a larger longitude (14.43) than Paris (2.35) because it's further east. Ergo for San Francisco having a larger value (-122) than Washington DC (-77) because it's further west.

Here are the rounded coordinates (in the order latitude, longitude) of some popular cities to help you.

London: 51.501, -0.118. (Greenwich is in London, hence the zero longitude)
Sydney: -33.865, 151.210
Tokyo: 35.653, 139.839
Singapore: 1.290, 103.852
Los Angeles: 34.052, -118.244
Oslo: 59.911, 10.758

Here's a bonus factoid for people in the UK, Edinburgh's main train station is further west (55.95, -3.18) than Liverpool's (53.40, -2.97).

I hope it helps, good luck!

How ethical alternatives succeed: a Signal case study

Alvin Bryan — Thu, 16 Jun 2022 09:54:58 +0000

Here's a story about the tick that beat the giant with a trick
— Smith and Thell, Goliath

In January 2021, Signal was only known by journalists and privacy geeks. In a matter of days, it topped the charts and was on everyone's phones.

How did that happen?

TL;DR

Signal was an overnight success that was years in the making. The app had all the components that any alternative product needs to succeed:

Zero or low switching cost, which means:
1. A seamless transition process
2. Feature parity, almost
3. Intuitive design
Issues with the status quo, i.e., a villain. The reason to switch has to be well-known and relatable.
Street credentials. If shouldn't be just you recommending the alternative.

What's the deal with WhatsApp and Signal?

WhatsApp, owned by Facebook/Meta is one of the main secure messaging apps. Signal is a similar app run by a non-profit with a small team. Interestingly, it was the Signal team that implemented WhatsApp's encryption.

These apps coeixsted for a while. WhatsApp was the mainstream app that almost everyone used, and Signal was the unknown that only journalists and privacy geeks used. Until everything changed.

One day, on January 2021 WhatsApp sent a notification to its users regarding a new privacy policy. The notification said that from 8th February, WhatsApp would start sharing data with its parent company (Facebook). The Internet started writing about the changes, and people started switching to Signal. A snowball effect ensued.

The overnight success

Signal became the most downloaded app in the App Store in India, Germany, France, Austria, Finland, Hong Kong, and Switzerland. The downloads went from 246,000 the week before the WhatsApp change to 8.8 million the week after. Facebook even bought ads for the word "signal" to prevent people from downloading it. 3 months after the initial incident, Facebook closed Signal's Instagram account.

This overnight success is attributed to Elon Musk advising people to "use Signal" on Twitter. While it made a gigantic difference, I don't think that's why it worked.

If Elon tweets "use Linux" tomorrow, no one will care. Why did "use Signal" work so well?

I. Zero or low switching cost

Convenience is everything.

1) A seamless transition process.

There are 4 steps to get on WhatsApp: Download the app, give it a phone number, wait for the text, and give it access to your contacts. That's it. For Signal, it's the exact same process. If Signal asked you to create an account, wait for a confirmation email, type a bio, enter a location, refer a friend, use a two-factor code, plus the other 4 steps, I wouldn't be writing this.

It should be as easy as possible to transition to the alternative. Otherwise people won't bother.

2) Feature parity, almost.

Open-source developers tend to pay too much attention to the specifics. In our case, Signal didn't have exactly the same features as WhatsApp. You couldn't search Emojis by their name, it didn't support group calls with more than 5 people, and the group admin features were limited. But it had most of the features that most people wanted.

It offered, all in all, a user experience that was similar enough.

Today, not only did Signal add all these missing features, it did so without sacrificing security and privacy. Continuing on my example with group calls, Signal now support group calls with up to 40 participants. That required a lot of engineering.

3) Intuitive design

The design of the the product must be pleasant, and easy to use. You should never have to learn a new app. Signal had a simple design without bells and whistles.

II. Issues with "the status quo"

Why would you switch when the current product works?

Claims like "It's Photoshop but open source" are terrible. They're appealing for developers but not the average person. "Photoshop without Adobe's pesky installer" is much better.

In Signal's case, Edward Snowden had recommended Signal for years. But humans are narrative creatures. We need a story to justify our behaviour. Issues have to be clear and resonate with people. It's not only chanting the merits of your alternative, it's about showing how ugly the status quo is.

WhatsApp was associated with security and privacy, but Facebook wasn't. That's what made people quit. The villain of the story became obvious.

III. Street credentials

The most discouraging problem with new social apps is "nobody I know uses that." This creates a self-defeating downward spiral that keeps the user base low.

Signal had just enough notoriety that it wasn't completely unknown. After Elon Musk's tweet, other celebrities joined the fun. Signal's founder and CEO was invited on The Joe Rogan Experiment, one of the biggest podcasts in the world.

As a result of that, Signal became a known quantity. When people asked their friends and families about this "signal thing," someone had heard of it somewhere.

What now?

There were multiple factors that contributed towards Signal's success. But the main takeaway is this: Make a great alternative product, and don't compromise.

If you're an early user of giving feedback about a new app, demand no less than a great UX. Don't worry about the small stuff. Don't nitpick about a feature if most people don't need it.

If you're a creator/developer, nail the core product, then reach out. I'm as jaded of the marketing logo wall as everyone else, but the beginnings are always tough. I get it, it's easy to forget UX glitches when you're too close to the product. And it's much more fun to work on a coding problem than crafting a compelling marketing message.

My hope is to see this success is replicated. More competition is better for consumers, well, most of the time. Remember when there was only one TV subscription service?

Thank you to Jeremiah Lee and Kev Quirk for reviewing drafts of this article.

What’s the problem with metadata?

Alvin Bryan — Mon, 26 Jul 2021 11:41:17 +0000

A friend asked me over the weekend: "What’s wrong with WhatsApp?"

If messages are encrypted, what’s the big deal? That’s a fair question. The answer reveals a larger problem. The problem with companies (in this case, Facebook) collecting metadata around your data.

Let's see why this is dangerous.

What’s a metadata anyway?

Data-hungry companies often defend themselves with this misleading statement: "It's OK, it's just metadata."

Well, what's a metadata? It's data that's about other data. For example: In a chat app, if the message is the primary data, then the metadata could be:

The time of the message
Who you're talking to.

Something like "Ben sends 1 message to Jack today at 18.33"

It's not OK at all.

Why are metadata dangerous?

Metadata collection is harmful to privacy. One single metadata may be harmless, but the more metadata you have, the more complex and precise a picture of you emerges. Let's not forget, metadata come from a variety of sources.

Let's go back to our example

"Ben sends 1 message to Mark today at 18.33"

That's pretty innocuous, right ?

But when Ben sent the message, WhatsApp (and by extension, Facebook) collected its location. If Ben sent 5 messages over 10 minutes without changing location, Facebook knows Ben isn't moving too much.

It turns out, Ben is sitting in a waiting room. Waiting to see a discernment counsellor. That's a therapist for people thinking about divorce. Ben wants to work on himself to save his marriage.

Facebook knows who Ben is married to already. They know it from an Instagram story of the wedding posted by one of Ben's contacts (even if Ben himself isn't on Instagram).

Now, from this piece of metadata (his location), Facebook can guess that Ben's marriage isn't doing well.

Before Ben even left the waiting room, his wife Sarah received an ad¹ for a divorce lawyer. 15 minutes later, Sarah sees another ad for a dating app.

You see, even a series "simple metadata" can reveal a lot about you.

This is not limited to Facebook. Anyone with metadata about you can run very complex algorithms and profit from it.

If your bank starts speaking about "sharing data with trusted partners," you should opt-out. Immediately. Now you know how they can make money from your location and card purchases.

Facebook sells information to advertisers everywhere on the Internet, not just on its platform. So Ben's wife can see the ad anywhere on the Internet, even if she's not on Facebook. ↩

Weak References in JavaScript

Alvin Bryan — Sun, 03 Jan 2021 11:29:06 +0000

ES6 introduced WeakMaps and WeakSets, which brings weak and strong references to JavaScript, a concept front-enders are not particularly used to.
If you're working on games, you have to pay very close attention to how memory and performance is managed.

I'm using WeakMap here as an example, but it's the same for WeakSet too. The main difference between Map and Set is that the latter only keeps unique values.

According to Wikipedia:

In computer programming, a weak reference is a reference that does not protect the referenced object from collection by a garbage collector, unlike a strong reference.

That actually, surprisingly, makes a lot of sense! Wikipedia got me used to definitions like Coroutines are computer program components that generalize subroutines for non-preemptive multitasking by allowing execution to be suspended and resumed.

Alright, what a WeakMap does, compared to a good old Map or {} is each individual key element in the set can be garbage-collected when they are not referenced somewhere else:

If this is the content of a regular Map / {}:

const bigObject = {
  id: 'spritesheet-1',
  data: [
    /* gigantic array with a lot of stuff */
  ],
  description: 'hello bla bla',
};

And you're only using it in the code like this

const spritesheetID = bigObject.id;
// the gigantic array in myMap.data is in memory

The whole object and the gigantic array will remain in memory and will not be CGed until it or its references are destroyed.

Whereas if you use a weak map anything that isn't being used in your program will be garbage-collected.

// create a WeakMap from the big object
const weakMap = new WeakMap(Object.entries(bigObject));

// gigantic array is garbage-collected
const spritesheetID = weakMap.get('id');

Now you could manually delete the keys of the object that you don't use, but this trick saves you having to keep track of your usage because this isn't C++.

People have also found other ways to use this with promises and more in this Stackoverflow thread.

That's all for this post! It's a simple concept but needed clarification for me, so I thought I might as well share it.

Cover Photo by Fredy Jacob on Unsplash.

Learn about other commands with `tldr`

Alvin Bryan — Wed, 25 Nov 2020 12:50:00 +0000

There are a few reasons that computer terminals scare people (myself included):

Movie stereotypes of green terminals used by hoodie-wearing hackers in basements.
How terminals try to “help” you.

The default help pages (called man pages for manual, go figure) don’t feel designed for humans to me. They’re hard to use and make sense of.

tldr pages try to fix that. The tldr utility gives you a people-friendly list of examples to help you with a command.

Example with the rename command that we discussed in a previous article:

Compare that with the man page, as follows:

RENAME(1) User Contributed Perl Documentation

NAME
       rename - renames multiple files

VERSION
       version 1.600

SYNOPSIS
       rename [switches|transforms] [files]

       Switches:

       -0/--null (when reading from STDIN)
       -f/--force or -i/--interactive (proceed or prompt when overwriting)
       -g/--glob (expand "*" etc. in filenames, useful in WindowsX CMD.EXE)
       -k/--backwards/--reverse-order
       -l/--symlink or -L/--hardlink
       -M/--use=Module
       -n/--just-print/--dry-run
       -N/--counter-format
       -p/--mkpath/--make-dirs
       --stdin/--no-stdin

See how neat this is with ffmpeg, a tool that’s notoriously unfriendly.

Also, as opposed to man pages, which require you to install a vim-like interface, tldr pages are easier to contribute to. Everything is in a GitHub repository.

Finally, tldr isn’t limited to the command line. There’s also a VSCode Extension, an Alfred Workflow and even an iOS app.

If you’re convinced, install it with brew install tldr on macOS and Linux.

That’s the end of the series! It introduced you to a few, well, nifty tools that I use quite often, and I hope that it will help you reach out to the terminal to save time.

Thanks!

Domain records made less weird with `host`

Alvin Bryan — Mon, 16 Nov 2020 14:09:20 +0000

I've been hosting my websites and my domains with different providers for a long time. Same goes for emails. In order to connect your domain to your provider or to your email address, you need do 🚨Domain Verification🚨. And that means doing a few obscure DNS operations like changing name servers and whatnot.

You set this up on your domain registrar's website. It's usually hidden behind various clunky UIs. Frustrating is an understatement.

Do you know what the worst part is? After you find the hidden thing, paste the random blob, and sear never to do it again, you can't tell for sure that it worked.

That's where the host command comes in. It lets you inspect the DNS records on your domain from your terminal. It probably does other stuff but that's all I ever needed. With this command, you can finally see what your wrangling with the UI did.

Here are a few examples:

Show TXT records

host -t txt alvin.codes

Show A records

host -t a alvin.codes

Show CNAME

host -t cname alvin.codes

Show Name Servers

host -t ns alvin.codes

The host command is similar to the dig command, but it's a lot simpler and easier to remember. I know which one I prefer between typing dig alvin.codes +noall +answer and host -t a alvin.codes.

Bonus: Gitlab & GitHub

Speaking of hidden settings... Here's a bonus for you. Here's what you need to do to connect Gitlab or Github pages to a custom domain.

For Gitlab, 2 things need to be set:

A record set to 35.185.44.232. (Until their IP changes 🤷‍♂️.)
A TXT record set to gitlab-pages-verification-code=[Your Verification Code]

For GitHub you need to create a CNAME file at the root of your repository. You can use with the GUI to set it up with the correct values for your domain.

Then, you need to set the following A records:

185.199.108.153
185.199.109.153
185.199.110.153
185.199.111.153

Feel free to reach for this article next time you have a domain to set up, I sure will.

Good luck,
Alvin

Batch-rename files easily with `rename`

Alvin Bryan — Tue, 27 Oct 2020 11:20:00 +0000

I use the rename action in macOS Finder when I need simple operations. For example, changing a file extension from .PNG to .png or replacing underscores with hyphens. For more complex stuff, like lowercasing, or removing a range of characters, Finder becomes too tedious.

That’s where the rename command comes in. It lets you use regular expressions and looks like this: rename -f '[regex]' [files].

Right off the bat, you want to remember the -n or --dry-run option. It’s super useful to test out what the resulting files will be without actually renaming them.

Here’s how you would replace all the double dashes with single ones:

~/Export ❯❯❯ rename -f 's/--/-/' * -n
'Example--1.png' would be renamed to 'Example-1.png'
'Example--2.png' would be renamed to 'Example-2.png'
'Example--3.png' would be renamed to 'Example-3.png'
'Example--4.png' would be renamed to 'Example-4.png'

The * in the command above means “do this on all files in the current folder.” You can use glob patterns to specify target files. So, to rename only .png files, you’d write rename '[regex]' *.png

As I said, regular expressions.

You write them like this s/[old]/[new]/ or y/[old]/[new]/ without the square brackets.

In our command, s/ regexes are used for 1-to-1 character mapping while y/ regexes are for more complex replacements involving character ranges. I mostly use y/ regexes because as I said earlier, there’s Finder. Here we go, practical examples.

Replacing dashes with underscores: rename -f 's/-/_/' *

It gets really powerful when you can work on character ranges:

rename -f 'y/a-z/A-Z/' * turns all lowercase into uppercase.
rename -f 'y/A-Z/a-z/' * turns all uppercase into lowercase

More real-world examples.

Turn filenames into URL-friendly "slugs" 🐌:
rename 'y/A-Z /a-z-/' *

Remove the last 𝒙 characters in a filename and replace them:
rename 's/.{𝒙}$/replacement/' *

In my case, Notion's Markdown export adds 34 random characters to every exported file. That's how I get rid of them:
rename 's/.{36}$/.md/' *.md

As usual, install it with Homebrew or apt-get: brew install rename or apt-get install rename.

Show your files and folders with `tree`

Alvin Bryan — Fri, 23 Oct 2020 12:48:22 +0000

The tree command is an easy way to print files and folder structures. Like you see in a lot of tutorials.

Running it without arguments will print your files and folders.

~/code-like-the-90s ❯❯❯ tree
.
├── css
│ └── main.css
├── img
│ └── bkg.png
├── index.html
└── script.js

2 directories, 4 files

Ignoring

You can tell it to ignore directories with tree -I [DirectoryName]. In most web scenarios, you’ll want to ignore your npm packages, so tree -I node_modules.

You can exclude more than one folder by separating them with a pipe character.

tree -I 'node_modules|.cache|test_*|public'

This is a must to ignore cache folders, build directories, etc.

Restricting output

The -d flag restricts it to only show your folders and hide files.

~/c/nextjs-app ❯❯❯ tree -d
.
├── pages
│ └── api
├── public
└── styles

4 directories

The -P flag allows you to only show a certain type of files. For example, if you want to list your JavaScript files while ignoring npm packages.

~/my-app ❯❯❯ tree -P '*.js' -I 'node_modules'
.
├── public
└── src
    ├── App.js
    ├── App.test.js
    ├── index.js
    ├── serviceWorker.js
    └── setupTests.js

2 directories, 5 files

Finally, you can restrict how deep in the folder structure you want to crawl using the -L flag. tree -L 2 will only go 2 levels deep.

As usual, install it with Homebrew or apt-get: brew install tree or apt-get install tree

There you go! I’ve used this command quite a lot to create documentation or get a sense of a new codebase. I hope it will be useful for you too.

Cheers

Nifty command lines: series intro

Alvin Bryan — Fri, 23 Oct 2020 12:45:36 +0000

I remember when scary terminals became required for web programmers. No more double-clicking index.html. You had to, gasp, run a command to work on your website. Who said they miss FTP? Not me…

I discovered later that the dreaded terminal could do operations that I used random websites for. For instance: Convert a font, a video, etc. While websites work, they can break, start showing NSFW ads, or stop being maintained.

Command-line interfaces have been around for years (if not decades) without ever changing. Also, it’s easier to remember a command than a bookmark.

Housekeeping

I recommend using Homebrew to install your command line tools. It works on macOS, Linux, and Windows using WSL2.

Personal website case study

Alvin Bryan — Thu, 15 Oct 2020 10:51:43 +0000

I recently launched my personal website. It took a while and was a slog at times, but I learnt a lot along the way. It feels very "me" now.

The launch day went beyond my expectations. I got lucky that Josh Comeau liked it enough to tweet about it. The numbers were nice, but the most important aspect was the response: People were impressed and genuinely liked it.

Hopefully folks here will be interested in what's going on under the hood.

Requirements
WebGL
Gatsby wish list

Disclaimer: For brevity’s sake I’m assuming a fair bit of prior knowledge. If you would like to learn more about something mentioned here, let me know on Twitter or here directly.

Requirements

Minimal tech lock-in
High lighthouse score (95, at least)
Try to reduce bundle size as much as possible
The reading experience works without JavaScript

Minimal tech lock-in

I don’t want my site to rely on a specific technology too much. I don’t use CSS-in-JS, I hardly use React hooks or component methods, and favour implicit declarations over “Gatsby magic.” Everything should be easy to reproduce with another generator.

I feel like I made the right choice with Gatsby, and it boils down to two time-saving elements: plugins and built-ins.

Do you want a dark mode? Here’s gatsby-plugin-dark-mode. Crazy WebGL graphics with glslify? You’ve got gatsby-plugin-glslify. An RSS feed? Yep. Gatsby even optimises my images, and adds aria-current to active links.

On the Markdown side of the house, I dearly missed Jekyll’s fantastic defaults, but again: Plugins! Remark (the markdown processor) has itself a thriving ecosystem. I got footnotes, custom expanding blocks and table of contents by adding the corresponding plugins.
You can see examples on the original post.

I’m also pleased that I didn’t have to fiddle with Gatsby internals too much.

High Lighthouse score

This is for the homepage that has a WebGL sketch using post-processing.

Reduce Bundle size

Throughout the development process of this site I was ruthless when it comes to dependency sizes:

I run every dependency through package-size to make sure there isn’t a smaller alternative, and including it is weighed against its cost.
The fonts are compressed as Woff2 files and self-hosted.
Preact is used to make the Gatsby runtime 30% smaller.

WebGL sites tend to have needlessly large bundle sizes, here’s my answer to that.

WebGL

This site was another excuse to experiment with 3D graphics, shaders and WebGL. Three.js was ruled out from the start because of the ~~ridiculously~~ large JavaScript size. I tried to strip most features out of Babylon.Js but the bundle was still too big. I ended up using Regl 👑 which is way more lightweight but more low-level, (you have to write GLSL). It’s battle-tested, has been stable for years, and isn’t changing any time soon. Fun fact: Mikola, the creator of Regl, even moved off-the-grid to a lava field at one point and no problem happened with the library.

I’m keeping an eye on OGL which is an even smaller WebGL library and even gives us a scene graph out-of-the-box, but the API isn’t final yet.

Here’s how they compare (minified size):

632.33 KB – Three.js v0.120.1
110.85 KB – Regl v1.6.1
98.39 KB – OGL v0.0.60

Picking Regl over Three.js saves us 500kb, more than a five-fold decrease in bundle size. Performance was also paramount. My goal was a smooth 60fps experience on my old budget Android.

Thanks to Gatsby’s code-splitting, the WebGL library is only included in the homepage.

Homepage sketch

First, I wanted to create a fractal. They have always fascinated me, whether in code or in nature. There are a lot of fractals to choose from in 2D, but in 3D they’re kind of hard. The only one that I could wrap my head around quickly was the Menger sponge.

The 1st homepage sketch: 160 000 cubes forming a Menger sponge fractal

After adding a bit of instancing magic, there it was. 60fps and all, except boring to look at. I tucked that code away and turned my attention to another piece of Math & Magic that I had wanted to play with: attractors.

The 2nd homepage sketch: Cubes along a Nosé-Hoover attractor

Despite running at 60fps it “felt” sluggish and became boring to look at.

The final attempt at ~~shoehorning~~ adding 3D graphics to this is what you can see on the homepage now.

Gatsby wish list

As with most things in development, there were a few surprises along the way, so here’s my wish list for the Gatsby team:

Become evergreen by default

I wish Gatsby’s relationship with older browsers was an “opt-in” one as opposed to “opt-out.” I prefer a lean website out of the box, with features like Webp enabled and polyfills removed by default. I would rather add backwards compatibility if necessary.

Disparity in plugin quality

Gatsby makes it easy to find plugins, and to know which ones are maintained by the core team. Despite this, there is a huge variance in the quality of the non-official plugins. I wish more things were parsed out of the plugin repository (like the number of open issues without a response) as some are still referenced despite deal-breaker issues.

Telemetry

That should absolutely be disabled by default from the stable release.

I understand the idea, but knowing that a seemingly innocuous CLI might transmit data when I’m not explicitly asking it to is scary, and sets a dangerous precedent. The logs may be “anonymised” but doing this is extremely hard and a waste of time.

If it’s not disabled by default, then “How to opt-out of telemetry” should at the very least be part of the kick-start tutorial (like VSCode does) and not buried in the documentation. I would even argue that the CLI should ask for again permission every once in a while.

Final words

On top of everything mentioned above, I wrote scripts, GraphQL queries, and learned about CSS grids, Exif data, and more. I feel like I’ve come out of it as a better coder.