Posts on Dennis Strtizke

Hetzner Request Limits

Tue, 30 Dec 2025 11:51:26 +0100

Maybe don’t run watch -n 0.5 hcloud server list to interactively monitor the status of your Hetzner servers…

I still recommend that technique for commands where you are not rate limited. Especially, when working with Kubernetes a simple watch -n 0.5 kubectl get pod will make a huge difference for visibility!

We don't share infrastructure code

Thu, 27 Nov 2025 10:10:44 +0100

At my software development company Kition Software, we don’t share infrastructure code with our clients. For a long time I thought of it as our secret sauce, which has to be protected. But I came to realise that chefs of famous restaurants share their recipes all the time and are still famous. So maybe my assumptions were wrong.

We typically build web software for clients who are the ultimate owner of the code produced. We, on the other hand, own and run the infrastructure through a managed service contract to ensure smooth operation. Therefore, we own all things related to infrastructure and maintenance, like Kubernetes Manifests and the actual operations and maintenance procedures.

I just recently understood the deeper reason I am against sharing our infrastructure code. Sharing the infrastructure code would be equivalent to the chef sharing how to run the restaurant itself. Even if you tried to replicate it by the letter, you wouldn’t be able to. Your premises have a different layout, you have different staff, and you are not that chef. Your restaurant would be different.

Also, you don’t want to run a restaurant… You want to eat a great meal!

So, I am against sharing infrastructure code, because we are running a chain of restaurants, whereas you just want to replicate cooking the meal for yourself. Even if you are highly capable of replicating the setup, you wouldn’t want to. You want to have a simple straightforward setup, to run your single application. That’s a lot different from our multi-application setup and processes.

That’s why we provide you with Dockerfiles, a Docker Compose stack, and the outline of basic maintenance tasks—everything you need for your kitchen.

You are able to know host keys before connecting?

Wed, 26 Nov 2025 18:12:51 +0100

How often in your tech career have you just said yes when being confronted with the following prompt?

$ ssh 115.166.58.26
The authenticity of host '115.166.58.26 (6c22:3021:deb3:e62f::1)' can't be established.
ED25519 key fingerprint is SHA256:Bm5pigTo5Xk2vJs4ecRw0Bt7mREt8zWjOScqFO+xAfw.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])?

If you are anything like most developers, you probably thought many times. I also did that. A LOT. But begrudgingly…

I knew of the risks, but most of the time the tools to verify host keys properly were just not available to me. Let me share a solution, I am using since quite a while to solve this conundrum.

Set host keys via `cloud-init`

Basically all cloud provider support cloud-init through which we can provide information during creation of a VM. I have used the following on Digital Ocean and Hetzner via Debian, Ubuntu and Fedora. Most providers and operating systems should have support, though.

Create the host key via

ssh-keygen -t ed25519 -C "our-production-host" -P "" -f key

Create the cloud-config.yaml via

cat > cloud-config.yaml <<EOF
#cloud-config
ssh_keys:
    ed25519_private: "$(awk '{printf "%s\\n", $0}' key)"
    ed25519_public: "$(awk '{printf "%s", $0}' key.pub)"

ssh_deletekeys: false
EOF

which produces something like

#cloud-config
ssh_keys:
    ed25519_private: "-----BEGIN OPENSSH PRIVATE KEY-----\n ... \n-----END OPENSSH PRIVATE KEY-----\n"
    ed25519_public: "ssh-ed25519 AAAA...6e70 our-production-host"

ssh_deletekeys: false

Now you are able to know the SSH key beforehand!

# in OpenSSH format
$ ssh-keygen -yf key
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIKiS7+VfuTVytSmgG2cmJPup4KhQxZ5InNTCraWeow4Z

# ... or as a fingerprint
$ ssh-keygen -lf key
256 SHA256:phjJalhzT4myMIpK9MqXNnnfE8mR/zeFeb4SyRckBY8 (ED25519)

We are even able to spare the manual verification step, if we add the key into our known_hosts file before connecting.

echo "23.192.228.84 $(ssh-keygen -yf key)" >> ~/.ssh/known_hosts

May your SSH connections be truly yours.

Conditional Redaction in Django Templates

Thu, 16 Oct 2025 12:39:31 +0200

Today I needed to redact names of users and some other sensitive strings from a significant part of a Django application. After starting to litter template code with {% if allow_unredacted %}...{% else %}...{% endif %} statements, I came to my senses and implemented a Custom Django Template Tag. That tag automatically redacts content based on the request. Nothing crazy, maybe it inspires you to implement something similar?

