Except you still can.

During setup you’re presented with “Register your fire” screen, and “Continue” button, and no way to bypass it. Follow these steps:

1. Tap “New to Amazon? Start here” link.
2. “Choose Country or Region” screen appears – select any country
3. “Create an Amazon Account” screen appears. Instead of entering name, email, and password just tap “Close” button

You’re back in the original “Register your fire” screen, but now in addition to “Continue” button you will see “Not now” that lets you skip the registration.

Now you’re free to install an appstore of your choice e.g. F-Droid or Google Play Store and use it as a regular Android tablet.

"I am a Trekkie because Star Trek isn't woke"

Star Trek:

[image or embed]

— Comfortably Numb (@ygalanter.bsky.social) Jan 4, 2024 at 6:40 PM

October 29, 2023: FiveThirtyEight became self-aware.

[image or embed]

— Comfortably Numb (@ygalanter.bsky.social) Oct 29, 2023 at 12:48 PM

So Musk removed news headlines from Twitter across all devices, Web and mobile. Ok then.

[image or embed]

— Comfortably Numb (@ygalanter.bsky.social) Oct 5, 2023 at 5:40 AM

These people are so close

[image or embed]

— Comfortably Numb (@ygalanter.bsky.social) Dec 29, 2023 at 5:25 PM

[image or embed]

— Comfortably Numb (@ygalanter.bsky.social) Nov 10, 2023 at 6:52 PM

ACAB includes fortune cookies

[image or embed]

— Comfortably Numb (@ygalanter.bsky.social) Feb 20, 2024 at 8:03 PM

Every now and then I wonder why I don't use Mastodon anymore, but then remember this experience, ah that's why. bsky.app/profile/ygal…

[image or embed]

— Comfortably Numb (@ygalanter.bsky.social) Feb 13, 2024 at 7:29 PM

I was able to change it back by updating git index

git update-index --chmod=+x script.sh

But I couldn’t commit this change, because as far as git was concerned nothing in the file changed. But I was able to force-add the change

git add --chmod=+x -- script.sh

After that I was able to commit and push the change.

A developer wrote a simple Lambda function in TypeScript that would receive a parameter of the following type:

interface Notification {
    slack?: {
        notify: boolean
    };
    github?: {
        notify: boolean
    };
}

The logic is simple – if slack.notify is true – send slack notification. If github.notify is true – send github commit status notification. The function deployed without issues, and it does send slack notifications. There is one problem: often it would send the same slack notification 3 times in a row.
What could be the reason? Let’s take a look at actual function. It goes something like this:

function notify(notification: any) {
 
    if (notification.slack.notify) {
        // ...
    }
 
    if (notification.github.notify) {
        // ...
    }
}

Notice anything wrong with it? Yes, that’s right – the type of the parameter is defined as any, which means no type checks is being done by TypeScript. Now, as you notice both slack and github properties are optional. What will happen if the function receives value like

{
   slack: {
      notify: true
   }
}

The first if condition is satisfied, and the function sends slack notification. But the second one will throw an exception

Cannot read property "notify" of undefined

because github property is not present in this value. Function throws the exception, and Lambda invocation fails. By default a failed Lambda re-tries invocation 2 times. So the slack notification will be send 2 more times. Mystery solved.

How could this be avoided? By defining function parameter as strongly typed. If you do so – TypeScript won’t let you compile the code as is. Moreover in IDEs like VS Code you will get visual representation of the error:

The only way TypeScript will let this thru if you specify properties as optional

function notify(notification: Notification) {
 
    if (notification.slack?.notify) {
        // ...
    }
 
    if (notification.github?.notify) {
        // ...
    }
}

With this version, in the above scenario if github property isn’t there – it won’t even bother to check for .notify value, the second if condition will fail before that.

Moral of this story: Let TypeScript do its thing, the types are there for a reason, and often the reason is to prevent you from shooting yourself in the foot.

