Devlog on mrnice.dev

Devlog #5 | Developing a webpage as an excuse to learn Rust, Yew and WebAssembly

Fri, 09 Oct 2020 16:09:49 +0300

If you haven’t read the rest of the devlogs, you can find them here. You might be missing some context if you don’t.

Also, this is an old blogpost about something that wasn’t actually released as part of the project yet. Maybe one day I’ll finish it but the documentation value is important.

After another successful workshop,

Another Git workshop in the books, as the game server monitoring graphs can attest ✅ So fun when things work out well and people enjoy and learn.

(But damn, I miss in-person workshops 😣) pic.twitter.com/mKYaEfwjqp

Devlog #4 | IT'S ALIIIIIIVE

Sat, 04 Jul 2020 18:53:26 +0300

If you haven’t read the rest of the devlogs, you can find them here. You might be missing some context if you don’t.

“The test of the machine is the satisfaction it gives you. There isn’t any other test. If the machine produces tranquility it’s right. If it disturbs you it’s wrong until either the machine or your mind is changed.”

― Robert M. Pirsig, Zen and the Art of Motorcycle Maintenance: An Inquiry Into Values

Devlog #3 | I have grown taller from walking with the trees 🌳

Thu, 28 May 2020 18:08:50 +0300

“Today I have grown taller from walking with the trees.”

― Karle Wilson Baker

Welcome back to my devlog series, where I discuss the development of make-git-better version 2 - a git CTF challenge. Last time we finished developing a script that automated generating the main git server hook for the CTF.

Today we’re automating another big part of the challenge: creating the level browser.

Why do we need a level browser?

When solving a CTF, I want to make sure I keep the fun/frustration factors pretty balanced. To that end, I want to communicate some things to the player, such as:

Devlog #2 | Automation applied to an efficient operation will magnify efficiency

Tue, 12 May 2020 20:20:31 +0300

Last time we talked a lot about the HOW. This post is about realizing some parts of that plan into a real working PoC.

It only took us three development logs to start writing code. So fast! /s

Side note: This time I’ve been working with my little brother Barak. His invaluable help (and willingness to work with me) is what will probably tip the scales in favor of this project actually making it to the finish line.

Devlog #1 | The best-laid plans of mice and men

Sat, 02 May 2020 18:02:38 +0300

Last time we talked a lot about the WHY. This post is all about the HOW.

If a task is done and no one marks it in a ticketing system, does it actually work?

Like I said last time, the first task was to start dumping tasks into a board; lo and behold. It’s still rather empty, but at least there’s something tangible to look at.

Devlog #0 | Thoughts about doing a devlog (but not an actual devlog, that would be silly)

Sat, 11 Apr 2020 14:00:45 +0300

A Devlog?

Yes.

Why?!

I’m trying to save a side project from dying

I have a cool side project called make-git-better. It’s a CTF-type challenge which is meant to teach you git. Right now, the project is teetering in the twilight zone of side projects. On one hand - I like it and it’s moderately successful (more than 30 people played it). On the other hand, I whipped up the first version quickly and with pretty much reckless abandon.