The Starting Point

There were many templates along the lines of

Some action by <span class="fw-semibold">{{ event.actor|user_display_name }}</span>.
Dataset delivered from <span>{{ dataset.supplier.name }}</span>.

To be safe I wanted the values to be hidden by default and only reveal them, if

the actor is the authenticated user or
the user has other groups than the one named Consultant.

The Redaction Approach

I wanted to redact the text by rendering a replacement string and apply the .redacted CSS class.

.redacted {
    filter: blur(8px);
    user-select: none;
    pointer-events: none;
}

That results in the following HTML, which renders as a blurred bar. Sneaky people using the DOM inspector to look up the value are left in the dark, too.

Some action by <span class="fw-semibold redacted">Nope&nbsp;Joe</span>.
Dataset delivered from <span class="redacted">Nope&nbsp;Joe</span>.

The Template Tag

Migrating the code to a custom template tag allowed me to uniformly redact users and arbitrary strings based on the current request and business requirements. First I made sure that we actually have access a request available to prevent any undefined behaviour later.

Continuing the flow, I am checking the users group membership and override the permission, if we get a user instance, which actually is the user themself. As a small bonus I was able to apply the user_display_name within the tag, which again spared some repetition in the templates.

Most importantly: based on the permission check, I replaced the value to some dummy string and added the .redacted CSS class.

from typing import Union

from django import template
from django.contrib.auth.models import User
from django.utils.html import format_html
from django_backoffice.templatetags.backoffice_tags import user_display_name
from thetool.groups.group_consultant import GroupConsultant

register = template.Library()


@register.simple_tag(takes_context=True)
def conditionally_redacted(context, value: Union[str, User], *css_classes):
    request = context.get("request")
    if not request:
        raise Exception(
            "Pass a request to all templates containing the conditionally_redacted template tag"
        )

    allow_unredacted = not (GroupConsultant.is_only_group(request) or request.thetool_groups == [])
    if isinstance(value, User):
        allow_unredacted = allow_unredacted or value == request.user
        value = user_display_name(value)

    if not allow_unredacted:
        css_classes += ("redacted",)
        value = "Nope&nbsp;Joe"

    return format_html(
        "<span{}>{}</span>",
        format_html(' class="{}"', " ".join(css_classes)) if css_classes else "",
        value,
    )

Using that template tag all redaction is done behind the scenes. Neat.

{% load common %}

Some action by {% conditionally_redacted event.actor "fw-semibold" %}.
Dataset delivered from {% conditionally_redacted dataset.supplier.name %}.

The Happy Dennis

I am happy about that implementation as I can easily assert its logic in unit tests and do not have to scatter the same checks over and over again through different views and templates.

Tricking Django's title Filter

Wed, 08 Oct 2025 12:51:00 +0200

Django’s title filter is often used to prettify strings in templates, for example, when rendering model verbose names in an admin or API interface. When handling abbreviations it can be a bit too eager in capitalising, though.

What happens if you apply the filter to the following API key model?

class SupplierAPIKey(AbstractAPIKey):
    ...

    class Meta:
        verbose_name = "supplier API key"
        verbose_name_plural = "supplier API keys"

It capitalises each word in the string, resulting in Supplier Api Key. Ugh… That hurts my brain.

Unicode to the rescue! The zero-width space (\u200b) acts like a regular space for text processing — but, well, has no width during rendering. By inserting it within the acronym, we can trick the title filter into keeping our uppercase characters as they are treated as individual words.

"supplier A\u200bP\u200bI key"

Be aware that these characters are still rendered and present. If you copy the following text and insert into a proper editor, which shows non-printing characters, they show up: Supplier API Key

May your strings be capitalised to your taste.

Testing Django Migrations with PostgreSQL and Foreign Keys

Wed, 01 Oct 2025 13:15:59 +0200

The incredibly helpful blogpost Writing Unit Tests for Django Migrations delivers what the title promises. Making testing of migrations.RunPython feasible and easy … as long as you don’t have to fill foreign key relations on PostgreSQL.

Following the suggested approach, you’ll create records to be migrated in the setUpBeforeMigration method.