In order to produce synthesized templates from stacks you have to have a full-blown CDK application. But what if you’re developing a standalone CDK construct as a library, to be used as a dependency in a CDK app? There is a way to scan it for vulnerabilities as well.

aws-cdk-lib/assertions module’s intended use is to write unit tests for CDK applications, and one of its features we can use is programmatically generate a CloudFormation template from a stack via Template.fromStack() method.

Take a look at the following code

import { MyCoolConstruct } from '../src/index';
import { Stack } from 'aws-cdk-lib';
import { Template } from 'aws-cdk-lib/assertions';
import * as fs from 'fs';
 
let stack = new Stack();
new MyCoolConstruct(stack, 'MyCoolConstruct');
 
let template = JSON.stringify(Template.fromStack(stack));
fs.writeFileSync('my-cool-construct.json', template);

Lines 01-04 import your construct code
Lines 06-07 create an empty stack and instantiate yout construct in it
Lines 09-10 create a CloudFormation template and save it as a file.

Now you can run this code to generate the template, and scan the resulting template with checkov

npx ts-node -- get-templates.ts
checkov -f my-cool-construct.json

Let’s say we have a class that defines a generic starship, and what happens to it when it’s hit by a weapon:

type Hit = 'phaser' | 'antimatter spread' | 'photon torpedo'
 
class Starship {
    private totalDamage: number;
 
    constructor(private shipName: string) {
        this.totalDamage = 0;
    }
 
    private addDamage(damage: number) {
        this.totalDamage += damage;
    }
 
    public isHitBy(hit: Hit) {
        console.log(`${this.shipName} is hit by ${hit}!`)
 
        switch(hit) {
            case 'phaser':
                this.addDamage(100);
                break;
            case 'antimatter spread':
                this.addDamage(300);
                break;
            case 'photon torpedo':
                this.addDamage(500);
                break
        }
    }
}

You can create your own class of starship based on this generic class, then build a ship of the new class, and simulate it being hit by a weapon:

class Galaxy extends Starship {
    constructor(name: string) {
        super(name);
    }
}
 
const enterprise = new Galaxy('Enterprise');
enterprise.isHitBy('photon torpedo');

Output:

"Enterprise is hit by photon torpedo!"

This is fine, but as you’ve seen the base class has a secret feature to calculate damage inflicted by the weapon. It is secret, because it’s defined by a private method, and is not exposed to derived classes. But, like Kirk in Kobayashi Maru, you want to break the rules, and have this forbidden knowledge.

If you attempt to add method override in a regular way:

class Galaxy extends Starship {
    constructor(name: string) {
        super(name);
    }
  
    addDamage(damage: number) {
        super.addDamage(damage);
        console.log(`The damage is: ${damage}`)
    }
}

You will be greeted with error message

Property 'addDamage' is private in type 'Starship' but not in type 'Galaxy'.

If you try to change your version of the method to private – TypeScript will complain again:

Types have separate declarations of a private property 'addDamage'.

In order to bypass TypeScript restrictions you can use square bracket notation instead of the dot:

class Galaxy extends Starship {
    constructor(name: string) {
        super(name);
 
        this['addDamage'] = (damage: number) => {
            super['addDamage'](damage);
            console.log(`The damage is: ${damage}`)
        }
    }
}

Now let’s try instantiate the subclass, and try hit it again:

const enterprise = new Galaxy('Enterprise');
enterprise.isHitBy('photon torpedo');

Now the output includes the info from our rule-breaking override:

"Enterprise is hit by photon torpedo!"
"The damage is: 500"

Once again, not to sound like a broken record, but use this approach only if you have to (e.g. if you’re subclassing a class from a library you have no control over, but absolutely need the access to its inner workings).

Let’s say you have a JavaScript code that performs some AWS SDK/CDK actions, and it requires AWS account IDs – for dev and prod deployment. In a regular repo you would define config.js something like this:

const awsAccounts = {
   dev: '1234567890',
   prod: '0987654321'
}

But if we’re building a template repo – we don’t want to hardcode those values. Instead we could use tmplr placeholder variables:

const awsAccounts = {
   dev: '{{ tmplr.dev_account_id }}',
   prod: '{{ tmplr.prod_account_id }}'
}

Save this file as config.tmplr.js – it becomes our template. A user of your template then can create a tmplr recipe:

steps:
  - read: dev_account_id
    eval: '1234567890'
  - read: prod_account_id
    eval: '0987654321'
  - copy: config.tmplr.js
    to: config.js

then save this it into .tmplr.yml file into repo root, and run tmplr cli command – it will create config.js file from config.tmplr.js substituting variables for values from the recipe.

It works great, but there is a problem.

If you’re actively developing the template – live code file (in our case config.js) that your template is based on will be changing – code will be added/removed/refactored. This means that the config.tmplr.js template will become outdated, will be out of sync with config.js. We need a way to update our template with the latest code. Luckily there is a way to automate this, so you don’t have to manually copy pieces of code from the live file to the template.

Basically we need an opposite of what tmplr does – take the file that has literal values, replace them with placeholder variables, and save it as a template. As far as I know as of the time of this post tmplr doesn’t have this capability, so I put together a small JavaScript helper (you will need to install one dependency 'js-yaml' to handle YAML files):

const yaml = require('js-yaml');
const fs = require('fs');
 
const tmplr = yaml.load(
      fs.readFileSync(`.tmplr.yml`, 'utf-8')).steps;
const files = tmplr.filter((step) => 'copy' in step);
const variables = tmplr.filter((step) => 'read' in step);
 
for (let file of files) {
  let fileContent = fs.readFileSync(file.to, 'utf-8');
 
  for (let variable of variables) {
    fileContent =
      fileContent.replaceAll(variable.eval, 
         `{{ tmplr.${variable.read} }}`);
  }
 
  fs.writeFileSync(
       file.copy, fileContent, { encoding: 'utf8', flag: 'w' });
  console.log(` Templated: "${file.to}" -> "${file.copy}"`);
}

This code uses the same .tmplr.yml file we created earlier for tmplr (Lines 04-07 read and parse the YAML file, and extract variable/value, copy_from/copy_to pairs from it). It then loops thru the files, loading live code file in every iteration (Lines 09-10). For each file it loops thru variables/values, and if it finds literal value – replaces it with placeholder variable (Lines 12-16). And finally it writes resulting template into template file (Lines 18-19)

You can run this script manually, or – if you’re using VS Code using Run On Save extension, or even in a GitHub workflow on push of a changed file. In any case your template files will be always in sync with your code files.

Let’s say you have following stack declarations in your lib/my-stacks.ts code:

import * as cdk from 'aws-cdk-lib';
 
export class Stack1 extends cdk.Stack {};
export class Stack2 extends cdk.Stack {};
export class AnotherStack extends cdk.Stack {};
export class YerAnotherStack extends cdk.Stack {};

And in your app’s entry point bin/my-stacks.ts you instantiate those stacks:

import * as cdk from 'aws-cdk-lib';
import * as stacks from '../lib/my-stacks'
 
const app = new cdk.App();
 
new stacks.Stack1(app, "Stack1");
new stacks.Stack2(app, "Stack2");
new stacks.AnotherStack(app, "AnotherStack");
new stacks.YerAnotherStack(app, "YetAnotherStack");

And then issue a CLI command to synthesize stacks, but you only want to synthesize “Stack1” and “AnotherStack”:

cdk synth Stack1 AnotherStack

The command output would have you believe that only 2 stacks were synthesized:

Successfully synthesized to ./cdk.out
Supply a stack id (AnotherStack, Stack1) to display its template.

But if you actually look into cdk.out folder – you will see all stack templates were synthesized:

AnotherStack.assets.json        Stack2.assets.json
AnotherStack.template.json      Stack2.template.json
Stack1.assets.json              YetAnotherStack.assets.json
Stack1.template.json            YetAnotherStack.template.json

CDK will synthesize templates for all stacks you instantiate no matter what stack names you pass – the names will only be used to filter the results. In order to synthesize only the stacks you request – only classes for the stacks you request must be instantiated. We can pass the stack names to a CDK command using context via option --context or its shorter form -c:

cdk synth -c stacks=Stack1,AnotherStack

And this is how we can interpret this in our entry point code:

import * as cdk from 'aws-cdk-lib';
import * as stacks from '../lib/my-stacks'
 
const app = new cdk.App();
const myStacks: string = app.node.tryGetContext('stacks');
 
Object.entries(stacks).forEach(([stackName, stack]) => {
  if (!myStacks || myStacks.split(',').includes(stackName)) {
    new stack(app, stackName)
  }
})

Here on Line 05 we read the context parameter we passed in the command line. And on Lines 07-11 we loop thru imported stacks. If stack name matches one of the names we passed as a parameter – only then it will be instantiated. If the -c stacks parameter isn’t passed – the value will be undefined – and all stacks will be instantiated and therefore synthesized.

Now, if you issue the command (don’t forget to clear previous content of cdk.out):

cdk synth -c stacks=Stack1,AnotherStack

The output will be the same as before:

Successfully synthesized to ./cdk.out
Supply a stack id (AnotherStack, Stack1) to display its template.

But if you look into cdk.out directory – you will only see requested stacks synthesized:

]AnotherStack.assets.json
AnotherStack.template.json
Stack1.assets.json
Stack1.template.json

Unfortunately if you run a Bitnami instance of WordPress (for example one provided by AWS LightSail with LetsEncrypt service providing a TLS certificate for you site – you may encounter an incompatibility issue. LetsEncrypt uses /.well-known/acme-challenge path on your site for certificate validation, but ActivityPub plugin uses /.well-known/webfinger path to return relevant profile information. It conflicts with LetsEncrypt and the WebFinger path returns “404 – not found”.

Fortunately there is an easy fix.

SSH to your server, locate file /opt/bitnami/apps/letsencrypt/conf/httpd-app.conf, and add highlighted lines to it:

<Directory "/opt/bitnami/apps/letsencrypt/.well-known">
    Options +MultiViews
    AllowOverride None
    <IfVersion < 2.3 >
        Order allow,deny
        Allow from all
    </IfVersion>
    <IfVersion >= 2.3>
        Require all granted
    </IfVersion>
     
    RewriteEngine On
    RewriteBase /.well-known/
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteRule ^(.*)$ /index.php?well_known_path=$1 [QSA,L]

</Directory>

After that Webfinger starts returning correct profile information, and your site can be found on the Fediverse.

aws account enable-region --region-name af-south-1

There is a caveat though – this command only begins to enable the region. The process could take a while, but the command exits right away. But what if you need do something with the region when it becomes available? Say you’re running a script and you need to bootstrap the region when its enabled. You need some way to wait for the enablement to finish. Luckily there is another AWS CLI command that lets you check the status of the region – ec2 describe-regions, e.g.

aws ec2 describe-regions --region-names af-south-1

One of the properties it return is whether the region is enabled/opted-in or not. Combining this with a little of bash magic – we can come up with a waiting routine:

aws account enable-region --region-name af-south-state=not-opted-in
until [ "$state" = "opted-in" ]
do
   echo Waiting for af-south-1...
   sleep 5
   state=$(aws ec2 describe-regions --region-names af-south-1 --query "Regions[0].OptInStatus" --output text)
done

Here on the Line 1 we execute command that initiates enabling region. And the rest is a loop: wait 5 seconds, and check the status of the region. Loop exits when the status becomes “opted-in”. At this point we know that the region has been enabled, and can proceed with using it.