olpeh · olpeh · Mar 8, 2020 · Mar 8, 2020 · Mar 8, 2020 · Mar 8, 2020
diff --git a/.gitignore b/.gitignore
@@ -1,12 +1,9 @@
 dat.json
 /_site
 Gemfile\.lock
-
 \.vscode/
 node_modules
-
 package-lock\.json
-
 visual-regression-screenshots
 elm-stuff/
 dist/

diff --git a/legacy/.prettierrc → .prettierrc b/legacy/.prettierrc → .prettierrc
diff --git a/README.md b/README.md
@@ -1,31 +1,31 @@
-# elm-pages-starter
+# olavihaapala.fi
 
-[![Deploy to Netlify](https://www.netlify.com/img/deploy/button.svg)](https://app.netlify.com/start/deploy?repository=https://github.com/dillonkearns/elm-pages-starter)
+[![license](http://img.shields.io/badge/license-MIT-brightgreen.svg?style=flat)](https://github.com/olpeh/olpeh.github.io/blob/master/LICENSE)
+[![Lighthouse score: 100/100](https://lighthouse-badge.appspot.com/?score=100)](https://github.com/olpeh/olpeh.github.io)
 
-This is an example repo to get you up and running with `elm-pages`.
+A blazing fast personal blog about development: [olavihaapala.fi](https://olavihaapala.fi).
 
-The entrypoint file is `index.js`. That file imports `src/Main.elm`. The `content` folder is turned into your static pages. The rest is mostly determined by logic in the Elm code! Learn more with the resources below.
+Read about [how I set up my blog](https://olavihaapala.fi/2017/11/19/hello-world.html).
 
-## Setup Instructions
+Read about [how I made my blog blazing fast](https://olavihaapala.fi/2019/02/19/how-i-made-my-blog-blazing-fast.html).
 
-Click "Use this template" on this Github page to fork the repo.
+![4 times 100 in the lighthouse audit.](/images/blazing-fast/all-100.png)
 
-Or git clone it:
+Site setup based on [elm-pages-starter](github.com:dillonkearns/elm-pages-starter.git)
+
+## Development
 
 ```
-git clone git@github.com:dillonkearns/elm-pages-starter.git
+yarn
+yarn start # starts a local dev server using `elm-pages develop`
 ```
 
-Then install and run the dev server
+## Deployment
 
 ```
-cd elm-pages-starter
-npm install
-npm start # starts a local dev server using `elm-pages develop`
+git push
 ```
 
-From there you can tweak the `content` folder or change the `src/Main.elm` file.
-
 ## Learn more about `elm-pages`
 
 - Documentation site: https://elm-pages.com

diff --git a/content/blog/draft.md b/content/blog/draft.md
diff --git a/...4-03-i-learned-frp-by-learning-cyclejs.md → content/blog/frp-cyclejs.md b/...4-03-i-learned-frp-by-learning-cyclejs.md → content/blog/frp-cyclejs.md
diff --git a/content/blog/hello-world.md b/content/blog/hello-world.md
@@ -0,0 +1,88 @@
+---
+{
+  'type': 'blog',
+  'author': 'Olavi Haapala',
+  'title': 'Hello World!',
+  'description': 'Setting up my personal blog and posting my first blog post',
+  'image': '/images/hello-world/thumbnail.png',
+  'altText': 'Screenshot of olpeh.github.io github page being published at olpe.fi',
+  'published': '2017-11-19',
+}
+---
+
+For a long time, I have been thinking about starting a blog. I have just never got it done. Last week I was participating in a `Thought Leadership Workshop` at work and got the boost needed for starting a blog. So, now, finally my blog sees the daylight! Amazing.
+
+In my blog I'm going to write about software development and stuff that I have learned while programming.
+
+So in order to get started with blogging, I'll start by writing about the steps that were needed in order to set up this blog. In this blog post I'm writing about how to setup HTTPS for a GitHub page using a custom domain.
+
+## First step - custom domain
+
+First step for me was to setup a custom domain (olpe.fi) to point to my github page (olpeh.github.io).
+
+In the settings page for my repository in GitHub I could easily set up a custom domain for the github page as seen in the screenshot below.
+
+![GitHub pages settings](/images/hello-world/gh-pages.png)
+
+This was not enough though. Had to read the page behind the [Learn more](https://help.github.com/articles/using-a-custom-domain-with-github-pages/) link. In my opinion that page is quite confusing and I did not know what to do really.
+
+In the end I found out that [this](https://help.github.com/articles/setting-up-an-apex-domain/#configuring-a-records-with-your-dns-provider/) was the page with the information that I needed:
+
+> 1.  Confirm that you have added a custom domain to your GitHub Pages site.
+>
+> 2.  Contact your DNS provider for detailed instructions on how to set up A records.
+>
+> 3.  Follow your DNS provider's instructions to create two A records that point your custom domain to the following IP addresses:
+>
+>     192.30.252.153
+>
+>     192.30.252.154
+
+So I went ahead and set up the correct `A` type records at my providers' page. See the screenshot below for the DNS records for the root domain `olpe.fi`. I also set up the same rules for `www.olpe.fi` in order to also support `www.olpe.fi`.
+
+![DNS rules](/images/hello-world/dns-louhi.png)
+
+This was enough to make my GitHub page (olpeh.github.io) available at [olpe.fi](https://olpe.fi) and [www.olpe.fi](https://www.olpe.fi). I was happy for a moment and tweeted this:
+
+![DNS rules applied](/images/hello-world/tweet-dns-http.png)
+
+## Next step - HTTPS
+
+Next step was to enable and force using HTTPS in stead of HTTP on olpe.fi. Should be fairly simple to turn it on, right? And why is it not on by default? Nowadays browsers will show a warning if a page is served using HTTP instead of HTTPS and I also wanted to make my site available as a secure P2P site using dat in Beaker browser which requires HTTPS. More about those later.
+
+However, it turns out GitHub does not support HTTPS for custom domains (yet)!
+
+![No https support](/images/hello-world/tweet-no-https.png)
+
+Well luckily I'm [not](https://github.com/isaacs/github/issues/156) the [only one](https://gist.github.com/coolaj86/e07d42f5961c68fc1fc8) wanting this feature and there are some workarounds available. I found a few nice tutorials about how to set up HTTPS for GitHub page with custom domain using Cloudfare (for free): [As a gist](https://gist.github.com/cvan/8630f847f579f90e0c014dc5199c337b) and a [blog post](https://blog.cloudflare.com/secure-and-fast-github-pages-with-cloudflare/) and [another](https://sheharyar.me/blog/free-ssl-for-github-pages-with-custom-domains/) and [one more](https://hackernoon.com/set-up-ssl-on-github-pages-with-custom-domains-for-free-a576bdf51bc).
+
+I tried following those instructions pretty carefully but ended up redirecting from `https://www.olpe.fi` to `https://olpe.fi` and from there back to `www`. These steps included creating an account to cloudfare, adding `olpe.fi` as a site there, enabling flexible encryption mode using SSL and adding some redirection rules for forcing https.
+
+In the end my working setup looked like this:
+
+![Cloudfare crypto settings](/images/hello-world/cloudfare-crypto.png)
+
+![Cloudfare page rules](/images/hello-world/cloudfare-page-rules.png)
+
+`Nimipalvelin` means `name server` in Finnish.
+
+![Louhi name servers](/images/hello-world/louhi-name-servers.png)
+
+So now my site was available via [HTTPS](https://olpe.fi/) and [dat](dat://olpe.fi/) as seen in the screenshot below.
+
+![HTTPS FTW](/images/hello-world/tweet-https-dat.png)
+
+Dat support was something that I had configured earlier with the help of [this blog post](https://handbook.protozoa.nz/experiments/p2p_github_pages.html). P2P websites are available using [Beaker browser](https://beakerbrowser.com/) I will try to write more about P2P in a future blog post. In the meantime you can read about [Secure Scuttlebutt](https://www.scuttlebutt.nz/) and probably try it out using [Patchwork](https://github.com/ssbc/patchwork).
+
+## Last step - the blog
+
+At this point my "blog" was served over HTTPS but the only thing missing was the actual blog. I wanted to stay using a GitHub page based blog so jekyll was a natural choice for a static web page. I got a nice tip from my colleague about [elmtown.audio](https://github.com/elmtown/elmtown.github.io) which is a simple GitHub page with static content. That setup was pretty much enough for me and I copied most of the setup from there except for the visual outlook.
+
+Next thing in my todo-list is to make the design of my blog better, but I'll just start off with some basic stylings and a simple looking blog.
+
+## Acknowledgements
+
+- Thanks to [Ossi Hanhinen](https://futurice.com/people/ossi-hanhinen) for giving me good hints on how to setup basic jekyll based static site. Reused the structure from: [elmtown.audio](https://github.com/elmtown/elmtown.github.io) which is made by Ossi
+- Thanks to my wonderful colleagues at [Futurice](https://futurice.com/) for arranging a Thought Leadership Workshop where I got the boost needed in order to start blogging
+- Thanks to all the people who wrote about how to setup HTTPS using Cloudfare
+- Thanks to [Cloudfare](https://www.cloudflare.com/) for providing a free plan that has all the most critical features
diff --git a/content/blog/hello.md b/content/blog/hello.md
diff --git a/...-02-19-how-i-made-my-blog-blazing-fast.md → ...t/blog/how-i-made-my-blog-blazing-fast.md b/...-02-19-how-i-made-my-blog-blazing-fast.md → ...t/blog/how-i-made-my-blog-blazing-fast.md
@@ -1,21 +1,22 @@
 ---
-title: 'How I Made My Blog Blazing Fast'
-date: 2019-02-19 00:00:00 Z
-layout: post
-excerpt: 'Have you noticed how fast my website loads? In this blog post, I will explain what usually slows down web pages, and how I was able to improve the performance of my website.'
-author: 'Olavi Haapala'
-author_twitter: '0lpeh'
-image: '/images/08-blazing-fast/bonfire.jpg'
-altText: 'Sparks coming from a bonfire, taken with a long exposure time.'
+{
+  'type': 'blog',
+  'author': 'Olavi Haapala',
+  'title': 'How I Made My Blog Blazing Fast',
+  'description': 'Have you noticed how fast my website loads? In this blog post, I will explain what usually slows down web pages, and how I was able to improve the performance of my website.',
+  'image': '/images/blazing-fast/bonfire.jpg',
+  'altText': 'Sparks coming from a bonfire, taken with a long exposure time.',
+  'published': '2019-02-19',
+}
 ---
 
 ## 4 x 100
 
-[![4 times 100 in the lighthouse audit.]({{ "/images/08-blazing-fast/100.png" | prepend: site.baseurl }})]({{ "/images/08-blazing-fast/100.png" | prepend: site.baseurl }}){:target="\_blank"}
+[![4 times 100 in the lighthouse audit.](/images/blazing-fast/all-100.png)](/images/blazing-fast/all-100.png)
 
 Isn't this a beautiful sight 😍.
 
-This screenshot is from the [Lighthouse](https://developers.google.com/web/tools/lighthouse/){:target="\_blank"}{:rel="noopener"} audit result for my webpage.
+This screenshot is from the [Lighthouse](https://developers.google.com/web/tools/lighthouse/) audit result for my webpage.
 Lighthouse is an amazing tool for _quickly_ auditing the performance of a website.
 It may give you useful hints when trying to find the performance bottlenecks in loading a webpage.
 However, the results are not absolute and they should be taken with a grain of salt.
@@ -36,7 +37,7 @@ Typically, the client refers to a web browser and the server is returning the HT
 The figure below shows a simplified version of what happens when a user accesses a traditional server rendered webpage.
 Only a successful case is covered in this example.
 
-[![The client-server architecture of the web.]({{ "/images/08-blazing-fast/client-server.png" | prepend: site.baseurl }})]({{ "/images/08-blazing-fast/client-server.png" | prepend: site.baseurl }}){:target="\_blank"}
+[![The client-server architecture of the web.](/images/blazing-fast/client-server.png)](/images/blazing-fast/client-server.png)
 
 First, the user opens a web browser and types in the address or clicks a link on a webpage.
 The browser will then do a DNS lookup for the address in order to find the server's IP address.
@@ -49,14 +50,14 @@ Finally, as early as possible, the webpage content will be rendered on the user
 
 ### Critical Rendering Path
 
-The above mentioned steps before a webpage is rendered are commonly referred to as the [Critical Rendering Path](https://developers.google.com/web/fundamentals/performance/critical-rendering-path/){:target="\_blank"}{:rel="noopener"}.
+The above mentioned steps before a webpage is rendered are commonly referred to as the [Critical Rendering Path](https://developers.google.com/web/fundamentals/performance/critical-rendering-path/).
 It consists of the steps required before the browser is able to display the contents of the webpage on your screen.
 
 Simplified version can be understood by looking at the following visualization by [Luis Vieira](https://medium.com/@luisvieira_gmr):
 
-[![Critical Rendering Path visualized.]({{ "/images/08-blazing-fast/critical-rendering-path.png" | prepend: site.baseurl }})]({{ "/images/08-blazing-fast/critical-rendering-path.png" | prepend: site.baseurl }}){:target="\_blank"}
+[![Critical Rendering Path visualized.](/images/blazing-fast/critical-rendering-path.png)](/images/blazing-fast/critical-rendering-path.png)
 
-Image source: [Understanding the critical rendering path, rendering pages in 1 second](https://medium.com/@luisvieira_gmr/understanding-the-critical-rendering-path-rendering-pages-in-1-second-735c6e45b47a){:target="\_blank"}{:rel="noopener"}.
+Image source: [Understanding the critical rendering path, rendering pages in 1 second](https://medium.com/@luisvieira_gmr/understanding-the-critical-rendering-path-rendering-pages-in-1-second-735c6e45b47a).
 
 CSSOM in the image refers to the CSS Object Model and DOM to the Document Object Model.
 As the visualization nicely shows, the browser has to rebuild the DOM and when it receives CSS, or synchronous JavaScript.
@@ -103,15 +104,15 @@ Facts contributing to a blazing fast experience on my webpage:
   - In my case, all the CSS is inlined
   - The HTML size remains still small: `3.8 KB` GZIPed
   - Small size is crucial for achieving a fast experience on mobile
-- Optimized and small images using [squoosh.app](https://squoosh.app/){:target="\_blank"}{:rel="noopener"}
+- Optimized and small images using [squoosh.app](https://squoosh.app/)
   - However, I only optimize the images on the first page, not the additional images that are in the blog posts
   - Should probably automate the process somehow
   - Typically I'm able to get ~60% smaller image sizes without losing too much visual information, that the human eye can see
 - Cloudflare used as a CDN, and minimizes assets
-  - read more about [my blog setup here]({{ "/2017/11/19/hello-world.html" | prepend: site.baseurl }})
+  - read more about [my blog setup here](/blog/hello-world)
 - Pages are prefetched for faster subsequent page loads
   - When navigating to another page, the page contents are already available in the cache
-  - I use [Quicklink](https://github.com/GoogleChromeLabs/quicklink){:target="\_blank"}{:rel="noopener"} to do this for me automatically
+  - I use [Quicklink](https://github.com/GoogleChromeLabs/quicklink) to do this for me automatically
   - My Quicklink usage can be seen in the bottom of the page and it looks like this:
 
 ```html
@@ -133,13 +134,13 @@ Facts contributing to a blazing fast experience on my webpage:
 
 The results of these optimizations as measured by Lighthouse can be in the screenshot below.
 
-[![Screenshot of the lighthouse audit results for my page.]({{ "/images/08-blazing-fast/lighthouse.png" | prepend: site.baseurl }})]({{ "/images/08-blazing-fast/lighthouse.png" | prepend: site.baseurl }}){:target="\_blank"}
+[![Screenshot of the lighthouse audit results for my page.](/images/blazing-fast/lighthouse.png)](/images/blazing-fast/lighthouse.png)
 
 Here is a nice visualization that shows what the different metrics refer to.
 
-[![Timeline that explains the different performance metrics.]({{ "/images/08-blazing-fast/perf-metrics-load-timeline.png" | prepend: site.baseurl }})]({{ "/images/08-blazing-fast/perf-metrics-load-timeline.png" | prepend: site.baseurl }}){:target="\_blank"}
+[![Timeline that explains the different performance metrics.](/images/blazing-fast/perf-metrics-load-timeline.png)](/images/blazing-fast/perf-metrics-load-timeline.png)
 
-Image source: [User-centric Performance Metrics](https://developers.google.com/web/fundamentals/performance/user-centric-performance-metrics){:target="\_blank"}{:rel="noopener"}.
+Image source: [User-centric Performance Metrics](https://developers.google.com/web/fundamentals/performance/user-centric-performance-metrics).
 
 As you can see from the lighthouse results, the First Contentful Paint and First Meaningful Paint are happening almost at the same moment.
 In fact, quite often Lighthouse reports same results for them when running the audit for my site.
@@ -152,14 +153,14 @@ This is achieved by not having heavy JavaScript resources on the page.
 
 ### WebPageTest Results
 
-Another way to measure the performance is to run a few test on [WebPageTest](https://www.webpagetest.org){:target="\_blank"}{:rel="noopener"}.
+Another way to measure the performance is to run a few test on [WebPageTest](https://www.webpagetest.org).
 It is an amazing (and free!) tool for performance audits.
 
 Here, you can see a screenshot of the WPT results for my page on February 17, 2019.
 
-[![Screenshot of WebPageTest results page for my site.]({{ "/images/08-blazing-fast/webpagetest.png" | prepend: site.baseurl }})]({{ "/images/08-blazing-fast/webpagetest.png" | prepend: site.baseurl }}){:target="\_blank"}
+[![Screenshot of WebPageTest results page for my site.](/images/blazing-fast/webpagetest.png)](/images/blazing-fast/webpagetest.png)
 
-[Link to the original results](https://www.webpagetest.org/result/190217_Z4_9211511cd7fce5ea4a7d3e867b1d2cb7/){:target="\_blank"}{:rel="noopener"}, where you can see more details.
+[Link to the original results](https://www.webpagetest.org/result/190217_Z4_9211511cd7fce5ea4a7d3e867b1d2cb7/), where you can see more details.
 
 The results from WPT look quite similar to the Lighthouse results, but for some reason the Lighthhouse score reported by WPT is not 100.
 I don't know the reason for this.
@@ -177,4 +178,4 @@ In order to get useful results, you may need to actually reach out to your users
 ## Learn More
 
 If you are interested in learning more about web performance, I have collected a list of links to useful resources on this topic.
-You can find [the list in this repository on GitHub](https://github.com/olpeh/notes-and-lists/blob/master/web-dev-interesting-links.md#web-performance){:target="\_blank"}{:rel="noopener"}.
+You can find [the list in this repository on GitHub](https://github.com/olpeh/notes-and-lists/blob/master/web-dev-interesting-links.md#web-performance).