class TestLeadSourceMigration(TestMigrations):
    migrate_from = "0056_rename_creator_leadsource_created_by_user"
    migrate_to = "0057_leadsource_channel_and_more"

    def setUpBeforeMigration(self, apps):
        Lead = apps.get_model("leadtool", "Lead")
        LeadSource = apps.get_model("leadtool", "LeadSource")

        lead = Lead.objects.create(
            identifier=1,
            first_name="Jane",
            last_name="Doe",
            email="jane.doe@example.com",
        )
        LeadSource.objects.create(lead=lead)

    def test_something(self):
        [...]

Running this test will not succeed.

django.db.utils.OperationalError: cannot ALTER TABLE "leadtool_leadsource" because it has pending trigger events

The suggested TestMigrations class is a subclass of TestCase, which executes each test method and associated lifecycle methods like setUp, and by extension setUpBeforeMigration, in a single transaction. The pending foreign key trigger events, prevent the ALTER TABLE and any other DDL of the succeeding migration to run.

We have a trivial fix though: inherit from TransactionTestCase. Now the record creation is committed to the database. Note that the database is reset to a known state by truncating all database tables instead of just rolling back a transaction, which is slower. Well worth it, though!

PS: Could we please take a moment to appreciate how well the wisdom of that 9.5 year old post held up?

Clean Django Storage Backend Configuration

Thu, 25 Sep 2025 21:30:43 +0200

TIL: You are able to pass arbitrary configuration values via the OPTIONS key to Django storage backends. They are passed as keyword arguments to the __init__ method of the storage backend.

That fact is pointed out in the Django STORAGES documentation and I apparently even used that before in kition-dev/djangodefaults… Using these OPTIONS I was able to turn

STATICFILES_STORAGE_HASH_EXCLUSIONS = [
    "css/\"images/",
]

STORAGES = {
    "staticfiles": {
        "BACKEND": "myproject.storage.SelectiveManifestStaticFilesStorage",
    },
}

… into …

STORAGES = {
    "staticfiles": {
        "BACKEND": "myproject.storage.SelectiveManifestStaticFilesStorage",
        "OPTIONS": {
            "hash_exclusions": [
                "css/\"images/",
            ],
        }
    },
}

Having got rid of that dangling configuration value loosely floating in the settings is a win for me. As a bonus, overriding the static files storage in the test settings discards the configuration options, too. Sweet.

If your custom storage backend accepts keyword arguments, put them under OPTIONS — it keeps settings cohesive and easier to override in different environments.

Dynamic Vue.js configuration

Wed, 27 Oct 2021 22:00:00 +0200

You are building a web application and want to easily swap an API endpoint URL, set API tokens or just don’t want to trigger a build pipeline for changing that one string - you need dynamic configuration.

Let’s get right to it. Here are three ways of doing dynamic configuration using Vue.js.

HTML `data-*` attributes

Utilise HTML data-attributes to pass configuration values to your Vue app.

<div id="app"
     data-some-api-key="ey.cafebabe"
     data-base-url="http://example.org"></div>

Within your main.js you are able to access these values via document.querySelector("#app").dataset.someApiKey;. All data attribute values are contained as camel cased properties of the dataset property.

From there you are able to pass these values to your main component, pass them to your Vuex store or do whatever else these values are intended for.

const dataset = document.querySelector("#app").dataset;

new Vue({
    render: h => h(App),
    store: createStore(dataset.baseUrl, dataset.someApiKey),
}).$mount('#app')

When to use this approach?

This kind of configuration is easy to understand for non-tech people. Imagine creating something like the Google tracking code: You would distribute your app by instructing people to paste the HTML snippet above, accompanied by a script tag and tell them to insert their site identifier and customer token. People like it, if they understand and do stuff by themselves!

Also, this approach is useful, if a backend templating engine is serving the HTML in which the Vue app is included. In that case you can use the configuration mechanism of your backend framework to configure the frontend application.

When running in a Docker Container, the same mechanism can be utilised through an entrypoint script that reads environment variables and inserts them in the HTML data attributes.

`config.js`

Start by creating a config file like below. Store it as public/config.js so it is not included in your Webpack build and served as a static file.

const config = (() => {
    return {
        someApiKey: "ey.cafebabe",
        baseUrl: "http://example.org"
    };
})();

Include the config through a script tag.

<!DOCTYPE html>
<html lang="">
...
<body>
    ...
    <div id="app"></div>
    <script src="<%= BASE_URL %>config.js"></script>
    <!-- built files will be auto injected -->
</body>
</html>

