When you want to run an old Chromium version on new hardware/OS you may run into some obsticles. First, you need to recreate the environment that this ancient code expects. Then you need to download the source code of Chromium and build it yourself. However, it's a pretty tidus and time consuming process, which is very well documented here.

A slightly faster way is to download a snapshot from the official: chromium-browser-snapshots. This will skip the build step and cut the amount of enviornment setup needed. However, they are sorted by a mysterious number...

Snapshot = Revision

The "snapshot number" is actually the revision number. So the challenge becomes: How can I find out the revision number of the specific chrome version I am looking for? This requires you to go through the source code where the major version corresponds to a tag which can lead you to a commit, which message has the revision number! Let the treasure hunt begin!

Case Study: Find v36

From the source code find the Tag that corresponds to the version you are looking for. There are usually a lot of tags for each MAJOR version. Click on one of the tags to see the source code tree at that point in time.

Then you navigate to src/chrome/VERSION. This file shows you the version of Chrome at this point in time. Now, click "blame" and find the last commit that changed the major version. For this case it was this commit: b1f8bdb570beade2a212e69bee1ea7340d80838e

The commit message is where we will find the revision number:

36 is the atomic number of krypton.
36 is both the square of 6 and a triangular number...

[...]

R=dharani@google.com, laforge@chromium.org

Review URL: https://codereview.chromium.org/218183002

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@260368 0039d316-1c4b-4281-b951-d872f2087c98

What we are looking for is on the last line after ...trunk/src@: 260368. This is the revision number! It seems like there is no strict format when it comes to specifying the revision number in the commit so it may look different for different commits. Now we can go to the snapshot folder of the specific architecture we are looking for (e.g. Linux_x64) and search for the revision number and then download the zip file with the chrome binary.

See source code here

Resources

• https://stackoverflow.com/questions/61274601/how-to-find-out-in-which-chromium-version-a-commit-was-shipped
• https://medium.com/dot-debug/running-chrome-in-a-docker-container-a55e7f4da4a8

So I dug in. Here's what finally made gravity click for me.

The Funnel Is Lying to You (Sort of)

The Funnel analogy tries to explain how a massive object like the Sun "bends" space so that smaller objects, like planets, move around it. But there are problems. It uses gravity (pulling down into the funnel) to explain gravity, which is a bit of a loop. Furthermore, the funnel is 2D. The Sun is a 3D ball. So why does the ball sink downward? Why not toward the Sun itself? And Earth isn't spiraling into the Sun like a marble down a funnel, so what gives?

The analogy is simple, but also misleading. It shows some effects, but hides the real structure underneath.

Space Isn't Nothing. It's a Stage with Rules.

We think of space as "nothing," but it''s actually something — a structure with properties. It has distances, directions, and time. And it has geometry — meaning it can be curved, warped, or stretched.

Even in a total vacuum, light still travels at a constant speed, clocks still tick, and you can measure how far something is. So this "nothing" has a shape — and that shape is affected by mass and energy.

Gravity Is Geometry, Not Force

Here's what Einstein figured out:

• Mass and energy curve spacetime.
• Objects move along the straightest path through this curved spacetime.

That's it! No invisible rope pulling things in. Just geometry changing the rules of motion.

A planet orbiting the Sun isn't being yanked by a force — it's moving in a straight line through a curved space. It looks like an orbit, but it's really just the planet following the bend in spacetime.

The Funnel Analogy — with a Twist

Let's revisit the funnel analogy — but modify it.

Yes, imagine a funnel — but now copy that funnel in every possible direction, forming a spherical warp around the mass. Instead of one drain in the middle, you've got a 3D pit from all angles.

Even better: imagine being inside this warping. No slope to fall down, just space itself bending around you.

The Earth doesn't orbit the Sun because it's falling down a slope. It orbits because its straight-line path loops around inside this 3D curvature.

Bonus: What Would Gravity Look Like If You Could See It?

It'd be wild.

Imagine being able to see invisible wind patterns — not just wind on a surface, but in every direction. Gravity would look like smooth curves near stable systems (planets, stars). Swirling warps and eddies where fields overlap (like the Earth–Moon–Sun system). Ripples spreading out when massive events happen (like black holes colliding — gravitational waves).

Each massive object would be like a stirring spoon in a cosmic fluid, and every smaller object would be caught in the flows.

Speed Doesn't Change the Curvature — Just How You Move Through It

One final piece: the shape of the gravity field (spacetime curvature) comes from the mass and energy — not from how fast you're moving. Your speed just determines your path through that shape.

So a satellite with just the right speed can loop endlessly in orbit. One with too little speed falls back. One with too much speed escapes. The terrain doesn't change — only your route through it does.

Finally: So What Is Gravity?

It's not a force pulling stuff down. It's the shape of space and time, telling everything how to move. And if we could see it, it wouldn't be a clean grid with one funnel — it'd be a chaotic, rippling, warping ocean of invisible geometry.

Strangely beautiful.
Still very hard to debug.

Bypassing the “Corepack is about to download” Prompt

When running corepack inside Docker, it pauses with a prompt asking to download the package manager. Not ideal for automated builds. The fix is simple. Setting COREPACK_ENABLE_DOWNLOAD_PROMPT=0 skips the download prompt and keeps things smooth in CI or Docker contexts.

RUN corepack enable && corepack install --global pnpm@9.8.0
ENV COREPACK_ENABLE_DOWNLOAD_PROMPT=0

source

“Cannot find matching keyid” Error

While installing pnpm, Corepack threw a cryptic error:

throw new Error(`Cannot find matching keyid: ${JSON.stringify({ signatures, keys })}`);

tl;dr: use latest corepack

The signing keys in NPM were rotated and newly signed releases from pnpm caused Corepack to fail verification. In order to fix it you need to use Corepack >0.31.0 to install and run pnpm without it crashing (due to verify signature failure).

source

Here is the full error for context:

/usr/local/lib/node_modules/corepack/dist/lib/corepack.cjs:22688
    throw new Error(`Cannot find matching keyid: ${JSON.stringify({ signatures, keys })}`);
          ^

Error: Cannot find matching keyid: {"signatures":[{"sig":"MEUCIQDI3E/8ZodnpZKAfKTeYe/+IF1wyawkKwK+0AkZodyJ9AIgQnQWC/XFtaz7eGusq5QPkYO0Vb412MsQcqxhadZ8IoA=","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"}],"keys":[{"expires":null,"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","keytype":"ecdsa-sha2-nistp256","scheme":"ecdsa-sha2-nistp256","key":"MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE1Olb3zMAFFxXKHiIkQO5cJ3Yhl5i6UPp+IhuteBJbuHcA5UogKo0EWtlWwW6KSaKoTNEYL7JlCQiVnkhBktUgg=="}]}
    at verifySignature (/usr/local/lib/node_modules/corepack/dist/lib/corepack.cjs:22688:11)

