![\"Chrome](\"img/chrome-version-blame.jpg\")
NOTE: This article assumes you are using a M-Series MacBook which introduces the issue of running x86/amd software on an ARM based CPU.
\nWhen 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.
\nA 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...
\nThe \"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!
\nFrom 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.
\n
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:
\n36 is the atomic number of krypton.\n36 is both the square of 6 and a triangular number...\n\n[...]\n\nR=dharani@google.com, laforge@chromium.org\n\nReview URL: https://codereview.chromium.org/218183002\n\ngit-svn-id: svn://svn.chromium.org/chrome/trunk/src@260368 0039d316-1c4b-4281-b951-d872f2087c98What 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
\nYou know how gravity is usually explained with that downwards funnel? A 2D grid, then someone plops a big bowling ball on it, and suddenly it's all marbles spinning into it. That analogy gets shown in every pop-science explainer ever — and for years, it totally threw me off.
\nSo I dug in. Here's what finally made gravity click for me.
\nThe 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?
\nThe analogy is simple, but also misleading. It shows some effects, but hides the real structure underneath.
\nWe 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.
\nEven 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.
\nHere's what Einstein figured out:
\nThat's it! No invisible rope pulling things in. Just geometry changing the rules of motion.
\nA 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.
\nLet's revisit the funnel analogy — but modify it.
\nYes, 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.
\nEven better: imagine being inside this warping. No slope to fall down, just space itself bending around you.
\nThe 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.
\nIt'd be wild.
\nImagine 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).
\nEach massive object would be like a stirring spoon in a cosmic fluid, and every smaller object would be caught in the flows.
\nOne 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.
\nSo 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.
\nIt's not a force pulling stuff down.\nIt's the shape of space and time, telling everything how to move.\nAnd 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.
\nStrangely beautiful.\nStill very hard to debug.While working on a Docker setup for a Node.js project, I ran into a couple of subtle Corepack issues that are worth noting.
\nWhen running corepack inside Docker, it pauses with a prompt asking to download the package manager. Not ideal for automated builds. The fix is simple.\nSetting 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\nENV COREPACK_ENABLE_DOWNLOAD_PROMPT=0While installing pnpm, Corepack threw a cryptic error:
\nthrow new Error(`Cannot find matching keyid: ${JSON.stringify({ signatures, keys })}`);tl;dr: use latest corepack
\nThe 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).
Here is the full error for context:
\n/usr/local/lib/node_modules/corepack/dist/lib/corepack.cjs:22688\n throw new Error(`Cannot find matching keyid: ${JSON.stringify({ signatures, keys })}`);\n ^\n\nError: 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==\"}]}\n at verifySignature (/usr/local/lib/node_modules/corepack/dist/lib/corepack.cjs:22688:11)I recently came across Bare, a new JavaScript runtime that takes minimalism to the extreme. It’s designed to let you “run JavaScript everywhere,” but without the bells and whistles of Node.js or Deno.
\nFirst reaction? Intrigued then skeptical.
\nJavaScript (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.
\nThen 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?
\nTo understand where Bare fits, you have to look at what it’s trying to be:
\nIn 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.
\nHere’s where the pragmatist in me kicks in.
\nIf 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.
\nAt that point, the question becomes clear:
\n\n\nIf you have the knowledge and skill to go this low-level just to get JavaScript running, why not just use Golang?
\n
Golang offers a compelling alternative:
\nFor 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.
\nTo 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.
\nIn that case, Bare is a great tool because it’s so minimal.
\nTools 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.
\nBut 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.
\nAt 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.
\n", "url": "https://okuno.se/blog/When-JavaScript-Gets-Too-Bare", "title": "When JavaScript Gets Too Bare", "summary": "A Developer’s Perspective on the Bare Runtime", "image": "https://okuno.se/blog/img/bare_pear.jpg", "date_modified": "2025-04-07T00:00:00.000Z" }, { "id": "https://okuno.se/blog/syncthing-discovery-server-in-docker-with-caddy", "content_html": "Short answer: Well, why not? Self hosting! Slightly longer answer: In theory it\ncould speed up client discovery since you don't need to query the same\ninstance(s) as everyone else on the planet. And it can also be more secure to\nopt out of the global discovery server and only rely on your own server to make\nyour digital footprint slightly smaller. The official guide can be found\nhere. Here is further\nreading on the\nsecurity behind the Syncthing infrastructure.
\nThe docker container can be found in Docker Hub under the\nnamesyncthing/discosrv. I am\nrunning it using the following bash script:
\nNAME=syncthing-discovery-server\nVERSION=1.23.6\n\ndocker run \\\n --name $NAME \\\n -d \\\n -p 127.0.0.1:8443:8443 \\\n --restart=unless-stopped \\\n --network shared_docker-network \\\n syncthing/discosrv:$VERSION -http \\Note that I am adding this container to a specific network and I am only\nexposing the port to localhost. In this network I am also running a caddy server\nwhich will be running a reverse proxy and handling the TLS/HTTPS requests. The\ndiscovery server needs TLS in order to operate securely. Since I am lazy I will\nuse Caddy to solve this issue for me. All I need to do is to setup an A or CNAME\nrecord which points to my server and Caddy handles the certificates.
\nAs mentioned above, Caddy will handle TLS. The following Caddyfile will reverse\nproxy all request with your.server.com to the Syncthing Discover Server\nrunning as a Docker Container in the same Docker network as the\nCaddy Docker Container. This Caddyfile is\ninspired by this old\nGithub comment.\nBut, one of the header is outdated now. The new header_up line to be used is:\nheader_up X-Tls-Client-Cert-Der-Base64 {http.request.tls.client.certificate_der_base64}.\nThis is pointed out in a\nnewer comment on a PR.\nPlease see the whole file below
your.server.com {\n reverse_proxy syncthing-discovery-server:8443 {\n header_up X-Forwarded-For {http.request.remote.host}\n header_up X-Client-Port {http.request.remote.port}\n header_up X-Tls-Client-Cert-Der-Base64 {http.request.tls.client.certificate_der_base64}\n }\n\n tls {\n client_auth {\n mode request\n }\n }\n}Go to Settings > Connections > Global Discovery Servers and make a comma and\nadd the full URL (e.g. https://your.server.com) to your Discovery Server. DONE!
Before we start, I did not try the docker image\nt4skforce/syncthing-discovery\n([Github(https://github.com/t4skforce/syncthing-discovery)]). This image also\nruns the Discovery Server with a reverse proxy, but you still need to provide\nthe SSL certificate yourself.
\nThis writeup was using the following versions for the included software
\n1.23.62.6.2I tried to install Rocket.chat today but failed/gave up\ndue to hardware limitations with RPi4 (Raspberry\nPi 4)[1]. However\nTIL about ARM instruction set (micro\nserver architecture) in the process.
\nThe problem began when I was trying to get MongoDb running on the RPi4. Not the\nlatest version, but recent version would not start. After a while I understood\nthat MongoDb targets a\nminimum instruction set of (ARMv8.2-A)\nwhich is later instruction set than what\nRPi4 implements (ARMv8-A).\nHowever I could still run a previous version of the major 4 version (4.2.18)\nwhich was before the switch (as of writing 6.0.5 is the latest version)\nHowever this solution is not very future proof and probably means that updating\nRocket.chat is limited.
After MongoDB was up and running my focus shifted to\nrocket.chat itself where I ran into the same issue.\nThere were no support for ARM when running the latest version Rocket.chat. I\nthought it was a bit weird since it’s just a node.js program... However there is\na 3 year old half decent instruction to run an older version,\nbut it wasn’t working out of the box.\nAfter some searching on their GitHub issues and their website forum I realized\nthat ARM support was not a priority nor something the core team was interested\nin.
\nAs a side quest I started looking into mini-pc since I remember a\ncomment on hacker news giving a\ntip about\nMeLe Quieter3Q\n(intel N5105 processor). It costs ¥35.000-¥40.000 which is more than double\nthe RPi4 (there are cheaper mini-pc but they have a loud fan) but it’s a x86-64\nprocessor which just makes everything so much easier for server development...\nWhat makes this something interesting is that the wattage is supposed to be very\nsimilar to RPi4 which is one of the main reasons I went for the RPi4 as my home\nserver solution, while also having a virtual (x86-x64) server at Digital Ocean\nas my main server.
RPi4 - 5W (idle 3W) source:\nsource1,\nsource2
\nQuieter3Q - 11W (idle 3W) source:\nsource1
\nAt this very moment I don’t have the need (nor the time #dad) to tinker with a\nmini PC but it’s definitely something to note for future needs.
\ntzdataApparently Caddy does not read the TZ enviornment variable. See:\nhttps://caddy.community/t/set-timezone-for-caddy-2-official-docker-image/8622
In order to get logs in local time you need to\nbuild your own image. I started\nbuilding my own Dockerfile in the blog post:\nCaddy in Docker with common_log. This is what\nwe need to add in order for TZ env var to work:
RUN apk add --no-cache tzdataWhich makes the full Dockerfile:
ARG VERSION=2.6.2\n\nFROM caddy:${VERSION}-builder AS builder\n\nRUN xcaddy build \\\n --with github.com/caddyserver/transform-encoder\n\nFROM caddy:${VERSION}\n\nRUN apk add --no-cache tzdata # <-- ADD THIS\n\nCOPY --from=builder /usr/bin/caddy /usr/bin/caddytransform-encoderSection spoiler: This was a dead end :)
\nI forked the\ntransform-encoder repo and hardcoded TimeLocal = True. I think it was a fun\nexercise to write some Go which I don't do so often. I\ncould successfully make the change and then tried to build a new caddy image.\nHowever, I ran into an error:
module declares its path as: github.com/caddyserver/transform-encoder\n but was required as: github.com/MrOggy85/transform-encoderIn order to replace the module with your fork you need to write your Dockerfile\nusing = like this:
RUN xcaddy build \\\n --with github.com/caddyserver/transform-encoder=github.com/MrOggy85/transform-encoder@masterI was finally able to build a new caddy image, ran it, but no change... Back to\nWhoogle and I finally found out what I statated in the beginning of this post,\nthat you just need to add/install tzdata.
Here is the image if you want to use it right away:
\ndocker pull mroggy85/caddy:2.6.2See my Docker Hub Page: https://hub.docker.com/r/mroggy85/caddy
\n", "url": "https://okuno.se/blog/caddy-in-docker-with-local-time", "title": "Caddy in Docker with Local Time", "summary": "When you want to log in your time zone", "image": "https://okuno.se/blog/caddy-in-docker-with-local-time/flying-whale-container-ship.jpeg", "date_modified": "2022-11-21T00:00:00.000Z" }, { "id": "https://okuno.se/blog/passwords-how-to-store-salt", "content_html": "This is the\nlink for\nthe full read.
\n\n\nTL;DR - You can store the salt in plaintext without any form of obfuscation or\nencryption, but don't just give it out to anyone who wants it.
\n\n
The reason we want to salt the password is to make it harder for an attacker\nto crack the passwords, once the DB has been comprimised. When the password\nhas been encrypted with the salt, an attacker can't use a\nrainbow table. This means that the\nattacker needs to spend a lot of time decrypting the passwords. This gives you\ntime to detect the breach and reset all the passwords.
\nRead the full answer here\nfor a full technical deep dive.
\n", "url": "https://okuno.se/blog/passwords-how-to-store-salt", "title": "Passwords - How to store salt?", "summary": "TI(r)L (Today I really Learned) how (and why) to store salt.", "image": "https://okuno.se/blog/passwords-how-to-store-salt/salt-fingers.jpeg", "date_modified": "2022-11-10T00:00:00.000Z" }, { "id": "https://okuno.se/blog/postgres-http-proxy", "content_html": "You are hacking away on a personal website using React or any other SPA\ntechnology. You also need to write a backend service to connect to your DB in\norder to persist your data across your different devices and client. However,\nimagine if you could just use a general backend to directly connect to your DB?
\nDeploy a HTTP server that accepts POST requests with a JSON body. The body needs\nto include the credentials and location of your DB as well as the SQL you want\nto execute. Then you just connect to the DB using the credentials from the\nrequest and execute the query. Return the result and you are done.
\nIt's very convenient to use for a web client. See this example using axios:
type PostgresProxyResponse = {\n command: \"SELECT\";\n query: unknown;\n rowCount: number;\n rows: any[][];\n};\n\nasync function request(q: string) {\n const response = await axios({\n url: \"/\",\n baseURL: HTTP_ADDRESS_OF_ADEPLOYED_API,\n method: \"POST\",\n data: {\n u: \"DB_USER\",\n pw: \"DB_PASSWORD\",\n h: \"DB_HOST\",\n port: \"DB_PORT\",\n db: \"DB_NAME\",\n q: \"SELECT * FROM table\",\n },\n });\n\n return response.data;\n}This is a short-cut solution for personal web projects to enable rapid\ndevelopment. This assumes you are consuming a Postgres DB that is open to the\ninternet. If you are developing a web service for other users, it means that\nthey need to establish connection to their own DB. Otherwise you need to include\nthe DB credentials (in plaintext) for all users to see.
\nNeedles to say, since this solution pushes the DB credentials down to the\nclient, it's not a very secure solution, unless you trust the client, since you\nwrote it yourself.
\nAnother issue is that you need to run your own proxy to be safe. Right now I am\nnot logging the credentials, but it's easy for a malicient service to store your\ncrentials. Also, since you are sending your DB credentials over the wire, make\nsure it's HTTPS!
\nThe API is static, which means it will open and close a DB connection for each\nrequest. Therefor it adds extra latency. Another performance concern is the\nmultiple protocols involved and data tranformation happening for each SQL\ncommand. With that said, this is obviously not a perforant nor a scalable\ntechnical solution. However, for the very small scale it's intended for it's\nsuffice.
\nThis is very handy if you like your website to be able to send SQL commands\ndirectly to the DB. It's very useful for small personal projects. But, it's\ndefinitly not recommended for any service with multiple users because of obvious\nsecurity concerns. Please use it at your own risk.
\nThis is far from rocket science, and someone probably already created this.\nHowever, I didn't find this solution after some (Brave) searching so I wrote it\ninstead.
\nSee Github: https://github.com/MrOggy85/postgres-proxy
\n", "url": "https://okuno.se/blog/postgres-http-proxy", "title": "Postgres HTTP proxy", "summary": "Lightweight HTTP proxy for sending SQL commands to a Postgres DB", "image": "https://okuno.se/blog/postgres-http-proxy/squid.png", "date_modified": "2022-09-25T00:00:00.000Z" }, { "id": "https://okuno.se/blog/caddy-in-docker-with-common-log", "content_html": "As of Caddy v2.5.0\nthey have \"removed the deprecated common_log field from HTTP access logs, and\nthe single_field encoder.\". For me as a casual user of Caddy who mostly just\nlooks at logs this is inconvenient. I don't use any tools to analyse json files\nfor automation, maybe I should? However, the good folks at Caddy doesn't leave\nus high and dry. \"If you relied on this, you may use the\ntransform encoder plugin\nto encode logs in Common Log format.\". But, since I am using Docker the version\nof Caddy I pull down from Docker Hub does not have this plugin available...\nEnter the builder.
According to\nCaddy's official Docker Hub documentation, we\nneed to create our own\nDockerfile with the builder\nimage (caddy:builder) and then create our own Caddy image.
This is how the Dockerfile looks like:
\nARG VERSION=2.5.2\n\nFROM caddy:${VERSION}-builder AS builder\n\nRUN xcaddy build \\\n --with github.com/caddyserver/transform-encoder\n\nFROM caddy:${VERSION}\n\nCOPY --from=builder /usr/bin/caddy /usr/bin/caddyThe magic part is the line:
\nRUN xcaddy build \\\n --with github.com/caddyserver/transform-encoderWhich pulls the transform-encoder plugin and installs it. Then we are\nswitching to a \"normal\" Caddy image and just replacing the binary with our\ncustom built one.
Now you just need to build and run this Dockerfile locally!
\n![\"docker](\"caddy-in-docker-with-common-log/container.jpeg\")
This is the syntax to use it in a\nCaddyfile:
\nlog {\n format transform \"{common_log}\"\n output file /var/log/homepage.log\n }docker pull mroggy85/caddy:2.5.2See my Docker Hub Page: https://hub.docker.com/r/mroggy85/caddy
\n", "url": "https://okuno.se/blog/caddy-in-docker-with-common-log", "title": "Caddy in Docker with common_log", "summary": "When you just want a simple log", "image": "https://okuno.se/blog/caddy-in-docker-with-common-log/caddy_in_docker.jpeg", "date_modified": "2022-07-14T00:00:00.000Z" }, { "id": "https://okuno.se/blog/iterm2-triggers", "content_html": "\n\ncreated using craiyon.com
\n
TIL\nabout\niTerm2 Triggers\nwhich is a super easy way to super charge your terminal. It's a feature that\nlet's you highlight text, create links and much more!
\nYou can find it in the settings here:\n![\"iTerm2](\"iterm2-triggers/iterm2-trigger-settings.jpg\")
One thing that I have added is to highligh IP Addresses, which makes it very\neasy to distinguish addresses when glancing over a log.
\nRegular Expression:\n(\\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}
![\"High](\"iterm2-triggers/ssh_log.jpg\")
\n\nLook at all those hacker attempts... Now in gold color!
\n
Another nice feature is to add a clickable link to the Jira ticket. For example\nwhen you check the git log you can now directly just shift+click and come\ndirectly to the Jira ticket in the browser.
\n(?i)wf-\\d+ (replace \"wf\" with your Jira project's key)Make Hyperlinkhttps://jira.your-company.jp/browse/\\0 (replace \"your-company\"\nwith your company's subdomain)![\"Terminal](\"iterm2-triggers/hacker.png\")
\n\n", "url": "https://okuno.se/blog/iterm2-triggers", "title": "iTerm2 Triggers", "summary": "'Supercharge your terminal'", "image": "https://okuno.se/blog/iterm2-triggers/pc-with-rainbow.png", "date_modified": "2022-06-22T00:00:00.000Z" }, { "id": "https://okuno.se/blog/perfect-code", "content_html": "created using craiyon.com
\n
Code that doesn't need change. Code that stand the test of time. Code that is\ngeneric enough that it will serve all future use cases.
\nWe devs are usually both lazy and perfectionists. If we could only write these\nperfect pieces of\nDRY (Do not Repeat\nYourself) business logic and helper function then we can use them as Lego\nblocks going forward. Then we could handle any business requirements, new or\nchanged, in theory.
\nHaving a file with frequent changes is considered a bad thing by a lot of\nvalidation tools. And why is that bad? Because we want to our code to reach a\nstable state. Write and forget. If we need to go back to the same place\nand make a change we missed an opportunity the first time to make it right.
\nHowever, I think this mindset is not very helpful when writing a business\napplication. Why? Because the business requirments change all the time.\nThe very reason for our code changes. This is nothing new, this is the basis of\nthe agile methology.\nHowever, the agile mindset is in conflict with the dev mentality and the persuit\nof perfect code.
\n\n\nThe reason we code is because we want to achieve something. If we want to\nachieve something different we need to change the code.
\n
We have to embrace the fact that our code will never be finished, since the\nreason, (business, competition, economy, etc), is ever-changing. This is the\nessence of\n\"embrace\nchange\" (2.) from the agile manifesto. Just follow the logic; The reason we\ncode is because we want to achieve something. If we want to achieve something\ndifferent we need to change the code.
\n\n\nin order to write good code we need to have good communication with business
\n
It all comes down to human communication, something that we devs are naturally\nbad at. A lot of us devs came to the field because we like to talk to computers\nrather than flimsy meat bags. But, in order to write good code we need to have\ngood communication with business. The quality of code cannot be soly determined\nby looking at the code, you have to also look at the purpose it serves. That's\nwhy code analytics tools can easily lead us astray. They don't take business\nrequirments into consideration. Good code may smell, but if the reason for the\ncode frequently change, what do u achieve by \"fixing\" it?
\n\n\nGeneric code only works if we anticipate business changes.
\n
Writing specific code rather than generic code will help you to quickly\nfulfill business requirments. Generic code only works if we anticipate business\nchanges. While there are many best practices to make generic code it all boils\ndown to guess-work. To be able to figure out what business wants in the future\nis similar to betting. You can take calculated risks with better communications\nwith business to get a better understanding of upcoming changes.
\nWe are better of if we concede the notion of perfect code and instead focus\non easily refactorable, extensible code or even code that can be thrown away.\nThis goes against programmer culture which glorifies e.g. old Unix programs that\nhave been around for centuries and doesn't need patches since the are\nconsidered done. Perfect. The author got it right.
\nWhile the persuit for perfect code is admirable and true in some sense, it\ndoesn't serve us as a guiding light. Instead, focusing on the reason will better\nguide our coding decision making. And since the reason is ever changing, your\ncode needs to change with it.
\n", "url": "https://okuno.se/blog/perfect-code", "title": "Perfect Code", "summary": "'The futile persuit of perfect code in a business application.'", "image": "https://okuno.se/blog/perfect-code/alexander-sinn-KgLtFCgfC28-unsplash.jpeg", "date_modified": "2022-06-14T00:00:00.000Z" }, { "id": "https://okuno.se/blog/the-web3-we-dont-need", "content_html": "In blockchain tech community there are a lot of\nreally\nsmart people working on very technically sophisticated solutions to very\ncomplex systems and problems. They are trying to fix the issues of today while\nanticipating the issues of tomorrow. They also have the financial backing of the\nvalue of the cryptocurrency that is flowing on top of the blockchain technology\nthey are working on.
\n\n\nWhat's the value added?
\n
The tech people only focuses on the technical solution. The financial people\nonly focuses on the speculation market. Both are pointing in a positive\ndirection. So from their perspective they can't fathom why they are\nreceiving\nso much criticism.
\n\n\nYes, blockchain technology is cool, but it does not meet the expectation it\nsets on itself.
\n
The cristism boils down to: What's the value added? It seems like the for\nthe majority of the solutions currently on the market, there would be a\nnegative value for switching to blockchain technology. There may be a new,\nnische, market for blockchain technology. This is were the divide between\nblockchain lovers 🥰 and haters 😤 are the greatest. Web3 is pitched to be a\nrevlutionary technology which is going to replace the current state. This bold\nclaim requires ground breaking technology. Looking from the outside, there is\nnothing that even remotely meets that standard when it comes to blockchain\ntechnology. This is the heart of the issue. Yes, blockchain technology is cool,\nbut it does not meet the expectation it sets on itself.
\n\n\nIt is a solution in search of a problem.
\n
The main innovation is the distributed leger. Yes, it removes central control,\n in\ntheory. Yes, it requires more resources than a traditional database, but\nthat's the trade-off. However, is this a technical solution that is interesting\nfor most mobile apps, SaaS, social media, websites, games and other technical\nservices and products out there? No, not really. The current problems are not\nsolved with this technological innovation. It is a solution in search of a\nproblem.
\nI view blockchain technology as separate from the value of cryptocurrency. But,\nI don't think they can be separated. They are driving each other forward. The\nhype of blockchain leads to an increase in value of cryptocurrency. The\nincreased value of cryptocurrency leads to an increase to the hype of\nblockchain. And the circle goes on... There is a promise of future market\nadaptation of blockchain/cryptocurrency technology. This is where web3 comes in.\nI want to make a distinction between blockchain and web3. From a technical point\nof view it's a suttle one, but from a community point of view it's a\ndifferentiator worth noting.
\nThese are all very smart people, working on a grand vision with high principles.\nIt's a very admirable cause and an exciting future, if it ever would be\nrealized. It's a space that has been around for at least 14 years, since Bitcoin\nemerged 2008 (I guess you can say it started earlier or later depending on your\ndefinition, but this is what I am going with here). Over the years a lot of\ninnovations has happened, new blockchains have emerged with different technical\nsolutions. New solutions on top of blockchains have emerged like smart contracts\nand NFTs. Here is where web3 definition stsrts
\nI see web3 as an evolution of the blockchain and cryptocurrency community. With\na very important addition, the non-techy, financial speculative persons. There\nwas a realization that a lot of money could be made in this space. Add som fomo\nand trending social media posts. All of these people were very influencal. They\nhad capital and good reputation. But, in order to sustain the flow of cash, the\ntechnology needed to be inflated. Big promises were made that can't be backed up\nwith the reality of the technology.
\nThis is my prediction: When investors realize that blockchain and cryptocurrency\nwill not reach the anticipated market adaption, we will see a meltdown in\ninvestments in companies working on blockchain technology and the hype over\nblockchain will be over. Blockchain and cryptocurrency will still be around of\ncourse, but the talk about web3 as the next step in the evolution of the web\nwill die out. DFi, or \"Decentralized Finance\" will still be around since that's\nthe main application of blockchain technology, interacting with the transactions\non the ledger. But, that's the limit and were mass adoptation of blockchain tech\nwill end.
\n", "url": "https://okuno.se/blog/the-web3-we-dont-need", "title": "The Web3 that we don't need", "summary": "'It seems to me like a perfect storm of tech, greed and smart people.'", "image": "https://okuno.se/blog/the-web3-we-dont-need/clark-van-der-beken-mcCAFvlzZFQ-unsplash.jpeg", "date_modified": "2022-01-12T00:00:00.000Z" }, { "id": "https://okuno.se/blog/photo-blog-with-nextjs-deno-syncthing", "content_html": "Nowadays Instagram is the standard for photo blogging. I really don't like\nInstagram for a number of reasons including giving my data to the Facebook\nalgorithm, and the whole idea of sharing with everyone by default. I recently\nlooked into an open source alternative: Pixelfed and\ntried out running my own server. It's a\nnice service, but to share my photos with my family and friends the barrier of\nentry is too high. Another alternative is to run a Ghost blog, which I have\ntried. However, posting a new entry with pictures is pretty tedious and I found\nmyself not posting as much as I wanted.
\nWhat I am trying to achieve is pretty simple: Just a website where each page is\nan album with pictures of my everyday life that can be viewed by my close family\nand friends, if they want. And the most important: A very very easy way to\npublish new photos and albums.
\n![\"High](\"photo-blog-nextjs-deno-syncthing/high-level-diagram.png\")
Technologies used:
\n\nFrom an end users perspective there is nothing interesting. Just a website that\nconnects to an API which serves some images.
\nFrom the website admin point of view it gets more interesting. Let's say you\nwant to upload a new album with some images. Just copy the images on your phone\nto the special folder on your phone, wait a couple of seconds and boom! Your new\nalbum has been published! But how does it work?
\nSyncthing is a peer-2-peer file syncing service which doesn't require any\ncentral server like e.g. Dropbox. For this project I have a folder on my server\nthat is synced with a folder on my smartphone. This can also be synced with\nanother device if you want to edit/add photos from another device.
\nDeno is the new kid on the block that will eventually replace Node.js. With deno\nI built a simple HTTP server, running in a Docker container, that reads from a\nmounted folder called files. The endpoint /list will return each folder name\nthat exists in the main folder. The endpoint /album/:albumName will list all\nthe images in the given album folder folder. And finally the endpoint\n/photo/:albumName/:photoName returns the image.
Look at the code
\nNext.js is a JS Framework on top of React and Node.js from Vercel. The website\nbasically have 2 routes. The index route will list the albums. When clicking on\nan album the page will list all the photos in the album.
\nLook at the code
\nTo make the deployment easy I am leveraging Vercel to host the frontend and to\nauto-deploy on each push to master.
I also setup Docker Hub to listen for pushes to master and auto-publish a new\nDocker image. Currently this flow is semi-automated cause I still need to login\nto my server and pull the latest image and restart the container.
That's it! If you follow these steps you now have a photo blog you can share\nwith your friends and super easily update with new albumbs and photos.
\nYou can find my photo blog here: https://www2.oskarlindgren.se/photos
\nRepos
\n\n", "url": "https://okuno.se/blog/photo-blog-with-nextjs-deno-syncthing", "title": "Photo Blog with NextJS, Deno and Syncthing", "summary": "'How to create an auto-publishing Photo Blog, powered by Next.js, Deno and Syncthing'", "image": "https://okuno.se/blog/photo-blog-nextjs-deno-syncthing/Photo_Blog.png", "date_modified": "2021-05-16T00:00:00.000Z" }, { "id": "https://okuno.se/blog/self-hosting-running-your-own-services", "content_html": "What put me on this journey is a couple of factors:
\nTo host your own services is a really good learning opportunity for server\nmanagement and security. And as an added bonus you get personal services which\nis only used by you and your friends.
\n![\"Docker](\"self-hosting-running-your-own-services/portainer_digitalocean_docker.png\")
I have two small virtual servers (1 CPU, 1GB RAM each) on\nDigital Ocean which costs me 15$/month. And I\nrun all my services with Docker to make most use of\neach server. Docker also simplifies maintenance drastically since nothing has to\nbe directly installed on the server. And I use Caddy\nas a reverse proxy for easy HTTPS/SSL support and super easy configuration\ncompared to nginx. This is how my Caddyfile looks like:
\noskarlindgren.se {\n redir https://www.oskarlindgren.se{uri}\n}\n\nwww.oskarlindgren.se {\n root * /usr/share/caddy\n\n redir /blog /blog/\n reverse_proxy /blog/* http://tech-blog:2368\n\n redir /photos /photos/\n reverse_proxy /photos/* http://photo-blog:2368\n\n file_server\n}\n\nMASKED.oskarlindgren.se {\n reverse_proxy http://owncloud-docker-server_owncloud_1:8080\n}\n\nMASKED.oskarlindgren.se {\n reverse_proxy http://firefly:8080\n}\n\nMASKED.oskarlindgren.se {\n reverse_proxy http://freshrss\n}\n\nMASKED.oskarlindgren.se {\n reverse_proxy http://fathom:8080\n}I also recently added a 300GB volume for 30$/month for additional storage.\nPrimarily to be able to store photos.
\nTotal monthly cost: 45$
\nThis is my price for privacy and learning :)
\nRunning my own email server may be the most important service I have. The main\nreason is privacy. The reason you get email for free from Google and others is\nthat they are reading your emails and knows who you are communicating with. I\nfeel that it's a bit creepy. There are some services that offer you privacy, but\nyou have to trust them and you have to rely on their service. The ultimate\nsolution is to run your own email server. It's not super easy but there are\nmultiple projects that give you an easy setup. I use Mailu\nwhich is a stable email solution.
\nUpdate: Even though I ran Mailu without any bigger problems for a while I found\nit too tedious to tinker with. Especially for sending email. I now switched to\nTutanota which is a ery privacy focues email provider\nbased in Germany.
\nI am still using my own domain, and it was easy to allow wild card aliases which\nallows me to create email aliases on the fly to have a unique address for each\nservice I signed up for.
\nUpdate: I recently switched from Owncloud to Nextcloud since Nextcloud comes\nwith batteries included for a personal use.
\nIt's super easy to run Nextcloud (or\nOwncloud) and let your phone sync your contacts,\ncalendar and documents from it. And as an extra bonus you can store all your\nimportant documents there instead of in Google Drive or Dropbox.
\nThis blog is running on Ghost and hosted on my server Vercel powered by Nuxt.\nThe analytics is provided by Fathom which has a\nLite version you can use for free.
\nUpdate: I decided to use a static site generator instead of Ghost. Ghost is well\nsuited for someone with low technical knowledge, but when you are a developer it\nbecomes a blocker rather than an enabler. I also don't like the fact that it\nrelies on a DB. I want something super fast and simple. I got inspired by\nthis article from derkizni and set up\nNuxt using\n@nuxt/content.
\n![\"Screenshot](\"oskarlindgren_homepage.png\")
My homepage is just a HTML file and a CSS file. I tried to keep it light, which\nmakes it eligible for the 250kb club. Using Caddy to\nserve these static files with TLS/SSL support makes it super easy to make\nchanges through sFTP.
\nUpdate: I'm still using Caddy as a reverse proxy for all my self hosted\nservices. But, I switched to Vercel for my homepage and other frontend because\nof the ease of deployment.
\nI recently started running PhotoPrism to organize and\nhost my photos. It's an alternative to Google Photos and Dropbox which can auto\nimport your photos and organize them based on Tensorflow and analyzing the image\nmetadata.
\nHowever, PhotoPrism needs at least 2 CPU cores and is very CPU intensive when\ningesting photos so I decided to put it on my local server at home. I tried some\nlighter services like Piwigo and Lychee, but they where a bit too light when it\ncomes to the features I was looking for.
\nTo consume blogs, newsletters, etc I use FreshRSS which is a very simple and\nlight service to keep track of the blogs I like to read. Instead of relying on\nan external service like Feedly you can just run your own.
\nI have opted out of any central storage of my files by using\nSyncthing. Syncthing let's you sync your files\ndirectly to any other device (Note: It doesn't work on iPhone). This is very\nconvenient to:
\nFor my notes I just have a folder with markdown files (which I view/edit with\nVSCode). Then I can use Markor on my\nAndroid phone to easily view and edit my notes.
\nPreviously I used Lastpass, but I switched to KeePass\nsince I don't want to store my passwords with someone else. With KeePass and\nSyncthing you can achieve the same level of convenience as with Lastpass, but\nwithout the risk of your passwords getting leaked in a hack of Lastpass.
\nThere are a couple of reasons why you want to run your own services.
\n\n\nYou wouldn't give your front door key to your local store owner, right?
\n
When you are giving your data to someone else, they will use it for other\npurposes than yours. It's hard to predict what someone else can find out about\nyou or what they will do to the data once they have it. Normally a service is\nrun to make money for the owner. This means that they will use your data to\nmaximize their profit. If the service chooses to try to improve the service\nbased on your data that could be a net benefit for both of you. However, the\nservice providers purpose is to make you stay, not to help you. They may try to\ngame you into staying or even create a wall garden. If you keep your data to\nyourself and only share necessary data to specific people you know you will have\na safer life.
\nReal world example: You wouldn't give your front door key to your local store\nowner, right? Even if it would be convenient if they can go in and leave some\ngroceries in your kitchen, it wouldn't feel safe to let in a stranger in your\nhome unsupervised...
\nIt is very convenient to rely on a service to store and organize your data. But,\nwhat happens when the service goes down, or when they decide to shut down\ncompletely. When you run your own service you run it for yourself. The purpose\nis to help yourself to organize your life. You will probably not create any of\nthese solutions from scratch, but rather rely on Open Source and Free Software.\nThese projects are driver by likeminded people that want to solve a problem and\nto let others use it for free.
\nOf course you have now traded a dependency of a for-profit to a dependency on an\nopen source service. But, for me I think it's better to be dependent on a free,\nopen source, right to fork service than a paid, proprietary, closed source\nservice.
\n\n\nThe probability that you will be a target of a hack is lower than any known\nservice out there.
\n
When you run a server that is accessible on the internet you will constantly be\nproned by script kiddies. Just make sure you have\nFail2ban setup and that you\ndon't expose any ports that you don't need to limit attack vectors. The\nprobability that you will be a target of a hack is lower than any known service\nout there. However the top services out there will probably be way better than\nyou at server security. In the end, as long as you are comfortable with the risk\nwhen running your own services and take proper precautions it should be fine.
\nBackup, backup, backup. Even if you rely on a service you should make sure to\nbackup your data regularly. However, when you run your own it's even more\nimportant to have backups. Make sure you store the backups in another machine.
\n", "url": "https://okuno.se/blog/self-hosting-running-your-own-services", "title": "Self-hosting - running your own services", "summary": "'Getting rid of Google, Dropbox, Microsoft and others.'", "image": "https://okuno.se/blog/self-hosting-running-your-own-services/pexels-brett-sayles-2881229.jpg", "date_modified": "2020-12-31T00:00:00.000Z" }, { "id": "https://okuno.se/blog/making-a-deno-cli-learning-japanese-numbers", "content_html": "I have been a heavy node user and advocate it for several years now. It's a\nreally empowering tool for frontend devs like me. Node is still really good and\nthere is no immediate reason for switching to Deno if you don't see the problems\nas presented by the creator, Ryan Dahl:
\n\n\n“With Deno you get TypeScript as a first class citizen”
\n
Since around 1,5 years ago I have been mainly writing code using TypeScript. I\nwas hesitant at first since I didn't think types was needed in Javascript until\nI started using TypeScript. It really makes writing Javascript Apps a bliss.\nWith Deno you get TypeScript as a first class citizen. No need for any babel or\ntypescript compiler setup. Deno will natively support your code. If you also\nlike typescript and don't like extra setup boilerplate code Deno is for you.
\n\n\n“Deno allows you to get your dependencies from anywhere on the web”
\n
Another reason for using Deno is more of a political one. NPM has grown and are\nnow part of Microsoft. It is a centralized resource which is a part of the\ncentralization of the web we have seen in the recent years. Sure, you can still\nhost your own NPM repository, but by design Node needs to be compatible with\nNPM. Deno allows you to get your dependencies from anywhere on the web. If that\nis from Github or somewhere else it's totally up to the you and the community.\nTo be fair, currently most of the libraries are hosted in Github or NPM.
\n\n\n“Talk is cheap. Show me the code.” - Linus Torvalds
\n
That's all about the background of why I like Deno. Let's move on to the code. I\nwanted to make a simple app where a number was spoken in Japanese and the user\nwould guess the number by typing it directly. Writing a simple script executed\nin the terminal makes the app very light with no need to create a Web interface\nor Desktop application. But, I still wanted the TUI to be nice and snappy so\nthat the user can go through a lot of numbers fast.
\nI chose to go with a REPL approach to make the program continue executing until\nthe user chooses to exit (by ctrl-c). The core of the program is this while\nloop:
\nconst buffer = new Uint8Array(1024);\n\nwhile (true) {\n const input = await Deno.stdin.read(buffer);\n const textRaw = new TextDecoder().decode(buffer.subarray(0, input!));\n const text = textRaw.trim();\n console.log(`you wrote: ${text}`);\n}Btw, did I mention that Deno supports top-level async/await?
\nAs you can see in the code above. We are simply (a)waiting for the user to input\nsome text. Then we can decode it and do something with that text. For this app\nwe want to check if the users guess was the expected number. Let's add some more\ncode!
\nconst nextNumber = Math.round(Math.random() * maxNumber);\n\nconst input = await Deno.stdin.read(buffer);\nconst textRaw = new TextDecoder().decode(buffer.subarray(0, input!));\nconst text = textRaw.trim();\n\nconst numberGuess = Number(text);\nconst result = numberGuess === nextNumber;\n\nif (result) {\n console.log(\"You are correct!\");\n} else {\n console.log(`Incorrect! The correct number is: ${nextNumber}`);\n}This will let the user input a guess and then we check against nextNumber.\nHowever as you can see there is an undeclared variable here: maxNumber. This\nis an input that the user has to give when starting the program to determine\nwhat range you want to practice on. Deno makes it easy to read the parameters of\na program:
const maxNumberRaw = Deno.args[0];\nconst maxNumber = Number(maxNumberRaw);\nif (Number.isNaN(maxNumber)) {\n console.log(\"Please start program like this:\");\n console.log(\"./start.sh MAX_NUMBER\");\n Deno.exit(0);\n}But, the user is still not hearing any number! Ok, let's add one of the main\npieces of the program; Let the machine speak! So, this next part assumes that\nthe user is running a Mac. This can easily be modified to be adapted to Linux\nand Windows. I am using the program say to do text-to-speech. This comes\npreinstalled on any Mac. Then we can use the Japanese voice to let the number be\nspoken in Japanese. To run a command from Deno it's as easy as this:
\nfunction sayNumber(number: string) {\n Deno.run({\n cmd: [\"say\", \"-v\", \"Kyoko\", number],\n });\n}Each string in the array maps to a word written in the terminal. Just be careful\nsince it's async. If you want to make sure that the command you are executing is\nfinished before moving on you need to await it.
\nNow we can add use this function to let the computer speak the number and the\nuser can guess it. I also added a clear command after each guess to clean up for\nthe next number. And of course some cute bunnies to emote the result to the\nuser.
\n// /) /) (\\\\_/) (\\\\-/)\n// ( ^.^ ) (>.<) (='.'=)\n// C(\") (\") (\")_(\") (\")-(\")oSee the full source here.
\nHappy coding!
\n", "url": "https://okuno.se/blog/making-a-deno-cli-learning-japanese-numbers", "title": "Making a Deno CLI - Learning Japanese Numbers", "summary": "'I have been following the evolution of Deno since I first heard about it. I really like node.js and I was playing around with it when it since it was released. '", "image": "https://okuno.se/blog/japanese_numbers_deno.jpg", "date_modified": "2020-07-27T00:00:00.000Z" }, { "id": "https://okuno.se/blog/where-does-docker-names-come-from", "content_html": "The random name generation comes from this package in the moby repo. There is a\nlist of adjectives and a list of famous scientists and hackers that gets\nrandomly combined to form the names of the docker containers we all have come to\nlove. The combinations are random with one exception of boring_wozniak since\n\"Steve Wozniak is not boring\"\naccording to the comment.
The list is actively maintained and new scientists are added and also removed.\nAfter being accused of sexually abusing trafficking victims, Marvin Minsky was\nremoved along with Richard Stallman that publicly defended his actions.
\nI recently listened to the podcast Shoptalk episode\n\"Is there a Great Divide\" about the\ndivide between frontend developers. I was not aware that there was a divide in\nthe first place. The main symptom they discuss is the difference between what a\njob listing says and what the actual job is.
\nThis inspired me to think about where frontend development is today. I have\nlately also recently seen a divide, but on another topic, when it comes to use\nstatic types and Object Oriented Programming in the frontend. But, let's go back\nfrom the start first to see why we are where we are today.
\nDisclaimer:
This is a gross simplification of the history of the web and\ndata has been cherry picked to fit my narrative. There is probably some facts\nnot mentioned or wrongly described that effects some of my points and I am open\nto feedback to adjust my views.
![\"Sir](\"evolution-of-frontend-devs/9407011_31-A5-at-72-dpi.jpg\")
The information Highway was born at CERN by Tim Beerners-Lee and\nreleased to the public in 1991.\nAt this point every website was just static webpages directly served from the\nweb servers. Each URL pointed to a specific directory which had an index.html\nwhere you also could point to other sources like css files, images, etc.\nUpdating the website meant changing the html file, uploading a new version by\nftp and then the users got the new content. After some time the need for a more\ndynamic experience led to the introduction of\nJavascript in 1995 by Brendan Eich\nand during the same year\ncookies were introduced by\nthe same state of the art browser at the time: Netscape.
\nAt this point frontend development was not really a known term. Programmers were\nable to create html files that could be interpreted by a browser to show a\ndocument. It was mainly used in research and websites where very informative and\nnon interactive.
\n![\"Gilfoyle](\"evolution-of-frontend-devs/gilfoyle.jpg\")
\n\n\"I tried to make it slow. I really did. But I'm not Dinesh. It's very\ndifficult for me to do shitty work.\" - Gilfoyle
\n
The need for more an even more dynamic experience led\nRasmus Lerdorf to, in 1995, create PHP\nto be able to serve web pages through a template engine. This led to a\nremarkable creativity boost for web development since you could access a\ndatabase to tailor the experience of the user and create an html page on the\nfly.
\nBut the most important interesting part of this time was that a lot of people\ncould set up their own website easily thanks to services like e.g. Angelfire,\nGeocities, AOL, etc. I think that, the idea that frontend is easy and\nunimportant was born during this era. The second half of the 90s can be\nsummarized by these gifs that frequently was shown on peoples websites:
\n![\"Under](\"evolution-of-frontend-devs/HoHollywoodPicture3800construction.gif\")
\n![\"Under](\"evolution-of-frontend-devs/ajaj0077lines_bulletsconstruction.gif\")
\n![\"Under](\"evolution-of-frontend-devs/AtAthens6321underconstruction_lemmings.gif\")
![\"Firebar](\"evolution-of-frontend-devs/firebar.gif\")
This technology would however enable the environment where internet based\nbusiness could start to form. And it also led to a specialization between\nfrontend and backend. The frontend developers was mainly focusing on the design\nof the page through html and css with a small portion of Javascript to enable\nsome dynamic features. And the backend developers would focus on the business\nlogic of the site.
\n![\"WWW](\"evolution-of-frontend-devs/bubble_burst.jpg\")
The web gained a lot of traction during the second half of the 90s and got a\ncrazy hype which led to the dot-com bubble which\nbursted in 2000.\nBut, the web was not dead. The technology was still great but the expectations\nhad to be realigned closer to the reality of what promises the technology and\ndevelopers could offer.
\nDuring the first decade of 2000 the web became even more dynamic and the term\nweb 2.0 was coined and got popularized by\nO'Rilley Media in 2004. The web\nbecame a platform for applications and the clients (browsers) started to become\nricher. Realtime updates of the website became a big feature.
\nNow frontend development became more complex. A lot of business logic that was\npreviously handled by the server was moved to client side to enable user\ninteraction without the need of a page reload with the use of Ajax calls. There\nwas also a ton of third party integrations that bloated the global scope and the\ncss files grew into biblical proportions. And there were still a lot of\ndifferences between browsers which led to\njQuery being born in 2006 by John Resig.
\n![\"man](\"evolution-of-frontend-devs/spaghetti.jpeg\")
\n\nLeave the gun – take the cannoli. - Clemenza
\n
By around 2010 web development was a mess, imho. The server and client code was\na perfect spaghetti carbonara served a million times a second around the globe.\nA lot of great developers and organizations started to generalize the solutions\nthey created and shared them with the community which led to the next generation\nof frontend developers.
\n![\"hipster](\"evolution-of-frontend-devs/optimize.jpeg\")
\n\n\"...which made frontend development into it's own domain.\"
\n
In 2010 AngularJS and Backbone was released, followed by Ember the next year.\nThis was the start of Web Apps which introduced concepts like MVC which were\nnever used in frontend before. It was also a step back to the first generation\nof websites with statically served websites, but a leap forward for dynamic\nwebsites and rich clients. The result was a totally decoupled frontend and\nbackend which made frontend development into it's own domain. The server didn't\nneed to serve html and became an Restful API for the frontend to consume\n(However the need for a good SEO score later reversed this decision and\nintroduced server side rendering of the frontend app).
\n\n\n\"This would later be known as Javascript fatigue to try to keep up with all\nthe new stuff.\"
\n
When the frontend was living in it's own world outside the server a lot of\ntooling was invented to handle the need for a rapid development which led to\nGrunt, Gulp and Webpack to be introduced. Furthermore NPM became the place to\nshare libraries, where several new solutions would be published every day. This\nwould later be known as Javascript fatigue to try to keep up with all the new\nstuff. Javascript as a language grew with a lot of new features. But, all\nfeatures where not supported by all browsers or not yet finalized which led to\nthe creation of Babel. As a frontend developer in around 2016 you where expected\nto master these tools and to at least have the knowledge of one of the\njavascript frameworks out there.
\nThis new frontend development divided the notion of a frontend developer from\nthe previous era. Being proficient in html and css was not enough to get you\nhired anymore. Now programming skills and knowledge about certain frameworks was\nwhat frontend development was all about.
\nThe shift didn't happen over night though. Most companies continued to use their\nprevious server side template based solutions, but slowly started to convert to\nthe new javascript frameworks as they matured. As more and more businesses\nshifted their tech stack to heavily rely on a Javascript framework, this meant\nthat more and more of their business logic moved to the frontend.
\n\n\n\"...the biggest migration wave in programming history.\"
\n
This is what I identify as the biggest migration wave in programming history.\nNot only a shift in tech stack, but especially for backend developers migrating\nto a brand new world. Backend developers that previously only been working on\nserver side code in statically typed compiled languages now found themselves in\nthe dynamic and browser interpreted domain of Javascript. And they were far from\nhappy to find themselves in this country... As Javascript gained traction and\npopularity so did the frustration which was popularized by the\nwat presentation in 2012 by Gary Bernhardt.\nIt's an understatement to say that Javascript as a language did not fit into the\nexpectations of these developers.
\n![\"Harvey](\"evolution-of-frontend-devs/harvey.jpg\")
There where several attempts to radically improve Javascript with a superset\nlanguage such as\nCoffeeScript, introduced in 2010 by Jeremy Ashkenas,\nfollowed by\nDart in 2011\nand\nElm in 2012.\nThese languages were popular, but never gained any mainstream traction.
\nClass was introduced in ECMAScript 2015 to the delight of objected oriented\ndevelopers, but was imho, vastly misinterpreted since it was only a syntactic\nsugar for using the new operator. This however created a big shift in how a lot\nof Javascript was written, since the former backend developers were used to\ndeclare classes when coding. There was already an awkward naming convention in\nJavascript to use an underscore to mark a method as \"private\", when in reality\nit was accessible publicly. This remained a practice even after class was\nintroduced, since it didn't actually change the underlying language.
\nThere was however still a big annoyance with Javascript: The lack of static\ntypes. Enter: TypeScript by Microsoft. The first version of\nTypeScript was released 2012,\nbut it wasn't until after ECMAScript 2015 and\nAngular 2 which was officially released in 2016,\nuntil it gained some serious traction of the community. Typescript became the\nstandard way of writing Angular apps. Facebook had their own way of doing static\ntype checking in React with Flow, but it never went mainstream and now a lot of\ndevelopment is now done with Typescript.\nVue added Typescript support from version 2\nand in their next version will be\nwritten in Typescript and be a first class citizen.\nThe Javascript community embraced Typescript during 2018 and more and more\nlibraries bundled type definitions and wrote their libraries using Typescript.
\nThe web browser is today a synonym to Chrome. The\nBrowser Wars are over and Chromium\nis the victor. Microsoft's decision to shift Edge to be Chromium based is a\nproof that the game has changed. The only odd sheep left on the battlefield is\nFirefox and Safari, but they can't currently put up a fight.
\nGoogle had plans to introduce Dart as a replacement for Javascript in the\nbrowser, but\ncancelled those plans in 2015.\nDuring this time Dart was not by any means a popular language and Chrome was\nstill not the dominant browser as it is today. But, today the environment has\nchanged. All the ingredients that wasn't present before is now in place. I\npredict that during 2019 there will be a first version of Edge and Chrome that\nsupports Typescript native in the browser.
\nBeing a frontend developer in the 2020s will be indistinguishable from a backend\ndeveloper. The wild wild west of frontend development has an expiration date\nwhich will come sooner than we expect. Be prepared for the change.
\nSources:
\nBefore moving on. If you don't want to host your own NPM Registry you can just\nuse NPM's own solution for 7$ per user: https://www.npm-enterprise.com/
\nStill interested? Let's start!
\nNote: This setup is written for:
\n![betanews.com](\"https://betanews.com/wp-content/uploads/2014/10/bubble_burst.jpg\"){kind=link}
Ubuntu 18.04\nDocker version 18.09.0, build 4d60db4\ndocker-compose version 1.21.2, build a133471It will probably be compatible with Mac and other Linux distros though.
\nWe will use docker and docker-compose. If you haven't installed them already\nplease download and install them here: https://www.docker.com/get-started
\nIt actually turns out that NPM has a pretty simple structure. You can just roll\nyour own with a Node.js server and a CouchDB instance and follow the\ninstructions from NPM: https://docs.npmjs.com/misc/registry
\nBut, who wants to reinvent the wheel if we already have a Ferrari available with\nminimal setup? Let me introduce you to Verdaccio; \"a lightweight private npm\nproxy registry\" which is a pretty damn good description. It's a node.js server\nwith a simple file based db, but you can also configure it to store your\npackages in a Amazon S3 bucket or Google Cloud Storage.
\nWe want to run Verdaccio as a docker container for ease of deployment. You can\nfind the latest Dockerfile here. We will use Verdaccio version 3, which is the\nlatest as of writing this blog post. First of, let's create a docker-compose.yml\nfile and fill it with this content:
\nversion: '3.1'\n\nservices:\n verdaccio:\n container_name: 'verdaccio'\n image: verdaccio/verdaccio:3.0.0\n restart: always\n ports:\n - \"4873:4873\"\n volumes:\n - ./data:/verdaccio/\n networks:\n - docker-network\n\nnetworks:\n docker-network:\ndriver: bridgeNote that we are mounting a volume called \"data\". This is where Verdaccio stores\npackages and users. We want to store this on the host to be able to persist all\ndata when restarting our docker container. Let's create the data folder.
\n~$ mkdir dataVerdaccio is running inside the Docker Container with it's own user verdaccio\nand usergroup verdaccio. You need to give permission to your System's\nNetwork Management service to make changes in the folder. Let's create the\ndata folder and set the correct permissions.
~$ sudo chown -R systemd-network data/That's it! Let's fire up this bad boy!
\n~$ docker-compose up -dYou can now access it on http://localhost:4873
The config file data/conf/config.yaml holds the configuration.
Docs: https://verdaccio.org/docs/en/configuration
\nPoint your npm cli to Verdaccio
\n~$ npm set registry http://localhost:4873Add yourself as a user
\n~$ npm adduser --registry http://localhost:4873Now you can use npm as usual but everything will be proxied through Verdaccio.\nHave fun coding!
\nFull source at Github: https://github.com/MrOggy85/verdaccio-docker
\n", "url": "https://okuno.se/blog/private-npm-registry-with-verdaccio-2-2", "title": "Setup a Private NPM Registry with Verdaccio and Docker", "summary": "\"When collaborating on frontend application writing component libraries our companies doesn't always want to share that code with the community (boo!). Using package managers like npm and yarn is really powerful to handle our third party code. When working locally it's easy to use npm link or yarn link for ease of development. Then when we want to use our library with our application we need to provide a repo link with a tag and auth token (ugly and unsafe!). Let's do it proper by publishing our library to our own NPM registry instead! And also get an additional cache layer in case NPM is down...\"", "image": "https://okuno.se/blog/mi_scusi.png", "date_modified": "2019-01-14T00:00:00.000Z" }, { "id": "https://okuno.se/blog/creating-a-8-bit-retro-cv-page", "content_html": "One of my first games I ever played was Sonic. The old sonic games for Sega Mega\nDrive has aged well and are still really enjoyable. In that spirit I decided an\nafternoon to have a page that had a side scrolling background with some basic\ninformation. Basically just some links to LinkedIn and Github where my real CV\nis :)
\nMy initial inspiration for the page was when I stumbled upon\nNES.css from reading the\nFrontend Focus newsletter. It was so simple\nand elegant and really touch my childish self. I just had to use it for a\nproject. And why not use that style for a CV page?
\nAdd 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.
\n<section class=\"container with-title\">\n <h2 class=\"title\">Oskar</h2>\n</section>Then I will add a row with my Github picture and a encouraging text to navigate\nsome of the sites where I actually have some content to show.
\n<section class=\"container with-title\">\n <h2 class=\"title\">Oskar</h2>\n <div class=\"row\">\n <img src=\"https://avatars0.githubusercontent.com/u/2677573?s=460&v=4\" alt=\"profile picture\" width=\"100\" height=\"100\" />\n <div style=\"margin-left:28px;\">\n <p>\n Hello!\n </p>\n <p>\n Please check me out on Github and LinkedIn or follow me on Twitter.\n </p>\n </div>\n </div>\n</section>\n\n#styles.css\n.row {\n display: flex;\n flex-direction: row;\n}The next row will be a list of icons with links to the services I want the\nvisitors to navigate to
\n<div class=\"row right-aligned\">\n <a href=\"https://github.com/MrOggy85\" style=\"margin-right:5px\">\n <i class=\"icon github is-medium\"></i>\n </a>\n <a href=\"https://twitter.com/oskarlindgren\" style=\"margin-right:5px\">\n <i class=\"icon twitter is-medium\"></i>\n </a>\n <a href=\"https://www.linkedin.com/in/oskarlindgren/\">\n <img src=\"assets/linkedin.png\" width=\"48\" height=\"48\" />\n </a>\n</div>\n\n#styles.css\n.right-aligned {\n justify-content: flex-end;\n}The result:
\n![\"CV](\"cv_homepage_card.png\")
Okay so that very informative and pretty cool. But, it's not very engaging. I\nneeded some kind of visually stunning effect in the same spirit. I needed a side\nscrolling background!
\nTo create a good depth perception 3 level of backgrounds scrolling at different\nspeeds is good enough. And we can achieve this with only CSS.
\nFirst the HTML
\n<div class=\"wrapper\">\n <div class=\"mountains\"></div>\n <div class=\"trees\"></div>\n <div class=\"grass\"></div>\n</div>For the background images I found some really nice pictures at a Fandom site\ncalled\nSuper Mario Bros X Wiki.\nI needed to adapt the pictures a little bit since the image will repeat 3 times\nat the x axis to create the illusion of scrolling (if you have a really wide\npicture you don't need this).
\nTo accomplish the scrolling effect we will use animation and @keyframes.\nLet's start with the first layer which will be the mountains in the far back.
.mountains {\n position:absolute;\n top:0;\n bottom:0;\n left:0;\n right:0;\n background:url('assets/mountains.gif');\n background-repeat: repeat-x;\n animation: mountains-slide 60s linear infinite;\n width: 3072px;\n}\n\n@keyframes mountains-slide{\n 0%{\n transform: translate3d(0, 0, 0);\n }\n 100%{\n transform: translate3d(-1024px, 0, 0);\n }\n}The width is 3 times the image width size and the translate3d property tells\nit to move to the left and repeat infinitely. That's all there is to it. Then\nyou can just add as much layers as you want, position them absolutely and\nexperiment with the animation speed to create different velocity to get that\ndepth perception we are trying to achieve here.
The end result:
\n![\"website](\"oskarlindgren_website.gif\")
View the full source at Github.
\nCheckout it out live at https://www.oskarlindgren.se
\n", "url": "https://okuno.se/blog/creating-a-8-bit-retro-cv-page", "title": "Creating a 8 bit Retro CV Page", "summary": "I grow up playing SNES (スーパーファミコン) and Sega Mega Drive (メガドライブ). My love for pixel graphic games are absolute. Therefore it made sense for me to build a website in that style to represent me as the geek I was growing up and the person that I still am.", "image": "https://okuno.se/blog/oskarlindgren_homepage.png", "date_modified": "2018-12-30T00:00:00.000Z" } ] }