When reading the config values, make sure to define a default value as there is no guarantee that the config.js will be loaded in all circumstances.

let value = process.env.VUE_APP_SOME_API_KEY;
// eslint-disable-next-line no-undef
if (typeof config != "undefined") {
    // eslint-disable-next-line no-undef
    value = config.someApiKey;
}

When to use this approach?

Use this approach, if you want to provide the configuration in a file external of the application. You would be able to change the config.js on your web server, provide it via deployment tools or generate it from environment variables in a container entrypoint script.

Remote config(.js)

This one is similar to the previous case, where the config.js is distributed alongside the application. Instead of placing the file on the same web server as the application, you call an external location, where the config resides.

I am feeling almost stupid to include this approach, but there are some differences in the usage. For one, you have to be careful about security. Make sure that only trusted parties are able to change the config and no one is providing a malicious config to you. For another, you are able to use external config systems like Spring Cloud Config, Consul, etc. In these cases you would most likely process some structured data format like JSON though.

When to use this approach?

Use this approach, if you have a configuration management system in place and want to use it for the frontend application, too.

Also, this approach might prove useful, if there are some restrictions on the deployment itself. Maybe you are not able to change environment variables, the HTML or trigger a new deployment? This approach is for you.

Do you really need dynamic runtime configuration?

Before implementing the runtime configuration think twice: is the added complexity really worth the configuration need?

Can your configuration needs be dealt with via .env files? That would make things way easier. Put your development configuration values into .env your production ones in .env.production and let your build and distribution process take care of the configuration.

If this suffices, go that direction! It is straight forward, everyone knows how to find the values and everything stays predictable.

Sensible Solidity testing via Go Ethereum

Wed, 13 Oct 2021 09:00:00 +0200

You have built a smart contract, tested it via unit tests, explored it via Metamask and a block explorer and now want to deploy to the Mainnet. Didn’t you forget something?

Until now you most likely tested your Solidity code via a local network like hardhat node, ganache-cli or the Ganache UI. Those are very convenient and fast, but are not the same thing as the real network. In this post we will explore how to test your code using the “official Go implementation of the Ethereum protocol” called geth, which enables us to be much closer to the Mainnet.

I will be using Hardhat on macOS within zsh in my descriptions, but similar workflows exist for other toolchains.

Start a local network via Geth

If you are looking for a very quick local setup and are fine with having only one account available, geth --dev is a solid option. The chain does not persist, if the command is terminated.

In most cases you will need more though: multiple accounts, account locking and unlocking, mining controls, timing changes, etc. All of these are possible through geth. Follow these steps to create your geth based local network.

Install `geth`

Follow the extensive Installing geth instructions in the documentation.

Create accounts

geth handles encrypted private keys only. Within the local development environment we (oftentimes) don’t really care about key security. To handle passwords create a file named passwords containing the same password on each line. Create as many lines as you want to create accounts.

# passwords
secret
...
secret

Execute the geth account new command once for every account you need.

geth account new --datadir data --password passwords

Genesis Block configuration

Next we have to instruct geth how our chain should behave. This is done via the genesis block.

{
  "config": {
    "chainId": 15,
    "homesteadBlock": 0,
    "eip150Block": 0,
    "eip155Block": 0,
    "eip158Block": 0,
    "byzantiumBlock": 0,
    "constantinopleBlock": 0,
    "petersburgBlock": 0,
    "clique": {
      "period": 0,
      "epoch": 30000
    }
  },
  "difficulty": "1",
  "gasLimit": "8000000",
  "extradata": "0x0000000000000000000000000000000000000000000000000000000000000000<insert signer key without 0x prefix>0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000",
  "alloc": {
    "c736af4e3dd4e0b463c3cbfecc9ab84705b69d8b": { "balance": "40000000000000000000" },
    ...
    "ba4b47ee3abdc81531304bb09d45a085fb59c6ce": { "balance": "40000000000000000000" }
  }
}

Notable properties:

Use the clique consensus algorithm, which is proof-of-authority and spares us to execute proof-of-work mining. Read more on choosing a consensus algorithm in the documentation.
The extradata property needs to contain the account used to sign blocks. I recommend to use the first account as the signing account. This selection works well with most framework assumptions. Insert the signing account public key without the 0x prefix in the padded string.
Add one entry per account in the alloc property to assign an initial balance to the respective account. The value is specified in wei. (I find it very useful to execute web3.toWei(10, "ether") to convert Ether to wei, which outputs 10000000000000000000)