First reaction? Intrigued then skeptical.

JavaScript Is Great - Because It’s Easy

JavaScript (and TypeScript) continues to be my go-to language for many things. Not because it’s perfect, but because it’s simple and productive. The tooling, the ecosystem, and the fact that you can go from idea to prototype in a few minutes is powerful. It’s not the fastest or most efficient language, but with modern engines like V8, it’s good enough for most web and backend apps.

Then enters Bare — essentially a JavaScript runtime without a standard library. No fs, no net, no fetch, no built-in utilities. It’s just you, your JS code, and a JavaScript engine like V8 (which you are responsible for integrating).

So what’s the point?

How Bare Is It

To understand where Bare fits, you have to look at what it’s trying to be:

• Not batteries-included: Unlike Node.js or Deno, Bare gives you nothing by default. You must define the runtime environment yourself.
• Highly modular: You decide what goes in, making it ideal for small, focused deployments.
• Cross-platform focused: It aims to run JavaScript in places JS usually doesn’t go—low-spec devices, embedded systems, mobile runtimes, and more.

In that light, it starts to make sense. Bare isn’t trying to be your daily driver. It’s for when you want just enough JavaScript to get the job done and have full control over what’s included and how it behaves.

Let’s Talk Tradeoffs

Here’s where the pragmatist in me kicks in.

If I’m using JavaScript because it’s easy and fast to work with, then Bare removes much of what makes it appealing. I don't want to care about C and low-level systems when writing Javascript.

At that point, the question becomes clear:

If you have the knowledge and skill to go this low-level just to get JavaScript running, why not just use Golang?

Why Golang Is Often a Better Fit

Golang offers a compelling alternative:

• Compiles to native code (no VM, no runtime)
• rich standard library
• low cpu and memory usage

For most real-world apps that need to run on low-resource environments (think IoT devices, routers, small VMs), Go gives you all the control you need—with the productivity and ecosystem that Bare is intentionally missing.

So When Is Bare a Good Fit?

To be fair, Bare does have a niche. It might be the right choice if you have an existing JS codebase you want to port to a constrained environment. Instead of rewriting the business logic you can rewrite the underlying platform. whatever makes more sense for your project.

In that case, Bare is a great tool because it’s so minimal.

Final Thoughts

Tools like Bare are important, not because everyone should use them, but because they push the boundaries of what’s possible. They give us control and minimalism when we really need it, even if it comes at the cost of convenience and developer experience.

But for most developers looking to build reliable, efficient applications, especially in constrained environments, languages like Go are simply more practical. Bare removes the comfort that makes JavaScript appealing, and unless you’re deeply invested in JS or working in very specific contexts, you’re probably better off using a tool designed for that space from the start.

At the end of the day, the tool doesn’t matter as much as the outcome. Choose what makes sense, not what’s trendy. Bare is fascinating — but for me, and probably many others, it’s a sharp tool for a narrow job.

Short answer: Well, why not? Self hosting! Slightly longer answer: In theory it could speed up client discovery since you don't need to query the same instance(s) as everyone else on the planet. And it can also be more secure to opt out of the global discovery server and only rely on your own server to make your digital footprint slightly smaller. The official guide can be found here. Here is further reading on the security behind the Syncthing infrastructure.

1. Run Discovery Server as Docker Container

The docker container can be found in Docker Hub under the namesyncthing/discosrv. I am running it using the following bash script:

NAME=syncthing-discovery-server
VERSION=1.23.6

docker run \
  --name $NAME \
  -d \
  -p 127.0.0.1:8443:8443 \
  --restart=unless-stopped \
  --network shared_docker-network \
  syncthing/discosrv:$VERSION -http \

Note that I am adding this container to a specific network and I am only exposing the port to localhost. In this network I am also running a caddy server which will be running a reverse proxy and handling the TLS/HTTPS requests. The discovery server needs TLS in order to operate securely. Since I am lazy I will use Caddy to solve this issue for me. All I need to do is to setup an A or CNAME record which points to my server and Caddy handles the certificates.

2. Setup Caddy as Reverse Proxy

As mentioned above, Caddy will handle TLS. The following Caddyfile will reverse proxy all request with your.server.com to the Syncthing Discover Server running as a Docker Container in the same Docker network as the Caddy Docker Container. This Caddyfile is inspired by this old Github comment. But, one of the header is outdated now. The new header_up line to be used is: header_up X-Tls-Client-Cert-Der-Base64 {http.request.tls.client.certificate_der_base64}. This is pointed out in a newer comment on a PR. Please see the whole file below

your.server.com {
  reverse_proxy syncthing-discovery-server:8443 {
    header_up X-Forwarded-For {http.request.remote.host}
    header_up X-Client-Port {http.request.remote.port}
    header_up X-Tls-Client-Cert-Der-Base64 {http.request.tls.client.certificate_der_base64}
  }

  tls {
    client_auth {
      mode request
    }
  }
}

3. Point your Syncthing Client to your Discovery Server

