`.
+
+ Indent paragraphs to include them in the footnote.
+
+ `{ my code }`
+
+ Add as many paragraphs as you like.
+
+## Code blocks
+
+Code blocks support the following annotations:
+
+- `linenos`: Display line numbers column
+- `hl_lines`: Highlight specific lines, e.g. `hl_lines=1 3-5 9`
+- `linenostart`: Start line number, e.g. `linenostart=20`
+- `hide_lines`: Hide specific lines, e.g. `hide_lines=1-2`
+
+It's placed after the language, which will look like this:
+
+````
+```rust,linenos,hl_lines=1 3-5 9
+println!("Hello, world!");
+```
+````
+
+### Examples
+
+Plain, without line numbers:
+
+```typescript
+// @ts-check
+
+/** @type {import('next').NextConfig} */
+const nextConfig = {
+ output: "export",
+ trailingSlash: true,
+ experimental: {
+ // Statically type links to prevent typos and other errors when using next/link, improving type safety when navigating between pages.
+ typedRoutes: true,
+ },
+};
+
+module.exports = nextConfig;
+```
+
+With line numbers:
+
+```typescript,linenos
+// @ts-check
+
+/** @type {import('next').NextConfig} */
+const nextConfig = {
+ output: "export",
+ trailingSlash: true,
+ experimental: {
+ // Statically type links to prevent typos and other errors when using next/link, improving type safety when navigating between pages.
+ typedRoutes: true,
+ },
+};
+
+module.exports = nextConfig;
+```
+
+With line numbers and highlighting:
+
+```typescript,linenos,hl_lines=1 3-5 9
+// @ts-check
+
+/** @type {import('next').NextConfig} */
+const nextConfig = {
+ output: "export",
+ trailingSlash: true,
+ experimental: {
+ // Statically type links to prevent typos and other errors when using next/link, improving type safety when navigating between pages.
+ typedRoutes: true,
+ },
+};
+
+module.exports = nextConfig;
+```
+
+Without line numbers but with highlighting:
+
+```typescript,hl_lines=1 3-5 9 13
+// @ts-check
+
+/** @type {import('next').NextConfig} */
+const nextConfig = {
+ output: "export",
+ trailingSlash: true,
+ experimental: {
+ // Statically type links to prevent typos and other errors when using next/link, improving type safety when navigating between pages.
+ typedRoutes: true,
+ },
+};
+
+module.exports = nextConfig;
+```
+
+## Code from files
+
+Loading code from a colocated file, and hiding specific lines:
+
+```typescript,hide_lines=1-5 10-15
+{{ load_code(path="example.ts") }}
+```
+
+## Inline code
+
+We're using [leptos_i18n](https://github.com/Baptistemontan/leptos_i18n) for localization in Leptos, which supports an API that's very close to the one we used in Next.js. We already pulled in the dependency when we updated our `Cargo.toml` file earlier, so let's get the rest of it set up.
+
+We'll create a `ui-internal/messages/` folder where our locales will live....
+
+## Images
+
+Pulling in a colocated image:
+
+{{ image(path="logo.png", alt="codethoughts logo", width=200) }}
+
+Pulling in a colocated image with caption:
+
+{{ image(path="logo.png", caption="codethoughts", width=200) }}
+
+Showing multiple images:
+
+{{ images(paths=["logo.png", "logo.png", "logo.png"], captions=["codethoughts logo 1", "logo 2"], widths=[100, 200, 100], defaultAlt="The default alt", defaultWidth=200) }}
+
+## Tables
+
+A simple table with a header, defaulting to centered alignment:
+
+| | Header 2 | Header 3 |
+|----------|----------|----------|
+| Row 1 | Row 1 | Row 1 |
+| Row 2 | Row 2 | Row 2 |
+| Row 3 | Row 3 | Row 3 |
+
+A table with different text alignment:
+
+| Longer header 1 | Longer header 2 | Longer header 3 |
+| :--- | :--: | ---: |
+| Row 1 | Row 1 | Row 1 |
+| Row 2 | Row 2 | Row 2 |
+
+A left-aligned table (uses `... ` HTML tags):
+
+
+
+| Header 1 | Header 2 | Header 3 |
+|----------|----------|----------|
+| Row 1 | Row 1 | Row 1 |
+| Row 2 | Row 2 | Row 2 |
+
+
+
+A right-aligned table (uses `... ` HTML tags):
+
+
+
+| Header 1 | Header 2 | Header 3 |
+|----------|----------|----------|
+| Row 1 | Row 1 | Row 1 |
+| Row 2 | Row 2 | Row 2 |
+
+
+
+
+A simple table without header (empty headers hidden with CSS):
+
+||||
+|----------|----------|----------|
+| Row 1 | Row 1 | Row 1 |
+| Row 2 | Row 2 | Row 2 |
+| Row 3 | Row 3 | Row 3 |
+
+This is a clever little trick of convoluted logic (lots of negation!) which checks:
+
+- If there's a `thead` element
+- That do **not** have `th` elements
+- That are **not** empty
+- Then hide it
+
+```css
+thead:not(thead:has(th:not(:empty))) {
+ display: none;
+}
+```
+
+## Quotes
+
+A single line quote:
+
+> This is a blockquote with two paragraphs. Lorem ipsum dolor sit amet.
+
+And a multi-line quote:
+
+> This is a blockquote with two paragraphs. Lorem ipsum dolor sit amet.
+>
+> And it can span multiple lines...
+
+## Callouts
+
+A callout:
+
+{% aside() %}
+ This is meant to be a tip or `call` out some [additonal info](#).
+{% end %}
diff --git a/content/drafts/component-overview/logo.png b/content/drafts/component-overview/logo.png
new file mode 100644
index 0000000..a29a6ae
Binary files /dev/null and b/content/drafts/component-overview/logo.png differ
diff --git a/posts/2023-10-16-the-stack-part-3.md b/content/importable-posts/2023-10-16-the-stack-part-3.md
similarity index 98%
rename from posts/2023-10-16-the-stack-part-3.md
rename to content/importable-posts/2023-10-16-the-stack-part-3.md
index 430cfd3..a392cf3 100644
--- a/posts/2023-10-16-the-stack-part-3.md
+++ b/content/importable-posts/2023-10-16-the-stack-part-3.md
@@ -1,8 +1,10 @@
----
-title: "The Stack Part 3: Building a Frontend"
-tags: rust, typescript, wasm, nextjs, leptos, aws, cloud, infrastructure, cdk, ci
-date: 2023-10-16
----
++++
+title = "The Stack Part 3: Building a Frontend"
+date = 2023-10-16
+in_search_index = false
+[taxonomies]
+tags = ["rust", "typescript", "wasm", "nextjs", "leptos", "aws", "cloud", "infrastructure", "cdk", "ci"]
++++
In [the last post](/posts/2023-10-07-the-stack-part-2.html) we set up our deployment, fully automated on merge to our `main` branch. In this post we will be building our UI (Frontend) applications. See the full overview of posts [here](/posts/2023-01-29-the-stack.html#what-will-we-be-covering).
@@ -16,24 +18,9 @@ We are essentially hedging our bets by building both a JavaScript-based Frontend
There is quite a lot to cover. My recommendation is to clone down the Part 3 branch in the [GitHub repository](https://github.com/codetalkio/the-stack/tree/part-3-frontend) and use this post as an explanation of what is set up.
-
-
-- [Prelude: Static Site Generation](#prelude-static-site-generation)
-- [Next.js](#next.js)
- - [Setting up our Next.js App](#setting-up-our-next.js-app)
- - [Building Static Files](#building-static-files)
- - [Setting up Localization](#setting-up-localization)
-- [Leptos (Rust/WASM)](#leptos-rustwasm)
- - [Setting up our Leptos App](#setting-up-our-leptos-app)
- - [Setting up Tailwind CSS](#setting-up-tailwind-css)
- - [Setting up Localization](#setting-up-localization-1)
-- [Bonus: End-to-End Tests](#bonus-end-to-end-tests)
-- [Bonus: DevEx Improvements](#bonus-devex-improvements)
-- [Automating Deployments via CDK](#automating-deployments-via-cdk)
- - [Building artifacts in CI](#building-artifacts-in-ci)
- - [Deploying to S3 + CloudFront](#deploying-to-s3-cloudfront)
-- [Next Steps](#next-steps)
+
+{{ toc() }}
## Prelude: Static Site Generation
@@ -1335,6 +1322,7 @@ This means that it will fit into our `Global` stack. Cross-stack references in C
Some examples of issues/annoyances and workarounds with `Exports`: [Here](https://github.com/aws/aws-cdk/issues/17741), [here](https://chariotsolutions.com/blog/post/limiting-cross-stack-references-in-cdk/), [here](https://github.com/aws/aws-cdk/issues/5304), and [here](https://www.endoflineblog.com/cdk-tips-03-how-to-unblock-cross-stack-references).
+
Instead, we will rely on the approach outlined in this nice article from AWS on how to [Read parameters across AWS Regions with AWS CloudFormation custom resources](https://aws.amazon.com/blogs/infrastructure-and-automation/read-parameters-across-aws-regions-with-aws-cloudformation-custom-resources/).
We will essentially:
diff --git a/content/importable-posts/_index.md b/content/importable-posts/_index.md
new file mode 100644
index 0000000..f251468
--- /dev/null
+++ b/content/importable-posts/_index.md
@@ -0,0 +1,8 @@
++++
+title = "Importable Posts"
+sort_by = "date"
+template = "posts.html"
+page_template = "importable-post-page.html"
+in_search_index = false
+insert_anchor_links = "heading"
++++
diff --git a/content/pages/_index.md b/content/pages/_index.md
new file mode 100644
index 0000000..ee573c7
--- /dev/null
+++ b/content/pages/_index.md
@@ -0,0 +1,3 @@
++++
+page_template = "content-page.html"
++++
diff --git a/content/pages/about.md b/content/pages/about.md
new file mode 100644
index 0000000..f676d24
--- /dev/null
+++ b/content/pages/about.md
@@ -0,0 +1,6 @@
++++
+title = "About"
+
+[extra]
+parent = "posts/_index.md"
++++
diff --git a/content/pages/archive.md b/content/pages/archive.md
new file mode 100644
index 0000000..d892634
--- /dev/null
+++ b/content/pages/archive.md
@@ -0,0 +1,8 @@
++++
+title = "Archive"
+
+[extra]
+parent = "posts/_index.md"
++++
+
+{{ archive() }}
diff --git a/posts/2014-01-31-what-is-this-about.md b/content/posts/2014-01-31-what-is-this-about.md
similarity index 94%
rename from posts/2014-01-31-what-is-this-about.md
rename to content/posts/2014-01-31-what-is-this-about.md
index 2660fa1..5c47630 100644
--- a/posts/2014-01-31-what-is-this-about.md
+++ b/content/posts/2014-01-31-what-is-this-about.md
@@ -1,8 +1,9 @@
----
-title: What is this about?
-tags: ramblings
-date: 2014-01-31
----
++++
+title = "What is this about?"
+date = 2014-01-31
+[taxonomies]
+tags = ["ramblings"]
++++
This blog will mostly serve as a personal memory pad. I often discover a process, learn something new or just am plain forgetful. Therefore I'll try to write down various things that I learn during my journey as a programmer and enthusiast on all things technical.
@@ -10,11 +11,11 @@ With that in mind, the idea is to make the content posted here general enough so
What will be on here? Mostly things related to programming and technology. What I learn is almost always related to some hobby project I got going on.
-
+
Another thing I'll try to do is post upfront whatever version of tools or libraries I might be using throughout that post. Far too often has it bothered me that I didn't know what version an article or tutorial applied to, or had in mind, and because of that, one might be doing something that was solved in later versions of said library or tool.
-# A little background on me
+## A little background on me
_Updated on 21st of March, 2020._
diff --git a/posts/2014-02-13-deploying-with-vagrant.md b/content/posts/2014-02-13-deploying-with-vagrant.md
similarity index 92%
rename from posts/2014-02-13-deploying-with-vagrant.md
rename to content/posts/2014-02-13-deploying-with-vagrant.md
index d2f15cd..9b88aae 100644
--- a/posts/2014-02-13-deploying-with-vagrant.md
+++ b/content/posts/2014-02-13-deploying-with-vagrant.md
@@ -1,36 +1,25 @@
----
-title: Deploying with Vagrant
-tags: vagrant
-date: 2014-02-13
-versions:
-- Vagrant 1.4.3
----
++++
+title = "Deploying with Vagrant"
+date = 2014-02-13
+[taxonomies]
+tags = ["vagrant"]
+[extra]
+versions = ["Vagrant 1.4.3"]
++++
-_UPDATE: I wouldn't really recommend this approach anymore! In stead you should look into [Docker](https://www.docker.com) for containerization and [Stack](http://docs.haskellstack.org/en/stable/README/) for the Haskell side_
+_UPDATE: I wouldn't really recommend this approach anymore! Instead you should look into [Docker](https://www.docker.com) for containerization and [Stack](http://docs.haskellstack.org/en/stable/README/) for the Haskell side_
I recently started looking into ways that I could improve my current deployment workflow. Since my server doesn't have much RAM, I currently build the binaries locally in a Virtual Machine (VM from here on out) and then send them to the server using `scp`.
Although I can't do much about the server part (except buying a bigger server), I can do something about what I do locally. I set out to check what possibilities I had, and ended up looking at Vagrant.
-
+
While it doesn't cut hugely from the local part of my deployment hassles, it could at least streamline it a bit, and help remove the cabal hell that I'd sometimes run into with my current setup (having multiple applications that I deploy from the same VM).
A quick overview of the article:
-* [What is Vagrant?](#whatisvagrant)
-* [Getting started with Vagrant](#gettingstartedwithvagrant)
-* [Replicating your server](#replicatingyourserver)
-* [Rolling your own Vagrant box](#rollingyourownvagrantbox)
-* [Setting up the VM](#settingupthevm)
- * [Sudo access](#sudoaccess)
- * [Installing VirtualBox's Guest Additions](#installingvirtualboxsguestadditions)
- * [Installing packages](#installingpackages)
- * [Custom packages](#custompackages)
- * [SSH keys](#sshkeys)
-* [Exporting the VM box](#exportingthevmbox)
-* [But how do we use it?](#buthowdoweuseit)
-* [Concluding thoughts](#concludingthoughts)
+{{ toc() }}
## What is Vagrant?
Vagrant basically manages your VMs in a manner that is local to each project you use it in (although you can use it in a more general way). As standard it uses VirtualBox, but you can also use it with other providers, such as VMWare.
diff --git a/posts/2014-09-24-local-notifications-from-irssi-on-a-remote-server.md b/content/posts/2014-09-24-local-notifications-from-irssi-on-a-remote-server.md
similarity index 95%
rename from posts/2014-09-24-local-notifications-from-irssi-on-a-remote-server.md
rename to content/posts/2014-09-24-local-notifications-from-irssi-on-a-remote-server.md
index 03a7b10..eb2d1e3 100644
--- a/posts/2014-09-24-local-notifications-from-irssi-on-a-remote-server.md
+++ b/content/posts/2014-09-24-local-notifications-from-irssi-on-a-remote-server.md
@@ -1,13 +1,11 @@
----
-title: Local notifications from irssi on a remote server
-tags: irssi
-date: 2014-09-24
-versions:
-- OS X 10.9 Mavericks (should work on all, unless they change launchtl plists)
-- irssi v0.8.15
-- autossh v1.4c
-- terminal-notifier v1.6.1
----
++++
+title = "Local notifications from irssi on a remote server"
+date = 2014-09-24
+[taxonomies]
+tags = ["irssi"]
+[extra]
+versions = ["OS X 10.9 Mavericks (should work on all, unless they change launchtl plists)", "irssi v0.8.15", "autossh v1.4c", "terminal-notifier v1.6.1"]
++++
So, if you're like me and like to have your IRC client (in this instance [irssi](http://www.irssi.org)) running on a server in a `tmux` or `screen` session to never miss out on the conversation, you might feel like you're missing some of the benefits of running a local IRC client.
@@ -15,8 +13,9 @@ In particular, I was missing local notifications when someone would highlight my
So, how does one solve this problem?
-
+
+{{ toc() }}
## The setup
The final setup will look something like this,
diff --git a/posts/2014-09-25-irssi-notifications-on-ios-and-android.md b/content/posts/2014-09-25-irssi-notifications-on-ios-and-android/index.md
similarity index 90%
rename from posts/2014-09-25-irssi-notifications-on-ios-and-android.md
rename to content/posts/2014-09-25-irssi-notifications-on-ios-and-android/index.md
index 5bec5c1..8ed8fd1 100644
--- a/posts/2014-09-25-irssi-notifications-on-ios-and-android.md
+++ b/content/posts/2014-09-25-irssi-notifications-on-ios-and-android/index.md
@@ -1,15 +1,18 @@
----
-title: Irssi notifications on iOS and Android
-tags: irssi
-date: 2014-09-25
----
++++
+title = "Irssi notifications on iOS and Android"
+date = 2014-09-25
+[taxonomies]
+tags = ["irssi"]
++++
Or really anywhere that [https://pushover.net](https://pushover.net) supports.
In light of the [earlier article](/posts/2014-09-24-local-notifications-from-irssi-on-a-remote-server.html), I thought I'd might as well supercharge my IRC setup. So, now we're gonna get some notifications for our mobile devices via pushover.
-
+
+
+{{ toc() }}
## Setting up pushover
There really isn't much to do here. First, go create an account and download the app on the device you want notifications on.
@@ -17,7 +20,7 @@ There really isn't much to do here. First, go create an account and download the
Then, register a pushover application. You can do this from the dashboard, or
directly from [https://pushover.net/apps/build](https://pushover.net/apps/build). It will look something like this,
-
+{{ image(path="pushover-config.png", caption="Pushover Application Registration", width=600) }}
## Setting up the script
@@ -27,7 +30,8 @@ So, like the article mentioned before, I'm assuming you're using [irssi](http://
Create a file called something like `irssi_pushover.sh` with the contents below,
irssi_pushover.sh
-```bash
+
+```bash,linenos
#!/bin/bash
# Replace `YOUR_APP_TOKEN` and `YOUR_USER_TOKEN` with your values from pushover
diff --git a/resources/images/pushover-config.png b/content/posts/2014-09-25-irssi-notifications-on-ios-and-android/pushover-config.png
similarity index 100%
rename from resources/images/pushover-config.png
rename to content/posts/2014-09-25-irssi-notifications-on-ios-and-android/pushover-config.png
diff --git a/resources/images/S3-create-policy.png b/content/posts/2015-11-18-s3-bucket-specific-policy/S3-create-policy.png
similarity index 100%
rename from resources/images/S3-create-policy.png
rename to content/posts/2015-11-18-s3-bucket-specific-policy/S3-create-policy.png
diff --git a/resources/images/S3-edit-permissions-added.png b/content/posts/2015-11-18-s3-bucket-specific-policy/S3-edit-permissions-added.png
similarity index 100%
rename from resources/images/S3-edit-permissions-added.png
rename to content/posts/2015-11-18-s3-bucket-specific-policy/S3-edit-permissions-added.png
diff --git a/resources/images/S3-edit-permissions.png b/content/posts/2015-11-18-s3-bucket-specific-policy/S3-edit-permissions.png
similarity index 100%
rename from resources/images/S3-edit-permissions.png
rename to content/posts/2015-11-18-s3-bucket-specific-policy/S3-edit-permissions.png
diff --git a/resources/images/S3-policy-generator.png b/content/posts/2015-11-18-s3-bucket-specific-policy/S3-policy-generator.png
similarity index 100%
rename from resources/images/S3-policy-generator.png
rename to content/posts/2015-11-18-s3-bucket-specific-policy/S3-policy-generator.png
diff --git a/resources/images/S3-review-policy.png b/content/posts/2015-11-18-s3-bucket-specific-policy/S3-review-policy.png
similarity index 100%
rename from resources/images/S3-review-policy.png
rename to content/posts/2015-11-18-s3-bucket-specific-policy/S3-review-policy.png
diff --git a/posts/2015-11-18-s3-bucket-specific-policy.md b/content/posts/2015-11-18-s3-bucket-specific-policy/index.md
similarity index 63%
rename from posts/2015-11-18-s3-bucket-specific-policy.md
rename to content/posts/2015-11-18-s3-bucket-specific-policy/index.md
index c672452..e3d9870 100644
--- a/posts/2015-11-18-s3-bucket-specific-policy.md
+++ b/content/posts/2015-11-18-s3-bucket-specific-policy/index.md
@@ -1,8 +1,9 @@
----
-title: S3 bucket specific policy
-tags: aws
-date: 2015-11-18
----
++++
+title = "S3 bucket specific policy"
+date = 2015-11-18
+[taxonomies]
+tags = ["aws"]
++++
I have recently started caring a bit more about security on my AWS
applications, and to this end Identity & Access Management (IAM) users are a great way to limit access to
@@ -14,21 +15,17 @@ bucket, and for this an IAM role was created.
There are two ways to generate policies:
-* Using the policy generator
-* Manually creating a policy
+{{ toc() }}
I will generally advise to either use the generator completely or at least use
it for the basis of the policy you want to create.
-
+
## Using the policy generator
To access the generator go into IAM -> Policies -> Create Policy -> Policy Generator.
-
- 
- 
-
+{{ images(paths=["S3-create-policy.png", "S3-policy-generator.png"], captions=["S3 Create Policy", "S3 Select Policy Generator"], widths=[400, 400]) }}
You will then be able to create the policy. To do this, first set the AWS
service to `Amazon S3` and then choose the actions that you want to support.
@@ -39,11 +36,7 @@ Finally, you need to set the `ARN` of your bucket. This will be something like
`arn:aws:s3:::YourBucketName/*` to allow access to all elements in your S3
bucket named `YourBucketName`. It'll look a little something like in the left figure below.
-
- 
-
- 
- 
-
+{{ images(paths=["S3-edit-permissions.png", "S3-review-policy.png"], captions=["S3 Edit Permissions", "S3 Review Policy"], widths=[400, 400]) }}
Finally add the statement, and you can click next which should present you
with something like the right image above.
@@ -59,8 +52,8 @@ You can either use the generator as a basis for this document or craft your
own. The following is the one generated from the policy generator which can be
directly used here.
-
- 
-S3 bucket policy
-```javascript
+
+```javascript,linenos
{
"Version": "2012-10-17",
"Statement": [
diff --git a/posts/2015-11-18-setting-up-unrealircd-and-anope-on-ec2.md b/content/posts/2015-11-18-setting-up-unrealircd-and-anope-on-ec2.md
similarity index 91%
rename from posts/2015-11-18-setting-up-unrealircd-and-anope-on-ec2.md
rename to content/posts/2015-11-18-setting-up-unrealircd-and-anope-on-ec2.md
index ad5831b..cff607e 100644
--- a/posts/2015-11-18-setting-up-unrealircd-and-anope-on-ec2.md
+++ b/content/posts/2015-11-18-setting-up-unrealircd-and-anope-on-ec2.md
@@ -1,11 +1,11 @@
----
-title: Setting up UnrealIRCd and Anope IRC Services on EC2
-tags: irc, aws, unrealircd, anope
-date: 2015-11-18
-versions:
-- UnrealIRCd 4.0.0-rc3
-- Anope 2.0.2
----
++++
+title = "Setting up UnrealIRCd and Anope IRC Services on EC2"
+date = 2015-11-18
+[taxonomies]
+tags = ["irc", "aws", "unrealircd", "anope"]
+[extra]
+versions = ["UnrealIRCd 4.0.0-rc3", "Anope 2.0.2"]
++++
Having recently discovered sameroom.io I wanted to update the codetalk IRC server to be compliant with their
authentication method. This basically just meant enabling `SASL` support, but
@@ -15,21 +15,15 @@ set up on AWS using `EC2` and `S3`.
This will go through the process of doing exactly that, by talking about:
-* enabling SASL support
-* installing `UnrealIRCd`
-* installing `Anope`
-* a little about automating the launch of the `EC2` instance that the IRC server will run on, using the `user-data` field as input for a setup
-script.
-* all the important files gathered in a github repo
+
-
+{{ toc() }}
If you just want to throw yourself in the deep end, you can fork/clone the github
repository, alter the configuration and script variables to fit your need and
quickly be on with it. I recommend though that you skim through most of this to
get an overview of what is happening.
-
## SASL support
SASL (Simple Authentication and Security Layer) is a framework for
authentication and data security. For all intents and purposes we won't bother
@@ -48,8 +42,8 @@ a block for Anope.
__UnrealIRCd__: The following links the Anope services to the IRC server and sets the
SASL server to the services server.
-services.conf
-```bash
+```bash,linenos
+/* FILE: services.conf */
link services.myircserver.org {
incoming {
mask *;
@@ -77,8 +71,8 @@ set {
__Anope__: Enabling SASL is fairly simple, and just requires that the module is
loaded. The rest is handled by Anope.
-modules.conf
-```bash
+```bash,linenos
+/* FILE: modules.conf */
/* Load the SASL module m_sasl */
module { name = "m_sasl" }
```
@@ -95,8 +89,8 @@ Since we are building UnrealIRCd from source, we will need some build tools.
These can be found in the `Development Tools` group. Other than that, there are
some curl, ssl and other libraries that needs to be installed.
-install-unrealircd.sh
-```bash
+```bash,linenos
+# FILE: install-unrealircd.sh
yum -yq groupinstall "Development Tools" \
&& yum -yq install \
curl \
@@ -111,8 +105,9 @@ yum -yq groupinstall "Development Tools" \
Now we are able to compile UnrealIRCd from source. We will do all of this in
one giant step:
-install-unrealircd.sh
-```bash
+
+```bash,linenos
+# FILE: install-unrealircd.sh
# UnrealIRCd version
UNREAL_VERSION="unrealircd-4.0.0-rc3"
@@ -143,8 +138,9 @@ have SSL enabled, we will also need an SSL certificate! Luckily, this can also
be done through without any user input. It does require some information
though, so you should substitute the variables with your information.
-install-unrealircd.sh
-```bash
+
+```bash,linenos
+# FILE: install-unrealircd.sh
# SSL certificate information
# The two-letter ISO abbreviation for your country
SSL_CERTIFICATE_COUNTRY="DK"
@@ -186,16 +182,16 @@ the tools (namely the `Development Tools` packages).
Anope uses (or at least we use it here) cmake to build. This means we have to
install cmake before doing anything else.
-install-anope.sh
-```bash
+```bash,linenos
+# FILE: install-anope.sh
yum -y install cmake
```
Now we can compile Anope IRC services from source. We will fetch it and compile
it in one step:
-install-anope.sh
-```bash
+```bash,linenos
+# FILE: install-anope.sh
# Anope version
ANOPE_VERSION="2.0.2"
@@ -253,8 +249,8 @@ into place, using the install scripts mentioned earlier. By having a IAM role
with S3 read access attached to it, we can download objects from the S3 bucket
directly.
-init-ec2.sh
-```bash
+```bash,linenos
+# FILE: init-ec2.sh
#!/bin/bash
# Bucket location
export AWS_S3_BUCKET="YourBucket/install"
@@ -288,8 +284,9 @@ While launching stuff from the console is indeed very fun...the first couple of
times, it quickly gets tedious. Therefore we will utilize the AWS API, to
create an EC2 instance, tag it and associate an elastic IP to it.
-launch-ec2-instance.sh
-```bash
+
+```bash,linenos
+# FILE: launch-ec2-instance.sh
#!/bin/bash
# AWS user credentials
@@ -345,7 +342,7 @@ to match what you need. The AMI ID can be found in the AMI store (you can start
launching an instance and stop after the first screen).
-## Github repo, ready to fork!
+## GitHub repo, ready to fork!
All of the scripts and configuration files to set it all up can be found in
this [github repo](https://github.com/codetalkio/AWS-IRC-Setup). You'll want to
change the configuration files in the `config` folder to fit your server
diff --git a/posts/2015-11-28-briefly-on-the-purpose-of-functors-applicatives-and-monads.md b/content/posts/2015-11-28-briefly-on-the-purpose-of-functors-applicatives-and-monads.md
similarity index 86%
rename from posts/2015-11-28-briefly-on-the-purpose-of-functors-applicatives-and-monads.md
rename to content/posts/2015-11-28-briefly-on-the-purpose-of-functors-applicatives-and-monads.md
index f1e7861..68a9807 100644
--- a/posts/2015-11-28-briefly-on-the-purpose-of-functors-applicatives-and-monads.md
+++ b/content/posts/2015-11-28-briefly-on-the-purpose-of-functors-applicatives-and-monads.md
@@ -1,13 +1,16 @@
----
-title: Briefly on the purpose of Functors, Applicatives and Monads
-tags: haskell
-date: 2015-11-28
----
++++
+title = "Briefly on the purpose of Functors, Applicatives and Monads"
+date = 2015-11-28
+[taxonomies]
+tags = ["haskell"]
++++
In a recent thread on [/r/haskell](https://www.reddit.com/r/haskell/) about how
to [motivate the AMP proposal in teaching](https://www.reddit.com/r/haskell/comments/3tpom7/amp_how_do_you_motivate_this_in_teaching/), I read a comment that finally helped me understand the purpose of `Functor`s, `Applicative`s and `Monad`s.
-
+
+
+{{ toc() }}
## Wait, what is AMP?
@@ -18,8 +21,8 @@ a `Monad` is always an `Applicative`.
The hierachy of `Functor`, `Applicative` and `Monad` is thus changed to,
-Typeclass hierachy
-```haskell
+
+```haskell,linenos
class Functor f where
-- ...
@@ -48,26 +51,24 @@ I'm mostly going to paraphrase [/u/ForTheFunctionGod's](https://www.reddit.com/u
One can naturally extend the intuition of a `Functor` to an `Applicative` and
from there to a `Monad`.
-__An explanation of the first two might go as follows:__
+**An explanation of the first two might go as follows:**
--Let's say I have a list of numbers and want to add `2` to each of these -numbers. You can write `fmap (+2) [1..10]` (using `Functor`). -But what if I had two lists of numbers and wanted to add each number from the -first list to each number from the second list? With `Applicative` you can do -just that - it's like `fmap` only it can take multiple arguments. You can write -`(+) <$> [1,5,10] <*> [11..13]`. -+> Let's say I have a list of numbers and want to add `2` to each of these +> numbers. You can write `fmap (+2) [1..10]` (using `Functor`). +> +> But what if I had two lists of numbers and wanted to add each number from the +> first list to each number from the second list? With `Applicative` you can do +> just that - it's like `fmap` only it can take multiple arguments. You can write +> `(+) <$> [1,5,10] <*> [11..13]`.[^1] -__From here, one can motivate `Monad` by asking:__ -
-What if I wanted to abort midway through - say, if I encountered a problem? You can then write: -+**From here, one can motivate `Monad` by asking:** +> What if I wanted to abort midway through - say, if I encountered a problem? You can then write:[^1] -```haskell + +```haskell,linenos add xs ys = do x <- xs if x < 0 then [] @@ -178,8 +179,8 @@ because on each step the bind function `>>=` (or `=<<` for the other direction) To understand this better, let's take a look at the `Maybe` instance, -
Maybe Monad typeclass instance
-```haskell
+
+```haskell,linenos
instance Monad Maybe where
return x = Just x
Nothing >>= f = Nothing
@@ -209,3 +210,5 @@ Finally, I can deeply recommend the book [Haskell Programming - from first
principle](http://haskellbook.com). It is still in development as of this date,
but already features 700 pages of quality content. Simply the best Haskell book
I have ever read (or, I'm still reading it as of writing).
+
+[^1]: https://www.reddit.com/r/haskell/comments/3tpom7/amp_how_do_you_motivate_this_in_teaching/cx8an8b
diff --git a/posts/2016-05-10-compiling-scss-and-js-in-hakyll.md b/content/posts/2016-05-10-compiling-scss-and-js-in-hakyll.md
similarity index 91%
rename from posts/2016-05-10-compiling-scss-and-js-in-hakyll.md
rename to content/posts/2016-05-10-compiling-scss-and-js-in-hakyll.md
index ab33c3a..8c6bd90 100644
--- a/posts/2016-05-10-compiling-scss-and-js-in-hakyll.md
+++ b/content/posts/2016-05-10-compiling-scss-and-js-in-hakyll.md
@@ -1,30 +1,29 @@
----
-title: Compiling SCSS and JavaScript in Hakyll
-tags: haskell, hakyll
-date: 2016-05-10
-versions:
-- Hakyll 4.8.3.0
-- hjsmin 0.2.0.1
-- Sass 3.4.18
-- Stackage LTS 5.15
----
++++
+title = "Compiling SCSS and JavaScript in Hakyll"
+date = 2016-05-10
+[taxonomies]
+tags = ["haskell", "hakyll"]
+[extra]
+versions = ["Hakyll 4.8.3.0", "hjsmin 0.2.0.1", "Sass 3.4.18", "Stackage LTS 5.15"]
++++
This seems to be an often asked question, so I thought I'd try and share the approach that I've arrived at after having explored a couple of solutions to the problem. If you want to see the full code in action, check out the [repo for the codetalk.io site](https://github.com/codetalkio/codetalk.io/blob/v1.0.0/site.hs#L9) (linking to v1.0.0 is intended, in case the code changes later on).
-
+
+
+{{ toc() }}
## Compiling and minifying JavaScript
For some reason `Hakyll` does not include its own JavaScript compiler, which makes little sense. Luckily there is a package called `hjsmin` giving us `Text.Jasmine`, which we will use to both compile and minify our JavaScript files.
-
-
+{% end %}
To get `hjsmin` 0.2.0.1 working with `stack`, add `hjsmin == 0.2.*` as a dependency in the projects cabal file, and the following to the `stack.yaml` file in the project,
-```yaml
+```yaml ,linenos
...
extra-deps: [ hjsmin-0.2.0.1
, language-javascript-0.6.0.4
@@ -35,7 +34,7 @@ extra-deps: [ hjsmin-0.2.0.1
Now we are ready to construct the compiler itself, by jumping into `site.hs`,
-```haskell
+```haskell ,linenos
import qualified Data.ByteString.Lazy.Char8 as C
import Text.Jasmine
@@ -51,7 +50,7 @@ The code is fairly straightforward. We use the `Text.Jasmine` provided function
Later on inside the main `Hakyll` function in `site.hs`, we use it as we would the other compilers,
-```haskell
+```haskell ,linenos
-- | Define the rules for the site/hakyll compiler
main :: IO ()
main = hakyll $ do
@@ -69,15 +68,13 @@ For those who aren't aware, there are other ways to write CSS than CSS. Sass and
This time we rely on external dependencies, namely the `sass` tool, which can be installed with `gem install sass`.
-💡
+{% aside() %}
From personal experience an earlier version of `hjsmin`, e.g. 0.1.5.3, would throw a parse error on some files such as jQuery. This has later been fixed in 0.2.0.1, but unfortunately Stackage is using 0.1.5.3 in the current LTS 5.15.
-
-
-
+{% end %}
Same as with the JavaScript minification, we add a compiler in `site.hs`,
-```haskell
+```haskell ,linenos
-- | Create a SCSS compiler that transpiles the SCSS to CSS and
-- minifies it (relying on the external 'sass' tool)
compressScssCompiler :: Compiler (Item String)
@@ -102,7 +99,7 @@ This time we have no library dependencies, and use the `Hakyll` provided functio
Much like with the JavaScript compiler, we use it in the main `Hakyll` function inside `site.hs` as such:
-```haskell
+```haskell ,linenos
-- | Define the rules for the site/hakyll compiler
main :: IO ()
main = hakyll $ do
diff --git a/posts/2016-05-11-using-electron-with-haskell.md b/content/posts/2016-05-11-using-electron-with-haskell.md
similarity index 79%
rename from posts/2016-05-11-using-electron-with-haskell.md
rename to content/posts/2016-05-11-using-electron-with-haskell.md
index faa402e..3b0ae43 100644
--- a/posts/2016-05-11-using-electron-with-haskell.md
+++ b/content/posts/2016-05-11-using-electron-with-haskell.md
@@ -1,26 +1,23 @@
----
-title: Using Electron with Haskell
-tags: haskell, electron
-date: 2016-05-11
-versions:
-- 'Electron 1.0.1'
-- 'Stackage LTS 5.15'
-- 'servant 0.4.4.7'
----
-
-_If you want to grab the whole code from this post, it can be found at [codetalkio/Haskell-Electron-app](https://github.com/codetalkio/Haskell-Electron-app){target="_blank" rel="noopener noreferrer"}._
-
-Not much literature exist on using `Electron` as a GUI tool for Haskell development, so I thought I'd explore the space a little. Being initially a bit clueless on how `Electron` would launch the Haskell web server, I was watching [the Electron meetup talk by Mike Craig from Wagon HG](https://youtu.be/mUAu7lcgYWE?t=6m54s){target="_blank" rel="noopener noreferrer"} (they use `Electron` with Haskell) and noticed they actually mention it on the slides:
-
-
-
-💡
+{% aside() %}
There is a library called [`hsass`](https://hackage.haskell.org/package/hsass), which provides a Haskell interface, but I've been running into problems with linking to the underlying C API. As such, I've opted for the external dependency for now.
-- * Statically compiled Haskell executable - * Shipped in Electron app bundle - * main.js in Electron spawns the subprocess - * Executable creates a localhost HTTP server - * JS talks to Haskell over AJAX -++++ +title =" Using Electron with Haskell" +date = 2016-05-11 +[taxonomies] +tags = ["haskell", "electron"] +[extra] +versions = ["Electron 1.0.1", "Stackage LTS 5.15", "servant 0.4.4.7"] ++++ + +_If you want to grab the whole code from this post, it can be found at [codetalkio/Haskell-Electron-app](https://github.com/codetalkio/Haskell-Electron-app)._ + +Not much literature exist on using `Electron` as a GUI tool for Haskell development, so I thought I'd explore the space a little. Being initially a bit clueless on how `Electron` would launch the Haskell web server, I was watching [the Electron meetup talk by Mike Craig from Wagon HG](https://youtu.be/mUAu7lcgYWE?t=6m54s) (they use `Electron` with Haskell) and noticed they actually mention it on the slides: + + + +> * Statically compiled Haskell executable +> * Shipped in Electron app bundle +> * main.js in Electron spawns the subprocess +> * Executable creates a localhost HTTP server +> * JS talks to Haskell over AJAX Importantly the bit _main.js in Electron spawns the subprocess_ is the part that was somehow missing in my mental model of how this would be structured (my JavaScript experience mainly lies in webdev and not really with Node.js and server-side/desktop JS). @@ -38,8 +35,12 @@ Haskell-Electron-app/ ...servant files ``` +Let's dive into it: + +{{ toc() }} + ## Setting up Electron -`Electron` has a nice [quick start guide](http://electron.atom.io/docs/latest/tutorial/quick-start/){target="_blank" rel="noopener noreferrer"}, which helps you get going fairly, well, quick. For our purposes, the following will set up the initial app we will use throughout. +`Electron` has a nice [quick start guide](http://electron.atom.io/docs/latest/tutorial/quick-start/), which helps you get going fairly, well, quick. For our purposes, the following will set up the initial app we will use throughout. ```bash $ cd Haskell-Electron-app @@ -52,7 +53,7 @@ And that's it really. You've now got a basic `Electron` app running locally. The ## Setting up the Haskell webserver -We'll be using [servant](http://haskell-servant.readthedocs.io/en/stable/){target="_blank" rel="noopener noreferrer"} for a minimal application, but you could really use anything that will run a web server (such as [Yesod](http://www.yesodweb.com){target="_blank" rel="noopener noreferrer"}, [WAI](https://www.stackage.org/package/wai){target="_blank" rel="noopener noreferrer"}, [Snap](http://snapframework.com){target="_blank" rel="noopener noreferrer"}, [Happstack](http://www.happstack.com){target="_blank" rel="noopener noreferrer"} etc, you get the idea :). +We'll be using [servant](http://haskell-servant.readthedocs.io/en/stable/) for a minimal application, but you could really use anything that will run a web server (such as [Yesod](http://www.yesodweb.com), [WAI](https://www.stackage.org/package/wai), [Snap](http://snapframework.com), [Happstack](http://www.happstack.com) etc, you get the idea :). Assuming that `stack` is installed, you can set up a new `servant` project with @@ -63,9 +64,9 @@ $ cd backend $ stack build ``` -which will download the `servant` project template for you (from the [stack templates repo](https://github.com/commercialhaskell/stack-templates){target="_blank" rel="noopener noreferrer"}) and build it. +which will download the `servant` project template for you (from the [stack templates repo](https://github.com/commercialhaskell/stack-templates)) and build it. -To test that it works run `stack exec backend-exe` which will start the executable that `stack build` produced. You now have a web server running at `127.0.0.1:8080` - try and navigate to [127.0.0.1:8080/users](http://127.0.0.1:8080/users){target="_blank" rel="noopener noreferrer"} and check it out! :) +To test that it works run `stack exec backend-exe` which will start the executable that `stack build` produced. You now have a web server running at `127.0.0.1:8080` - try and navigate to [127.0.0.1:8080/users](http://127.0.0.1:8080/users) and check it out! :) For the lack of a better named I have called the application _backend_, but it could really be anything you fancy. @@ -77,7 +78,7 @@ Since the `servant` template project has given us the endpoint `127.0.0.1:8080/u By default the chromium developer tools are enabled in `Electron`. I suggest you keep them enabled while debugging, since that makes it a lot easier to see if anything went wrong. If you want to disable it, you just need to comment/remove a line in `Haskell-Electron-app/haskell-app/main.js`: -```javascript +```typescript ,linenos ... function createWindow () { // Create the browser window, @@ -91,11 +92,11 @@ function createWindow () { ... ``` -Short interlude: we'll be a bit lazy and download [jQuery 2.2.3 minified](https://code.jquery.com/jquery-2.2.3.min.js){target="_blank" rel="noopener noreferrer"}. Put that into `Haskell-Electron-app/haskell-app/resources/jQuery-2.2.3.min.js` so we can include it later on and get the nice AJAX functionality it provides. +Short interlude: we'll be a bit lazy and download [jQuery 2.2.3 minified](https://code.jquery.com/jquery-2.2.3.min.js). Put that into `Haskell-Electron-app/haskell-app/resources/jQuery-2.2.3.min.js` so we can include it later on and get the nice AJAX functionality it provides. Back to work in `Haskell-Electron-app/haskell-app`, lets change the `index.html` page and prepare it for our list of users. -```html +```html ,linenos @@ -126,7 +127,7 @@ Back to work in `Haskell-Electron-app/haskell-app`, lets change the `index.html` And finally we'll implement the logic in `renderer.js`, -```javascript +```typescript ,linenos // Backend and endpoint details. const host = 'http://127.0.0.1:8080' const endpoint = '/users' @@ -172,7 +173,7 @@ fetchUserList(waitTimeBetweenAttempt, maxNoOfAttempts) We simply request the `JSON` data at `http://127.0.0.1:8080/users`, with `$.getJSON(...)`, and display it if we received the data. If the request failed, we keep retrying until we either get a response or reach the maximum number of attempts (here set to 50 via `maxNoOfAttempts`). -The real purpose behind the retry will become apparent later on, when we might need to wait for the server to become available. Normally you will use a status endpoint that you are 100% sure is correct and not failing to check for the availability (inspired by the answer [Mike from Wagon HQ gave here](https://www.reddit.com/r/haskell/comments/4ipah2/resources_for_electron_haskell/d30mupm){target="_blank" rel="noopener noreferrer"}). +The real purpose behind the retry will become apparent later on, when we might need to wait for the server to become available. Normally you will use a status endpoint that you are 100% sure is correct and not failing to check for the availability (inspired by the answer [Mike from Wagon HQ gave here](https://www.reddit.com/r/haskell/comments/4ipah2/resources_for_electron_haskell/d30mupm)). ## Launching the Haskell web server from Electron @@ -180,7 +181,7 @@ Now to the interesting part, let's try to launch the Haskell web server from ins First though, let us set the `haskell-app/resources` folder as the target for our binary, in the `stack.yaml` file, with the `local-bin-path` configuration value. -```yaml +```yaml ,linenos resolver: lts-5.15 local-bin-path: ../haskell-app/resources ... @@ -199,7 +200,7 @@ After that it is surprisingly easy to launch the executable from within `Electro Since there are bits and pieces that are added I'll include the whole `Haskell-Electron-app/haskell-app/main.js` file, with most of the comments removed. -```javascript +```typescript ,linenos const electron = require('electron') // Used to spawn processes. const child_process = require('child_process') @@ -246,13 +247,13 @@ app.on('activate', function () { Let's briefly go through what is happening: -* We are using the [child_process.spawn](https://nodejs.org/api/child_process.html#child_process_child_process_spawn_command_args_options){target="_blank" rel="noopener noreferrer"} command to launch our backend web server -* We imported the `child_process` module with `const child_process = require('child_process')` -* Defined a variable `let backendServer` that'll let us keep the backend server from being garbage collected -* Added a function `createBackendServer` that runs `child_process.spawn('./resources/backend-exe')` to spawn the process -* Added the `createBackendServer` function to the `ready` hook with `app.on('ready', createBackendServer)` -* Close the `backendServer` when the event `will-quit` occurs +- We are using the [child_process.spawn](https://nodejs.org/api/child_process.html#child_process_child_process_spawn_command_args_options) command to launch our backend web server +- We imported the `child_process` module with `const child_process = require('child_process')` +- Defined a variable `let backendServer` that'll let us keep the backend server from being garbage collected +- Added a function `createBackendServer` that runs `child_process.spawn('./resources/backend-exe')` to spawn the process +- Added the `createBackendServer` function to the `ready` hook with `app.on('ready', createBackendServer)` +- Close the `backendServer` when the event `will-quit` occurs __And voila!__ We now have Electron spawning a process that runs a Haskell web server! :) -Next step would be to package the app up for distribution to see if that affects anything, but I'll save that for another time (and `Electron` already has [a page on distribution here](http://electron.atom.io/docs/v0.37.8/tutorial/application-distribution/){target="_blank" rel="noopener noreferrer"}). +Next step would be to package the app up for distribution to see if that affects anything, but I'll save that for another time (and `Electron` already has [a page on distribution here](http://electron.atom.io/docs/v0.37.8/tutorial/application-distribution/)). diff --git a/posts/2018-02-07-Mobile-Haskell.md b/content/posts/2018-02-07-mobile-haskell/index.md similarity index 64% rename from posts/2018-02-07-Mobile-Haskell.md rename to content/posts/2018-02-07-mobile-haskell/index.md index 30e6383..ac5ebf9 100644 --- a/posts/2018-02-07-Mobile-Haskell.md +++ b/content/posts/2018-02-07-mobile-haskell/index.md @@ -1,34 +1,36 @@ ---- -title: Mobile Haskell (iOS) -tags: haskell, mobile, iOS -date: 2018-02-07 -versions: -- 'Xcode Version 9.2 (9C40b)' -- 'Cabal HEAD (commit [94a7374](https://github.com/haskell/cabal/commit/94a7374d7b1a9b55454209e92d5057ba81be7d6a){target="_blank" rel="noopener noreferrer"})' -- 'Stack Version 1.6.3' -- 'LLVM Version 5.0.1' ---- ++++ +title = "Mobile Haskell (iOS)" +date = 2018-02-07 +[taxonomies] +tags = ["haskell", "mobile", "iOS"] +[extra] +versions = ["Xcode Version 9.2 (9C40b)", "Cabal HEAD (commit [94a7374](https://github.com/haskell/cabal/commit/94a7374d7b1a9b55454209e92d5057ba81be7d6a){target=\"_blank\" rel=\"noopener noreferrer\"})", "Stack Version 1.6.3", "LLVM Version 5.0.1"] ++++ A lot of progress has been going on to make Haskell work on mobile natively, instead of e.g. generating JavaScript via GHCJS and using that. Unfortunately, not much documentation exists yet on how to build a project using these tools all together. This post will be an attempt to piece together the tools and various attempts into a coherent step-by-step guide. We will start by setting up the tools needed, and then build an iOS app that runs in both the simulator and on the device itself (i.e. a x86 build and an arm build). - + For the impatient and brave, simply, -- clone down the [MobileHaskellFun](https://github.com/Tehnix/MobileHaskellFun){target="_blank" rel="noopener noreferrer"} repository, +- clone down the [MobileHaskellFun](https://github.com/Tehnix/MobileHaskellFun) repository, - run `./setup-tools.sh` to set up the tools, - `cd` into `Offie/hs-src/` - build the package index `./call x86_64-apple-ios-cabal new-update --allow-newer`, - run `./call make iOS` to compile the program for iOS, - and finally launch Xcode and start the simulator. +Otherwise, let's go through the steps in detail: + +{{ toc() }} + ## Setting up the Tools A bunch of tools are needed, so we will set these up first. You might have some of these, but I will go through them anyways, for good measure. The steps will assume that we are on macOS for some parts, but it should not be part to adapt these to your system (all steps using `brew`). -If you don't have [stack](https://docs.haskellstack.org/en/stable/README/){target="_blank" rel="noopener noreferrer"} installed already, set it up with, +If you don't have [stack](https://docs.haskellstack.org/en/stable/README/) installed already, set it up with, ```bash $ curl -sSL https://get.haskellstack.org/ | sh @@ -40,7 +42,7 @@ We will collect all our tools and GHC versions in a folder in `$HOME`—for conv $ mkdir -p ~/.mobile-haskell ``` -Next step is cloning down [cabal](github.com/haskell/cabal){target="_blank" rel="noopener noreferrer"} and building cabal-install. This is necessary until `new-update` lands. +Next step is cloning down [cabal](github.com/haskell/cabal) and building cabal-install. This is necessary until `new-update` lands. ```bash $ cd ~/.mobile-haskell @@ -60,7 +62,7 @@ $ brew install llvm This should set up LLVM in `/usr/local/opt/llvm@5/bin` (or just `/usr/local/opt/llvm/bin`), remember this path for later. -We'll now set up the tools from [http://hackage.mobilehaskell.org](http://hackage.mobilehaskell.org){target="_blank" rel="noopener noreferrer"}, namely the toolchain-wrapper and the different GHC versions we will use. +We'll now set up the tools from [http://hackage.mobilehaskell.org](http://hackage.mobilehaskell.org), namely the toolchain-wrapper and the different GHC versions we will use. Let's start off with getting our GHCs, by downloading `ghc-8.4.0.20180109-x86_64-apple-ios.tar.xz` and `ghc-8.4.0.20180109-aarch64-apple-ios.tar.xz`, for the simulator and device respectively. You can download the by cliking their links on the website, or curl them down with (the links are probably outdated soon, so replace the links with the ones on the site), @@ -120,7 +122,7 @@ $ make && make install We should now have our libffi files for the two targets living in `~/.mobile-haskell/lffi/aarch64-apple-ios` and `~/.mobile-haskell/lffi/x86_64-apple-ios` respectively. --> -And that's it! We have now set up all the tools we need for later. If you want all the steps as a single script, check out the [setup script in the MobileHaskellFun repo](https://github.com/Tehnix/MobileHaskellFun/blob/master/setup-tools.sh){target="_blank" rel="noopener noreferrer"}. +And that's it! We have now set up all the tools we need for later. If you want all the steps as a single script, check out the [setup script in the MobileHaskellFun repo](https://github.com/Tehnix/MobileHaskellFun/blob/master/setup-tools.sh). ## Setting up the Xcode Project @@ -128,25 +130,20 @@ Setting up Xcode is a bit of a visual process, so I'll augment these steps with First, let's set up our Xcode project, by creating a new project. -
+{{ image(path="mobile-haskell-1. Create Project.png", caption="1. Create Project", width=600) }}
Choose `Single View Application`,
-
+{{ image(path="mobile-haskell-1.1. Create Project - Single View Application.png", caption="1.1. Create Project - Single View Application", width=600) }}
And set the name and location of your project,
-
- 
- 
-
-Now, let's add a folder to keep our Haskell code in and call it `hs-src`, by right-clicking our project and adding a `New Group`,
+{{ images(paths=["mobile-haskell-1.2. Create Project - Name.png", "mobile-haskell-1.3. Create Project - Set Location.png"], captions=["1.2. Create Project - Name", "1.3. Create Project - Set Location"], widths=[400, 400]) }}
-
- 
-
-
-
+Now, let's add a folder to keep our Haskell code in and call it `hs-src`, by right-clicking our project and adding a `New Group`,
+{{ image(path="mobile-haskell-2. Add Source Folder for Haskell Code.png", caption="2. Add Source Folder for Haskell Code", width=300) }}
## Interlude: Set up the Haskell Code
@@ -162,7 +159,7 @@ $ touch MobileFun.cabal cabal.project Makefile call LICENSE src/Lib.hs
We use the features of `cabal.project` to set our package repository to use the hackage.mobilehaskell.org overlay.
-```haskell
+```haskell ,linenos
packages: .
repository hackage.mobilehaskell
@@ -178,7 +175,7 @@ repository hackage.mobilehaskell
Just a simple cabal package setup.
-```haskell
+```haskell ,linenos
name: MobileFun
version: 0.1.0.0
license: BSD3
@@ -202,7 +199,7 @@ library
The Makefile simplifies a lot of the compilation process and passes the flags we need to use.
-```makefile
+```makefile ,linenos
LIB=MobileFun
ARCHIVE=libHS${LIB}
@@ -250,7 +247,7 @@ clean:
Our Haskell code for now, is simply some C FFI that sets up a small toy function.
-```haskell
+```haskell ,linenos
module Lib where
import Foreign.C (CString, newCString)
@@ -270,7 +267,7 @@ hello = "Hello from Haskell"
We use the `call` script to set up the various path variables that point to our tools, so we don't need these polluting our global command space. If you've followed the setup so far, the paths should match out-of-the-box.
-```bash
+```bash ,linenos
#!/usr/bin/env bash
# Path to LLVM (this is the default when installing via `brew`)
export PATH=/usr/local/opt/llvm@5/bin:$PATH
@@ -325,23 +322,15 @@ We should now have our library file at `hs-src/binaries/iOS/libHSMobileFun.a`. I
Now we need to tie together the Haskell code with Xcode. Drag-and-drop the newly created files into the `hs-src` group in Xcode (if it hasn't found it by itself).
-
-
+And set the name and location of your project,
+
+{{ image(path="mobile-haskell-3. Drag the files to Xcode.png", caption="3. Drag the files to Xcode", width=600) }}
Since we are using Swift, we need a bridging header to bring our C prototypes into Swift. We'll do this by adding an Objective-C file to the project, `tmp.m`, which will make Xcode ask if we want to create a bridging header, `Offie-Bridging-Header.h`, for which we will answer yes.
-
-
-
-
-
-
- 
- 
-
+{{ image(path="mobile-haskell-4. Create Objective-C File.png", caption="4. Create Objective-C File", width=300) }}
-
- 
-
- 
- 
-
+{{ images(paths=["mobile-haskell-4.1. Create Objective-C File - Choose Filetype.png", "mobile-haskell-4.2. Create Objective-C File - Set Name.png"], captions=["4.1. Create Objective-C File - Choose Filetype", "4.2. Create Objective-C File - Set Name"], widths=[400, 400]) }}
@@ -349,7 +338,7 @@ Since we are using Swift, we need a bridging header to bring our C prototypes in
In our bridging file, `Offie-Bridging-Header.h`, we add our prototypes that we need to glue in the Haskell code,
-```c
+```c ,linenos
extern void hs_init(int * argc, char ** argv[]);
extern char * hello();
```
@@ -358,7 +347,7 @@ extern char * hello();
Now let's go into `AppDelegate.swift` and call `hs_init` to initialize the Haskell code,
-```objective-c
+```objective-c ,linenos
import UIKit
@UIApplicationMain
@@ -388,15 +377,15 @@ Next, we will set up a label in a view controller. You can either set this up in
First go into the `Main.storyboard` and create a label element somewhere on the screen.
-
- 
-
+{{ image(path="mobile-haskell-7. Add Label.png", caption="7. Add Label", width=600) }}
Then enable the `Assistant Editor` in the top right cornor, and ctrl-click on the label, dragging it over to the `ViewController.swift` and name `helloWorldLabel`.
-
+{{ image(path="mobile-haskell-7.1. Add Label - Connect IBOutlet.png", caption="7.1. Add Label - Connect IBOutlet", width=600) }}
We can now set the text of the label by calling our Haskell function with `cString: hello()`, making our `ViewController.swift` look like,
-```objective-c
+```objective-c ,linenos
import UIKit
class ViewController: UIViewController {
@@ -420,46 +409,43 @@ The final step we need to do, is linking in our library that we built earlier, `
We do this by going into `Build Phases`, which is exposed under the Xcode project settings, and click the `+` to add a new library,
-
+{{ image(path="mobile-haskell-5. Build Phases.png", caption="5. Build Phases", width=650) }}
Choose `Add Other...` to locate the library,
-
+{{ image(path="mobile-haskell-5.1. Build Phases - Add New.png", caption="5.1. Build Phases - Add New", width=650) }}
and finally locate the library file in `hs-src/binaries/iOS/libHSMobileFun.a`,
-
+{{ image(path="mobile-haskell-5.2. Build Phases - Locate the Library.png", caption="5.2. Build Phases - Locate the Library", width=650) }}
We also need to set the build to not generate bytecode, because we are using the external GHC library. This is done under `Build Settings`, locating `Enable Bitcode` (e.g. via the search) and setting it to `No`.
-
+{{ image(path="mobile-haskell-6. Build Settings.png", caption="6. Build Settings", width=650) }}
## Run the Code!
Final step, let's run our code in the simulator
-
- 
-
+{{ image(path="mobile-haskell-9. Run Simulator.png", caption="9. Run Simulator", width=300) }}
Congratulations! You're now calling Haskell code from Swift and running it in an iOS simulator.
-
-
-
+{% end %}
-💡
+{% aside() %}
You might run into a problem like `could not create compact unwind for _ffi_call_unix64: does not use RBP or RSP based frame` in your Xcode builds. You can fix this by adding `libconv` to your libraries in `Build Phase`.
-
+{{ image(path="mobile-haskell-8. Add libconv to libraries.png", caption="8. Add libconv to libraries", width=650) }}
## Resources
Most of this is gathered from:
-- [A Haskell Cross Compiler for iOS](https://medium.com/@zw3rk/a-haskell-cross-compiler-for-ios-7cc009abe208){target="_blank" rel="noopener noreferrer"} and some of the other medium posts.
-- Various issues on the [mobile-haskell/hackage-overlay](https://github.com/mobilehaskell/hackage-overlay){target="_blank" rel="noopener noreferrer"} ([#5](https://github.com/mobilehaskell/hackage-overlay/issues/5){target="_blank" rel="noopener noreferrer"}, [#2](https://github.com/mobilehaskell/hackage-overlay/issues/2){target="_blank" rel="noopener noreferrer"}).
+- [A Haskell Cross Compiler for iOS](https://medium.com/@zw3rk/a-haskell-cross-compiler-for-ios-7cc009abe208) and some of the other medium posts.
+- Various issues on the [mobile-haskell/hackage-overlay](https://github.com/mobilehaskell/hackage-overlay) ([#5](https://github.com/mobilehaskell/hackage-overlay/issues/5), [#2](https://github.com/mobilehaskell/hackage-overlay/issues/2)).
- The [preliminary user guide](http://mobile-haskell-user-guide.readthedocs.io/en/latest/).
-If you are interested in following the development of Haskell in the mobile space, I recommend following [\@zw3rktech](https://twitter.com/zw3rktech){target="_blank" rel="noopener noreferrer"} and [\@mobilehaskell](https://twitter.com/mobilehaskell){target="_blank" rel="noopener noreferrer"}.
+If you are interested in following the development of Haskell in the mobile space, I recommend following [\@zw3rktech](https://twitter.com/zw3rktech) and [\@mobilehaskell](https://twitter.com/mobilehaskell).
-Finally, let me know if something is not working with the [MobileHaskellFun repository](https://github.com/Tehnix/MobileHaskellFun){target="_blank" rel="noopener noreferrer"}. I haven't dealt that much with setting up Xcode projects for sharing, so I'm a bit unclear on what settings follow the repository around.
+Finally, let me know if something is not working with the [MobileHaskellFun repository](https://github.com/Tehnix/MobileHaskellFun). I haven't dealt that much with setting up Xcode projects for sharing, so I'm a bit unclear on what settings follow the repository around.
diff --git a/resources/images/mobile-haskell-1. Create Project.png b/content/posts/2018-02-07-mobile-haskell/mobile-haskell-1. Create Project.png
similarity index 100%
rename from resources/images/mobile-haskell-1. Create Project.png
rename to content/posts/2018-02-07-mobile-haskell/mobile-haskell-1. Create Project.png
diff --git a/resources/images/mobile-haskell-1.1. Create Project - Single View Application.png b/content/posts/2018-02-07-mobile-haskell/mobile-haskell-1.1. Create Project - Single View Application.png
similarity index 100%
rename from resources/images/mobile-haskell-1.1. Create Project - Single View Application.png
rename to content/posts/2018-02-07-mobile-haskell/mobile-haskell-1.1. Create Project - Single View Application.png
diff --git a/resources/images/mobile-haskell-1.2. Create Project - Name.png b/content/posts/2018-02-07-mobile-haskell/mobile-haskell-1.2. Create Project - Name.png
similarity index 100%
rename from resources/images/mobile-haskell-1.2. Create Project - Name.png
rename to content/posts/2018-02-07-mobile-haskell/mobile-haskell-1.2. Create Project - Name.png
diff --git a/resources/images/mobile-haskell-1.3. Create Project - Set Location.png b/content/posts/2018-02-07-mobile-haskell/mobile-haskell-1.3. Create Project - Set Location.png
similarity index 100%
rename from resources/images/mobile-haskell-1.3. Create Project - Set Location.png
rename to content/posts/2018-02-07-mobile-haskell/mobile-haskell-1.3. Create Project - Set Location.png
diff --git a/resources/images/mobile-haskell-2. Add Source Folder for Haskell Code.png b/content/posts/2018-02-07-mobile-haskell/mobile-haskell-2. Add Source Folder for Haskell Code.png
similarity index 100%
rename from resources/images/mobile-haskell-2. Add Source Folder for Haskell Code.png
rename to content/posts/2018-02-07-mobile-haskell/mobile-haskell-2. Add Source Folder for Haskell Code.png
diff --git a/resources/images/mobile-haskell-2.1. Add Source Folder for Haskell Code.png b/content/posts/2018-02-07-mobile-haskell/mobile-haskell-2.1. Add Source Folder for Haskell Code.png
similarity index 100%
rename from resources/images/mobile-haskell-2.1. Add Source Folder for Haskell Code.png
rename to content/posts/2018-02-07-mobile-haskell/mobile-haskell-2.1. Add Source Folder for Haskell Code.png
diff --git a/resources/images/mobile-haskell-3. Drag the files to Xcode.png b/content/posts/2018-02-07-mobile-haskell/mobile-haskell-3. Drag the files to Xcode.png
similarity index 100%
rename from resources/images/mobile-haskell-3. Drag the files to Xcode.png
rename to content/posts/2018-02-07-mobile-haskell/mobile-haskell-3. Drag the files to Xcode.png
diff --git a/resources/images/mobile-haskell-4. Create Objective-C File.png b/content/posts/2018-02-07-mobile-haskell/mobile-haskell-4. Create Objective-C File.png
similarity index 100%
rename from resources/images/mobile-haskell-4. Create Objective-C File.png
rename to content/posts/2018-02-07-mobile-haskell/mobile-haskell-4. Create Objective-C File.png
diff --git a/resources/images/mobile-haskell-4.1. Create Objective-C File - Choose Filetype.png b/content/posts/2018-02-07-mobile-haskell/mobile-haskell-4.1. Create Objective-C File - Choose Filetype.png
similarity index 100%
rename from resources/images/mobile-haskell-4.1. Create Objective-C File - Choose Filetype.png
rename to content/posts/2018-02-07-mobile-haskell/mobile-haskell-4.1. Create Objective-C File - Choose Filetype.png
diff --git a/resources/images/mobile-haskell-4.2. Create Objective-C File - Set Name.png b/content/posts/2018-02-07-mobile-haskell/mobile-haskell-4.2. Create Objective-C File - Set Name.png
similarity index 100%
rename from resources/images/mobile-haskell-4.2. Create Objective-C File - Set Name.png
rename to content/posts/2018-02-07-mobile-haskell/mobile-haskell-4.2. Create Objective-C File - Set Name.png
diff --git a/resources/images/mobile-haskell-4.3. Create Objective-C File - Set Location.png b/content/posts/2018-02-07-mobile-haskell/mobile-haskell-4.3. Create Objective-C File - Set Location.png
similarity index 100%
rename from resources/images/mobile-haskell-4.3. Create Objective-C File - Set Location.png
rename to content/posts/2018-02-07-mobile-haskell/mobile-haskell-4.3. Create Objective-C File - Set Location.png
diff --git a/resources/images/mobile-haskell-4.4. Create Objective-C File - Create Bridging Header.png b/content/posts/2018-02-07-mobile-haskell/mobile-haskell-4.4. Create Objective-C File - Create Bridging Header.png
similarity index 100%
rename from resources/images/mobile-haskell-4.4. Create Objective-C File - Create Bridging Header.png
rename to content/posts/2018-02-07-mobile-haskell/mobile-haskell-4.4. Create Objective-C File - Create Bridging Header.png
diff --git a/resources/images/mobile-haskell-5. Build Phases.png b/content/posts/2018-02-07-mobile-haskell/mobile-haskell-5. Build Phases.png
similarity index 100%
rename from resources/images/mobile-haskell-5. Build Phases.png
rename to content/posts/2018-02-07-mobile-haskell/mobile-haskell-5. Build Phases.png
diff --git a/resources/images/mobile-haskell-5.1. Build Phases - Add New.png b/content/posts/2018-02-07-mobile-haskell/mobile-haskell-5.1. Build Phases - Add New.png
similarity index 100%
rename from resources/images/mobile-haskell-5.1. Build Phases - Add New.png
rename to content/posts/2018-02-07-mobile-haskell/mobile-haskell-5.1. Build Phases - Add New.png
diff --git a/resources/images/mobile-haskell-5.2. Build Phases - Locate the Library.png b/content/posts/2018-02-07-mobile-haskell/mobile-haskell-5.2. Build Phases - Locate the Library.png
similarity index 100%
rename from resources/images/mobile-haskell-5.2. Build Phases - Locate the Library.png
rename to content/posts/2018-02-07-mobile-haskell/mobile-haskell-5.2. Build Phases - Locate the Library.png
diff --git a/resources/images/mobile-haskell-6. Build Settings.png b/content/posts/2018-02-07-mobile-haskell/mobile-haskell-6. Build Settings.png
similarity index 100%
rename from resources/images/mobile-haskell-6. Build Settings.png
rename to content/posts/2018-02-07-mobile-haskell/mobile-haskell-6. Build Settings.png
diff --git a/resources/images/mobile-haskell-6. Build Settings.thumbnail.png b/content/posts/2018-02-07-mobile-haskell/mobile-haskell-6. Build Settings.thumbnail.png
similarity index 100%
rename from resources/images/mobile-haskell-6. Build Settings.thumbnail.png
rename to content/posts/2018-02-07-mobile-haskell/mobile-haskell-6. Build Settings.thumbnail.png
diff --git a/resources/images/mobile-haskell-7. Add Label.png b/content/posts/2018-02-07-mobile-haskell/mobile-haskell-7. Add Label.png
similarity index 100%
rename from resources/images/mobile-haskell-7. Add Label.png
rename to content/posts/2018-02-07-mobile-haskell/mobile-haskell-7. Add Label.png
diff --git a/resources/images/mobile-haskell-7. Add Label.thumbnail.png b/content/posts/2018-02-07-mobile-haskell/mobile-haskell-7. Add Label.thumbnail.png
similarity index 100%
rename from resources/images/mobile-haskell-7. Add Label.thumbnail.png
rename to content/posts/2018-02-07-mobile-haskell/mobile-haskell-7. Add Label.thumbnail.png
diff --git a/resources/images/mobile-haskell-7.1. Add Label - Connect IBOutlet.png b/content/posts/2018-02-07-mobile-haskell/mobile-haskell-7.1. Add Label - Connect IBOutlet.png
similarity index 100%
rename from resources/images/mobile-haskell-7.1. Add Label - Connect IBOutlet.png
rename to content/posts/2018-02-07-mobile-haskell/mobile-haskell-7.1. Add Label - Connect IBOutlet.png
diff --git a/resources/images/mobile-haskell-7.1. Add Label - Connect IBOutlet.thumbnail.png b/content/posts/2018-02-07-mobile-haskell/mobile-haskell-7.1. Add Label - Connect IBOutlet.thumbnail.png
similarity index 100%
rename from resources/images/mobile-haskell-7.1. Add Label - Connect IBOutlet.thumbnail.png
rename to content/posts/2018-02-07-mobile-haskell/mobile-haskell-7.1. Add Label - Connect IBOutlet.thumbnail.png
diff --git a/resources/images/mobile-haskell-8. Add libconv to libraries.png b/content/posts/2018-02-07-mobile-haskell/mobile-haskell-8. Add libconv to libraries.png
similarity index 100%
rename from resources/images/mobile-haskell-8. Add libconv to libraries.png
rename to content/posts/2018-02-07-mobile-haskell/mobile-haskell-8. Add libconv to libraries.png
diff --git a/resources/images/mobile-haskell-8. Add libconv to libraries.thumbnail.png b/content/posts/2018-02-07-mobile-haskell/mobile-haskell-8. Add libconv to libraries.thumbnail.png
similarity index 100%
rename from resources/images/mobile-haskell-8. Add libconv to libraries.thumbnail.png
rename to content/posts/2018-02-07-mobile-haskell/mobile-haskell-8. Add libconv to libraries.thumbnail.png
diff --git a/resources/images/mobile-haskell-9. Run Simulator.png b/content/posts/2018-02-07-mobile-haskell/mobile-haskell-9. Run Simulator.png
similarity index 100%
rename from resources/images/mobile-haskell-9. Run Simulator.png
rename to content/posts/2018-02-07-mobile-haskell/mobile-haskell-9. Run Simulator.png
diff --git a/resources/images/mobile-haskell-9. Run Simulator.thumbnail.png b/content/posts/2018-02-07-mobile-haskell/mobile-haskell-9. Run Simulator.thumbnail.png
similarity index 100%
rename from resources/images/mobile-haskell-9. Run Simulator.thumbnail.png
rename to content/posts/2018-02-07-mobile-haskell/mobile-haskell-9. Run Simulator.thumbnail.png
diff --git a/resources/images/dynamodb-migration-phase-1-background.png b/content/posts/2020-03-19-live-migration-of-dynamodb-tables/dynamodb-migration-phase-1-background.png
similarity index 100%
rename from resources/images/dynamodb-migration-phase-1-background.png
rename to content/posts/2020-03-19-live-migration-of-dynamodb-tables/dynamodb-migration-phase-1-background.png
diff --git a/resources/images/dynamodb-migration-phase-1.png b/content/posts/2020-03-19-live-migration-of-dynamodb-tables/dynamodb-migration-phase-1.png
similarity index 100%
rename from resources/images/dynamodb-migration-phase-1.png
rename to content/posts/2020-03-19-live-migration-of-dynamodb-tables/dynamodb-migration-phase-1.png
diff --git a/resources/images/dynamodb-migration-phase-2-background.png b/content/posts/2020-03-19-live-migration-of-dynamodb-tables/dynamodb-migration-phase-2-background.png
similarity index 100%
rename from resources/images/dynamodb-migration-phase-2-background.png
rename to content/posts/2020-03-19-live-migration-of-dynamodb-tables/dynamodb-migration-phase-2-background.png
diff --git a/resources/images/dynamodb-migration-phase-2.png b/content/posts/2020-03-19-live-migration-of-dynamodb-tables/dynamodb-migration-phase-2.png
similarity index 100%
rename from resources/images/dynamodb-migration-phase-2.png
rename to content/posts/2020-03-19-live-migration-of-dynamodb-tables/dynamodb-migration-phase-2.png
diff --git a/posts/2020-03-19-Live-Migration-of-DynamoDB-Tables.md b/content/posts/2020-03-19-live-migration-of-dynamodb-tables/index.md
similarity index 76%
rename from posts/2020-03-19-Live-Migration-of-DynamoDB-Tables.md
rename to content/posts/2020-03-19-live-migration-of-dynamodb-tables/index.md
index e2297cb..6a0e040 100644
--- a/posts/2020-03-19-Live-Migration-of-DynamoDB-Tables.md
+++ b/content/posts/2020-03-19-live-migration-of-dynamodb-tables/index.md
@@ -1,8 +1,9 @@
----
-title: Live Migration of DynamoDB Tables
-tags: aws, dynamodb, sqs, migration
-date: 2020-03-19
----
++++
+title = "Live Migration of DynamoDB Tables"
+date = 2020-03-19
+[taxonomies]
+tags = ["aws", "dynamodb", "sqs", "migration"]
++++
Recently I was faced with the challenge of having to migrate a set of AWS DynamoDB tables to completely new tables. We wanted to achieve this without affecting any of our users, and without having a maintenance window while migrating data from the old table to the new ones.
@@ -14,24 +15,27 @@ The following will be a very high-level overview of how you:
- Restart the migration if you made an error
- Complete the switchover after validating everything looks OK
-
+
-
-
+{% aside() %}
+ This won't be a detailed walkthrough, but will instead outline a method for people that are in the same situation we were.
+{% end %}
+
+We'll go through the following:
+
+{{ toc() }}
## Context
To put this migration into context, our entire cloud and setup are automated via CloudFormation, deploying many micro-services.
-To better orchestrate the deployment of these and have better handling of dependencies between the order of deployments, we had been working on a lot of infrastructure changes, switching around the tools that manage CloudFormation (from [serverless](https://serverless.com) to [AWS CDK](https://github.com/aws/aws-cdk){target="_blank" rel="noopener noreferrer"}).
+To better orchestrate the deployment of these and have better handling of dependencies between the order of deployments, we had been working on a lot of infrastructure changes, switching around the tools that manage CloudFormation (from [serverless](https://serverless.com) to [AWS CDK](https://github.com/aws/aws-cdk)).
Internally these tools generate unique references (logical ids), each in their own way, to the resources they generate CloudFormation for. This meant that we needed a way to change the logical ids of a resource for us to have the new tools adopt and manage the existing resources.
-Unfortunately, this is not possible for DynamoDB tables^[As mentioned in [serverless#1677](https://github.com/serverless/serverless/issues/1677){target="_blank" rel="noopener noreferrer"}, this is not supported.], without recreating the resources ☹️
+Unfortunately, this is not possible for DynamoDB tables^[As mentioned in [serverless#1677](https://github.com/serverless/serverless/issues/1677), this is not supported.], without recreating the resources ☹️
## Approach
-The idea came after AWS announced support for importing existing resources into a CloudFormation stack^[[https://aws.amazon.com/blogs/aws/new-import-existing-resources-into-a-cloudformation-stack/](https://aws.amazon.com/blogs/aws/new-import-existing-resources-into-a-cloudformation-stack/){target="_blank" rel="noopener noreferrer"}.], and was further motivated by the later support for restoring a DynamoDB table to another region^[[https://aws.amazon.com/blogs/database/restore-amazon-dynamodb-backups-to-different-aws-regions-and-with-custom-table-settings/](https://aws.amazon.com/blogs/database/restore-amazon-dynamodb-backups-to-different-aws-regions-and-with-custom-table-settings/){target="_blank" rel="noopener noreferrer"}.].
+The idea came after AWS announced support for importing existing resources into a CloudFormation stack[^1], and was further motivated by the later support for restoring a DynamoDB table to another region[^2].
The concept is simple and can be divided into two phases.
@@ -43,7 +47,7 @@ In the first phase, we will:
- Set up a Lambda function that will receive the events from these streams
- Set up a FIFO SQS queue which the Lambda function will put all of the events on
-💡
- This won't be detailed walkthrough but will instead outline a method for people that are in the same situation we were.
-
+{{ image(path="dynamodb-migration-phase-1.png", caption="Migration Phase 1", width=650) }}
After this is set up, all DynamoDB events will exist on the SQS queue. We will now create a backup for each of the tables. The time of the backups will be important later on. You don't have to note them down, since they are visible in the table backup overview.
@@ -58,7 +62,7 @@ We will now:
- Set up a Lambda Function that consumes from you SQS queue
- The consumer Lambda should only act on events that have happened on or after your backup time
-
+{{ image(path="dynamodb-migration-phase-2.png", caption="Migration Phase 2", width=650) }}
Since DynamoDB stream events contain all the information about a record, we can break them into the following:
@@ -83,7 +87,7 @@ When we felt comfortable that the new tables were correct, and had finalized the
Pointing the API to the new DynamoDB tables means that no more operations are done on the old tables, and thus no further events are put on the SQS. This had the effect that there was no rush to clean up the two Lambdas and SQS queue since they would simply not be performing any actions anymore.
-### Utilizing this approach for data transformation
+## Utilizing this approach for data transformation
We've only talked about migrating tables, without really touching the data. Still, this approach allows you to perform a data transformation along with your migration without needing to coordinate a complicated API switch or support both formats of data simultaneously.
You could do the following instead:
@@ -101,3 +105,7 @@ This way, you perform live transformations on your data and have ample time to s
While very high-level, this approach is a great tool to have in your toolbox when you run into those once-in-a-while cases where you need to perform these migrations.
If you are interested in me expanding more on the approach, please don't hesitate to leave a comment 🙂
+
+[^1]: [https://aws.amazon.com/blogs/aws/new-import-existing-resources-into-a-cloudformation-stack/](https://aws.amazon.com/blogs/aws/new-import-existing-resources-into-a-cloudformation-stack/)
+
+[^2]: [https://aws.amazon.com/blogs/database/restore-amazon-dynamodb-backups-to-different-aws-regions-and-with-custom-table-settings/](https://aws.amazon.com/blogs/database/restore-amazon-dynamodb-backups-to-different-aws-regions-and-with-custom-table-settings/)
diff --git a/posts/2020-03-20-Visual-Studio-Code-on-iPad.md b/content/posts/2020-03-20-visual-studio-code-on-ipad/index.md
similarity index 68%
rename from posts/2020-03-20-Visual-Studio-Code-on-iPad.md
rename to content/posts/2020-03-20-visual-studio-code-on-ipad/index.md
index aae6f8a..6506e75 100644
--- a/posts/2020-03-20-Visual-Studio-Code-on-iPad.md
+++ b/content/posts/2020-03-20-visual-studio-code-on-ipad/index.md
@@ -1,33 +1,34 @@
----
-title: Visual Studio Code on iPad
-tags: vscode, ipad, digital nomad
-date: 2020-03-20
-versions:
-- '`code-server` version 3.4.1'
-- 'Ubuntu 18.04 (should fit with most distros)'
-- 'Your own server'
-- 'Your own domain'
----
-
-With Apple increasing their focus^[[https://www.apple.com/newsroom/2020/03/apple-unveils-new-ipad-pro-with-lidar-scanner-and-trackpad-support-in-ipados/](https://www.apple.com/newsroom/2020/03/apple-unveils-new-ipad-pro-with-lidar-scanner-and-trackpad-support-in-ipados/){target="_blank" rel="noopener noreferrer"}.] on making the iPad a viable device for work, it is time to revisit using my iPad as a workstation for programming.
++++
+title = "Visual Studio Code on iPad"
+date = 2020-03-20
+[taxonomies]
+tags = ["vscode", "ipad", "digital nomad"]
+[extra]
+versions = ["`code-server` version 3.4.1", "Ubuntu 18.04 (should fit with most distros)", "Your own server", "Your own domain"]
++++
+
+With Apple increasing their focus[^1] on making the iPad a viable device for work, it is time to revisit using my iPad as a workstation for programming.
I rely heavily on command-line tools and language-specific tools (rust-analyser, node, ghcide, etc.) for my day-to-day programming, and my current setup features:
-- [Blink](https://blink.sh){target="_blank" rel="noopener noreferrer"} with mosh to a remote server.
-- Neovim and [wemux](https://github.com/zolrath/wemux){target="_blank" rel="noopener noreferrer"} on the remote server.
-- [iSH](https://ish.app){target="_blank" rel="noopener noreferrer"} to play around with very simple CLI needs locally on the iPad.
+- [Blink](https://blink.sh) with mosh to a remote server.
+- Neovim and [wemux](https://github.com/zolrath/wemux) on the remote server.
+- [iSH](https://ish.app) to play around with very simple CLI needs locally on the iPad.
On my computer, I use Visual Studio Code, and it's long been a wish to get that running somehow on my iPad. This is an attempt to make VS Code available on the iPad under the restrictions that we have to deal with.
-
+
-
-
+{% end %}
+
+We'll go through the following:
+
+{{ toc() }}
## Enter code-server
-[code-server](https://github.com/cdr/code-server){target="_blank" rel="noopener noreferrer"} enables you to run VS Code on a remote server, and access it through a browser. While not ideal, this is at least one way to get VS Code onto an iPad.
+[code-server](https://github.com/cdr/code-server) enables you to run VS Code on a remote server, and access it through a browser. While not ideal, this is at least one way to get VS Code onto an iPad.
First, SSH into your server, so that we can set up `code-server`,
@@ -41,7 +42,7 @@ Neat! 🙂 This was previously multiple steps, but code-server's recent addition
## Securing the setup for remote access
So far, `code-server` is only listening for local connections, but we'd like to be able to use it on the go, from a browser on the iPad. This means we have to do a little extra work to secure our setup.
-`code-server` covers how to do this [in their FAQ](https://github.com/cdr/code-server/blob/master/doc/FAQ.md#how-should-i-expose-code-server-to-the-internet){target="_blank" rel="noopener noreferrer"}, but skips the specific steps. Due to an issue with self-signed certificates on iOS, we cannot use these^[See issue [code-server#1122](https://github.com/cdr/code-server/issues/1122){target="_blank" rel="noopener noreferrer"} covering this.], so instead we will opt for [letsencrypt](https://letsencrypt.org){target="_blank" rel="noopener noreferrer"}!
+`code-server` covers how to do this [in their FAQ](https://github.com/cdr/code-server/blob/master/doc/FAQ.md#how-should-i-expose-code-server-to-the-internet), but skips the specific steps. Due to an issue with self-signed certificates on iOS, we cannot use these^[See issue [code-server#1122](https://github.com/cdr/code-server/issues/1122) covering this.], so instead we will opt for [letsencrypt](https://letsencrypt.org)!
+
**Table of Contents:**
@@ -45,9 +46,9 @@ First, we will set up our data structures and a few examples, which we will use
**TypeScript**
-Let us first set up our reference Object in TypeScript. Save the following in `house.ts` (or check out [typescript-json](https://github.com/codetalkio/codetalk.io/tree/master/resources/code/common-json-patterns/typescript-json){target="_blank" rel="noopener noreferrer"}):
+Let us first set up our reference Object in TypeScript. Save the following in `house.ts` (or check out [typescript-json](https://github.com/codetalkio/codethoughts.io/tree/master/content/posts/2020-04-05-common-json-patterns-in-haskell-rust-and-javascript/typescript-json)):
-```typescript
+```typescript ,linenos
interface Address {
country: string;
address: string;
@@ -86,13 +87,13 @@ The included snippet serves to give you an idea of the data structures, types, a
You can find the setup for each specific solution in:
-- [haskell-lens](https://github.com/codetalkio/codetalk.io/tree/master/resources/code/common-json-patterns/haskell-lens){target="_blank" rel="noopener noreferrer"}: Contains the Lens apporach.
-- [haskell-record-dot](https://github.com/codetalkio/codetalk.io/tree/master/resources/code/common-json-patterns/haskell-record-dot){target="_blank" rel="noopener noreferrer"}: Contains the Record Dot Syntax apporach.
+- [haskell-lens](https://github.com/codetalkio/codethoughts.io/tree/master/content/posts/2020-04-05-common-json-patterns-in-haskell-rust-and-javascript/haskell-lens): Contains the Lens apporach.
+- [haskell-record-dot](https://github.com/codetalkio/codethoughts.io/tree/master/content/posts/2020-04-05-common-json-patterns-in-haskell-rust-and-javascript/haskell-record-dot): Contains the Record Dot Syntax apporach.
Check out `src/House.hs` for the data structures, and `src/Main.hs` for all the examples throughout this post.
-```haskell
+```haskell ,linenos
data Address = Address
{ country :: String
, address :: String
@@ -129,15 +130,15 @@ house = Household
son = Person { id = 3, firstname = "Eric", lastname = "Swanson" }
```
-To allow overlapping record fields, we use [DuplicateRecordFields](https://github.com/adamgundry/ghc-proposals/blob/overloaded-record-fields/proposals/0000-overloaded-record-fields.rst#recap-duplicaterecordfields){target="_blank" rel="noopener noreferrer"} along with [OverloadedLabels](https://github.com/adamgundry/ghc-proposals/blob/overloaded-record-fields/proposals/0000-overloaded-record-fields.rst#recap-overloadedlabels){target="_blank" rel="noopener noreferrer"} (only in the Lens version), and a bunch of other extensions for deriving things via generics.
+To allow overlapping record fields, we use [DuplicateRecordFields](https://github.com/adamgundry/ghc-proposals/blob/overloaded-record-fields/proposals/0000-overloaded-record-fields.rst#recap-duplicaterecordfields) along with [OverloadedLabels](https://github.com/adamgundry/ghc-proposals/blob/overloaded-record-fields/proposals/0000-overloaded-record-fields.rst#recap-overloadedlabels) (only in the Lens version), and a bunch of other extensions for deriving things via generics.
We control the details of the JSON serialization / deserialization using the [derive-aeson](https://hackage.haskell.org/package/deriving-aeson) package + the [`DerivingVia`](https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0120-deriving-via.rst) language extension.
**Rust**
-The full setup can be found in [rust-serde](https://github.com/codetalkio/codetalk.io/tree/master/resources/code/common-json-patterns/rust-serde){target="_blank" rel="noopener noreferrer"}. Check out `src/house.rs` for the data structures, and `src/main.rs` for all the examples throughout this post.
+The full setup can be found in [rust-serde](https://github.com/codetalkio/codethoughts.io/tree/master/content/posts/2020-04-05-common-json-patterns-in-haskell-rust-and-javascript/rust-serde). Check out `src/house.rs` for the data structures, and `src/main.rs` for all the examples throughout this post.
-```rust
+```rust ,linenos
#[derive(Serialize, Deserialize, Debug, Clone)]
pub struct Address {
pub country: String,
@@ -183,10 +184,9 @@ pub fn house() -> Household {
If you wish to follow along, you can fire up a REPL for each approach. For the TypeScript and Rust versions, where we utilize mutability, we will clone the objects each time, to keep them consistent across examples and in our REPL.
-💡
+{% aside() %}
This setup unfortunately doesn't eliminate the need for a server yet! We'll have to dream of that day to come.
-
-
+{% aside() %}
+ In TypeScript this would more commonly be done using the spread operator, `...`, or using something like [`_.cloneDeep(value)`](https://lodash.com/docs/#cloneDeep).
+{% end %}
**TypeScript**
```bash
@@ -393,7 +393,7 @@ new_house.owner = new_ariel;
--> Household { /* Full Household object... */ }
```
-Alternatively we could use Rust's [Struct Update syntax](https://doc.rust-lang.org/book/ch05-01-defining-structs.html#creating-instances-from-other-instances-with-struct-update-syntax){target="_blank" rel="noopener noreferrer"}, `..`, which works much like the spread syntax (`...`) in JavaScript. It would look something like `Household { owner: new_ariel, ..house }`.
+Alternatively we could use Rust's [Struct Update syntax](https://doc.rust-lang.org/book/ch05-01-defining-structs.html#creating-instances-from-other-instances-with-struct-update-syntax), `..`, which works much like the spread syntax (`...`) in JavaScript. It would look something like `Household { owner: new_ariel, ..house }`.
### Set a nested field
Now it gets a bit more tricky.
@@ -419,7 +419,7 @@ house{ owner.firstname = "New Ariel"}
--> Household { {- Full Household object... -} }
```
-Note that the lack of spacing in `house{` is actually important, at least in the current state of [RecordDotSyntax](https://github.com/shayne-fletcher-da/ghc-proposals/blob/record-dot-syntax/proposals/0000-record-dot-syntax.md#3-examples){target="_blank" rel="noopener noreferrer"}.
+Note that the lack of spacing in `house{` is actually important, at least in the current state of [RecordDotSyntax](https://github.com/shayne-fletcher-da/ghc-proposals/blob/record-dot-syntax/proposals/0000-record-dot-syntax.md#3-examples).
**Rust:**
```rust
@@ -556,8 +556,6 @@ Like with Haskell, we let Rust know what data type we are trying to convert our
💡
- In TypeScript this would more commonly be done using the spread operator, `...`, or using something like [`_.cloneDeep(value)`](https://lodash.com/docs/#cloneDeep){target="_blank" rel="noopener noreferrer"}.
----- - Have other common patterns you'd like to see? Feel like some of the approaches could be improved? Leave a comment, and I will try to expand this list to be more comprehensive! ## Changelog @@ -574,12 +572,12 @@ Thanks to all the feedback from the [/r/rust](https://www.reddit.com/r/rust/comm - Switched the Rust approaches to use mutations instead of the unidiomatic immutable style it was written in. -[^moreOptions]: There are of course more options, like [Optics](https://www.well-typed.com/blog/2019/09/announcing-the-optics-library/){target="_blank" rel="noopener noreferrer"} ([usage example](https://www.reddit.com/r/haskell/comments/cyo4o2/welltyped_announcing_the_optics_library/eywc9ya?utm_source=share&utm_medium=web2x){target="_blank" rel="noopener noreferrer"}), but I won't cover them all here. +[^derivingAeson]: Along with [aeson](https://hackage.haskell.org/package/aeson), we will use the new [deriving-aeson](https://hackage.haskell.org/package/deriving-aeson) library to derive our instances. -[^derivingAeson]: Along with [aeson](https://hackage.haskell.org/package/aeson){target="_blank" rel="noopener noreferrer"}, we will use the new [deriving-aeson](https://hackage.haskell.org/package/deriving-aeson){target="_blank" rel="noopener noreferrer"} library to derive our instances. +[^moreOptions]: There are of course more options, like [Optics](https://www.well-typed.com/blog/2019/09/announcing-the-optics-library/) ([usage example](https://www.reddit.com/r/haskell/comments/cyo4o2/welltyped_announcing_the_optics_library/eywc9ya?utm_source=share&utm_medium=web2x)), but I won't cover them all here. -[^genericLens]: We use [generic-lens](https://github.com/kcsongor/generic-lens){target="_blank" rel="noopener noreferrer"} for Lens derivations instead of TemplateHaskell. +[^genericLens]: We use [generic-lens](https://github.com/kcsongor/generic-lens) for Lens derivations instead of TemplateHaskell. -[^recordDotSyntax]: It will take a bit of time before it is merged and available in GHC, so we will use the [record-dot-preprocessor](https://hackage.haskell.org/package/record-dot-preprocessor){target="_blank" rel="noopener noreferrer"} plugin to get a sneak peak. +[^recordDotSyntax]: It will take a bit of time before it is merged and available in GHC, so we will use the [record-dot-preprocessor](https://hackage.haskell.org/package/record-dot-preprocessor) plugin to get a sneak peak. [^dataMaybe]: `maybe` from Data.Maybe has the type signature `maybe :: b -> (a -> b) -> Maybe a -> b`, taking in as argument (1) a default value (2) a function to run if the value is `Just` and (3) the `Maybe` value we want to operate on. diff --git a/resources/code/common-json-patterns/rust-serde/Cargo.lock b/content/posts/2020-04-05-common-json-patterns-in-haskell-rust-and-javascript/rust-serde/Cargo.lock similarity index 100% rename from resources/code/common-json-patterns/rust-serde/Cargo.lock rename to content/posts/2020-04-05-common-json-patterns-in-haskell-rust-and-javascript/rust-serde/Cargo.lock diff --git a/resources/code/common-json-patterns/rust-serde/Cargo.toml b/content/posts/2020-04-05-common-json-patterns-in-haskell-rust-and-javascript/rust-serde/Cargo.toml similarity index 100% rename from resources/code/common-json-patterns/rust-serde/Cargo.toml rename to content/posts/2020-04-05-common-json-patterns-in-haskell-rust-and-javascript/rust-serde/Cargo.toml diff --git a/resources/code/common-json-patterns/rust-serde/src/house.rs b/content/posts/2020-04-05-common-json-patterns-in-haskell-rust-and-javascript/rust-serde/src/house.rs similarity index 100% rename from resources/code/common-json-patterns/rust-serde/src/house.rs rename to content/posts/2020-04-05-common-json-patterns-in-haskell-rust-and-javascript/rust-serde/src/house.rs diff --git a/resources/code/common-json-patterns/rust-serde/src/main.rs b/content/posts/2020-04-05-common-json-patterns-in-haskell-rust-and-javascript/rust-serde/src/main.rs similarity index 100% rename from resources/code/common-json-patterns/rust-serde/src/main.rs rename to content/posts/2020-04-05-common-json-patterns-in-haskell-rust-and-javascript/rust-serde/src/main.rs diff --git a/resources/code/common-json-patterns/typescript-json/.node-version b/content/posts/2020-04-05-common-json-patterns-in-haskell-rust-and-javascript/typescript-json/.node-version similarity index 100% rename from resources/code/common-json-patterns/typescript-json/.node-version rename to content/posts/2020-04-05-common-json-patterns-in-haskell-rust-and-javascript/typescript-json/.node-version diff --git a/resources/code/common-json-patterns/typescript-json/.vscode/settings.json b/content/posts/2020-04-05-common-json-patterns-in-haskell-rust-and-javascript/typescript-json/.vscode/settings.json similarity index 100% rename from resources/code/common-json-patterns/typescript-json/.vscode/settings.json rename to content/posts/2020-04-05-common-json-patterns-in-haskell-rust-and-javascript/typescript-json/.vscode/settings.json diff --git a/resources/code/common-json-patterns/typescript-json/house.ts b/content/posts/2020-04-05-common-json-patterns-in-haskell-rust-and-javascript/typescript-json/house.ts similarity index 100% rename from resources/code/common-json-patterns/typescript-json/house.ts rename to content/posts/2020-04-05-common-json-patterns-in-haskell-rust-and-javascript/typescript-json/house.ts diff --git a/resources/code/common-json-patterns/typescript-json/main.ts b/content/posts/2020-04-05-common-json-patterns-in-haskell-rust-and-javascript/typescript-json/main.ts similarity index 100% rename from resources/code/common-json-patterns/typescript-json/main.ts rename to content/posts/2020-04-05-common-json-patterns-in-haskell-rust-and-javascript/typescript-json/main.ts diff --git a/resources/code/common-json-patterns/typescript-json/package-lock.json b/content/posts/2020-04-05-common-json-patterns-in-haskell-rust-and-javascript/typescript-json/package-lock.json similarity index 100% rename from resources/code/common-json-patterns/typescript-json/package-lock.json rename to content/posts/2020-04-05-common-json-patterns-in-haskell-rust-and-javascript/typescript-json/package-lock.json diff --git a/resources/code/common-json-patterns/typescript-json/package.json b/content/posts/2020-04-05-common-json-patterns-in-haskell-rust-and-javascript/typescript-json/package.json similarity index 100% rename from resources/code/common-json-patterns/typescript-json/package.json rename to content/posts/2020-04-05-common-json-patterns-in-haskell-rust-and-javascript/typescript-json/package.json diff --git a/posts/2023-01-29-the-stack.md b/content/posts/2023-01-29-the-stack.md similarity index 95% rename from posts/2023-01-29-the-stack.md rename to content/posts/2023-01-29-the-stack.md index bdc1d39..f8175cb 100644 --- a/posts/2023-01-29-the-stack.md +++ b/content/posts/2023-01-29-the-stack.md @@ -1,8 +1,9 @@ ---- -title: "\"The Stack\": Everything you'll need" -tags: aws, cloud, infrastructure, cdk, rust -date: 2023-01-29 ---- ++++ +title = "\"The Stack\": Everything you'll need" +date = 2023-01-29 +[taxonomies] +tags = ["aws", "cloud", "infrastructure", "cdk", "rust"] ++++ This will be a series of blog posts where we will build up the perfect infrastructure setup for the majority of usecase, aka "The Stack". We'll be building everything on top of AWS. @@ -23,11 +24,19 @@ Some technology choices upfront: - We'll be using [Rust](https://www.rust-lang.org) throughout for each service, as it allows us to squeeze out the most performance while still giving us a nice developer experience. - [Federated GraphQL](https://www.apollographql.com/docs/federation/) will be our way of facilitating microservices. - + -# What will we be covering? +Here's an overview before we get into the details: -**You can see a sneak peak of the final setup below**. All of this will be covered in parts: +{{ toc() }} + +## What will we be covering? + +{% aside() %} + You can see a sneak peak of the final setup below. +{% end %} + +All of this will be covered in parts: - [Part 0: The introduction and goals (this post)](#what-will-we-be-covering) - The goals of "The Stack" and architecture overview @@ -62,7 +71,7 @@ Some technology choices upfront: - Part 15 (Bonus): Billing breakdown - Forming an overview of service costs via Billing Tags and the Cost Explorer -# Account Structure and Governance +## Account Structure and Governance Reorganizing your AWS Account structure is a pain, so let's see if we can get this right from the beginning. There are a few things that direct our choices here: @@ -131,7 +140,7 @@ graph TD class ControlTower,AWSProdMultiTenantAccount,AWSProdSingleTenantAccount,AWSIntegrationTestAccount,AWSPreviewAccount,AWSIndividualDeveloperAccount,AWSMonitoringAccount,AWSLogsAccount container; -# Service Infrastructure +## Service Infrastructure Each of the infrastructure accounts (Production, Integration, Developer) all hold the same services and follow the same setup. The infrastructure we will make might seem complex at first, and it is, but as we go through each piece everything will start to make sense. @@ -142,7 +151,7 @@ The diagram gets quite large, so we will split it up into three parts: - Asynchronous Work and Media -#### Client to Frontend +### Client to Frontend Let's focus first on the Client to Frontend paths: @@ -192,7 +201,7 @@ graph TD -#### Client to API +### Client to API As we can see, the two Frontends need something to talk to, let's check out the APIs: @@ -249,7 +258,7 @@ graph TD class Certificate,Frontend,Internal,API,Media,Database,Notification,Async,Monitoring container; -#### Asynchronous Work and Media +### Asynchronous Work and Media And finally we can see the Media and Async work (the Database and some APIs reappear here as well): @@ -309,7 +318,7 @@ graph TD -#### One diagram to rule them all +### One diagram to rule them all If we combine all the individual diagrams, we get: @@ -412,6 +421,6 @@ graph TD -# Next Steps +## Next Steps -Next up is to start building! Follow along in [Part 1 of the series here](/posts/2023-01-29-the-stack-part-1.html). +Next up is to start building! Follow along in [Part 1 of the series here](@/posts/2023-10-07-the-stack-part-1/index.md). diff --git a/posts/2023-10-07-the-stack-part-1.md b/content/posts/2023-10-07-the-stack-part-1/index.md similarity index 86% rename from posts/2023-10-07-the-stack-part-1.md rename to content/posts/2023-10-07-the-stack-part-1/index.md index a6ef950..d06496a 100644 --- a/posts/2023-10-07-the-stack-part-1.md +++ b/content/posts/2023-10-07-the-stack-part-1/index.md @@ -1,22 +1,13 @@ ---- -title: "The Stack Part 1: Setting up your AWS Account Structure" -tags: aws, cloud, infrastructure -date: 2023-10-07 ---- ++++ +title = "The Stack Part 1: Setting up your AWS Account Structure" +date = 2023-10-07 +[taxonomies] +tags = ["aws", "cloud", "infrastructure"] ++++ In [the last post](/posts/2023-01-29-the-stack.html) we went over the overall goals of "The Stack" and what we will be building. In this post we'll be setting up our AWS Account structure. See the full overview of posts [here](/posts/2023-01-29-the-stack.html#what-will-we-be-covering). -- [Set up Control Tower](#set-up-control-tower) - - [Step 1](#step-1) - - [Step 2](#step-2) - - [Step 3](#step-3) - - [Step 4](#step-4) - - [Step 5](#step-5) - - [Cleanup](#cleanup) -- [Adjusting Account Factory defaults](#adjusting-account-factory-defaults) -- [Set up our Development Organizational Unit](#set-up-our-development-organizational-unit) -- [Set up our AWS Accounts](#set-up-our-aws-accounts) -- [Next Steps](#next-steps) +{{ toc() }} As a reminder, here is the structure we are aiming for: @@ -29,7 +20,7 @@ As a reminder, here is the structure we are aiming for: - **Monitoring**: Centralize monitoring and observability into one account, allowing access to insights without access to sensitive logs or infrastructure from the other accounts - **Logs**: Centralized storage of logs, which may require different access considerations than metrics and traces - + Or, for the visual learners: @@ -147,9 +138,7 @@ We'll immediately start our good habit of adding billing tags whereever we can,
👈 Open the toggle for an example
-
-
-
+{{ image(path="the-stack-part-1-kms-step-1.png", caption="KMS Configuration", width=600) }}
-
-
-
+{{ image(path="the-stack-part-1-kms-error.png", caption="KMS error", width=650) }}
To avoid this:
@@ -172,7 +159,8 @@ To avoid this:
Replace `AWS_REGION`, `AWS_ACCOUNT_ID`, and `KMS_KEY_ID` and insert the following:
-```json
+
+```json ,linenos
{
"Sid": "Allow Config to use KMS for encryption",
"Effect": "Allow",
@@ -221,10 +209,9 @@ Finally, we'll also cleanup the VPCs that were created in our Control Tower:
2. Click on **Your VPCs** in the menu on the left, and click on your Control Tower VPC.
3. Choose **Actions** and then choose **Delete VPC** as well as confirming the choice.
-
-
-
+{% end %}
## Adjusting Account Factory defaults
@@ -259,9 +246,7 @@ Find the User portal URL:
3. Copy the **User portal URL** from the **Federated access management** card.
4. Bookmark this URL, you're gonna need it a lot.
-💡
+{% aside() %}
If you missed the KMS policy adjustment in Step 4 and the creation fails, you can go into CloudFormation and delete the stack called `AWSControlTowerBP-BASELINE-CLOUDTRAIL-MASTER`. Once that is done, you can go back to the Control Tower console and click "Retry" to try again.
-
-
-
+{{ image(path="the-stack-part-1-user-portal-url.png", caption="User portal URL", width=600) }}
Once you're logged into the Control Tower account using the portal, jump into the Account Factory again:
@@ -290,10 +275,8 @@ Pick the appropriate Organizational unit according to the list above, and click
You should end up with an overall structure like the following (Preview environment missing, but should be in the Development OU):
-
-
-
-
+{{ image(path="the-stack-part-1-account-overview.png", caption="Account overview", width=300) }}
## Next Steps
-Next up, we will be looking at how we can set up and automate our deployments to these environments so that once we start building it will update automatically. Follow along in [Part 2 of the series](/posts/2023-01-29-the-stack-part-2.html).
+Next up, we will be looking at how we can set up and automate our deployments to these environments so that once we start building it will update automatically. Follow along in [Part 2 of the series](@/posts/2023-10-08-the-stack-part-2/index.md).
diff --git a/resources/images/the-stack-part-1-account-overview 2.png b/content/posts/2023-10-07-the-stack-part-1/the-stack-part-1-account-overview.png
similarity index 100%
rename from resources/images/the-stack-part-1-account-overview 2.png
rename to content/posts/2023-10-07-the-stack-part-1/the-stack-part-1-account-overview.png
diff --git a/resources/images/the-stack-part-1-kms-error.png b/content/posts/2023-10-07-the-stack-part-1/the-stack-part-1-kms-error.png
similarity index 100%
rename from resources/images/the-stack-part-1-kms-error.png
rename to content/posts/2023-10-07-the-stack-part-1/the-stack-part-1-kms-error.png
diff --git a/resources/images/the-stack-part-1-kms-step-1.png b/content/posts/2023-10-07-the-stack-part-1/the-stack-part-1-kms-step-1.png
similarity index 100%
rename from resources/images/the-stack-part-1-kms-step-1.png
rename to content/posts/2023-10-07-the-stack-part-1/the-stack-part-1-kms-step-1.png
diff --git a/resources/images/the-stack-part-1-user-portal-url 2.png b/content/posts/2023-10-07-the-stack-part-1/the-stack-part-1-user-portal-url.png
similarity index 100%
rename from resources/images/the-stack-part-1-user-portal-url 2.png
rename to content/posts/2023-10-07-the-stack-part-1/the-stack-part-1-user-portal-url.png
diff --git a/posts/2023-10-07-the-stack-part-2.md b/content/posts/2023-10-08-the-stack-part-2/index.md
similarity index 89%
rename from posts/2023-10-07-the-stack-part-2.md
rename to content/posts/2023-10-08-the-stack-part-2/index.md
index 9f237bc..9b5ace8 100644
--- a/posts/2023-10-07-the-stack-part-2.md
+++ b/content/posts/2023-10-08-the-stack-part-2/index.md
@@ -1,8 +1,9 @@
----
-title: "The Stack Part 2: Automating Deployments via CI"
-tags: aws, cloud, infrastructure, cdk, ci
-date: 2023-10-07
----
++++
+title = "The Stack Part 2: Automating Deployments via CI"
+date = 2023-10-08
+[taxonomies]
+tags = ["aws", "cloud", "infrastructure", "cdk", "ci"]
++++
In [the last post](/posts/2023-10-07-the-stack-part-1.html) we created our Control Tower structure with all of our AWS Accounts in it. In this post we will be automating our deployment process for each of these environments. See the full overview of posts [here](/posts/2023-01-29-the-stack.html#what-will-we-be-covering).
@@ -17,19 +18,9 @@ If you want to jump straight to the code, you can find it in the [GitHub reposit
Otherwise, let's jump in!
-
+
-- [AWS: Seting up Credentials](#aws-seting-up-credentials)
-- [GitHub: Setting up Environments](#github-setting-up-environments)
-- [CDK: Infrastructure as Code](#cdk-infrastructure-as-code)
-- [Automated Deployments via GitHub Actions](#automated-deployments-via-github-actions)
- - [Boostrap Workflow](#boostrap-workflow)
- - [Deployment Workflow](#deployment-workflow)
- - [Trigger the Workflows](#trigger-the-workflows)
-- [Manual alternative: Bootstrapping our Accounts](#manual-alternative-bootstrapping-our-accounts)
-- [Manual alternative: Deployments](#manual-alternative-deployments)
-- [Bonus: Justfile and just](#bonus-justfile-and-just)
-- [Next Steps](#next-steps)
+{{ toc() }}
## AWS: Seting up Credentials
@@ -42,10 +33,9 @@ We will need to set up credentials for our GitHub Actions to be able to deploy t
For each of these we will need to set up IAM credentials that we can use in GitHub Actions to deploy our resources into each of these accounts.
-
-
-
+{% end %}
Let's get set up. First we'll define a group for the user to go into, create the user, and then create the access keys for the user:
@@ -86,15 +76,11 @@ Repeat those steps with the relevant values for each of the environments `Integr
Your `Environment` overview will look like this:
-💡
+{% aside() %}
GitHub also supports authenticating to AWS via OpenID. Check out their docs on that [here](https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/configuring-openid-connect-in-amazon-web-services).
-
-
-
+{{ image(path="the-stack-part-2-environment-overview.png", caption="Overview of Environments", width=600) }}
And each environment will roughly look like this:
-
-
-
-
+{{ image(path="the-stack-part-2-environment-configuration.png", caption="Configuration, secrets, and variables of an environment", width=600) }}
## CDK: Infrastructure as Code
@@ -128,7 +114,8 @@ In `deployment.ts` you'll see the root of our CDK stack. This is where we will d
For now, we will only define the `Global` layer:
-```typescript
+
+```typescript ,linenos
// ...imports
const app = new cdk.App();
@@ -160,7 +147,8 @@ Our `GlobalStack` is then defined in `lib/global/stack.ts`, and more or less jus
The interesting bit here is the call to `new domain.Stack` which is what actually kicks off the provisioning of resources, which are defined inside the `lib/global/domain.ts` file on layer deeper:
-```typescript
+
+```typescript ,linenos
// ...imports
interface StackProps extends cdk.StackProps, domain.StackProps {}
@@ -183,7 +171,8 @@ We create our Hosted Zone via `new route53.HostedZone` and our ACM certificate v
Let's get our resources defined:
-```typescript
+
+```typescript ,linenos
// ...imports
export interface StackProps extends cdk.StackProps {
/**
@@ -235,7 +224,8 @@ The GitHub Actions YAML might feel a bit verbose, so let's break it down a bit.
We first define our name and the trigger. Because we only want this to be triggered manually (bootstrapping just needs to run once) we can use `workflow_dispatch` which allows us to trigger it from the GitHub Actions UI ([docs here](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflow_dispatch)):
-```yaml
+
+```yaml ,linenos
name: "Deployment: Bootstrap"
on:
@@ -249,7 +239,8 @@ A neat way to "do the same thing" over a set of different things is to utilize t
This is what the `strategy` section does, and it then feeds this into the `environment` which tells GitHub Actions which environment variables and secrets are available, as well as automatically tracks our deployments in the GitHub UI:
-```yaml
+
+```yaml ,linenos
# ...
jobs:
bootstrap:
@@ -271,7 +262,8 @@ Now, what would happen if we ran this multiple times in parallel on the same env
To prevent this, we can tell GitHub to only allow one job to run at a time, given a group identifier. We do this by adding a `concurrency` control to our workflow ([docs here](https://docs.github.com/en/actions/using-jobs/using-concurrency)):
-```yaml
+
+```yaml ,linenos
# ...
# Limit to only one concurrent deployment per environment.
concurrency:
@@ -282,7 +274,8 @@ To prevent this, we can tell GitHub to only allow one job to run at a time, give
And finally, we get to the actual steps of logic we are performing. First we'll checkout our code, set up bun, and then use bun to install our dependencies:
-```yaml
+
+```yaml ,linenos
# ...
steps:
- uses: actions/checkout@v3
@@ -298,7 +291,8 @@ Now we're ready to bootstrap! We use the variables and secrets we defined previo
We pull in what we need, and then run the `cdk bootstrap` command via bun:
-```yaml
+
+```yaml ,linenos
# ...
- name: Bootstrap account
working-directory: ./deployment
@@ -316,9 +310,7 @@ Our deployment flow gets a bit more complicated. We're building for the future h
We will be building up the following flow, illustrated in the diagram below:
-
-
-
-
+{{ image(path="the-stack-part-2-deployment-flow.png", caption="Deployment flow", width=700) }}
This is what is called a "staggered deployment", but across our environments:
@@ -326,8 +318,8 @@ This is what is called a "staggered deployment", but across our environments:
- We validate that our IaC actually works.
2. Once the deployment is done, we perform checks against it to validate the health of the deployment (e.g. End-to-End tests, smoke tests, etc)
- We validate that our application actually works with our changes to our infrastructure.
-4. If everything looks good, we proceed to **Stage 2** which deploys both our `Production Single-tenant` and `Production Multi-tenant` environments in parallel.
-5. We do a final check that all is good, and then we're done!
+3. If everything looks good, we proceed to **Stage 2** which deploys both our `Production Single-tenant` and `Production Multi-tenant` environments in parallel.
+4. We do a final check that all is good, and then we're done!
This helps us build confidence that our deployments work, since our aim is to deploy changes immediately as they are merged into our `main` branch.
@@ -335,7 +327,8 @@ This helps us build confidence that our deployments work, since our aim is to de
Let's take a look at how we do this. First, we'll set up our triggers. We want to both allow manually triggering a deployment, again via `workflow_dispatch`, but we also want to immediately deploy when changes are merged to our `main` branch:
-```yaml
+
+```yaml ,linenos
name: "Deployment: Deploy to AWS"
on:
@@ -348,7 +341,8 @@ on:
All good and well, so let's start defining our jobs. Ignore the `uses` for now, that's a reuseable workflow which we'll get back to later in **Part 2** of this section:
-```yaml
+
+```yaml ,linenos
# ...
jobs:
# Stage 1 tests that the deployment is working correctly.
@@ -365,7 +359,8 @@ We first initiate our **Stage 1** deployment, specifying that it's the `Integrat
Next, we want to run our checks, but only after our **Stage 1** job has finished running successfully. To do this we use `needs` to define a dependency on a previous job ([docs here](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idneeds)).
-```yaml
+
+```yaml ,linenos
# ...
# Run tests against the environments from Stage 1.
stage-1-check:
@@ -385,7 +380,8 @@ We aren't doing much interesting for now in our test job, since we are only depl
Similarly, we use `needs` again to specify how we move into **Stage 2**. We first set up `Production Single-tenant`:
-```yaml
+
+```yaml ,linenos
# ...
# Stage 2 is our more critical environments, and only proceeds if prior stages succeed.
stage-2-single:
@@ -411,7 +407,8 @@ Similarly, we use `needs` again to specify how we move into **Stage 2**. We firs
And do the same for our `Production Multi-tenant` environment:
-```yaml
+
+```yaml ,linenos
# ...
stage-2-multi:
name: "Stage 2: Multi-tenant"
@@ -438,9 +435,8 @@ We could have been using using build `matrix`'s again, but that would mean that
Voila 🎉 We've now set the skeleton for the deployment flow we pictured earlier:
-
-
-
-
+
+{{ image(path="the-stack-part-2-deployment-flow.png", caption="Deployment flow", width=700) }}
**Part 2: Reuseable workflow**
@@ -450,7 +446,8 @@ We've done this in our `wf-deploy.yml` workflow, which we use in our `stage-1`,
First, we will need to define which inputs this workflow takes. Remember the `with` and `secrets` that we used earlier? That's how we pass information to our resuseable workflow. We define these in the `inputs` section:
-```yaml
+
+```yaml ,linenos
name: Deploy
on:
@@ -466,7 +463,8 @@ Here we simply specify that we require an `environment` to be passed along. We w
We can now proceed to the logic, which resembles the `cd-bootstrap` workflow we looked at earlier. We first set up our environment, concurrency group, and then install our dependencies:
-```yaml
+
+```yaml ,linenos
# ...
jobs:
deploy:
@@ -489,7 +487,8 @@ jobs:
Before we proceed to actually deploying anything, we want to sanity check that our deployment looks valid. We do this by trying to first synthesize the whole deployment ([some info on synth here](https://docs.aws.amazon.com/cdk/v2/guide/hello_world.html)), and then run whatever test suite we have:
-```yaml
+
+```yaml ,linenos
# ...
- name: Synthesize the whole stack
working-directory: ./deployment
@@ -513,7 +512,8 @@ Before we proceed to actually deploying anything, we want to sanity check that o
Everything should now be good, so let's run our actual deployment:
-```yaml
+
+```yaml ,linenos
# ...
- name: Deploy to ${{ inputs.environment }}
working-directory: ./deployment
@@ -534,9 +534,7 @@ Push your project to GitHub. You now have access to the workflows and can trigge
If you haven't done it already, let's run the `Deployment: Bootstrap` workflow first, to set up CDK on all accounts. Alternatively, jump to the section [Manual alternative: Bootstrapping our Accounts](#manual-alternative-bootstrapping-our-accounts) for how to do this manually.
-
-
-
-
+{{ image(path="the-stack-part-2-trigger-bootstrap-workflow.png", caption="Manually trigger the bootstrap workflow", width=700) }}
Next up, before we initiate the deployment it's recommended to be logged into your Domain Registrar that controls the DNS of your domain, so that you can quickly update your name servers to point to the Hosted Zone that we will be creating. This is necessary to DNS validate our ACM certificates.
@@ -559,9 +557,8 @@ This can easily take 5-15 minutes to complete the first time, depending on how q
You can go and see the generated CloudFormation stacks in the [AWS Console -> CloudFormation](https://console.aws.amazon.com/cloudformation/) which will look something like this:
-
-
-
-
+
+{{ image(path="the-stack-part-2-cloudformation.png", caption="Cloudformation stacks", width=600) }}
We've now set up the foundation for all of our future deployments of applications and services 🥳
@@ -635,7 +632,8 @@ $ curl --proto '=https' --tlsv1.2 -sSf https://just.systems/install.sh | bash -s
This allows us to set up a `justfile` in the root of our project, which we can then use to define shortcuts to our commands. For example, we can define a shortcut to run our CDK commands:
-```makefile
+
+```makefile ,linenos
# Display help information.
help:
@ just --list
@@ -691,4 +689,4 @@ $ just deploy # or just deploy Global
## Next Steps
-Next up is to add our first Frontend! Follow along in [Part 3 of the series](/posts/2023-10-16-the-stack-part-3.html).
+Next up is to add our first Frontend! Follow along in [Part 3 of the series](@/posts/2023-10-16-the-stack-part-3/index.md).
diff --git a/resources/images/the-stack-part-2-cloudformation.png b/content/posts/2023-10-08-the-stack-part-2/the-stack-part-2-cloudformation.png
similarity index 100%
rename from resources/images/the-stack-part-2-cloudformation.png
rename to content/posts/2023-10-08-the-stack-part-2/the-stack-part-2-cloudformation.png
diff --git a/resources/images/the-stack-part-2-deployment-flow.png b/content/posts/2023-10-08-the-stack-part-2/the-stack-part-2-deployment-flow.png
similarity index 100%
rename from resources/images/the-stack-part-2-deployment-flow.png
rename to content/posts/2023-10-08-the-stack-part-2/the-stack-part-2-deployment-flow.png
diff --git a/resources/images/the-stack-part-2-environment-configuration.png b/content/posts/2023-10-08-the-stack-part-2/the-stack-part-2-environment-configuration.png
similarity index 100%
rename from resources/images/the-stack-part-2-environment-configuration.png
rename to content/posts/2023-10-08-the-stack-part-2/the-stack-part-2-environment-configuration.png
diff --git a/resources/images/the-stack-part-2-environment-overview.png b/content/posts/2023-10-08-the-stack-part-2/the-stack-part-2-environment-overview.png
similarity index 100%
rename from resources/images/the-stack-part-2-environment-overview.png
rename to content/posts/2023-10-08-the-stack-part-2/the-stack-part-2-environment-overview.png
diff --git a/resources/images/the-stack-part-2-trigger-bootstrap-workflow.png b/content/posts/2023-10-08-the-stack-part-2/the-stack-part-2-trigger-bootstrap-workflow.png
similarity index 100%
rename from resources/images/the-stack-part-2-trigger-bootstrap-workflow.png
rename to content/posts/2023-10-08-the-stack-part-2/the-stack-part-2-trigger-bootstrap-workflow.png
diff --git a/content/posts/2023-10-16-the-stack-part-3/index.md b/content/posts/2023-10-16-the-stack-part-3/index.md
new file mode 100644
index 0000000..5c757c4
--- /dev/null
+++ b/content/posts/2023-10-16-the-stack-part-3/index.md
@@ -0,0 +1,1881 @@
++++
+title = "The Stack Part 3: Building a Frontend"
+date = 2023-10-16
+[taxonomies]
+tags = ["rust", "typescript", "wasm", "nextjs", "leptos", "aws", "cloud", "infrastructure", "cdk", "ci"]
++++
+
+In [the last post](/posts/2023-10-07-the-stack-part-2.html) we set up our deployment, fully automated on merge to our `main` branch. In this post we will be building our UI (Frontend) applications. See the full overview of posts [here](/posts/2023-01-29-the-stack.html#what-will-we-be-covering).
+
+At the end of this post we will have:
+
+- A [Next.js](https://nextjs.org/) Frontend app with support for localization, using Tailwind CSS.
+- A [Leptos](https://github.com/leptos-rs/leptos) Rust/WASM Frontend app with support for localization, using Tailwind CSS.
+- Automatic deployment of our Apps AWS using CDK, statically hosted using S3 + CloudFront.
+
+We are essentially hedging our bets by building both a JavaScript-based Frontend, which is the safe bet, and a Rust/WASM-based Frontend, which is the future bet. We will be using the same GraphQL API for both, so we can easily switch between them.
+
+There is quite a lot to cover. My recommendation is to clone down the Part 3 branch in the [GitHub repository](https://github.com/codetalkio/the-stack/tree/part-3-frontend) and use this post as an explanation of what is set up.
+
+
+
+{{ toc() }}
+
+
+## Prelude: Static Site Generation
+
+While SSR (Server Side Rendering) is seeing a renaissance these days, we are intentionally avoiding this functionality. If you remember the architecture outlined in [our introduction to the series](/posts/2023-01-29-the-stack.html#what-will-we-be-covering), we want to be able to serve our Frontend entirely using static file hosting.
+
+There are multiple reasons for this, going back to our core design goals:
+
+- **Low cost**: Static file hosting is extremely cheap, and scales as well as S3/CloudFront does (i.e. *very well*).
+- **Low operational overhead**: Static file hosting is extremely simple to operate—there are no servers for us to worry about and scale up/down as needed, no need for any orchestration yet.
+- **Performant**: Static file hosting is extremely performant, as the files are served directly from the edge, and not from a server.
+
+We do sacrifice the ability to do SSR and the various User Experiences that can potentially bring, but the benefits are far outweighed by the downsides in this tradeoff.
+
+## Next.js
+
+Next.js is one of the most popular React frameworks at the moment, and supports a lot of niceties as well as sets us on a path of a good structure from the get-go. It has a lot of momentum behind it, a strong focus on the Developer Experience, and uses React which makes it a very familiar option for a large majority of Frontend Engineers out there.
+
+We'll once again use [Bun](https://bun.sh/), which you can install via:
+
+```bash
+$ curl -fsSL https://bun.sh/install | bash
+```
+
+While [bun unfortunately doesn't fully support the Next.js App Router yet](https://bun.sh/guides/ecosystem/nextjs) we will still rely on it for installing dependencies and being our general go-to tool for running anything JS related.
+
+#### Setting up our Next.js App
+
+Let's get our Next.js app set up, which we will call `ui-app`:
+
+```bash
+$ bun create next-app # Call it ui-app
+✔ What is your project named? … ui-app
+✔ Would you like to use TypeScript? … Yes
+✔ Would you like to use ESLint? … Yes
+✔ Would you like to use Tailwind CSS? … Yes
+✔ Would you like to use `src/` directory? … Yes
+✔ Would you like to use App Router? (recommended) … Yes
+✔ Would you like to customize the default import alias (@/*)? … No
+```
+
+This gets us quite far, we now have an App we can run, Tailwind CSS is already set up, and we got a lot of the structure set up for us:
+
+```bash
+$ cd ui-app
+$ bun run dev # or bun run build
+next dev
+ ▲ Next.js 13.5.4
+ - Local: http://localhost:3000
+
+ ✓ Ready in 3s
+```
+
+Voila, we've got a little Hello World Next.js app!
+
+#### Building Static Files
+
+We need to do just one small change to our Next.js setup to make it output static files for us. We'll do this by adding `output: "export"` to our `next.config.js` file at the root of `ui-app/`:
+
+
+```typescript ,linenos
+// @ts-check
+
+/** @type {import('next').NextConfig} */
+const nextConfig = {
+ output: "export",
+ trailingSlash: true,
+ experimental: {
+ // Statically type links to prevent typos and other errors when using next/link, improving type safety when navigating between pages.
+ typedRoutes: true,
+ },
+};
+
+module.exports = nextConfig;
+```
+
+We also enabled `trailingSlash` ([docs here](https://nextjs.org/docs/pages/api-reference/next-config-js/trailingSlash)) to make Next.js work nicely with CloudFront.
+
+This tells Next.js that we want to to [Statically Export](https://nextjs.org/docs/app/building-your-application/deploying/static-exports) our files, which will generate an HTML file per route, which allows each route to serve the minimal content it needs, enabling faster page loads, instead of the traditional SPA approach of serving one large file upfront.
+
+We get the best of both worlds here, as we still get the reduced bundle sizes typical of SSR, but can retain the static file advantage of SPAs.
+
+#### Setting up Localization
+
+As our customer-base grows, we will inevitably run into the need to localization. To do this, we will restructure our App with basic support for this, as well as bring in a dependency to help us with this, namely [next-intl](https://www.npmjs.com/package/next-intl). Vercel also has some good documentation on how to [Get Started](https://next-intl-docs.vercel.app/docs/getting-started/app-router-client-components) here.
+
+Let's start by adding the dependency:
+
+```bash
+$ bun add next-intl
+```
+
+We'll also create a folder that will contain our localization files, which we'll call `messages/` in the root of the `ui-app/` project:
+
+```bash
+$ mkdir messages
+```
+
+This allows us to set up some text for our first languages. Create an English locale, `messages/en.json`, with the following:
+
+
+```json ,linenos
+{
+ "home": {
+ "intro": "Welcome!"
+ }
+}
+```
+
+And also a French locale, in `messages/fr.json`:
+
+
+```json ,linenos
+{
+ "home": {
+ "intro": "Bienvenue!"
+ }
+}
+```
+
+To make this a bit nicer to work with, we'll also [add typesafety](https://next-intl-docs.vercel.app/docs/workflows/typescript) by letting TypeScript know what keys we support in our localization function. Create a `ui-app/global.d.ts` file with the following:
+
+
+```typescript ,linenos
+// Use type safe message keys with `next-intl`, based on the contents/keys of
+// our default english locale.
+type Messages = typeof import("./messages/en.json");
+declare interface IntlMessages extends Messages {}
+```
+
+This ensures that if we misspell a key, or even remove one later on, we will be highlighted of the incorrect usage by TypeScript.
+
+We can now set up a route using the App Router to pick up our locale. We'll want the locale to be part of our URL as a prefix on all routes, so that we can pick it up as a [dynamic segment](https://nextjs.org/docs/app/building-your-application/routing/defining-routes#creating-routes) and use it to load the correct localization file.
+
+First we will create a folder where our localized pages will live in, and also clean up the default files that Next.js created for us:
+
+```bash
+$ mkdir "src/app/[locale]"
+$ rm src/app/page.tsx src/app/layout.tsx
+```
+
+Let's create a simply page in here at `src/app/[locale]/page.tsx`, and get our welcome text from the localization file:
+
+
+```typescript ,linenos
+"use client";
+
+import { useTranslations } from "next-intl";
+
+export default function Home() {
+ const t = useTranslations("home");
+
+ return (
+ // Name="grid place-content-center content-center h-screen">
+ 
-{t("intro")}
+
+
+ );
+}
+```
+
+We'll need to mark the component as `'use client'` for now, while [next-intl is working on server-side support](https://next-intl-docs.vercel.app/docs/getting-started/app-router-server-components).
+
+Since we removed existing layout file, we need to define a new one that also handles setting up our localization at the root of our components. We'll create a `src/app/[locale]/layout.tsx` file with the following:
+
+
+```typescript ,linenos
+import "../globals.css";
+import type { Metadata } from "next";
+import { Inter } from "next/font/google";
+import { NextIntlClientProvider } from "next-intl";
+import { notFound } from "next/navigation";
+import { ReactNode } from 'react';
+import { promises as fs } from 'fs';
+
+export const metadata: Metadata = {
+ title: "Hello, World!",
+ description: "Ready to set things up",
+}
+
+const inter = Inter({ subsets: ["latin"] });
+
+/**
+ * Set up all supported locales as static parameters, which ensures we generate
+ * static pages for each possible value of `locale`.
+ */
+export async function generateStaticParams() {
+ // Construct an array of all supported locales based on the files in the `messages/` directory.
+ const localeFiles = await fs.readdir(`${process.cwd()}/messages`);
+ return localeFiles.map((f) => ({locale: f.replace(/\.json$/, "")}));
+}
+
+/**
+ * Load the contents of a given locale's messages file.
+ */
+async function messagesContent(locale: string) {
+ try {
+ return (await import(`../../../messages/${locale}.json`)).default;
+ } catch (error) {
+ console.error("Something went wrong", error);
+ notFound();
+ }
+}
+
+type Props = {
+ children: ReactNode;
+ params: {
+ locale: string;
+ };
+};
+
+export default async function Layout({ children, params: { locale } }: Props) {
+ const messages = await messagesContent(locale);
+ return (
+
+ // Name={inter.className}>
+
+ {children}
+
+
+
+ );
+}
+```
+
+To avoid needing to maintain a hardcoded list of locales, we dynamically find all the locales defined in our `messages/` folder during build time, and construct a list of supported locales from this. We then pass the contents of this into `NextIntlClientProvider`.
+
+We could imagine later on, once our translation file becomes massive, that we split up `en.json` into smaller segments such as `en/home.json`, and load these parts specifically in a `app/[locale]/home/layout.tsx` file. For now though, we'll keep it simple.
+
+As the final piece of this puzzle, we need a way to let Next.js know where it should route to by default, since we removed the default root pages.
+
+We unfortunately cannot use [middlewares](https://next-intl-docs.vercel.app/docs/routing/middleware) when statically exporting our site, so we will instead redirect the user upon loading the page. Create a `src/app/page.tsx` file with the following:
+
+
+```typescript ,linenos
+import { redirect } from "next/navigation";
+
+export default function Root() {
+ redirect("/en");
+}
+```
+
+Along with a root layout file at `src/app/layout.tsx`:
+
+```typescript
+import { ReactNode } from "react";
+
+type Props = {
+ children: ReactNode;
+};
+
+export default function Layout({ children }: Props) {
+ return children;
+}
+```
+
+You should now have a structure that looks like this:
+
+```bash
+.
+├── README.md
+├── bun.lockb
+├── global.d.ts
+├── messages
+│ └── en.json
+│ └── fr.json
+├── next.config.js
+├── package.json
+├── postcss.config.js
+├── public
+│ └── favicon.ico
+├── src
+│ └── app
+│ ├── [locale]
+│ │ ├── layout.tsx
+│ │ └── page.tsx
+│ ├── favicon.ico
+│ ├── globals.css
+│ ├── layout.tsx
+│ └── page.tsx
+├── tailwind.config.ts
+└── tsconfig.json
+```
+
+And that's it! We're now able to run our app and check it out in the browser:
+
+```bash
+$ bun run dev
+```
+
+{{ image(path="the-stack-part-3-ui-app-skeleton.png", caption="Screenshot of our ui-app", width=500) }}
+
+It may not look like much, but we've implemented a lot of the core functionality we need to get started, such as static builds and localization.
+
+As the final step we will add our commands to just, [extending our existing justfile](/posts/2023-10-07-the-stack-part-2.html#bonus-just):
+
+
+```makefile ,linenos
+_setup-ui-app:
+ #!/usr/bin/env bash
+ set -euxo pipefail
+ cd ui-app
+ bun install
+```
+
+We'll also set up a new command for running our development server:
+
+
+```makefile ,linenos
+# Run
+ Go to fr
+ Go to en
+
+
"Hello, world!"
} +} +``` + +We can now run our App using Trunk: + +```bash +$ trunk serve --open +``` + +Voila, we've got a little Hello World Leptos app! + +#### Setting up Tailwind CSS + +Let's configure Tailwind CSS for our Leptos App. First, we need to tell Tailwind where to look for files that might contain our CSS classes. Create a `ui-internal/tailwind.config.ts` file with the following: + + +```typescript ,linenos +/** @type {import('tailwindcss').Config} */ +module.exports = { + content: { + files: ["*.html", "./src/**/*.rs"], + }, + theme: { + extend: {}, + }, + plugins: [], +}; +``` + +We also need to tell `trunk` to build Tailwind CSS as part of its build process. We can do this by creating a `ui-internal/Trunk.toml` file: + + +```toml ,linenos +[[hooks]] +stage = "pre_build" +command = "sh" +command_arguments = [ + "-c", + "bunx tailwindcss --input resources/input.css --output public/output.css", +] +``` + +This let's `trunk` know that before it builds our WASM App, it should run the `bunx tailwindcss ...` command, which will generate our Tailwind CSS file, which it puts into `public/output.css`. + +Now, you might have noticed we also have an input file. Let's get that set up, along with a `resources/` folder: + +```bash +$ mkdir ui-internal/resources +``` + +We'll then create our base Tailwind CSS file at `ui-internal/resources/input.css`, mimicing our Next.js setup: + + +```css ,linenos +@tailwind base; +@tailwind components; +@tailwind utilities; + +:root { + --foreground-rgb: 0, 0, 0; + --background-start-rgb: 214, 219, 220; + --background-end-rgb: 255, 255, 255; +} + +@media (prefers-color-scheme: dark) { + :root { + --foreground-rgb: 255, 255, 255; + --background-start-rgb: 0, 0, 0; + --background-end-rgb: 0, 0, 0; + } +} + +body { + color: rgb(var(--foreground-rgb)); + background: linear-gradient( + to bottom, + transparent, + rgb(var(--background-end-rgb)) + ) + rgb(var(--background-start-rgb)); +} + +``` + +Final step, we need to pull in our Tailwind CSS file in our `index.html`. Update the contents to the following: + + +```html ,linenos + + + + + + + +
+
+ }
+}
+```
+
+The magic here comes from the `crate::i18n::*` which got generated by `leptos_i18n::load_locales!()`, and the `use_i18n` hook that we now got access to. Very similar to our Next.js App, we then call the macro `t!` to get the correct translation for the current locale, given a JSON key.
+
+We're not entirely done yet, we need to tell our Leptos App about the `I18nContext` at the root of our application. We also still need to add support for routing between locales.
+
+Let's update `src/app.rs` to do this:
+
+
+```rust ,linenos
+use crate::i18n::*;
+use leptos::*;
+use leptos_meta::*;
+use leptos_router::*;
+
+use crate::home;
+
+const DEFAULT_LOCALE: &str = "en";
+
+#[derive(Params, PartialEq, Clone, Debug)]
+pub struct LayoutParams {
+ locale: String,
+}
+
+#[component(transparent)]
+fn LocalizedRoute{t!(i18n, home.intro)}
+
+ "Go to fr"
+ "Go to en"
+
+
-
+{% end %}
And finally, create a new file `src/bin/uniffi-bindgen.rs`:
-```rust
+
+```rust ,linenos
fn main() {
uniffi::uniffi_bindgen_main()
}
@@ -96,36 +103,32 @@ We’re now ready to build the binary for generating our bindings, and then use
```bash
# Build the uniffi-bindgen binary and our initial library file.
-cargo build
-cargo run --bin uniffi-bindgen generate --library ./target/debug/libmobile.a --language swift --out-dir ./bindings
-
+$ cargo build
+$ cargo run --bin uniffi-bindgen generate --library ./target/debug/libmobile.a --language swift --out-dir ./bindings
```
We also need to rename the FFI file to `module.modulemap` so that XCFramework will find it:
```bash
-mv ./bindings/sharedFFI.modulemap ./bindings/module.modulemap
-
+$ mv ./bindings/sharedFFI.modulemap ./bindings/module.modulemap
```
Now, let's add support for iOS, the Simulator and macOS via rustup:
```bash
-rustup target add aarch64-apple-darwin
-rustup target add aarch64-apple-ios
-rustup target add aarch64-apple-ios-sim
-rustup target add x86_64-apple-ios # iOS simulator, also needed on Arm Macs.
-
+$ rustup target add aarch64-apple-darwin
+$ rustup target add aarch64-apple-ios
+$ rustup target add aarch64-apple-ios-sim
+$ rustup target add x86_64-apple-ios # iOS simulator, also needed on Arm Macs.
```
and then build the library for all of our targets:
```bash
-carbo build --release --target=aarch64-apple-darwin
-carbo build --release --target=aarch64-apple-ios
-carbo build --release --target=aarch64-apple-ios-sim
-carbo build --release --target=x86_64-apple-ios
-
+$ carbo build --release --target=aarch64-apple-darwin
+$ carbo build --release --target=aarch64-apple-ios
+$ carbo build --release --target=aarch64-apple-ios-sim
+$ carbo build --release --target=x86_64-apple-ios
```
We'll combine `x86_64-apple-ios` and `aarch64-apple-ios-sim` into a single binary later on, but for now we keep them separate.
@@ -133,12 +136,11 @@ We'll combine `x86_64-apple-ios` and `aarch64-apple-ios-sim` into a single binar
If we want watchOS we need to handle things a bit differently, since these are Tier 3 targets (i.e. rustup won't have their stdlib):
```bash
-cargo +nightly build -Zbuild-std=std,panic_abort --release --target=aarch64-apple-watchos-sim
-cargo +nightly build -Zbuild-std=std,panic_abort --release --target=x86_64-apple-watchos-sim
-cargo +nightly build -Zbuild-std=std,panic_abort --release --target=aarch64-apple-watchos
-cargo +nightly build -Zbuild-std=std,panic_abort --release --target=armv7k-apple-watchos
-cargo +nightly build -Zbuild-std=std,panic_abort --release --target=arm64_32-apple-watchos
-
+$ cargo +nightly build -Zbuild-std=std,panic_abort --release --target=aarch64-apple-watchos-sim
+$ cargo +nightly build -Zbuild-std=std,panic_abort --release --target=x86_64-apple-watchos-sim
+$ cargo +nightly build -Zbuild-std=std,panic_abort --release --target=aarch64-apple-watchos
+$ cargo +nightly build -Zbuild-std=std,panic_abort --release --target=armv7k-apple-watchos
+$ cargo +nightly build -Zbuild-std=std,panic_abort --release --target=arm64_32-apple-watchos
```
That's a lot of targets, which represent all the various Watch models, as well as the simulators (we always need both ARM and x86).
@@ -147,35 +149,33 @@ That's a lot of targets, which represent all the various Watch models, as well a
```bash
# Combine the watchOS simulator libraries into a single file using lipo.
-mkdir -p target/watchOS-sim/release
-lipo -create target/aarch64-apple-watchos-sim/release/libmobile.a \\
-target/x86_64-apple-watchos-sim/release/libmobile.a \\
+$ mkdir -p target/watchOS-sim/release
+$ lipo -create target/aarch64-apple-watchos-sim/release/libmobile.a \\
+ target/x86_64-apple-watchos-sim/release/libmobile.a \\
-o target/watchOS-sim/release/libmobile.a
# Confirm the architectures.
-lipo -info target/watchOS-sim/release/libmobile.a
+$ lipo -info target/watchOS-sim/release/libmobile.a
# Combine the watchOS libraries into a single file using lipo.
-mkdir -p target/watchOS/release
-lipo -create target/aarch64-apple-watchos/release/libmobile.a \\
+$ mkdir -p target/watchOS/release
+$ lipo -create target/aarch64-apple-watchos/release/libmobile.a \\
target/arm64_32-apple-watchos/release/libmobile.a \\
target/armv7k-apple-watchos/release/libmobile.a \\
-o target/watchOS/release/libmobile.a
# Confirm the architectures.
-lipo -info target/watchOS/release/libmobile.a
-
+$ lipo -info target/watchOS/release/libmobile.a
```
We can then create our XCFramework:
```bash
-xcodebuild -create-xcframework \\
+$ xcodebuild -create-xcframework \\
-library ./target/aarch64-apple-ios-sim/release/libmobile.a -headers ./bindings \\
-library ./target/aarch64-apple-ios/release/libmobile.a -headers ./bindings \\
-library ./target/aarch64-apple-darwin/release/libmobile.a -headers ./bindings \\
-library ./target/watchOS-sim/release/libmobile.a -headers ./bindings \\
-library ./target/watchOS/release/libmobile.a -headers ./bindings \\
-output "ios/Shared.xcframework"
-
```
And finally, we'll combine `x86_64-apple-ios` and `aarch64-apple-ios-sim` into a single binary. If we included both of these in the XCFramework, `xcodebuild` would complain that these are the same, and not generate our XCFramework file. Oddly enough, it will not be able to build the project without both, so we let `xcodebuild` generate the XCFramework first, and then replace the binary with the fat binary:
@@ -184,18 +184,17 @@ And finally, we'll combine `x86_64-apple-ios` and `aarch64-apple-ios-sim` into a
# We need to combine the architectures for the iOS Simulator libraries after we've
# constructed the XCFramework, otherwise it will complain about them being the same,
# while also failing because of missing x86_64 if we omit it.
-mkdir -p target/iOS-sim/release
-lipo -create target/aarch64-apple-ios-sim/release/libmobile.a \\
- target/x86_64-apple-ios/release/libmobile.a \\
- -o target/iOS-sim/release/libmobile.a
+$ mkdir -p target/iOS-sim/release
+$ lipo -create target/aarch64-apple-ios-sim/release/libmobile.a \\
+ target/x86_64-apple-ios/release/libmobile.a \\
+ -o target/iOS-sim/release/libmobile.a
# Confirm the architectures.
-lipo -info target/iOS-sim/release/libmobile.a
+$ lipo -info target/iOS-sim/release/libmobile.a
# Move it into place.
-rm ios/Shared.xcframework/ios-arm64-simulator/libmobile.a
-cp target/iOS-sim/release/libmobile.a ios/Shared.xcframework/ios-arm64-simulator/libmobile.a
-
+$ rm ios/Shared.xcframework/ios-arm64-simulator/libmobile.a
+$ cp target/iOS-sim/release/libmobile.a ios/Shared.xcframework/ios-arm64-simulator/libmobile.a
```
Done!
-As the final step we drag-n-drop `./ios/Shared.xcframework` and `./bindings/shared.swift` into the XCode project whereever you want them. I personally like to create a new group (folder) called `Generated` for them (the `build-ios.sh` script assumes that's the case)..
+As the final step we *drag-n-drop* `./ios/Shared.xcframework` and `./bindings/shared.swift` into the XCode project whereever you want them. I personally like to create a new group (folder) called `Generated` for them (the `build-ios.sh` script assumes that's the case).
diff --git a/posts/2024-06-24-using-capacitor-plugins-from-rust-wasm.md b/content/posts/2024-06-24-using-capacitor-plugins-from-rust-wasm/index.md
similarity index 88%
rename from posts/2024-06-24-using-capacitor-plugins-from-rust-wasm.md
rename to content/posts/2024-06-24-using-capacitor-plugins-from-rust-wasm/index.md
index b362727..79e62f2 100644
--- a/posts/2024-06-24-using-capacitor-plugins-from-rust-wasm.md
+++ b/content/posts/2024-06-24-using-capacitor-plugins-from-rust-wasm/index.md
@@ -1,16 +1,17 @@
----
-title: "Using Capacitor Plugins from Rust/WASM"
-tags: rust, wasm, leptos, mobile
-date: 2024-06-24
----
++++
+title = "Using Capacitor Plugins from Rust/WASM"
+date = 2024-06-24
+[taxonomies]
+tags = ["rust", "wasm", "leptos", "mobile"]
++++
-This is a part of the post [Mobile: A different way using Rust?](/posts/2024-06-25-mobile-a-different-way.html).
+This is a part of the post [Mobile: A different way using Rust?](@/posts/2024-06-25-mobile-a-different-way/index.md).
Capacitor is normally used in combination with JavaScript projects, so there is little help available if you want to use it in a Rust/WASM project. Worry not! That's exactly what we'll take a look at in this post.
-Since Capacitor is a JS framework there will be a little extra work involved in interacting with any plugins, but it’s honestly not a lot we need to do. Let’s take a quick tour through what I’ve set up in the example repository [https://github.com/Tehnix/template-mobile-wasm](https://github.com/Tehnix/template-mobile-wasm)[.](https://github.com/Tehnix/playground-mobile-wasm?tab=readme-ov-file)
+Since Capacitor is a JS framework there will be a little extra work involved in interacting with any plugins, but it’s honestly not a lot we need to do. Let’s take a quick tour through what I’ve set up in the example repository [https://github.com/Tehnix/template-mobile-wasm](https://github.com/Tehnix/template-mobile-wasm).
-
+
We've set up four crates:
@@ -21,6 +22,12 @@ We've set up four crates:
In this post we'll focus on the `capacitor-rs` and `appy` crates, which contain our Capacitor bridge and our app where we'll use it respectively.
+An overview of what we'll cover:
+
+{{ toc() }}
+
+## Setting up `capacitor-rs`
+
First, let’s create a new library where we’ll keep the Capacitor bridge related code in:
```bash
@@ -51,13 +58,15 @@ mkdir src/plugins
Let’s set up our `capacitor-rs/src/lib.rs` to expose the plugins folder:
-```rust
+
+```rust ,linenos
pub mod plugins;
```
And finally, let’s update our dependencies of the Rust project in `./capacitor-rs/Cargo.toml`:
-```toml
+
+```toml ,linenos
[package]
name = "capacitor-rs"
version = "0.1.0"
@@ -71,6 +80,8 @@ wasm-bindgen-futures = { version = "0.4" }
js-sys = { version = "0.3" }
```
+## Bridging a CapacitorJS plugin
+
For this example we’ll set up the [Haptics](https://capacitorjs.com/docs/apis/haptics) plugin, which will allow us to provide tactile feedback from our App in response to user interactions.
Our approach will be:
@@ -84,7 +95,8 @@ Our approach will be:
Let’s add the TypeScript side of things in `./js/haptics.ts` which quite simply just wraps and exposes the Capacitor functionality:
-```tsx
+
+```tsx ,linenos
/**
* https://capacitorjs.com/docs/apis/haptics
*/
@@ -130,7 +142,8 @@ Which gives us a corresponding bundled file in `js-dist/haptics.js` that we can
As the final step, we’ll bridge this into our Rust code by setting up `src/plugins/haptics.rs`:
-```rust
+
+```rust ,linenos
use wasm_bindgen::prelude::*;
#[wasm_bindgen]
@@ -216,13 +229,17 @@ Let’s break down what’s going on here:
We also need to add a `src/plugins/mod.rs` file to expose our new plugin:
-```rust
+
+```rust ,linenos
pub mod haptics;
```
+## Calling it from our App
+
We’re now ready to use it in our App by adding the new `capacitor-rs` crate to our dependencies in our WASM app:
-```toml
+
+```toml ,linenos
# ...
[dependencies]
capacitor-rs = { version = "0.1.0", path = "../capacitor-rs" }
@@ -231,7 +248,8 @@ capacitor-rs = { version = "0.1.0", path = "../capacitor-rs" }
And then using it like you like a normal Rust function:
-```rust
+
+```rust ,linenos
use log::info;
use capacitor_rs::plugins::haptics;
use leptos::*;
@@ -260,8 +278,4 @@ And that’s it!
Since I can’t exactly screenshot a haptic vibration, here’s an example where we use the [Capacitor](https://capacitorjs.com/docs/basics/utilities) utility function to determine which platform we are on, set up in the same way:
-💡
+{% aside() %}
If you are rexporting another crate, like I am in the example repository, you can replace all of the contents of `src/lib.rs` with this line pointing to your other crate, e.g. “shared”, `shared::uniffi_reexport_scaffolding!();` ([docs here](https://mozilla.github.io/uniffi-rs/0.27/tutorial/Rust_scaffolding.html#libraries-that-depend-on-uniffi-components)).
-
- 
- 
-
-
+{{ images(paths=["using-capacitor-plugins-from-rust-wasm-iphone.png", "using-capacitor-plugins-from-rust-wasm-web.png"], captions=["Screenshot of Capacitor running on iPhone", "Screenshot of Capacitor running in Web"], widths=[400, 400]) }}
diff --git a/resources/images/using-capacitor-plugins-from-rust-wasm-iphone.png b/content/posts/2024-06-24-using-capacitor-plugins-from-rust-wasm/using-capacitor-plugins-from-rust-wasm-iphone.png
similarity index 100%
rename from resources/images/using-capacitor-plugins-from-rust-wasm-iphone.png
rename to content/posts/2024-06-24-using-capacitor-plugins-from-rust-wasm/using-capacitor-plugins-from-rust-wasm-iphone.png
diff --git a/resources/images/using-capacitor-plugins-from-rust-wasm-web.png b/content/posts/2024-06-24-using-capacitor-plugins-from-rust-wasm/using-capacitor-plugins-from-rust-wasm-web.png
similarity index 100%
rename from resources/images/using-capacitor-plugins-from-rust-wasm-web.png
rename to content/posts/2024-06-24-using-capacitor-plugins-from-rust-wasm/using-capacitor-plugins-from-rust-wasm-web.png
diff --git a/importable/2024-06-25-mobile-a-different-way.md b/content/posts/2024-06-25-mobile-a-different-way/index.md
similarity index 58%
rename from importable/2024-06-25-mobile-a-different-way.md
rename to content/posts/2024-06-25-mobile-a-different-way/index.md
index 52914d1..bbeba33 100644
--- a/importable/2024-06-25-mobile-a-different-way.md
+++ b/content/posts/2024-06-25-mobile-a-different-way/index.md
@@ -1,10 +1,11 @@
----
-title: "Mobile: A different way using Rust?"
-tags: rust, wasm, leptos, mobile, capacitor, swift, xcode
-date: 2024-06-25
----
++++
+title = "Mobile: A different way using Rust?"
+date = 2024-06-25
+[taxonomies]
+tags = ["rust", "wasm", "leptos", "mobile", "capacitor", "swift", "xcode"]
++++
-After having spent the better part of two months deep in the trenches of iOS development with Swift, I can comfortably say: Web Development simple is more mature.
+After having spent the better part of two months deep in the trenches of iOS development with Swift, I can comfortably say: Web Development simply is more mature.
Let’s just run over a few things I ran into that’s bad, broken, or made for a poor experience:
@@ -19,16 +20,19 @@ Let’s just run over a few things I ran into that’s bad, broken, or made for
- UI performance issues are very easy to sneak in, and very hard to track down
- Apple’s frameworks sure do have a lot of bugs and you’ll commonly see stuff being broken almost permanently
-Admittedly, these might be trivial grips for someone that has spent years in the Mobile ecosystem, but they certainly didn’t make me fall in love with it. More importantly, it wasn’t really providing a great user experience either.
+Admittedly, these might be trivial gripes for someone that has spent years in the Mobile ecosystem, but they certainly didn’t make me fall in love with it. More importantly, it wasn’t really providing a great user experience either.
….so what’s the alternative?
-
+
-
- 
-
-
+{% aside() %}
+ Looking for the TL;DR? Checkout [https://github.com/Tehnix/template-mobile-wasm](https://github.com/Tehnix/template-mobile-wasm) for a ready setup with Rust/Leptos, i18n, TailwindCSS, Capacitor + bindings, iOS/Android, Widget, watchOS, and code sharing to Swift + Kotlin.
+{% end %}
+
+Here's an overview of what we'll cover:
+
+{{ toc() }}
## The goals
@@ -52,18 +56,22 @@ Rust supports Frontend development via WASM, supported in all major browsers, an
Good alternatives for a full-stack language would be TypeScript and Node.js/Bun. For reasons we’ll see later, this is not the choice we go with in the end, but for now let’s consider it a viable alternative (it might be for you!).
-Now, how do we get our Rust or TypeScript code onto our different deployment targets? Let’s make an overview of how you’d typically do:
+Now, how do we get our Rust or TypeScript code onto our different deployment targets? Let’s make an overview of how you’d typically do. For good measure, let’s also compare with Dart/Flutter:
+
-| Language / Target | Backend Options | Frontend Options | Mobile Options |
-| --- | --- | --- | --- |
-| Rust | - Native Support | - Leptos (WASM) 💡
- Looking for the TL;DR? Checkout [https://github.com/Tehnix/template-mobile-wasm](https://github.com/Tehnix/template-mobile-wasm)
-- Dioxus (WASM)
- Yew (WASM)
- …etc | - Capacitor (WASM in WebView)
- Tauri (Beta, WASM in WebView) | -| TypeScript | - Node.js
- Bun | - Native Support (React, Vue, Svelte, Solid, etc) | - Capacitor (JS in WebView) | +| Language / Target | Backend Options | Frontend Options | Mobile Options | +|-------------|------------------|--------------------------|-------------------------------| +| Rust | - Native Support | - Leptos (WASM)
- Dioxus (WASM)
- Yew (WASM)
- …etc | - Capacitor (WASM in WebView)
- Tauri (Beta, WASM in WebView) | +| TypeScript | - Node.js
- Bun | - Native Support (React, Vue, Svelte, Solid, etc) | - Capacitor (JS in WebView) | +| Dart/Flutter| - Native Support | - Native for Dart
- Flutter (HTML or Canvas) | - Flutter | For Rust there are some interesting projects brewing such as [Robius](https://robius.rs) which is quite ambitious and hopefully gains traction. +The choice is not yet super clear here, and all could work so far. One concern I have with Dart/Flutter specifically is the lack of maturity in its Backend ecosystem currently. It you’ll quickly run into missing or unmaintained libraries. + **Choice**: Rust & WASM -**Alternative**: TypeScript & Node.js/Bun +**Alternative**: TypeScript + Node.js/Bun or Dart/Flutter ## **All Targets** @@ -77,9 +85,7 @@ If you want to develop an iOS Widget ([those little things](https://support.appl Here’s an example of a Widget for a Todo App, providing interactivity from the Home Screen: -
-
-
+{{ image(path="mobile-a-different-way-widget-screenshot.jpg", caption="Screenshot of Capacitor an iOS Widget", width=450) }}
This seemingly innocuous example is also where most of our options get limited and we’ll have to get a bit creative with how we solve it.
@@ -87,14 +93,15 @@ So how does support look like for our Mobile options? (we’ll simplify for a mo
| Mobile Options / Target Support | iOS App | macOS App | Widget Extension | watchOS | watchOS Complication |
| --- | --- | --- | --- | --- | --- |
-| Tauri | ✅ (sorta)* | ✅ (same App as the iOS App)*** | ❌ | ❌ | ❌ |
-| Capacitor | ✅ (sorta)** | ✅ (same App as the iOS App)*** | ✅⚠️ (via Native code) | ✅⚠️ (via Native code) | ✅⚠️ (via Native code) |
+| Tauri | ✅ (sorta)[^1] | ✅ (same App as the iOS App)[^2] | ❌ | ❌ | ❌ |
+| Capacitor | ✅ (sorta)[^3] | ✅ (same App as the iOS App)[^2] | ✅⚠️ (via Native code) | ✅⚠️ (via Native code) | ✅⚠️ (via Native code) |
+| Flutter | ✅ | ✅ | ✅⚠️ (via Native code) | ✅⚠️ (via Native code) | ✅⚠️ (via Native code) |
-*: Platform support overview here [https://v2.tauri.app/plugin/](https://v2.tauri.app/plugin/)
+[^1]: Platform support overview here [https://v2.tauri.app/plugin/](https://v2.tauri.app/plugin/)
-**: Platform support overview here [https://capacitorjs.com/docs/apis](https://capacitorjs.com/docs/apis)
+[^2]: This is the “Designed for iPad” type of App which is essentially an iOS App that runs completely native on ARM-based Macbooks. Alternatively you can also deploy it as an Electron App using [https://github.com/capacitor-community/electron](https://github.com/capacitor-community/electron) for other targets.
-***: This is the “Designed for iPad” type of App which is essentially an iOS App that runs completely native on ARM-based Macbooks. Alternatively you can also deploy it as an Electron App using [https://github.com/capacitor-community/electron](https://github.com/capacitor-community/electron) for other targets.
+[^3]: Platform support overview here [https://capacitorjs.com/docs/apis](https://capacitorjs.com/docs/apis)
Before continuing, let’s talk about that ✅⚠️ score though—what does that mean exactly?
@@ -104,23 +111,19 @@ But will our chosen framework support that, or will we get completely blocked ev
For Tauri, the answer is: We are blocked ([#9766](https://github.com/tauri-apps/tauri/issues/9766) is still open in the Tauri repo), and cannot proceed.
-Luckily, for Capacitor, that’s not entirely the case. We can open XCode and add our own Targets that will build alongside our App, for anything that we want, such as Widgets and our watchOS App.
+Luckily, for both Capacitor and Dart/Flutter, that’s not entirely the case. We can open XCode and add our own Targets that will build alongside our App, for anything that we want, such as Widgets and our watchOS App.
That looks like this in XCode:
-
-
-
-
-
-The limitation here is that these additional targets only support native code (i.e. Swift), which neatly brings us onto our next section.
+{{ image(path="mobile-a-different-way-xcode-adding-targets.png", caption="Adding additional Targets in Xcode", width=650) }}
-Now, getting back to the topic of the main app, how do we actually communicate with and/or use the native capabilities that Capacitor supports?
+The limitation here is that these additional targets only support native code (i.e. Swift or Kotlin/Java).
-I’ve written up a guide on how exactly to do that in detail here [Using Capacitor Plugins from Rust/WASM](/posts/2024-06-24-using-capacitor-plugins-from-rust-wasm.html).
+**Before jumping into the next section where we’ll look at code sharing**, how do we actually communicate with and/or use the native capabilities that Capacitor supports? I’ve written up a guide on how exactly to do that in detail here: [Using Capacitor Plugins from Rust/WASM](/posts/2024-06-24-using-capacitor-plugins-from-rust-wasm.html).
**Choice**: Capacitor
-**Alternative**: None
+**Alternative**: Dart/Flutter
## **Code Sharing**
@@ -132,12 +135,15 @@ This is where we get into the differences in our language choice. Our options ar
- Calling Rust using [UniFFI](https://mozilla.github.io/uniffi-rs/latest/) and generated Swift bindings
- Calling JavaScript by evaluating it using [JavaScriptCore](https://developer.apple.com/documentation/javascriptcore)
+- Calling Flutter via FFI generated using [add-to-app](https://docs.flutter.dev/add-to-app)
We can quickly exclude the [JavaScriptCore](https://developer.apple.com/documentation/javascriptcore) option as a viable route, it’s simply not gonna be even remotely ergonomic.
You essentially import your JavaScript file, or put the code in a String. Then you evaluate it, and can get the output. There’s not much interop between the host language (Swift) and the guest language (JavaScript), providing for poor ergonomics in our usecase (some examples [here](https://stackoverflow.com/a/37435316) and [here](https://douglashill.co/javascript-in-swift/)).
-How does the Rust side of things then look like?
+Dart/Flutter does support calling [Objective-C/Swift from within Dart](https://dart.dev/interop/objective-c-interop#callbacks-and-multithreading-limitations), and with a bit of work it does seem to be able to generate FFI bindings via Flutter to go the other way as well, with a few examples given in [their documentation](https://docs.flutter.dev/add-to-app).
+
+How does the Rust side of things then look like? Very much like Dart/Flutter actually!
1. Use the [uniffi crate](https://crates.io/crates/uniffi)
2. Annotate the functions, enums, records, etc that you want to export with a macro
@@ -146,56 +152,67 @@ How does the Rust side of things then look like?
5. Import the generated Swift and `.xcframework` into XCode
6. Done!
-I’ve written up a guide on how exactly to do that in detail here [Setting up UniFFI for iOS, Simulators, and watchOS](/posts/2024-06-24-setting-up-uniffi-for-ios-simulators-and-watchos.html).
+I’ve written up a guide on how exactly to do that in detail here: [Setting up UniFFI for iOS, Simulators, and watchOS](/posts/2024-06-24-setting-up-uniffi-for-ios-simulators-and-watchos.html).
Once you’ve done the initial project setup (for building the targets and generating the `.xcframework` file) you don’t really touch that again, and you only need to concern yourself with which things to expose to Swift.
Let’s make a small example of code using `uniffi` would look like:
-https://gist.github.com/Tehnix/2a7c3059816f04fe2ccbc5390c96e3ed.js?file=uniffi-example.rs
+
+```rust ,linenos
+uniffi::setup_scaffolding!();
+
+#[derive(uniffi::Enum)]
+pub enum Fruits {
+ Watermelon,
+ Cranberry,
+ Cherry,
+}
+
+#[uniffi::export]
+pub fn eat_fruit(fruit: Fruits) -> String {
+ match fruit {
+ Fruits::Watermelon => "Eating Watermelon".to_string(),
+ Fruits::Cranberry => "Eating Cranberry".to_string(),
+ Fruits::Cherry => "Eating Cherry".to_string(),
+ }
+}
+```
How do we call the generated code? As you would any other Swift code!
-https://gist.github.com/Tehnix/2a7c3059816f04fe2ccbc5390c96e3ed.js?file=Example.swift
+
+```swift ,linenos
+// Calling our Rust function with our Rust enum as an argument.
+eatFruit(fruit: Fruits.watermelon)
+```
-https://gist.github.com/Tehnix/2a7c3059816f04fe2ccbc5390c96e3ed.js?file=Example.swift%20(**Code%20Sharing**).swift
+
+```swift ,linenos
+// It'll work everywhere you'd expect it to, e.g. in String interpolation here.
+Text("Ready? \(eatFruit(fruit: Fruits.watermelon))")
+```
-Final result in the iOS Simulator, running our Web App as a Mobile App:
+Final result in the iOS and Android Simulators, running our Web App as a Mobile App:
-Final result in the iOS Simulator, running our Web App as a Mobile App:
+{{ images(paths=["mobile-a-different-way-ios-simulator.png", "mobile-a-different-way-android-simulator.png"], captions=["Final result in the iOS Simulator", "Final result in the Android Simulator"], widths=[400, 400]) }}
-
-
-
-
-
-In the Android Simulator:
-
-
-
-
-
-
Same application on the Web:
-
-
-
-
+{{ image(path="mobile-a-different-way-web.png", caption="Final result on the Web", width=500) }}
The Widget Extension in the XCode Preview:
-
-
-
-
+{{ image(path="mobile-a-different-way-widget-preview.png", caption="Final result as a Widget Preview in Xcode", width=600) }}
The watchOS App in the XCode Preview:
-
-
-
-
+{{ image(path="mobile-a-different-way-watchos-preview.png", caption="Final result as a watchOS Preview in Xcode", width=600) }}
**Choice**: Rust with [UniFFI](https://mozilla.github.io/uniffi-rs/latest/)
-**Alternative**: None
+**Alternative**: Dart/Flutter
## Conclusion
@@ -211,4 +228,8 @@ Let’s revisit our original goals with our final results:
- **Code Sharing**: If we must drop into native code (Swift/Kotlin) we should be able to use code from our “core” language
- Expose our Rust code to our native Swift code using UniFFI
+Why not Dart/Flutter? My main holdback stems from the maturity the language and ecosystem has on the Backend, which seems to be quite lacking. Rust definitely has it beat here, with an extremely vibrant ecosystem.
+
I’m personally pretty happy with the solution. Most people probably won’t need the watchOS and Widgets, so they won’t have to touch Swift code, but it’s at least nice to know that you haven’t closed off that option for yourself down the road, as some options would leave you.
+
+[👉 Let me know what you think over on Medium](https://codethoughts.medium.com/mobile-a-different-way-using-rust-0e7b1dfa8cbf) or down in the comments below.
diff --git a/resources/images/mobile-a-different-way-android-simulator.png b/content/posts/2024-06-25-mobile-a-different-way/mobile-a-different-way-android-simulator.png
similarity index 100%
rename from resources/images/mobile-a-different-way-android-simulator.png
rename to content/posts/2024-06-25-mobile-a-different-way/mobile-a-different-way-android-simulator.png
diff --git a/resources/images/mobile-a-different-way-ios-simulator.png b/content/posts/2024-06-25-mobile-a-different-way/mobile-a-different-way-ios-simulator.png
similarity index 100%
rename from resources/images/mobile-a-different-way-ios-simulator.png
rename to content/posts/2024-06-25-mobile-a-different-way/mobile-a-different-way-ios-simulator.png
diff --git a/resources/images/mobile-a-different-way-watchos-preview.png b/content/posts/2024-06-25-mobile-a-different-way/mobile-a-different-way-watchos-preview.png
similarity index 100%
rename from resources/images/mobile-a-different-way-watchos-preview.png
rename to content/posts/2024-06-25-mobile-a-different-way/mobile-a-different-way-watchos-preview.png
diff --git a/resources/images/mobile-a-different-way-web.png b/content/posts/2024-06-25-mobile-a-different-way/mobile-a-different-way-web.png
similarity index 100%
rename from resources/images/mobile-a-different-way-web.png
rename to content/posts/2024-06-25-mobile-a-different-way/mobile-a-different-way-web.png
diff --git a/resources/images/mobile-a-different-way-widget-preview.png b/content/posts/2024-06-25-mobile-a-different-way/mobile-a-different-way-widget-preview.png
similarity index 100%
rename from resources/images/mobile-a-different-way-widget-preview.png
rename to content/posts/2024-06-25-mobile-a-different-way/mobile-a-different-way-widget-preview.png
diff --git a/resources/images/mobile-a-different-way-widget-screenshot.jpeg b/content/posts/2024-06-25-mobile-a-different-way/mobile-a-different-way-widget-screenshot.jpg
similarity index 100%
rename from resources/images/mobile-a-different-way-widget-screenshot.jpeg
rename to content/posts/2024-06-25-mobile-a-different-way/mobile-a-different-way-widget-screenshot.jpg
diff --git a/resources/images/mobile-a-different-way-xcode-adding-targets.png b/content/posts/2024-06-25-mobile-a-different-way/mobile-a-different-way-xcode-adding-targets.png
similarity index 100%
rename from resources/images/mobile-a-different-way-xcode-adding-targets.png
rename to content/posts/2024-06-25-mobile-a-different-way/mobile-a-different-way-xcode-adding-targets.png
diff --git a/resources/images/how-i-structure-my-work-as-a-solor-founder-goals.png b/content/posts/2024-06-26-how-i-structure-my-work-as-a-solor-founder/how-i-structure-my-work-as-a-solor-founder-goals.png
similarity index 100%
rename from resources/images/how-i-structure-my-work-as-a-solor-founder-goals.png
rename to content/posts/2024-06-26-how-i-structure-my-work-as-a-solor-founder/how-i-structure-my-work-as-a-solor-founder-goals.png
diff --git a/resources/images/how-i-structure-my-work-as-a-solor-founder-initiatives.png b/content/posts/2024-06-26-how-i-structure-my-work-as-a-solor-founder/how-i-structure-my-work-as-a-solor-founder-initiatives.png
similarity index 100%
rename from resources/images/how-i-structure-my-work-as-a-solor-founder-initiatives.png
rename to content/posts/2024-06-26-how-i-structure-my-work-as-a-solor-founder/how-i-structure-my-work-as-a-solor-founder-initiatives.png
diff --git a/resources/images/how-i-structure-my-work-as-a-solor-founder-issues.png b/content/posts/2024-06-26-how-i-structure-my-work-as-a-solor-founder/how-i-structure-my-work-as-a-solor-founder-issues.png
similarity index 100%
rename from resources/images/how-i-structure-my-work-as-a-solor-founder-issues.png
rename to content/posts/2024-06-26-how-i-structure-my-work-as-a-solor-founder/how-i-structure-my-work-as-a-solor-founder-issues.png
diff --git a/posts/2024-06-26-how-i-structure-my-work-as-a-solor-founder.md b/content/posts/2024-06-26-how-i-structure-my-work-as-a-solor-founder/index.md
similarity index 84%
rename from posts/2024-06-26-how-i-structure-my-work-as-a-solor-founder.md
rename to content/posts/2024-06-26-how-i-structure-my-work-as-a-solor-founder/index.md
index 7e1df24..39d3d45 100644
--- a/posts/2024-06-26-how-i-structure-my-work-as-a-solor-founder.md
+++ b/content/posts/2024-06-26-how-i-structure-my-work-as-a-solor-founder/index.md
@@ -1,8 +1,9 @@
----
-title: "How I structure work as a Solo Founder"
-tags: project management, solo founder, codetalk
-date: 2024-06-26
----
++++
+title = "How I structure work as a Solo Founder"
+date = 2024-06-26
+[taxonomies]
+tags = ["project management", "solo founder", "codetalk"]
++++
This is for sure something that will keep evolving over time, but I got inspired by [this Hacker News post](https://news.ycombinator.com/item?id=40742831) to share in more detail how I organize myself and my work (you can see my short answer [here](https://news.ycombinator.com/item?id=40743669)).
@@ -16,9 +17,11 @@ You could rephrase this slightly to: How do I run *my own* project management?
For most Engineers, this is not actually something they’ve needed to do often, especially if working in larger corporations. The people that have worked at Startups are a mixed bag, where some learn the value of structure, and others managed to get by without since the fast-paced environment changes things around all the time anyways.
-I’ve personally landed in the camp of: Structure is valuable, even crucial, but it should never get in my way. Best of both worlds sorta.
+I’ve personally landed in the camp of: **Structure is valuable, even crucial, but it should never get in my way. Best of both worlds sorta.**
-
+
+
+{{ toc() }}
## What is my context?
@@ -64,9 +67,7 @@ At the time of writing, I currently have two focuses for the month of July:
In Linear, I’ve structure the monthly goals using their new [Initiatives](https://linear.app/docs/initiatives), which gives me a great way to write a high-level summary of the goal, and gather the related projects that will get me there into each of them.
-
-
-
-
+{{ image(path="how-i-structure-my-work-as-a-solor-founder-initiatives.png", caption="A view of my Initiatives in Linear for July 2024", width=700) }}
A view of my Initiatives in Linear for July 2024.
@@ -90,9 +91,7 @@ I then use this prioritization as the input for my daily goals, and it also make
In Linear I’ve set up a Custom View with a simple filter on the Initiatives I have active at the moment, named “Initiative Issues” in the screenshot below.
-
-
-
-
+{{ image(path="how-i-structure-my-work-as-a-solor-founder-issues.png", caption="A Custom View with a filter on the currently active Initiatives", width=700) }}
A Custom View with a filter on the currently active Initiatives.
@@ -102,9 +101,7 @@ Arriving at the final step, I start from the “Initiative Issues” list and pi
These issues then go into another Custom View called “Goal of the day” which just gathers all issues with the `Goal` label on them, as well as having myself assigned to them.
-
-
-
-
+{{ image(path="how-i-structure-my-work-as-a-solor-founder-goals.png", caption="A Custom View with a filter on “Goals", width=700) }}
A Custom View with a filter on “Goals” label being added.
@@ -150,4 +147,6 @@ Honestly, most things would work, and you can even just do it with pen-and-paper
As an alternative to Linear, I’d probably recommend Notion. You will need to set up the structure more yourself, but you can wrangle their [Projects](https://www.notion.so/product/projects) functionality into something that will allow you a very similar setup.
-I always love to get inspiration, so I’d love to hear from you about your own preferred way of organizing yourself. [Let me know what you think over on Medium.](https://codethoughts.medium.com/how-i-structure-work-as-a-solo-founder-4944afcfc2f2)
+I always love to get inspiration, so I’d love to hear from you about your own preferred way of organizing yourself.
+
+[👉 Let me know what you think over on Medium](https://codethoughts.medium.com/how-i-structure-work-as-a-solo-founder-4944afcfc2f2) or in the comments below.
diff --git a/content/posts/_index.md b/content/posts/_index.md
new file mode 100644
index 0000000..d2f87a6
--- /dev/null
+++ b/content/posts/_index.md
@@ -0,0 +1,8 @@
++++
+title = "Posts"
+sort_by = "date"
+template = "posts.html"
+page_template = "post-page.html"
+transparent = true
+insert_anchor_links = "heading"
++++
diff --git a/deploy_rsa.enc b/deploy_rsa.enc
deleted file mode 100644
index c9e7747..0000000
Binary files a/deploy_rsa.enc and /dev/null differ
diff --git a/justfile b/justfile
index ae54085..d20787e 100644
--- a/justfile
+++ b/justfile
@@ -12,49 +12,41 @@ code:
[linux]
install-tooling:
@ just _install-tooling-all-platforms
- # Install imagemagick for mogrify.
- command -v mogrify >/dev/null 2>&1 || sudo apt install imagemagick
- gh release download --clobber --pattern "hakyll-site" --dir ./dist
- chmod +x ./dist/hakyll-site
+ echo "Currently unsupported, see https://www.getzola.org/documentation/getting-started/installation/ for installation instructions."
# Install tooling for working with the codetalk blog.
[macos]
install-tooling:
@ just _install-tooling-all-platforms
- # Install imagemagick for mogrify.
- command -v mogrify >/dev/null 2>&1 || brew install imagemagick
+ # Install zola.
+ brew install zola
_install-tooling-all-platforms:
- # Install stack.
- command -v stack >/dev/null 2>&1 || curl -sSL https://get.haskellstack.org/ | sh
- # Install ghcup.
- command -v ghcup >/dev/null 2>&1 || curl --proto '=https' --tlsv1.2 -sSf https://get-ghcup.haskell.org | sh
- # Install sass.
- command -v sass >/dev/null 2>&1 || npm i -g sass
+ echo "Setting up tools..."
-# Setup dependencies and build the hakyll executable.
-setup:
- stack build
-
-# Deploy the blog to S3 and invalidate CloudFront cache.
-deploy:
- #!/usr/bin/env bash
- set -euxo pipefail
- just build
- # Sync files to S3.
- aws s3 sync _site s3://codetalk.io --delete
- # Invalidate Cloudflare cache.
- curl -X DELETE "https://api.cloudflare.com/client/v4/zones/${CLOUDFLARE_ZONE}/purge_cache" \
- -H "Authorization: Bearer ${CLOUDFLARE_TOKEN}" \
- -H "Content-Type: application/json" \
- --data '{"purge_everything":true}'
-
-# Run hakyll development server in watch mode.
+# Run zola development server in watch mode.
dev:
- stack exec -- hakyll-site watch --port 4566
+ bunx concurrently --names tailwind,zola "bunx tailwindcss --input styles/input.css --output static/styles/output.css --watch" "zola serve --port 4566"
# Build blog artifacts and static files.
build:
- ./dist/hakyll-site clean || stack exec -- hakyll-site clean
- ./dist/hakyll-site clean || stack exec -- hakyll-site build
- sass resources/scss/app.scss:_site/app.css --style compressed
+ bunx tailwindcss --input styles/input.css --output static/styles/output.css --minify
+ zola build
+
+# Generate posts with Gists instead of code blocks.
+generate-gists:
+ cd tools && bun run index.ts
+
+# TODO: Move deployment to CloudFlare Pages?
+# Deploy the blog to S3 and invalidate CloudFront cache.
+# deploy:
+# #!/usr/bin/env bash
+# set -euxo pipefail
+# just build
+# # Sync files to S3.
+# aws s3 sync _site s3://codetalk.io --delete
+# # Invalidate Cloudflare cache.
+# curl -X DELETE "https://api.cloudflare.com/client/v4/zones/${CLOUDFLARE_ZONE}/purge_cache" \
+# -H "Authorization: Bearer ${CLOUDFLARE_TOKEN}" \
+# -H "Content-Type: application/json" \
+# --data '{"purge_everything":true}'
diff --git a/resources/bookmarks/April.html b/resources/bookmarks/April.html
deleted file mode 100644
index c8e9a50..0000000
--- a/resources/bookmarks/April.html
+++ /dev/null
@@ -1,307 +0,0 @@
- 
-April
-- Blog Rewrite with Hakyll and Purescript · in Code
-
- https://www.rsync.net/resources/notices/canary.txt -
- Deploying to amazon is broken by sse4_crc32 · Issue #1050 · ParsePlatform/parse-server · GitHub -
- Dwarf Fortress' creator on how he's 42% towards simulating existence | Hacker News -
- You can now install a GSM network using apt-get | LaForge's home page -
- Apricity OS -
- Stream PirateBay movies directly from CLI | Hacker News -
- Full Linux-on-PS4 hits Github • The Register -
- Full Linux-on-PS4 hits GitHub | Hacker News -
- Save Netflix! | Electronic Frontier Foundation -
- register-machine-typelevel: A computationally universal register machine implementation at the type-level | Hackage -
- Well, that escalated quickly. : haskell -
- Deploying Haskell for Mac projects on OS X and Linux · Haskell for Mac -
- Deploying Haskell for Mac projects on OS X and Linux using Stack : haskell -
- Abandoning gitflow and GitHub | Hacker News -
- XenialXerus/ReleaseNotes - Ubuntu Wiki -
- At this time you should not upgrade a production desktop from 14.04 to 16.04 | Hacker News -
- Being a ‘Dumb’ Girl in Computer Science | Rewriting the Code -
- Tokamak: A Rust IDE for Atom | Hacker News -
- Issue 326539 - chromium - OS X Notification Center should be used on Mac - Monorail -
- Native Mac Notifications Comes to Chrome Stable | Hacker News -
- Tor exit node operator gets raided by police | Hacker News -
- When A Dark Web Volunteer Gets Raided By The Police : All Tech Considered : NPR -
- How We Saved $132k a Year With an IT Infrastructure Audit | Hacker News -
- Nostalrius Begins -
- Blizzard shutting down Nostalrius, popular WoW private server | Hacker News -
- WebTorrent Desktop -
- WebTorrent Desktop – Open source streaming torrent client | Hacker News -
- GitHub · Where software is built -
- Vis: A Vim Like Text Editor | Hacker News -
- Workflow automation : haskell -
- Internet hyperlinks do not infringe copyright, EU court advised | Reuters -
- Internet hyperlinks do not infringe copyright, EU court advised | Hacker News -
- Why Erlang Matters -
- Why Erlang Matters | Hacker News -
- Android Studio 2.0 | Android Developers Blog -
- Android Studio 2.0 Released | Hacker News -
- Design better databases | Hacker News -
- Open Whisper Systems >> Blog >> Signal Desktop beta now publicly available -
- Hidden latency in the Linux network stack | Hacker News -
- React v15.0 | React -
- React v15.0 | Hacker News -
- Don't wrap text in <span> elements by mwiencek · Pull Request #5753 · facebook/react -
- Reddit: The Official App For iPhone and Android. Meow. -
- React v15.0 | Hacker News -
- Computer paints 'new Rembrandt' after old works analysis - BBC News -
- EX-99.1 -
- Jeff Bezos’ letter to shareholders | Hacker News -
- Erlang 19.0 Garbage Collector | Hacker News -
- Why does Go seem to be the most heavily criticised among the newer programming languages? - Quora -
- Why Everyone Hates Go · npf.io -
- Erlang Garbage Collection Details and Why They Matter | Hacker News -
- Building a Better Custom Haskell Prelude | Hacker News -
- Knuth versus Email -
- stack support for yesod devel -
- LiveReload with Yesod + Stack on existing project? : haskell -
- Yesod quick start guide -
- yesodweb/yesod: A RESTful Haskell web framework built on WAI. -
- numeric-prelude: An experimental alternative hierarchy of numeric type classes | Hackage -
- Building a Better Custom Haskell Prelude -
- Performance comparison between s3fs and riofs · Issue #6 · skoobe/riofs -
- Efficient Integer Overflow Checking in LLVM – Embedded in Academia -
- Efficient Integer Overflow Checking in LLVM | Hacker News -
- Congratulations! You’ve Been Fired - The New York Times -
- Could the String problem be solved as an compiler optimisation ? : haskell -
- It's the IO type, not IO monad. : haskell -
- Domino's: Pizza and Payments -
- Domino's: Pizza and Payments | Hacker News -
- Haskell Diary #2 - Algebra of Data Types -
- Haskell Diary #2 - Algebra of Data Types : haskell -
- HP Claims Innovation Over Apple With 'World's Thinnest Laptop' - Mac Rumors -
- Apple Seeds First OS X 10.11.5 El Capitan Beta to Developers - Mac Rumors -
- Open-sourcing Haxl, a library for Haskell | Engineering Blog | Facebook Code -
- A year after its launch, it’s now clear that pretty much no one needs an Apple Watch - Quartz -
- Nginx Caching - Servers for Hackers -
- Stumbled across SublimeHaskell when setting up a new laptop for dev. Very nice Haskell integration with plenty of features. : haskell -
- Jyt -
- LLVM based Just-in-Time-Compiler for C++ | Hacker News -
- Arq 5: Massively faster backup and restore - Arq Backup Blog : Arq Backup Blog -
- Arq 5: Massively faster backup and restore for Mac and Windows | Hacker News -
- Neil Mitchell's Haskell Blog: GHCid 0.6 Released -
- Facebook Messenger Platform | Hacker News -
- GitHub’s CSP journey - GitHub Engineering -
- Haskell for all: Worst practices should be hard -
- Worst practices should be hard : haskell -
- Forbes Site, After Begging You Turn Off Adblocker, Serves Up A Steaming Pile Of Malware 'Ads' | Techdirt -
- Forbes Site, After Begging You Turn Off Adblocker, Serves Up Malware 'Ads' | Hacker News -
- Haskell vs. Erlang, Reloaded | Lambda the Ultimate -
- functional programming - Haskell vs Erlang for web services - Programmers Stack Exchange -
- Erlang 19.0 Garbage Collector | Hacker News -
- Erlang Solutions - Erlang/OTP 19 GC -
- DevOps is dead. Long live DevOps | Hacker News -
- Managed services killed DevOps | TechCrunch -
- vim/version8.txt at master · vim/vim · GitHub -
- Vim 8.0 is coming | Hacker News -
- Third-Party Reddit Apps Pulled From App Store for NSFW Content [Updated] - Mac Rumors -
- Facebook Introduces Chatbots for Messenger, Pushes Further Into Live Video - Mac Rumors -
- 9.7" iPad Pro's 'Excellent' Display is 'Major Upgrade' Over iPad Air 2 - Mac Rumors -
- bye — Medium -
- Min | A smarter, faster web browser -
- Show HN: Min – web browser with better search and built-in ad blocking | Hacker News -
- 3 Approaches to Monadic API Design in Haskell - Pusher Blog -
- How the 'FIFA Soccer' Video Games Get Such Awesome Soundtracks | GQ -
- Apple Jumps On the WebRTC Bandwagon - Post - No Jitter -
- Apple Jumps on the WebRTC Bandwagon | Hacker News -
- QuakeNet IRC Network- Article - Trust is not transitive: or why IRC over SSL is pointless. -
- Why IRC over SSL is pointless (2009) | Hacker News -
- Post-Mortem for Google Compute Engine’s Global Outage on April 11 | Hacker News -
- CaptionBot by Microsoft | Hacker News -
- The WHATWG Blog — Adding JavaScript modules to the web platform -
- Adding JavaScript modules to the web platform | Hacker News -
- Docker 1.11: The first OCI-compliant runtime, built on containerd | Hacker News -
- PlayTBC.com | Experience the finest - World of Warcraft: The Burning Crusade -
- Atom text editor 1.7.0 released | Hacker News -
- Creating signed GitHub releases - Debian Wiki -
- Announcing Rust 1.8 - The Rust Programming Language Blog -
- Announcing Rust 1.8 | Hacker News -
- Warcraft fans' fury at Blizzard over server closure - BBC News -
- Warcraft fans' fury at Blizzard over server closure | Hacker News -
- Nostalrius Memories : wow -
- In Loving Memory - WoWWiki - Wikia -
- Google App Engine Silently Stopped Sending Email 5 Weeks Ago | Hacker News -
- Renderings vs. Reality: The Improbable Rise of Tree-Covered Skyscrapers - 99% Invisible -
- Renderings vs. Reality: The Improbable Rise of Tree-Covered Skyscrapers | Hacker News -
- The Famous Photo of Chernobyl's Most Dangerous Radioactive Material Was a Selfie | Atlas Obscura -
- Famous Photo of Chernobyl's Most Radioactive Material Was a Selfie | Hacker News -
- How (and why) to make your software faster | Hacker News -
- How (and why) to make your software faster -
- 1031899 – Github spy on user reading emails -
- Two-factor authentication for Apple ID | Hacker News -
- Keeping secrecy the exception, not the rule: An issue for both consumers and businesses - Microsoft on the Issues -
- Keeping secrecy the exception, not the rule | Hacker News -
- A New Map for America | Hacker News -
- When Lobbying was Illegal -
- When Lobbying was Illegal | Hacker News -
- Sorry, You Can’t Speed Read - The New York Times -
- jaspy/README.rst at master · koehlma/jaspy -
- Jaspy – A Python VM written in JavaScript | Hacker News -
- Challenges of micro-service deployments -
- Challenges of micro-service deployments | Hacker News -
- Why does Haskell, in your opinion, suck? : haskell -
- Advanced DDoS Protection and Mitigation | CloudFlare | The web performance & security company -
- Checked exceptions with open-signals : haskell -
- Shtetl-Optimized » Blog Archive » Grading Trudeau on quantum computing -
- Grading Trudeau on quantum computing | Hacker News -
- Why aren’t we using SSH for everything? | Hacker News -
- Why learning Haskell/Python makes you a worse programmer - All Unkept -
- Why learning Haskell/Python makes you a worse programmer (2006) | Hacker News -
- How a Diode Changed My Life | Hacker News -
- An interesting html5-animated clock | Hacker News -
- What are row types exactly? : haskell -
- Google CDN Beta is here ... and it's already one of the fastest CDNs out there | Hacker News -
- [ANNOUNCE] GHC 8.0.1 release candidate 3 available -
- [ANNOUNCE] GHC 8.0.1 release candidate 3 available : haskell -
- Deepjazz: AI-generated 'jazz' | Hacker News -
- Static website on S3, CloudFront and Route 53, the right way! – Un blog sur tout et rien -
- Does async syntax have any advantages over do notation? : haskell -
- Attoparsec & Line Numbers : haskell -
- When does one consider using Arrows? : haskell -
- Mad scientist shrinks Arduino to size of an AA battery | TechCrunch -
- Intel Releases the Arduino 101 Source Code | Hacker News -
- Ravens score just as high as big-brained chimps on cognitive tests | Hacker News -
- When it comes to brains, size doesn’t matter | Ars Technica -
- Coding Inspiration: 3 Teen Sisters Crush Coding Records, Stereotypes -
- Can we have -XHaskell2016 which turns on the most commonly used and safe extensions? : haskell -
- Reducing garbage-collection pause time in a Haskell program : haskell -
- Reducing garbage-collection pause time in a Haskell program - Stack Overflow -
- why Haskell cannot do pattern match ? : haskell -
- Apple pays $25M to a university—and the patent troll it cut a deal with | Ars Technica -
- Thoughts on using _ as syntactic sugar for partially applied functions. : haskell -
- FBI Paid More Than $1 Million to Hack San Bernardino iPhone - WSJ -
- FBI Paid More Than $1M to Hack San Bernardino iPhone | Hacker News -
- How can I do this in hamlet? : haskell -
- Performance These Days | Hacker News -
- How fast can we make interpreted Python? (2013) | Hacker News -
- Why is haskell.org powered by some much PHP? : haskell -
- Performance issues in my factoring function? : haskell -
- Haskell.org News : haskell -
- (Newbie) Certain I'm making a very basic mistake, but not entirely sure where in this Haskell Text Editor : haskell -
- [ANN] Stratosphere: AWS CloudFormation EDSL in Haskell : haskell -
- [Haskell-cafe] [ANN] Stratosphere: AWS CloudFormation EDSL in Haskell -
- Haskell's Type Classes: We Can Do Better – John A De Goes -
- Reducing garbage-collection pause time in a Haskell program : haskell -
- The average size of Web pages is now the average size of a Doom install | Hacker News -
- The web is Doom - mobiForge -
- Edward Snowden: The Internet Is Broken | Popular Science -
- Edward Snowden: The Internet Is Broken | Hacker News -
- Why Write in English? by Tim Parks | NYR Daily | The New York Review of Books -
- Why Write in English? | Hacker News -
- One Easy Way to Make Wikipedia Better - The Atlantic -
- Yakuza 3 reviewed by Yakuza / Boing Boing -
- Haskell's Typeclasses: We Can Do Better : haskell -
- So, you want to learn bookkeeping | Hacker News -
- One Easy Way to Make Wikipedia Better | Hacker News -
- The impact of Prince’s death on Wikipedia | Hacker News -
- William Shakespeare, Playwright and Poet, Is Dead at 52 | Hacker News -
- Cached deriving : haskell -
- simple Haskell question!!! Please help me!! : haskell -
- Web framework for building browser UI for an app running LAN/localhost : haskell -
- Use OpenGL to get more RAM | Hacker News -
- GitHub - graphitemaster/moreram: Get more system memory -
- Something Secret This Way Comes — Llogiq on stuff -
- [Rust] Something Secret This Way Comes | Hacker News -
- Show HN: QBE – a new compiler back end | Hacker News -
- Functors, Applicatives, and Monads in Plain English | Hacker News -
- Russ Bishop - Functors, Applicatives, and Monads in Plain English -
- William Shakespeare, Playwright and Poet, Is Dead at 52 - The New York Times -
- The Science of Making Friends | Hacker News -
- CloudFlare Now Supporting More Ports -
- A web based dashboard for monitoring and controlling Philips Hue lights : haskell -
- blitzcode/hue-dashboard: A web based dashboard for monitoring and controlling Philips Hue lights -
- mtl: Monad classes, using functional dependencies | Hackage -
- monad-log: A simple and fast logging monad | Hackage -
- [announcement] monad-log: A simple and fast logging monad : haskell -
- Problems installing (starting?) Haskell Platform on OSX : haskell -
- The Dark Side of Haskell : haskell -
- Newbie question about map and evaluation : haskell -
- Dealing with error messages/codes returned within IO : haskell -
- Is there any guarantee that a version of Stack will be same tomorrow as it is today? : haskell -
- brew/Analytics.md at master · Homebrew/brew -
- Homebrew now sends usage information to Google Analytics | Hacker News -
- Half Your Brain Is Alert The First Night In A New Place : Shots - Health News : NPR -
- Half Your Brain Stands Guard When Sleeping in a New Place | Hacker News -
- Docker for Mac Beta Review | Hacker News -
- BYOT Bring your own team -
- The CIA Waterboarded the Wrong Man 83 Times in 1 Month | Hacker News -
- Kidnap A Soviet? Well . . . Shiite Moslems Tried It In Lebanon - Once - philly-archives -
- Effectiveness of torture for interrogation - Wikipedia, the free encyclopedia -
- Summary of the -XHaskell2016 feedback : haskell -
- Basic Syntax Extensions - School of Haskell | School of Haskell -
- ANN: ghc-8.0.1-rc4 (quiet update) : haskell -
- λ Bubble Pop!(A simple game that illustrates functional computation) : haskell -
- λ Bubble Pop! -
- A revolutionary new way to access all your files | | Dropbox Business Blog -
- Dropbox Project Infinite | Hacker News -
- Elixir RAM and the Template of Doom -
- Elixir RAM and the Template of Doom | Hacker News -
- Lionsgate is making its films available on Steam | Gadgette -
- Lionsgate is making its films available on Steam | Hacker News -
- World’s Fastest Growing Open Source Platform Pushes Out New Release | Node.js -
- Node.js v6.0 Released | Hacker News -
- Updating Our Prefixing Policy | WebKit -
- https://www.rsync.net/resources/notices/canary.txt -
-