Initialise the network by running geth init --datadir data genesis.json.

Start the network

Execute the following command to start the private network. Replace and insert all public keys of the accounts you want to unlock in the --unlock flag. Remember that your passwords file needs to have at least as many lines has you want to unlock accounts.

geth --datadir data --nodiscover --mine --fakepow \
  --http --http.addr 0.0.0.0 --http.vhosts "*" --http.api "eth,net,web3,txpool,debug"
  --allow-insecure-unlock --password data/passwords \
  --unlock 0xc736af4e3dd4e0b463c3cbfecc9ab84705b69d8b,...

Notable properties:

The --nodiscover flag makes sure that our node doesn’t search for peers to sync
The --mine flag enables block creation on our node. In combination with the --fakepow flag we disable proof-of-work mining.
The --http.* flags enables us to (1) run geth attach via the network and (2) access the chain via a Docker based Blockscout instance.

Cleanup

In the following commands we used a directory named data as the storage location. Just remove it once you are done.

Run your test suite

Now that the local geth network is running, the actual testing is straight forward. First, within the hardhat.config.js add a new network.

module.exports = {
  ...
  networks: {
    ...
    geth: {
      url: "http://127.0.0.1:8545"
    }
  }
};

Having done that, execute your test suite via npx hardhat test --network geth. Do your tests also work on the official Go Ethereum implementation? Yes, that is great. No? Good you caught that before deploying to Mainnet.

$ npx hardhat test --network geth

  Distribution Wallet
    deployment
      ✓ should set the correct owner

  1 passing (194ms)

If you need to analyse some issues or want to dig deeper, start the Geth JavaScript console via geth attach http://127.0.0.1:8545/, which allows you to execute the web3, eth and more commands.

$ geth attach http://127.0.0.1:8545/
Welcome to the Geth JavaScript console!

instance: Geth/v1.10.8-stable/darwin-amd64/go1.16.6
coinbase: 0xc736af4e3dd4e0b463c3cbfecc9ab84705b69d8b
at block: 9 (Tue Oct 12 2021 09:53:25 GMT+0200 (CEST))
 modules: debug:1.0 eth:1.0 net:1.0 rpc:1.0 txpool:1.0 web3:1.0

To exit, press ctrl-d
> web3.toWei(10, "ether")
"10000000000000000000"
> eth.accounts
["0xc736af4e3dd4e0b463c3cbfecc9ab84705b69d8b", "0xd8508d13c889728420103d6025761dfd98f43c36", "0x1a30d4f3db1d4781daf11398b55c62001cbef590", "0x3057d5b4f3ee1a6a56965af6708736fce858bc59", "0xba4b47ee3abdc81531304bb09d45a085fb59c6ce"]
> eth.getBalance(eth.accounts[1])
45999979000000000000
> web3.fromWei(eth.getBalance(eth.accounts[1]))
45.999979

Bonus: Block Explorer

In the post Using Block Explorers with Hardhat we tried different approaches to visually explore the local network. That worked reasonably well.

As our local network is now run through geth, compatibility is of no issue anymore. Fancy some Blockscout? Follow these steps:

Make sure the geth network is running.
Clone the Blockscout repository
Change to the docker directory

Execute the Makefile, which will build Blockscout on its first execution. (This took about 15 minutes on my machine)

COIN=ETH \
ETHEREUM_JSONRPC_VARIANT=geth \
ETHEREUM_JSONRPC_HTTP_URL=http://host.docker.internal:8545 \
make start

Visit http://localhost:4000

Going forward

Looking at this post, I am quite surprised how lengthy it got. Maybe it is time to implement a script geth-dev that provides the start, stop, cleanup and accounts commands? Maybe something to integrate this easily into Mocha based tests? Send an email to me and tell me what you think!

We wont use Ethermine Polygon Payouts

Wed, 29 Sep 2021 11:15:00 +0200

At D12S Ventures we run a small 612 MH/s Ethererum mining operation. With the rollout of EIP-1559 on 4th August 2021 Ethermine changed the payout policies for miners, where the miner has to pay the payout transaction fees. Ethermine argues that they won’t be able to cover these costs and therefore need to pass them on.

I don’t like this change, but it it necessary. Also, I support the EIP-1559 that made the payout policy change necessary in the first place. Ultimately, the Ethereum Platform will be better through it.

The change of the payout policy also brought the possibility to use Level 2 Polygon (formerly Matic) for payouts. Let’s see why we wont use them for now.