Go to Settings > Connections > Global Discovery Servers and make a comma and add the full URL (e.g. https://your.server.com) to your Discovery Server. DONE!

Notable mention - t4skforce

Before we start, I did not try the docker image t4skforce/syncthing-discovery ([Github(https://github.com/t4skforce/syncthing-discovery)]). This image also runs the Discovery Server with a reverse proxy, but you still need to provide the SSL certificate yourself.

Versions

This writeup was using the following versions for the included software

• Syncthing 1.23.6
• Caddy 2.6.2

Resources

• Manual

First Boss: MongoDb

The problem began when I was trying to get MongoDb running on the RPi4. Not the latest version, but recent version would not start. After a while I understood that MongoDb targets a minimum instruction set of (ARMv8.2-A) which is later instruction set than what RPi4 implements (ARMv8-A). However I could still run a previous version of the major 4 version (4.2.18) which was before the switch (as of writing 6.0.5 is the latest version) However this solution is not very future proof and probably means that updating Rocket.chat is limited.

Second Boss: Rocket.Chat (spoiler alert: Game Over)

After MongoDB was up and running my focus shifted to rocket.chat itself where I ran into the same issue. There were no support for ARM when running the latest version Rocket.chat. I thought it was a bit weird since it’s just a node.js program... However there is a 3 year old half decent instruction to run an older version, but it wasn’t working out of the box. After some searching on their GitHub issues and their website forum I realized that ARM support was not a priority nor something the core team was interested in.

Side Quest: Mini-PC

As a side quest I started looking into mini-pc since I remember a comment on hacker news giving a tip about MeLe Quieter3Q (intel N5105 processor). It costs ¥35.000-¥40.000 which is more than double the RPi4 (there are cheaper mini-pc but they have a loud fan) but it’s a x86-64 processor which just makes everything so much easier for server development... What makes this something interesting is that the wattage is supposed to be very similar to RPi4 which is one of the main reasons I went for the RPi4 as my home server solution, while also having a virtual (x86-x64) server at Digital Ocean as my main server.

RPi4 - 5W (idle 3W) source: source1, source2

Quieter3Q - 11W (idle 3W) source: source1

At this very moment I don’t have the need (nor the time #dad) to tinker with a mini PC but it’s definitely something to note for future needs.

Footnotes

1.

• arm64 Docker images
• Outdated snap packages for armhf and arm64

Apparently Caddy does not read the TZ enviornment variable. See: https://caddy.community/t/set-timezone-for-caddy-2-official-docker-image/8622

In order to get logs in local time you need to build your own image. I started building my own Dockerfile in the blog post: Caddy in Docker with common_log. This is what we need to add in order for TZ env var to work:

RUN apk add --no-cache tzdata

Which makes the full Dockerfile:

ARG VERSION=2.6.2

FROM caddy:${VERSION}-builder AS builder

RUN xcaddy build \
  --with github.com/caddyserver/transform-encoder

FROM caddy:${VERSION}

RUN apk add --no-cache tzdata # <-- ADD THIS

COPY --from=builder /usr/bin/caddy /usr/bin/caddy

Forking and modifying transform-encoder

Section spoiler: This was a dead end :)

I forked the transform-encoder repo and hardcoded TimeLocal = True. I think it was a fun exercise to write some Go which I don't do so often. I could successfully make the change and then tried to build a new caddy image. However, I ran into an error:

module declares its path as: github.com/caddyserver/transform-encoder
        but was required as: github.com/MrOggy85/transform-encoder

In order to replace the module with your fork you need to write your Dockerfile using = like this:

RUN xcaddy build \
  --with github.com/caddyserver/transform-encoder=github.com/MrOggy85/transform-encoder@master

I was finally able to build a new caddy image, ran it, but no change... Back to Whoogle and I finally found out what I statated in the beginning of this post, that you just need to add/install tzdata.

tl;dr

Here is the image if you want to use it right away:

docker pull mroggy85/caddy:2.6.2

See my Docker Hub Page: https://hub.docker.com/r/mroggy85/caddy

TL;DR - You can store the salt in plaintext without any form of obfuscation or encryption, but don't just give it out to anyone who wants it.

Polynomial

The reason we want to salt the password is to make it harder for an attacker to crack the passwords, once the DB has been comprimised. When the password has been encrypted with the salt, an attacker can't use a rainbow table. This means that the attacker needs to spend a lot of time decrypting the passwords. This gives you time to detect the breach and reset all the passwords.

Read the full answer here for a full technical deep dive.

You are hacking away on a personal website using React or any other SPA technology. You also need to write a backend service to connect to your DB in order to persist your data across your different devices and client. However, imagine if you could just use a general backend to directly connect to your DB?

How?

Deploy a HTTP server that accepts POST requests with a JSON body. The body needs to include the credentials and location of your DB as well as the SQL you want to execute. Then you just connect to the DB using the credentials from the request and execute the query. Return the result and you are done.

Usage Example

It's very convenient to use for a web client. See this example using axios:

type PostgresProxyResponse = {
  command: "SELECT";
  query: unknown;
  rowCount: number;
  rows: any[][];
};

async function request(q: string) {
  const response = await axios({
    url: "/",
    baseURL: HTTP_ADDRESS_OF_ADEPLOYED_API,
    method: "POST",
    data: {
      u: "DB_USER",
      pw: "DB_PASSWORD",
      h: "DB_HOST",
      port: "DB_PORT",
      db: "DB_NAME",
      q: "SELECT * FROM table",
    },
  });

  return response.data;
}

Security concerns

This is a short-cut solution for personal web projects to enable rapid development. This assumes you are consuming a Postgres DB that is open to the internet. If you are developing a web service for other users, it means that they need to establish connection to their own DB. Otherwise you need to include the DB credentials (in plaintext) for all users to see.

Needles to say, since this solution pushes the DB credentials down to the client, it's not a very secure solution, unless you trust the client, since you wrote it yourself.

Another issue is that you need to run your own proxy to be safe. Right now I am not logging the credentials, but it's easy for a malicient service to store your crentials. Also, since you are sending your DB credentials over the wire, make sure it's HTTPS!

Performance concerns

The API is static, which means it will open and close a DB connection for each request. Therefor it adds extra latency. Another performance concern is the multiple protocols involved and data tranformation happening for each SQL command. With that said, this is obviously not a perforant nor a scalable technical solution. However, for the very small scale it's intended for it's suffice.

This is very handy if you like your website to be able to send SQL commands directly to the DB. It's very useful for small personal projects. But, it's definitly not recommended for any service with multiple users because of obvious security concerns. Please use it at your own risk.

Take away

This is far from rocket science, and someone probably already created this. However, I didn't find this solution after some (Brave) searching so I wrote it instead.

See Github: https://github.com/MrOggy85/postgres-proxy

According to Caddy's official Docker Hub documentation, we need to create our own Dockerfile with the builder image (caddy:builder) and then create our own Caddy image.

This is how the Dockerfile looks like:

ARG VERSION=2.5.2

FROM caddy:${VERSION}-builder AS builder

RUN xcaddy build \
  --with github.com/caddyserver/transform-encoder

FROM caddy:${VERSION}

COPY --from=builder /usr/bin/caddy /usr/bin/caddy

The magic part is the line:

RUN xcaddy build \
  --with github.com/caddyserver/transform-encoder

Which pulls the transform-encoder plugin and installs it. Then we are switching to a "normal" Caddy image and just replacing the binary with our custom built one.

Now you just need to build and run this Dockerfile locally!

Caddyfile

This is the syntax to use it in a Caddyfile:

log {
        format transform "{common_log}"
        output file /var/log/homepage.log
    }

tl;dr

docker pull mroggy85/caddy:2.5.2

See my Docker Hub Page: https://hub.docker.com/r/mroggy85/caddy

created using craiyon.com

TIL about iTerm2 Triggers which is a super easy way to super charge your terminal. It's a feature that let's you highlight text, create links and much more!

You can find it in the settings here:

Highlight IP Address

One thing that I have added is to highligh IP Addresses, which makes it very easy to distinguish addresses when glancing over a log.

Regular Expression: (\b25[0-5]|\b2[0-4][0-9]|\b[01]?[0-9][0-9]?)(\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)){3}

Look at all those hacker attempts... Now in gold color!

Link to Jira

Another nice feature is to add a clickable link to the Jira ticket. For example when you check the git log you can now directly just shift+click and come directly to the Jira ticket in the browser.

• Regular Expression: (?i)wf-\d+ (replace "wf" with your Jira project's key)
• Action: Make Hyperlink
• Parameters https://jira.your-company.jp/browse/\0 (replace "your-company" with your company's subdomain)

created using craiyon.com

• Why strive for this type of code?

We devs are usually both lazy and perfectionists. If we could only write these perfect pieces of DRY (Do not Repeat Yourself) business logic and helper function then we can use them as Lego blocks going forward. Then we could handle any business requirements, new or changed, in theory.

Having a file with frequent changes is considered a bad thing by a lot of validation tools. And why is that bad? Because we want to our code to reach a stable state. Write and forget. If we need to go back to the same place and make a change we missed an opportunity the first time to make it right.

• We have now wasted time. Right?

However, I think this mindset is not very helpful when writing a business application. Why? Because the business requirments change all the time. The very reason for our code changes. This is nothing new, this is the basis of the agile methology. However, the agile mindset is in conflict with the dev mentality and the persuit of perfect code.

The reason we code is because we want to achieve something. If we want to achieve something different we need to change the code.

We have to embrace the fact that our code will never be finished, since the reason, (business, competition, economy, etc), is ever-changing. This is the essence of "embrace change" (2.) from the agile manifesto. Just follow the logic; The reason we code is because we want to achieve something. If we want to achieve something different we need to change the code.

in order to write good code we need to have good communication with business

It all comes down to human communication, something that we devs are naturally bad at. A lot of us devs came to the field because we like to talk to computers rather than flimsy meat bags. But, in order to write good code we need to have good communication with business. The quality of code cannot be soly determined by looking at the code, you have to also look at the purpose it serves. That's why code analytics tools can easily lead us astray. They don't take business requirments into consideration. Good code may smell, but if the reason for the code frequently change, what do u achieve by "fixing" it?

Generic code only works if we anticipate business changes.

Writing specific code rather than generic code will help you to quickly fulfill business requirments. Generic code only works if we anticipate business changes. While there are many best practices to make generic code it all boils down to guess-work. To be able to figure out what business wants in the future is similar to betting. You can take calculated risks with better communications with business to get a better understanding of upcoming changes.

We are better of if we concede the notion of perfect code and instead focus on easily refactorable, extensible code or even code that can be thrown away. This goes against programmer culture which glorifies e.g. old Unix programs that have been around for centuries and doesn't need patches since the are considered done. Perfect. The author got it right.

While the persuit for perfect code is admirable and true in some sense, it doesn't serve us as a guiding light. Instead, focusing on the reason will better guide our coding decision making. And since the reason is ever changing, your code needs to change with it.

We have a communication issue

What's the value added?

The tech people only focuses on the technical solution. The financial people only focuses on the speculation market. Both are pointing in a positive direction. So from their perspective they can't fathom why they are receiving so much criticism.

Yes, blockchain technology is cool, but it does not meet the expectation it sets on itself.

The cristism boils down to: What's the value added? It seems like the for the majority of the solutions currently on the market, there would be a negative value for switching to blockchain technology. There may be a new, nische, market for blockchain technology. This is were the divide between blockchain lovers 🥰 and haters 😤 are the greatest. Web3 is pitched to be a revlutionary technology which is going to replace the current state. This bold claim requires ground breaking technology. Looking from the outside, there is nothing that even remotely meets that standard when it comes to blockchain technology. This is the heart of the issue. Yes, blockchain technology is cool, but it does not meet the expectation it sets on itself.

It is a solution in search of a problem.

The main innovation is the distributed leger. Yes, it removes central control, in theory. Yes, it requires more resources than a traditional database, but that's the trade-off. However, is this a technical solution that is interesting for most mobile apps, SaaS, social media, websites, games and other technical services and products out there? No, not really. The current problems are not solved with this technological innovation. It is a solution in search of a problem.

Can't Separate Blockchain and Cryptocurrency Speculation

I view blockchain technology as separate from the value of cryptocurrency. But, I don't think they can be separated. They are driving each other forward. The hype of blockchain leads to an increase in value of cryptocurrency. The increased value of cryptocurrency leads to an increase to the hype of blockchain. And the circle goes on... There is a promise of future market adaptation of blockchain/cryptocurrency technology. This is where web3 comes in. I want to make a distinction between blockchain and web3. From a technical point of view it's a suttle one, but from a community point of view it's a differentiator worth noting.

Definition of blockchain technology and the people working in this space

These are all very smart people, working on a grand vision with high principles. It's a very admirable cause and an exciting future, if it ever would be realized. It's a space that has been around for at least 14 years, since Bitcoin emerged 2008 (I guess you can say it started earlier or later depending on your definition, but this is what I am going with here). Over the years a lot of innovations has happened, new blockchains have emerged with different technical solutions. New solutions on top of blockchains have emerged like smart contracts and NFTs. Here is where web3 definition stsrts

Definition of Web3

I see web3 as an evolution of the blockchain and cryptocurrency community. With a very important addition, the non-techy, financial speculative persons. There was a realization that a lot of money could be made in this space. Add som fomo and trending social media posts. All of these people were very influencal. They had capital and good reputation. But, in order to sustain the flow of cash, the technology needed to be inflated. Big promises were made that can't be backed up with the reality of the technology.

Possible Future

This is my prediction: When investors realize that blockchain and cryptocurrency will not reach the anticipated market adaption, we will see a meltdown in investments in companies working on blockchain technology and the hype over blockchain will be over. Blockchain and cryptocurrency will still be around of course, but the talk about web3 as the next step in the evolution of the web will die out. DFi, or "Decentralized Finance" will still be around since that's the main application of blockchain technology, interacting with the transactions on the ledger. But, that's the limit and were mass adoptation of blockchain tech will end.

Nowadays Instagram is the standard for photo blogging. I really don't like Instagram for a number of reasons including giving my data to the Facebook algorithm, and the whole idea of sharing with everyone by default. I recently looked into an open source alternative: Pixelfed and tried out running my own server. It's a nice service, but to share my photos with my family and friends the barrier of entry is too high. Another alternative is to run a Ghost blog, which I have tried. However, posting a new entry with pictures is pretty tedious and I found myself not posting as much as I wanted.

What I am trying to achieve is pretty simple: Just a website where each page is an album with pictures of my everyday life that can be viewed by my close family and friends, if they want. And the most important: A very very easy way to publish new photos and albums.

Overview

Technologies used:

• Next.js
• Deno
• Syncthing

From an end users perspective there is nothing interesting. Just a website that connects to an API which serves some images.

From the website admin point of view it gets more interesting. Let's say you want to upload a new album with some images. Just copy the images on your phone to the special folder on your phone, wait a couple of seconds and boom! Your new album has been published! But how does it work?

Syncthing - Sync Photos

Syncthing is a peer-2-peer file syncing service which doesn't require any central server like e.g. Dropbox. For this project I have a folder on my server that is synced with a folder on my smartphone. This can also be synced with another device if you want to edit/add photos from another device.

Deno - Serve Photos

Deno is the new kid on the block that will eventually replace Node.js. With deno I built a simple HTTP server, running in a Docker container, that reads from a mounted folder called files. The endpoint /list will return each folder name that exists in the main folder. The endpoint /album/:albumName will list all the images in the given album folder folder. And finally the endpoint /photo/:albumName/:photoName returns the image.

Look at the code

Next.js - Show Photos

Next.js is a JS Framework on top of React and Node.js from Vercel. The website basically have 2 routes. The index route will list the albums. When clicking on an album the page will list all the photos in the album.

Look at the code

Further Automation

To make the deployment easy I am leveraging Vercel to host the frontend and to auto-deploy on each push to master.

I also setup Docker Hub to listen for pushes to master and auto-publish a new Docker image. Currently this flow is semi-automated cause I still need to login to my server and pull the latest image and restart the container.

Conclusion

That's it! If you follow these steps you now have a photo blog you can share with your friends and super easily update with new albumbs and photos.

You can find my photo blog here: https://www2.oskarlindgren.se/photos

Repos

• Photo File Server repo
• Photo Blog repo

• Ownership/Control - owning the service (together with the community)
• Privacy - owning the data
• Learning - opportunity to learn
• Stability - no unexpected changes
• Reliability - the service will not dissapear (Google graveyard...)
• Cost - server cost but no service costs

To host your own services is a really good learning opportunity for server management and security. And as an added bonus you get personal services which is only used by you and your friends.

How does my server structure look like?

I have two small virtual servers (1 CPU, 1GB RAM each) on Digital Ocean which costs me 15$/month. And I run all my services with Docker to make most use of each server. Docker also simplifies maintenance drastically since nothing has to be directly installed on the server. And I use Caddy as a reverse proxy for easy HTTPS/SSL support and super easy configuration compared to nginx. This is how my Caddyfile looks like:

oskarlindgren.se {
    redir https://www.oskarlindgren.se{uri}
}

www.oskarlindgren.se {
    root * /usr/share/caddy

    redir /blog /blog/
    reverse_proxy /blog/* http://tech-blog:2368

    redir /photos /photos/
        reverse_proxy /photos/* http://photo-blog:2368

    file_server
}

MASKED.oskarlindgren.se {
    reverse_proxy http://owncloud-docker-server_owncloud_1:8080
}

MASKED.oskarlindgren.se {
    reverse_proxy http://firefly:8080
}

MASKED.oskarlindgren.se {
    reverse_proxy http://freshrss
}

MASKED.oskarlindgren.se {
    reverse_proxy http://fathom:8080
}

I also recently added a 300GB volume for 30$/month for additional storage. Primarily to be able to store photos.

Total monthly cost: 45$

This is my price for privacy and learning :)

What services do I run?

Email - Mailu

Running my own email server may be the most important service I have. The main reason is privacy. The reason you get email for free from Google and others is that they are reading your emails and knows who you are communicating with. I feel that it's a bit creepy. There are some services that offer you privacy, but you have to trust them and you have to rely on their service. The ultimate solution is to run your own email server. It's not super easy but there are multiple projects that give you an easy setup. I use Mailu which is a stable email solution.

Update: Even though I ran Mailu without any bigger problems for a while I found it too tedious to tinker with. Especially for sending email. I now switched to Tutanota which is a ery privacy focues email provider based in Germany.

I am still using my own domain, and it was easy to allow wild card aliases which allows me to create email aliases on the fly to have a unique address for each service I signed up for.

Calendar, Contacts, Documents - Owncloud Nextcloud

Update: I recently switched from Owncloud to Nextcloud since Nextcloud comes with batteries included for a personal use.

It's super easy to run Nextcloud (or Owncloud) and let your phone sync your contacts, calendar and documents from it. And as an extra bonus you can store all your important documents there instead of in Google Drive or Dropbox.

Blog - Ghost Nuxt

This blog is running on Ghost and hosted on my server Vercel powered by Nuxt. The analytics is provided by Fathom which has a Lite version you can use for free.

Update: I decided to use a static site generator instead of Ghost. Ghost is well suited for someone with low technical knowledge, but when you are a developer it becomes a blocker rather than an enabler. I also don't like the fact that it relies on a DB. I want something super fast and simple. I got inspired by this article from derkizni and set up Nuxt using @nuxt/content.

Homepage - Caddy

My homepage is just a HTML file and a CSS file. I tried to keep it light, which makes it eligible for the 250kb club. Using Caddy to serve these static files with TLS/SSL support makes it super easy to make changes through sFTP.

Update: I'm still using Caddy as a reverse proxy for all my self hosted services. But, I switched to Vercel for my homepage and other frontend because of the ease of deployment.

Photos - PhotoPrism

I recently started running PhotoPrism to organize and host my photos. It's an alternative to Google Photos and Dropbox which can auto import your photos and organize them based on Tensorflow and analyzing the image metadata.

However, PhotoPrism needs at least 2 CPU cores and is very CPU intensive when ingesting photos so I decided to put it on my local server at home. I tried some lighter services like Piwigo and Lychee, but they where a bit too light when it comes to the features I was looking for.

RSS Reader - FreshRSS

To consume blogs, newsletters, etc I use FreshRSS which is a very simple and light service to keep track of the blogs I like to read. Instead of relying on an external service like Feedly you can just run your own.

Notes, Files and Passwords - Syncthing / KeePass

I have opted out of any central storage of my files by using Syncthing. Syncthing let's you sync your files directly to any other device (Note: It doesn't work on iPhone). This is very convenient to:

• backup your mobile photos to your server
• sync documents between phone and laptop
• sync your keepass password file
• sync your ssh keys

For my notes I just have a folder with markdown files (which I view/edit with VSCode). Then I can use Markor on my Android phone to easily view and edit my notes.

Previously I used Lastpass, but I switched to KeePass since I don't want to store my passwords with someone else. With KeePass and Syncthing you can achieve the same level of convenience as with Lastpass, but without the risk of your passwords getting leaked in a hack of Lastpass.

Why do you want to run your own services?

There are a couple of reasons why you want to run your own services.

Privacy

You wouldn't give your front door key to your local store owner, right?

When you are giving your data to someone else, they will use it for other purposes than yours. It's hard to predict what someone else can find out about you or what they will do to the data once they have it. Normally a service is run to make money for the owner. This means that they will use your data to maximize their profit. If the service chooses to try to improve the service based on your data that could be a net benefit for both of you. However, the service providers purpose is to make you stay, not to help you. They may try to game you into staying or even create a wall garden. If you keep your data to yourself and only share necessary data to specific people you know you will have a safer life.

Real world example: You wouldn't give your front door key to your local store owner, right? Even if it would be convenient if they can go in and leave some groceries in your kitchen, it wouldn't feel safe to let in a stranger in your home unsupervised...

Ownership

It is very convenient to rely on a service to store and organize your data. But, what happens when the service goes down, or when they decide to shut down completely. When you run your own service you run it for yourself. The purpose is to help yourself to organize your life. You will probably not create any of these solutions from scratch, but rather rely on Open Source and Free Software. These projects are driver by likeminded people that want to solve a problem and to let others use it for free.

Of course you have now traded a dependency of a for-profit to a dependency on an open source service. But, for me I think it's better to be dependent on a free, open source, right to fork service than a paid, proprietary, closed source service.

Security

The probability that you will be a target of a hack is lower than any known service out there.

When you run a server that is accessible on the internet you will constantly be proned by script kiddies. Just make sure you have Fail2ban setup and that you don't expose any ports that you don't need to limit attack vectors. The probability that you will be a target of a hack is lower than any known service out there. However the top services out there will probably be way better than you at server security. In the end, as long as you are comfortable with the risk when running your own services and take proper precautions it should be fine.

Backup

Backup, backup, backup. Even if you rely on a service you should make sure to backup your data regularly. However, when you run your own it's even more important to have backups. Make sure you store the backups in another machine.

“With Deno you get TypeScript as a first class citizen”

Since around 1,5 years ago I have been mainly writing code using TypeScript. I was hesitant at first since I didn't think types was needed in Javascript until I started using TypeScript. It really makes writing Javascript Apps a bliss. With Deno you get TypeScript as a first class citizen. No need for any babel or typescript compiler setup. Deno will natively support your code. If you also like typescript and don't like extra setup boilerplate code Deno is for you.

“Deno allows you to get your dependencies from anywhere on the web”

Another reason for using Deno is more of a political one. NPM has grown and are now part of Microsoft. It is a centralized resource which is a part of the centralization of the web we have seen in the recent years. Sure, you can still host your own NPM repository, but by design Node needs to be compatible with NPM. Deno allows you to get your dependencies from anywhere on the web. If that is from Github or somewhere else it's totally up to the you and the community. To be fair, currently most of the libraries are hosted in Github or NPM.

“Talk is cheap. Show me the code.” - Linus Torvalds

That's all about the background of why I like Deno. Let's move on to the code. I wanted to make a simple app where a number was spoken in Japanese and the user would guess the number by typing it directly. Writing a simple script executed in the terminal makes the app very light with no need to create a Web interface or Desktop application. But, I still wanted the TUI to be nice and snappy so that the user can go through a lot of numbers fast.

I chose to go with a REPL approach to make the program continue executing until the user chooses to exit (by ctrl-c). The core of the program is this while loop:

const buffer = new Uint8Array(1024);

while (true) {
  const input = await Deno.stdin.read(buffer);
  const textRaw = new TextDecoder().decode(buffer.subarray(0, input!));
  const text = textRaw.trim();
  console.log(`you wrote: ${text}`);
}

Btw, did I mention that Deno supports top-level async/await?

As you can see in the code above. We are simply (a)waiting for the user to input some text. Then we can decode it and do something with that text. For this app we want to check if the users guess was the expected number. Let's add some more code!

const nextNumber = Math.round(Math.random() * maxNumber);

const input = await Deno.stdin.read(buffer);
const textRaw = new TextDecoder().decode(buffer.subarray(0, input!));
const text = textRaw.trim();

const numberGuess = Number(text);
const result = numberGuess === nextNumber;

if (result) {
  console.log("You are correct!");
} else {
  console.log(`Incorrect! The correct number is: ${nextNumber}`);
}

This will let the user input a guess and then we check against nextNumber. However as you can see there is an undeclared variable here: maxNumber. This is an input that the user has to give when starting the program to determine what range you want to practice on. Deno makes it easy to read the parameters of a program:

const maxNumberRaw = Deno.args[0];
const maxNumber = Number(maxNumberRaw);
if (Number.isNaN(maxNumber)) {
  console.log("Please start program like this:");
  console.log("./start.sh MAX_NUMBER");
  Deno.exit(0);
}

But, the user is still not hearing any number! Ok, let's add one of the main pieces of the program; Let the machine speak! So, this next part assumes that the user is running a Mac. This can easily be modified to be adapted to Linux and Windows. I am using the program say to do text-to-speech. This comes preinstalled on any Mac. Then we can use the Japanese voice to let the number be spoken in Japanese. To run a command from Deno it's as easy as this:

function sayNumber(number: string) {
  Deno.run({
    cmd: ["say", "-v", "Kyoko", number],
  });
}

Each string in the array maps to a word written in the terminal. Just be careful since it's async. If you want to make sure that the command you are executing is finished before moving on you need to await it.

Now we can add use this function to let the computer speak the number and the user can guess it. I also added a clear command after each guess to clean up for the next number. And of course some cute bunnies to emote the result to the user.

//   /) /)     (\\_/)   (\\-/)
//  ( ^.^ )    (>.<)    (='.'=)
// C(") (")   (")_(")   (")-(")o

See the full source here.

Happy coding!

The list is actively maintained and new scientists are added and also removed. After being accused of sexually abusing trafficking victims, Marvin Minsky was removed along with Richard Stallman that publicly defended his actions.

• related article: https://frightanic.com/computers/docker-default-container-names/
• Image credit: https://www.praqma.com/stories/Deploying-to-kubernetes-as-part-of-a-pipeline/

This inspired me to think about where frontend development is today. I have lately also recently seen a divide, but on another topic, when it comes to use static types and Object Oriented Programming in the frontend. But, let's go back from the start first to see why we are where we are today.

Disclaimer:
This is a gross simplification of the history of the web and data has been cherry picked to fit my narrative. There is probably some facts not mentioned or wrongly described that effects some of my points and I am open to feedback to adjust my views.

First Gen - World Wide Web Dev

The information Highway was born at CERN by Tim Beerners-Lee and released to the public in 1991. At this point every website was just static webpages directly served from the web servers. Each URL pointed to a specific directory which had an index.html where you also could point to other sources like css files, images, etc. Updating the website meant changing the html file, uploading a new version by ftp and then the users got the new content. After some time the need for a more dynamic experience led to the introduction of Javascript in 1995 by Brendan Eich and during the same year cookies were introduced by the same state of the art browser at the time: Netscape.

At this point frontend development was not really a known term. Programmers were able to create html files that could be interpreted by a browser to show a document. It was mainly used in research and websites where very informative and non interactive.

Second Gen - Web 2.0

"I tried to make it slow. I really did. But I'm not Dinesh. It's very difficult for me to do shitty work." - Gilfoyle

The need for more an even more dynamic experience led Rasmus Lerdorf to, in 1995, create PHP to be able to serve web pages through a template engine. This led to a remarkable creativity boost for web development since you could access a database to tailor the experience of the user and create an html page on the fly.

But the most important interesting part of this time was that a lot of people could set up their own website easily thanks to services like e.g. Angelfire, Geocities, AOL, etc. I think that, the idea that frontend is easy and unimportant was born during this era. The second half of the 90s can be summarized by these gifs that frequently was shown on peoples websites:

This technology would however enable the environment where internet based business could start to form. And it also led to a specialization between frontend and backend. The frontend developers was mainly focusing on the design of the page through html and css with a small portion of Javascript to enable some dynamic features. And the backend developers would focus on the business logic of the site.

The web gained a lot of traction during the second half of the 90s and got a crazy hype which led to the dot-com bubble which bursted in 2000. But, the web was not dead. The technology was still great but the expectations had to be realigned closer to the reality of what promises the technology and developers could offer.

During the first decade of 2000 the web became even more dynamic and the term web 2.0 was coined and got popularized by O'Rilley Media in 2004. The web became a platform for applications and the clients (browsers) started to become richer. Realtime updates of the website became a big feature.

Now frontend development became more complex. A lot of business logic that was previously handled by the server was moved to client side to enable user interaction without the need of a page reload with the use of Ajax calls. There was also a ton of third party integrations that bloated the global scope and the css files grew into biblical proportions. And there were still a lot of differences between browsers which led to jQuery being born in 2006 by John Resig.

Leave the gun – take the cannoli. - Clemenza

By around 2010 web development was a mess, imho. The server and client code was a perfect spaghetti carbonara served a million times a second around the globe. A lot of great developers and organizations started to generalize the solutions they created and shared them with the community which led to the next generation of frontend developers.

Third Gen - Javascript Dev

"...which made frontend development into it's own domain."

In 2010 AngularJS and Backbone was released, followed by Ember the next year. This was the start of Web Apps which introduced concepts like MVC which were never used in frontend before. It was also a step back to the first generation of websites with statically served websites, but a leap forward for dynamic websites and rich clients. The result was a totally decoupled frontend and backend which made frontend development into it's own domain. The server didn't need to serve html and became an Restful API for the frontend to consume (However the need for a good SEO score later reversed this decision and introduced server side rendering of the frontend app).

"This would later be known as Javascript fatigue to try to keep up with all the new stuff."

When the frontend was living in it's own world outside the server a lot of tooling was invented to handle the need for a rapid development which led to Grunt, Gulp and Webpack to be introduced. Furthermore NPM became the place to share libraries, where several new solutions would be published every day. This would later be known as Javascript fatigue to try to keep up with all the new stuff. Javascript as a language grew with a lot of new features. But, all features where not supported by all browsers or not yet finalized which led to the creation of Babel. As a frontend developer in around 2016 you where expected to master these tools and to at least have the knowledge of one of the javascript frameworks out there.

This new frontend development divided the notion of a frontend developer from the previous era. Being proficient in html and css was not enough to get you hired anymore. Now programming skills and knowledge about certain frameworks was what frontend development was all about.

The shift didn't happen over night though. Most companies continued to use their previous server side template based solutions, but slowly started to convert to the new javascript frameworks as they matured. As more and more businesses shifted their tech stack to heavily rely on a Javascript framework, this meant that more and more of their business logic moved to the frontend.

"...the biggest migration wave in programming history."

This is what I identify as the biggest migration wave in programming history. Not only a shift in tech stack, but especially for backend developers migrating to a brand new world. Backend developers that previously only been working on server side code in statically typed compiled languages now found themselves in the dynamic and browser interpreted domain of Javascript. And they were far from happy to find themselves in this country... As Javascript gained traction and popularity so did the frustration which was popularized by the wat presentation in 2012 by Gary Bernhardt. It's an understatement to say that Javascript as a language did not fit into the expectations of these developers.

(predicted) Forth Gen - Typescript Dev

There where several attempts to radically improve Javascript with a superset language such as CoffeeScript, introduced in 2010 by Jeremy Ashkenas, followed by Dart in 2011 and Elm in 2012. These languages were popular, but never gained any mainstream traction.

Class was introduced in ECMAScript 2015 to the delight of objected oriented developers, but was imho, vastly misinterpreted since it was only a syntactic sugar for using the new operator. This however created a big shift in how a lot of Javascript was written, since the former backend developers were used to declare classes when coding. There was already an awkward naming convention in Javascript to use an underscore to mark a method as "private", when in reality it was accessible publicly. This remained a practice even after class was introduced, since it didn't actually change the underlying language.

There was however still a big annoyance with Javascript: The lack of static types. Enter: TypeScript by Microsoft. The first version of TypeScript was released 2012, but it wasn't until after ECMAScript 2015 and Angular 2 which was officially released in 2016, until it gained some serious traction of the community. Typescript became the standard way of writing Angular apps. Facebook had their own way of doing static type checking in React with Flow, but it never went mainstream and now a lot of development is now done with Typescript. Vue added Typescript support from version 2 and in their next version will be written in Typescript and be a first class citizen. The Javascript community embraced Typescript during 2018 and more and more libraries bundled type definitions and wrote their libraries using Typescript.

The Future of Frontend Development

The web browser is today a synonym to Chrome. The Browser Wars are over and Chromium is the victor. Microsoft's decision to shift Edge to be Chromium based is a proof that the game has changed. The only odd sheep left on the battlefield is Firefox and Safari, but they can't currently put up a fight.

Google had plans to introduce Dart as a replacement for Javascript in the browser, but cancelled those plans in 2015. During this time Dart was not by any means a popular language and Chrome was still not the dominant browser as it is today. But, today the environment has changed. All the ingredients that wasn't present before is now in place. I predict that during 2019 there will be a first version of Edge and Chrome that supports Typescript native in the browser.

Being a frontend developer in the 2020s will be indistinguishable from a backend developer. The wild wild west of frontend development has an expiration date which will come sooner than we expect. Be prepared for the change.

Sources:

• https://shoptalkshow.com/episodes/346/
• https://en.wikipedia.org/wiki/World_Wide_Web
• https://en.wikipedia.org/wiki/JavaScript#History
• https://en.wikipedia.org/wiki/HTTP_cookie#History
• https://en.wikipedia.org/wiki/PHP#History
• https://en.wikipedia.org/wiki/Dot-com_bubble#Bursting_of_the_bubble
• https://en.wikipedia.org/wiki/Web_2.0#Web_2.0
• https://en.wikipedia.org/wiki/JQuery#History
• https://en.wikipedia.org/wiki/AngularJS
• https://en.wikipedia.org/wiki/Backbone.js
• https://en.wikipedia.org/wiki/Ember.js#History
• https://www.destroyallsoftware.com/talks/wat
• https://en.wikipedia.org/wiki/CoffeeScript
• https://en.wikipedia.org/wiki/Dart_(programming_language)#History
• https://en.wikipedia.org/wiki/Elm_(programming_language)#History
• https://en.wikipedia.org/wiki/TypeScript#History
• https://en.wikipedia.org/wiki/Angular_(web_framework)#Version_2
• https://techcrunch.com/2015/03/25/google-will-not-integrate-its-dart-programming-language-into-chrome/

Still interested? Let's start!

Note: This setup is written for:

Ubuntu 18.04
Docker version 18.09.0, build 4d60db4
docker-compose version 1.21.2, build a133471

It will probably be compatible with Mac and other Linux distros though.

We will use docker and docker-compose. If you haven't installed them already please download and install them here: https://www.docker.com/get-started

What is a NPM Registry?

It actually turns out that NPM has a pretty simple structure. You can just roll your own with a Node.js server and a CouchDB instance and follow the instructions from NPM: https://docs.npmjs.com/misc/registry

A better alternative: Verdaccio

But, who wants to reinvent the wheel if we already have a Ferrari available with minimal setup? Let me introduce you to Verdaccio; "a lightweight private npm proxy registry" which is a pretty damn good description. It's a node.js server with a simple file based db, but you can also configure it to store your packages in a Amazon S3 bucket or Google Cloud Storage.

Verdaccio with Docker-Compose

We want to run Verdaccio as a docker container for ease of deployment. You can find the latest Dockerfile here. We will use Verdaccio version 3, which is the latest as of writing this blog post. First of, let's create a docker-compose.yml file and fill it with this content:

version: '3.1'

services:
  verdaccio:
    container_name: 'verdaccio'
    image: verdaccio/verdaccio:3.0.0
    restart: always
    ports:
      - "4873:4873"
    volumes:
      - ./data:/verdaccio/
    networks:
      - docker-network

networks:
  docker-network:
driver: bridge

Note that we are mounting a volume called "data". This is where Verdaccio stores packages and users. We want to store this on the host to be able to persist all data when restarting our docker container. Let's create the data folder.

~$ mkdir data

Verdaccio is running inside the Docker Container with it's own user verdaccio and usergroup verdaccio. You need to give permission to your System's Network Management service to make changes in the folder. Let's create the data folder and set the correct permissions.

~$ sudo chown -R systemd-network data/

That's it! Let's fire up this bad boy!

~$ docker-compose up -d

You can now access it on http://localhost:4873

Configuring Verdaccio

The config file data/conf/config.yaml holds the configuration.

Docs: https://verdaccio.org/docs/en/configuration

Basic Usage

Point your npm cli to Verdaccio

~$ npm set registry http://localhost:4873

Add yourself as a user

~$ npm adduser --registry http://localhost:4873

Now you can use npm as usual but everything will be proxied through Verdaccio. Have fun coding!

Full source at Github: https://github.com/MrOggy85/verdaccio-docker

My initial inspiration for the page was when I stumbled upon NES.css from reading the Frontend Focus newsletter. It was so simple and elegant and really touch my childish self. I just had to use it for a project. And why not use that style for a CV page?

Create a Profile Card

Add the NES.css to your <head>

<link href="https://unpkg.com/nes.css@0.0.2/css/nes.min.css" rel="stylesheet" />

The next step is to create a container with a title using the NES.css framework.

<section class="container with-title">
  <h2 class="title">Oskar</h2>
</section>

Then I will add a row with my Github picture and a encouraging text to navigate some of the sites where I actually have some content to show.

<section class="container with-title">
    <h2 class="title">Oskar</h2>
    <div class="row">
    <img src="https://avatars0.githubusercontent.com/u/2677573?s=460&v=4" alt="profile picture" width="100" height="100" />
    <div style="margin-left:28px;">
        <p>
              Hello!
        </p>
        <p>
              Please check me out on Github and LinkedIn or follow me on Twitter.
        </p>
        </div>
    </div>
</section>

#styles.css
.row {
  display: flex;
  flex-direction: row;
}

The next row will be a list of icons with links to the services I want the visitors to navigate to

<div class="row right-aligned">
     <a href="https://github.com/MrOggy85" style="margin-right:5px">
         <i class="icon github is-medium"></i>
     </a>
     <a href="https://twitter.com/oskarlindgren" style="margin-right:5px">
         <i class="icon twitter is-medium"></i>
     </a>
     <a href="https://www.linkedin.com/in/oskarlindgren/">
         <img src="assets/linkedin.png" width="48" height="48" />
     </a>
</div>

#styles.css
.right-aligned {
  justify-content: flex-end;
}

The result:

Okay so that very informative and pretty cool. But, it's not very engaging. I needed some kind of visually stunning effect in the same spirit. I needed a side scrolling background!

Creating a 3 layer Side Scrolling Background

To create a good depth perception 3 level of backgrounds scrolling at different speeds is good enough. And we can achieve this with only CSS.

First the HTML

<div class="wrapper">
    <div class="mountains"></div>
    <div class="trees"></div>
    <div class="grass"></div>
</div>

For the background images I found some really nice pictures at a Fandom site called Super Mario Bros X Wiki. I needed to adapt the pictures a little bit since the image will repeat 3 times at the x axis to create the illusion of scrolling (if you have a really wide picture you don't need this).

To accomplish the scrolling effect we will use animation and @keyframes. Let's start with the first layer which will be the mountains in the far back.

.mountains {
  position:absolute;
  top:0;
  bottom:0;
  left:0;
  right:0;
  background:url('assets/mountains.gif');
  background-repeat: repeat-x;
  animation: mountains-slide 60s linear infinite;
  width: 3072px;
}

@keyframes mountains-slide{
  0%{
    transform: translate3d(0, 0, 0);
  }
  100%{
    transform: translate3d(-1024px, 0, 0);
  }
}

The width is 3 times the image width size and the translate3d property tells it to move to the left and repeat infinitely. That's all there is to it. Then you can just add as much layers as you want, position them absolutely and experiment with the animation speed to create different velocity to get that depth perception we are trying to achieve here.

The end result:

View the full source at Github.

Checkout it out live at https://www.oskarlindgren.se