For context, find our mining strategy below:

We operate two miners, totalling 612 MH/s
Payouts happen every 0.1 ETH mined
Every 14 days we liquidate half of the mined ETH in the past 14 days to Euro.
The remaining mined ETH is kept until a preset price-threshold is reached, where we will again cash out half of the ETH.
We will keep holding some portion of ETH indefinitely.

Let us walk through the different payout options.

Ethermine Payouts before EIP-1559

Before EIP-1559 and the payout policy change we received all payouts using a 0.00002 ETH transaction fee. This is insanely low. So low in fact that it only makes 0.02% of the transaction value.

Cashing out to Euro involved a transaction to Coinbase Pro, the trading fees and a fiat wire fee (SEPA transfer). In total this did cost about 0.0005 - 0.003 ETH and dependent on the current ETH-EUR exchange rate 1.00 - 3.53€.

Ethermine Payouts via Polygon

To test drive Polygon we used Polygon payouts for one week. This is the first time for us to try the Polygon network and it seems great. Low fees in the price region where MetaMask shows 0.00€ for a transaction. Nice! Also, wallet integration and swapping is easy.

BUT, remember the strategy above where we liquidate half of the profits every two weeks to Euro? How would we do this with Polygon? Search an Exchange that supports the Polygon Network. For us that’s Binance. Binance supports Polygon Network transfers for MATIC, so we swap our ETH to MATIC. Now trading the MATIC-EUR pair, we get the fiat needed for electricity, salaries etc. But getting these Euros to a bank account is only possible via Credit Card and a 1% withdrawal fee. That does not seem like a great deal…

We wont use Polygon (for Ethermine Payouts, probably never)

Right now Polygon payouts are more tedious for us than Mainnet payouts. We have to do an additional token swap and face a fiat payout fee. This brings the total cost of the payouts to the same level as the ones based on the Mainnet.

Also, we would be holding ETH on Polygon and not on the Mainnet. Considering that the transfer to the Mainnet requires a lot of Gas - as it is a smart contract transaction - and takes 7 days, I don’t now, if we every going to switch to Polygon.

Foundation – Building in Public

Wed, 22 Sep 2021 11:45:00 +0200

building

I am building software since 2006. 10 years of that professionally. For me, creating software means solving problems and creating opportunities for real people. This is what keeps me going.

Most of what I build lives in the proprietary domain, solving specific problems for a business or product of that business. There is at least one notable exception, which serves anyone who likes to use it.

While building, I must learn. A lot.

in public

Fortunately, building software for 10 years in a multitude of roles, domains, programming languages and architectures made a lot of that work feel ‘ordinary’. Nothing worth talking and certainly not writing about. Only when speaking to other developers about my ‘ordinary work’, I realised that this work may very well be novel from other people’s eyes.

Thinking about how I acquire new skills and knowledge it is through the ‘ordinary work’ of other people. You might have guessed it: the ‘ordinary work’ of other people seems extraordinary to me.

That’s what this blog is about: sharing my ‘ordinary work’ and taking you along when learning new skills.

Join me building stuff in public!

You can expect learnings and stories about Crypto, cloud native software development, infrastructure and keeping things running in production. All from the perspective of a software developer and technical founder.

Posts on Dennis Strtizke

Hetzner Request Limits

We don't share infrastructure code

You are able to know host keys before connecting?

Set host keys via cloud-init

Conditional Redaction in Django Templates

The Starting Point

The Redaction Approach

The Template Tag

The Happy Dennis

Tricking Django's title Filter

Testing Django Migrations with PostgreSQL and Foreign Keys

Clean Django Storage Backend Configuration

Dynamic Vue.js configuration

HTML data-* attributes

When to use this approach?

config.js

When to use this approach?

Remote config(.js)

When to use this approach?

Do you really need dynamic runtime configuration?

Sensible Solidity testing via Go Ethereum

Start a local network via Geth

Install geth

Create accounts

Genesis Block configuration

Start the network

Cleanup

Run your test suite

Bonus: Block Explorer

Going forward

We wont use Ethermine Polygon Payouts

Ethermine Payouts before EIP-1559

Ethermine Payouts via Polygon

We wont use Polygon (for Ethermine Payouts, probably never)

Foundation – Building in Public

building

in public

Set host keys via `cloud-init`

HTML `data-*` attributes

`config.js`

Install `geth`