DEV Community: Slobi

Animation Simulation 2D

Slobi — Fri, 12 Sep 2025 20:37:19 +0000

Genesis

I wanted to give life to this little guy:

I have years of experience making games and simulations, but I never had a chase to play with characters except for the ones that are in sprite sheets, plain dead images that go trough fast carousel and BaM! illusion of motion is there.

So I set my course to make something kind of lively and kind of real. I had some previous work done that was not very promising, just look:

It was a result of me wanting to make a Ninja, the task turned to be too big. So I decided to reborn it into something that I can realistically do in time I have and not to get bored doing it.

Few rules had to be broken

I have two dragons that fight, one wants to leverage all the libraries I have and return the fruits of work to base library, the other one wants to slash and dash all fresh baked code with a whip of the best current practices I adopted yesterday.

I decided to go to third route, I copied only the code I relay needed for this project. The copied code gets shredded with new code that is one off for this endeavor. And the code I can't find a place for... I just paste it into main.js, yeah sue me!

The result

My feel good was off the charts, I created one system for tracking two ententes with sprites that are independent. I tested adaptability of my ECS system, and was delighted. Got to play with my favorite math. Updated the collision system, shall I ever return it to the source?!

Don't lock back

I almost scraped this project in order try making my system warp one big sprite image, but I decided to leave that for some next time. And after falling on my face with energy once in doubt and fighting with scope creep I got some results:

The results were promising but it was not live, so I used some cursed code like:

        const rez = {}
        Object.defineProperty(rez, 'distance', {
            get() {
                return chainLink1.distance;
            },
            set(value) {
                chainLink1.distance = value
                chainLink2 && (chainLink2.distance = value)
            }
        });
        return rez
// ----- SO I CAN DO
        function animation(){
            const newDistance = lowPinDistance0 + lowPinDistance0 * Math.sin(t)/3.0
            lowPinConnection0.distance = newDistance
            lowPinConnection1.distance = newDistance
            t+=0.075
        }

And it finally started to act like real live puctuation sign:

Conclusion

Some games are there for players the wast majority is for the creators of those games. Some projects are hard by nature, we don't need to make them even harder with fake walls that are not even there. If this idea lives I will come around and invest my proper energy and time, but at least I seen the result early and can get feedback early.

Thank you for reading, I hope that someone will find this article helpful or at least amusing!

I Built MultiFile Canvas for VS Code

Slobi — Fri, 22 Aug 2025 20:42:00 +0000

Why are we here

Sometimes you just need to bounce between tiny utility files, configs, and snippets. The constant tab switching drives me nuts.

I looked around for a solution, but couldn’t find anything that worked the way I wanted. I’m not committed enough to go full keyboard-only IDE (Vim-like), though some of those ideas were very appealing.

What I really wanted was a single file or view where I could edit multiple files at once. I also wanted it integrated into a familiar environment, because my goal is to produce, not just learn a new tool.

So… I did what any developer eventually does: I built it myself.

👉 Introducing MultiFile Canvas – a VS Code extension that lets you merge multiple files into a single view.

🚀 How it works

Create a .mf file (like project.mf)
Add dividers like:

---- main.js ----

---- lib/utils.js ----

---- index.js ----

Files load directly under the merged view
Edit inside your .mf, and saving writes back to the originals
If originals change, your view updates
Rename references to copy or load different files

Basically: no more endless tab flipping when juggling small files.

🎯 Why I made this

I originally built MultiFile Canvas just for my own workflow, but I figured someone else might also find it useful.

It’s lightweight, simple, and does exactly what I needed.

You can check it out here:

👉 Marketplace link

If you give it a try, let me know what you think! Feedback is very welcome.

Please note this is my first extension, and I built it in just two days.

Journal Transcriber: Write journal by dictating it

Slobi — Mon, 25 Nov 2024 16:15:04 +0000

Hello

Dear readers, today I am going to talk about a journal script I kind of wrote. 😉

The Problem of Saving My Thoughts

The problem I’m trying to solve is that I want to save my thoughts.

I have no problem reading what I wrote, but I don’t enjoy waiting. I can dictate, but I don’t want to save or listen to my voice.

Whenever I encounter such a situation, I get into engineering mode, and if it’s something I can tackle within a few hours of work, I go for it.

Initial Research

First, I researched a voice-to-text library that’s easy to use, and I found Vosk. It has a huge library of models. I opted for two small ones because I want to use the app while I code. They give somewhat decent results.

The Python Solution

Then, with the magic of multiple AI models, I came to a solution in Python. It streams my microphone and system sound to the Vosk model, which provides a transcription written with timestamps in a file with the current date.

From Prototype to Daily Usability

It serves the purpose, but it’s not convenient for daily use. One of my mottoes is: if it’s not easy and instant, I won’t use it. So, I packed the script into a Python module and wrote a *.desktop file to register it as a regular Linux application in my case, Pop!_OS.
Just a quick extra touch was adding a keyboard shortcut and behold the miracle it works!
Notifications using notify-send are there to let you know the app's current state.

Eliminating Console Clutter

One thing that irritates me is when an application runs in the console because it clutters my workspace. To avoid this, I needed a simple way to start and stop the app without relying on the terminal. My solution was to implement a lock file system.

When the app starts, it creates a lock file containing its process ID (PID). If the lock already exists, the script uses it to send a KeyboardInterrupt signal to stop the running instance and exits. This way, the first call starts the app and begins transcribing, while the second call stops it.

Solving Problems the Inventive Way

I hope this article sparked someone’s wish to solve their own problem in a unique, inventive, and somewhat polished way.

Feel free to check my other similar article:
Automating Text Extraction from Screenshots

Also feel free to check out code:
on Github

Have a great day 🚀

Journal Transcriber: Write journal by dictating it

Slobi — Wed, 20 Nov 2024 10:58:49 +0000

Hello

Dear readers, today I am going to talk about a journal script I kind of wrote. 😉

The Problem of Saving My Thoughts

The problem I’m trying to solve is that I want to save my thoughts.

I have no problem reading what I wrote, but I don’t enjoy waiting. I can dictate, but I don’t want to save or listen to my voice.

Whenever I encounter such a situation, I get into engineering mode, and if it’s something I can tackle within a few hours of work, I go for it.

Initial Research

The Python Solution

From Prototype to Daily Usability

Eliminating Console Clutter

Solving Problems the Inventive Way

I hope this article sparked someone’s wish to solve their own problem in a unique, inventive, and somewhat polished way.

Feel free to check my other similar article:
Automating Text Extraction from Screenshots

Also feel free to check out code:
on Github

Have a great day 🚀

Flipping Data Structures to optimize performance 🚀

Slobi — Mon, 02 Sep 2024 14:08:06 +0000

What do I mean

When we want a high performance system, we can greatly benefit by thinking in terms of efficient data organization. When we have multilayered maps or hash tables, sometimes a simple reorientation of data is all that we need.

In my ECS system, I have:

_entities that map id -> Entity(id)
_components that map Entity.id -> Component.Type -> Set(Component())

So when we query for all Entities that have a Component of a specific type, we list all entities and then filter out those that do not have a Component.Type entry or where the set size is 0.

This works well enough to a certain point, but we can observe that this algorithm performs similarly when searching for both common and rare components, even though searching for a rare component should, intuitively be faster.

One optimization we can implement is to flip the _component map Entity.id and Component.Type:

_components that map Component.Type -> Entity.id -> Set(Component())

The benefit is that when a component is rare, we only have to traverse a short list to check if the set is empty and filter those entities accordingly. This could be further improved by deleting the entity entry for a type when the set is empty. This way, our query can simply return a set.

Here are the results of this optimization for 100_000 eateries and 600 rare Component instances:

queryCommon: 51.256ms -> 16.161ms

queryRare: 58.081ms -> 0.346ms

getComponentsCommon: 37.668ms -> 34.671ms

getComponentsRare: 21.635ms -> 9.959ms

Conclusion

By reorganizing how components are mapped within the ECS, we can significantly improve the performance of queries, especially for rare components. This simple yet effective change allows the system to handle query more efficiently.

Hope this helps developers not to forget to handle their data appropriately even when using something like JavaScript.

Intuition VS. Guesstimate - Why are projects more late than not.

Slobi — Mon, 29 Jul 2024 14:08:42 +0000

I have been in the IT industry long enough to feel that projects rarely go according to schedule.

At first, I was in teams of young people with little to no experience. We did our jobs as best we could, but we missed our deadlines from time to time. We did all the engineering beforehand to give the best possible estimates with some buffer, but again we were wrong almost as much as we were when we were just eyeballing it.

Then I moved on to some more advanced projects, organizations, and teams. I also gained more experience, but still, the pattern continued. I was unhappy about it, I thought that I was a terrible engineer, and managers were unhappy from time to time.

My first line of defense was the thought that the software base we built on top of was bad, so we were struggling to fix the mess beneath our app layer, and that was the reason we frequently missed our deadlines.

My second phase was the belief that people are not suited to do programming, but by some miracle, we managed to do it anyway. So, I felt pretty good when we made something work.

Years passed, and I changed teams and talked to many people, but the pattern emerged everywhere. So, I started to suspect that it is not that simple. We can't just make up a story and call it a day, feeling good about our failure to meet deadlines. I owed it to myself to think of something better, so I did.

In words, it goes something like this: When doing one task, it is pretty probable for it to be done somewhere around the standard deviation of the estimate, and that task goes pretty well. I view it as a probability density function to finish a task in any given moment, I am not a mathematician, so excuse my crudeness. But when a task goes wrong, when we get out of that nice and safe zone, we have a low chance to finish it at any of the next moments. Imagine a Gaussian distribution, but it has a tail that is very thin. There is a low chance of getting into that tail because there is much more surface before that, so our minds ignore it, and managers do too.

My defense against that case was to give overestimates, and most people also do it, so our guess is always on the right side of the median, but regularly we finished our tasks on time, meaning early by our estimate. The reaction of management was that we were pressured to keep it real. But then, from time to time, there was a task or maybe a few that made everyone unhappy. We felt hopeless, missed deadlines even four times the estimate, and sometimes had to reorganize and redo the whole thing again.

Still, when we look at one task at a time, it is not all that grim. There is a slight chance that we make a mistake, but with more work, it will get fixed. We are humans, and we can do one thing at a time, so let's assume that ideally we finish one thing and then move on to another. It turns out that we get into that unpleasant situation more frequently than we intuitively felt we should. It makes us doubt our path in software engineering. I can't feel bummed forever about such feelings, so I started making an excuse that when we combine multiple Gaussian distributions with that tiny tail, it grows. But I did not have time to sit down and do the homework, so I made my best predictions and moved on with my life.

Recently, I was in a release situation that is still ongoing, and the feeling came back. So, I decided to do the work to get that thing calculated with my limited and rusted math knowledge.

Implementation

The standard software procedure is if you can't define a thing well, you make a discrete approximation and grind numbers through a few for loops until you get integration, function product, or something you can't define but seems logical. In my mind, it's the same as simulation.

So, the distribution approximation I came up with is:

function trail(x) {
    return Math.tanh(x*6-4) + Math.tanh(-x*3+4.3) * (1-trailProb) + Math.tanh(-x+4.3) * trailProb
}

It is not pretty, but it gives the top figure. The idea of using the hyperbolic tangent function came from an AI course for perception, where it is used as a quick fix for the Sigmoid function.

Then I made it discrete like this:

let oneTask = {}
for(let i = 0; i < 200; i++){
    oneTask[i] =  trail(i/10)
}

I had a relative probability of finishing a task every 10% of a time estimate. It looks like this:

Then I had to come up with a way to combine tasks. Good thing it was discreet so I could reason about it and calculate it:

combineTwoTasks(task1, task2) {
    let twoTasks = {}
    for(let i = 0; i < 100; i++){
        for(let j = 0; j < 200; j++){
            let y1 = task1[i]
            let y2 = task2[j]
            let finalx = i+j
            let finaly = y1*y2/DEVIDEER
            twoTasks[finalx] = twoTasks[finalx] ? twoTasks[finalx] + finaly: finaly
        }
    }
    return twoTasks
}

So, the x position is the added time of finishing the first task and the added time of finishing the second task, and the probability is the product of those two probabilities. Basically, it boils down to getting the sum of 7 when tossing two consecutive dice. In the end, you get all the ways you can finish at some moment. So, two tasks combined give another probability curve, going once again, you get 3 tasks, and so on.

So the whole code looks like this:

let oneTask = {}
for(let i = 0; i < 200; i++){
    oneTask[i] =  trail(i/10)
}
let twoTasks = this.combineTwoTasks(oneTask, oneTask)
let threeTasks = this.combineTwoTasks(oneTask, twoTasks)
let nTasks = oneTask
for(let i = 0; i < 7; i++){
    nTasks = this.combineTwoTasks(oneTask, nTasks)
}
for(let i = 0; i < 200; i++){
    this.addPoint(i/10, -oneTask[i]||0)
    this.addPoint(i/10, -twoTasks[i]||0, '#00ff00')
    this.addPoint(i/10, -threeTasks[i]||0, '#0000ff')
    this.addPoint(i/10, -nTasks[i]||0, '#00ffff')
}

For the first few tasks, the time and probability of finishing look like this:

And it looks fine. We should be ashamed to do all this work and get a result that throws a wet towel in our faces and says we are all bad developers. But this is when all the variables are known when there is no unknown thing that can make that tedious tail. When we raise the chance to get into that awkward situation just a little bit, the results are a bit different:

We see that a small tail of a task that is barely perceivable can impact us on the fourth task destructively. Something like barely 1-2% of the area under the curve becomes 20%-30%, and that is only for 4 tasks with an almost sure outcome. We have almost no chance to finish on time (<10%) and a good chance to overdo it by 1.5x of the original guesstimate. 2x is not far-fetched either.

I wanted to play a little bit and see 7 sequential tasks:

The story continues, we should be done by 7, we are probably doing it by 9.5 estimates, and we have the same chance to finish after 13 estimates as we do to finish on time.

Every task is different

There are a lot of tasks that have much bigger tail sections due to various reasons. Only the tasks where all the variables are known and are in the pure Gaussian distribution form can be estimated and delivered repeatedly and reliably.

I hope this helps fellow developers not to feel bad when things go wrong. It is the nature of the universe and helps organizations and managers adapt to the truth.

You can check my few hours of coding mess here:
Github source

The Compounded Interest of Good Software: An example of Carousel Components

Slobi — Mon, 15 Apr 2024 10:28:14 +0000

While working on software there's a constant war between compounded interest and technical debt. Both have their places in the life-cycle of a project, but understanding when to leverage one over the other can make all the difference in the long run.

The Need for a Carousel Component

I am working on a website, and I need a carousel component that seamlessly transitions between images, accommodating both mouse and touch inputs. A seemingly simple task, but one that can quickly spiral into a mess if not handled properly.

The Trap of Technical Debt

In the past, I've fallen victim to the allure of technical debt. I'd hastily cobble together a carousel component, sacrificing long-term stability for short-term gains. Sure, it worked, but it was like building a house of cards, fragile and prone to 💩 at any moment. Ten years ago I worked on such component and I must confess that I got weeks of salary just on that functionality that barely worked.

The Power of Compounded Interest

Instead of falling to the temptation of using some over-bloated library like Bootsrap, or writing something from scratch, I decided to invest in compounded interest. I had previously written and maintained a library for touch and mouse abstraction, a foundational piece of code that I could leverage for future projects.

The library in question is one that I already talked about the Touch, and the interface is straight forward:

// Init Touch with HTMLDivElement
let touch  = new Touch(carouselOuter);

// bind logic to event
touch.onForce(({delta:{x, y}}) => {
  carouselByX(carouselOuter, x);
  carouselByY(carouselOuter, y);
});

Building the Perfect Carousel

Armed with my existing library, I set out to build the ultimate carousel component. It was a breeze with the hardest part of the work already done and tested, I was able to focus on refining the user experience and ensuring seamless functionality across all devices.

The Payoff

In just a few hours, I had a carousel component that not only met my requirements but exceeded them. It seamlessly transitioned between images, gracefully handled both mouse and touch inputs, and added a touch of polish to my website that wasn't there before.

The usage is and it just work:

// Init carousel by calling function
// pass the querySelector string
// I used <y class='carousel'>
initCarousel('.carousel')

<div class="carousel overflow-hidden some-style">
  <div class="carousel-inner more-style">
    <div class="item-style">
       Example element
    </div>
  </div>
</div>

Conclusion

When it comes to software development, always strive to invest in compounded interest rather than accruing technical debt. Sure, it may require more upfront effort, but the dividends it pays in the long run are well worth it.

Feel free to checkout GitHub: https://github.com/slobacartoonac/js_lib/blob/main/fe/carousel/index.js

Automating Text Extraction from Screenshots with Tesseract and Gnome Screenshot

Slobi — Mon, 12 Feb 2024 13:44:26 +0000

Manually transcribing it can be tedious and time-consuming. However if you are on right system (Pop OS in this case), with the power of automation and the right tools, you can streamline this process and save yourself valuable time.

In this article, I'll share with you how I created a simple yet effective script using Tesseract OCR (Optical Character Recognition) and Gnome Screenshot to extract text from any region of the screen and copy it to the clipboard. Let's dive in!

Setting the Stage

Before we get started, it's important to note that you'll need to have both Gnome Screenshot and Tesseract installed on your system. These tools are readily available on most Linux distributions and can be easily installed using your package manager of choice. Once you have them installed, you're ready to proceed.

The Script

The script I've crafted combines the functionalities of Gnome Screenshot and Tesseract to capture a selected area of the screen, extract the text from it, and copy it to the clipboard. Here's a breakdown of what each part of the script does:



#!/bin/bash

# Create a temporary directory

TMPDIR=$(mktemp -d)

# Take a screenshot of a selected area and save it as screenshot.png in the temporary directory

gnome-screenshot -a -f $TMPDIR/screenshot.png

# Process the screenshot with Tesseract and save the result to a text file in the temporary directory

tesseract $TMPDIR/screenshot.png $TMPDIR/output

# Copy the result to the clipboard

# ignore all non-ASCII characters

cat $TMPDIR/output.txt |

    tr -cd '\11\12\15\40-\176' | grep . | perl -pe 'chomp if eof' |

    xclip -selection clipboard

# Optionally, remove the temporary directory when done

rm -r $TMPDIR

How It Works

The script starts by creating a temporary directory to store the screenshot and its processed output. It then uses Gnome Screenshot to capture a selected area of the screen and save it as "screenshot.png" in the temporary directory.

Next, the script utilizes Tesseract to process the screenshot and extract any text present in it. The extracted text is saved to a file named "output.txt" in the same temporary directory.

The script then cleans up the extracted text, removing any non-ASCII characters, and copies it to the clipboard using the xclip command.

Finally, the temporary directory is removed to tidy up after the process is complete.

Enhancements and Customizations

Personally I made this script runable by using chmod +x screenshot_to_clipboard.sh. Then I added ti to /usr/local/bin/screenshot_to_clipboard.sh so it is available to all users terminals. Also I did added keyboard shortcut to Ctrl+Q using GUI settings on PosOS but it should be straight forward for all gnome based systems.

Usage

The process of using it is fairly straight forward, you click shortcut, the area selector is automatically initiated, when you select the area all readable text is copied to clipboard, the script is over and you can continue using your computer normally.

Conclusion

With the Tesseract OCR and Gnome Screenshot combo, extracting text from images or screenshots is a breeze! This script isn't just simple it's customizable too. Set it up once, hit a shortcut, and boom! Text is in your clipboard, ready to go. It's like magic for your productivity! 🚀

Independent on my journey

Slobi — Thu, 11 Jan 2024 16:12:35 +0000

I want to emphasize my love for this the blogging space, where I can express my thoughts and projects that I am working on. However, I found myself at the mercy of moderators who can be triggered by any comment. One bad experience stands out when I commented on a particularly controversial article. The article drew an inappropriate comparison, likening company preferences for TypeScript to how certain groups of people strongly favor a particular religion.

I attempted to steer the conversation towards a more technical discussion, disregarding the sensitive religious aspect. To my surprise, a few hours later, I received two notifications. One was a reply to my comment, and the writer was rude. The other notification informed me that one of my blog posts violated the terms of service due to the use of a particular tag.

It dawned on me that I could lose all my content on this platform simply by upsetting the wrong person. In response, I took the precaution of downloading all my posts in Markdown format, along with all associated images. Subsequently, I added all the blogs to my personal website and established a secure and controlled environment for hosting my blogs, ensuring their safety and integrity.

Tech Stack I Use:

For the technical infrastructure of my self-hosted blog, I opted for a robust set of tools:

Webpack with EJS:

I leverage Webpack in conjunction with EJS for efficient bundling and rendering of my blog pages. EJS provides a flexible templating engine, allowing me to structure my content seamlessly.

Markdown to EJS Conversion:

I've developed a script that converts Markdown files to EJS, ensuring compatibility with my chosen templating engine.

Metadata Extraction:

Using regular expressions, I extract key-value pairs from the headers of my Markdown files. This process enables me to gather essential metadata such as titles, covers, and other relevant information.

// Regular expression to match key-value pairs
const regex = /\b([a-zA-Z0-9_]+):\s*([\s\S]*?)(?=\n|$)/g;

Markdown Rendering:

I utilize the markdown-it library to render Markdown content, enhancing the readability of my blog posts. Additionally, I employ highlight.js for syntax highlighting, with the Atom One Dark theme for a visually appealing code presentation.

Customization with mila:

The markdown-it-link-attributes (mila) extension allows me to customize link attributes, providing an extra layer of control over the appearance and behavior of hyperlinks in my blog posts.
Here's a snippet of included libraries:

const MarkdownIt = require('markdown-it');
const hljs = require('highlight.js');
var mila = require("markdown-it-link-attributes");

// Linking to the highlight.js Atom One Dark theme
<link rel="stylesheet" href="../../node_modules/highlight.js/styles/atom-one-dark.css">

I've found this setup to be exceptionally effective in creating and maintaining my blog, providing a seamless and personalized experience for both me and my readers.

It took me about 2 afternoons:

And I think that result is decent given that I am full stack developer that works on business and service software.

Please let me know what you think and feel free to read my other articles while they are here ;)

Or there is a backup Backup Link (other half) but mainly here

Coding Plane of Programming Languages and Programmers by AI

Slobi — Sat, 16 Dec 2023 15:44:45 +0000

In the vast plain of programming languages, selecting the right one can be similar to navigating an unknown cosmic terrain. This journey becomes even more unknown when tailored to different programmer types. Let's jump on a three minute exploration into the unique universe of 2D projection, where the closeness between programmers and languages reveals the effort required to reach coding nirvana, all within the context of AI-generated properties.

The Force Field of Programming:

Imagine a force field governed by an enigmatic formula — (x-1)*(x^-1). In this coding cosmos, if a language and a programmer find themselves too close (<1), an invisible force urges them to diverge, to maintain a healthy distance. Conversely, if separated by vast expanses, a subtle force beckons them to draw near, inviting collaboration. This force field encapsulates the essence of our exploration.

Mapping the Cosmic Landscape:

Our journey commences with the unique touch of AI-generated properties. The parameters:

learning curve,
syntax complexity,
and 'similarity_to_other_languages', 'syntax_complexity', 'community_support', 'ecosystem', 'performance', 'distance_from_machine_code', 'parameter_strictness', 'prevention_of_runtime_bugs'

become constellations in this cosmic map. These properties, meticulously crafted by artificial intelligence, shape the 2D landscape. The distances between points signify the effort, the cosmic energy, required for a programmer to traverse from one language to another or vice versa.

Unveiling Relationships in 2D:

As the cosmic map takes shape, intricate relationships between AI-generated languages and programmers unfold. Each entity competes for its celestial spot, guided by the properties that define it. The graphical representation not only showcases the unique bond between a programmer and a language but also paints a broader picture of the cosmic dynamics within the programming landscape.

Symphony of diverse coding elements, all driven by the artistic touch of artificial intelligence. Testing our cosmic model reveals patterns resembling a cosmic symphony, each note representing the nuanced relationships between languages and programmers.

Here is the space frontier:

The detailed for beginners so you don't wonder into dark and far places in space:

If you want to see for yourself:

Live demo example

Please note that we have 9D world projected into 2D so the representation is not always accurate but it is surely informative.

Conclusion: Navigating the Cosmic Coding Odyssey:

In conclusion, our 2D odyssey through the cosmic coding landscape, with its AI-generated properties, provides a unique lens for understanding the relationships between programming languages and programmers. Beyond traditional metrics, this cosmic approach offers a holistic view, guiding developers toward informed and efficient coding choices. As we continue to chart the cosmic coding realms, the force field of (x-1)*(x^-1) remains our guiding light in this AI-infused cosmic odyssey. May your coding journey be filled with celestial discoveries and effortless traversals across the cosmic expanse.

Tag Recommendation to Game Design: A True Story of Word-Difference-Calculator

Slobi — Thu, 07 Dec 2023 19:13:51 +0000

Introduction

A while back I made an app that tracks my spending
and after a while I realized that my tag system was lacking because I had multiple tags that were similar but letter case were different or I had a missing letter. That made my statistical evaluation of my spending go nuts.

I was promoted to make a solution and from that the "word-difference-calculator" was born.

Evaluating Missed Letter Cases

When typing on PC first letter is small by default, and I like my tags that way, but on mobile phone first letter is upper case by default and that is annoying.
So I addressed that problem with following code:

if (letter1 !== letter2) {
    if (letter1.toLowerCase() === letter2.toLowerCase()) {
            weightedDifference += caseWeight; // case difference
    }
}

Evaluating Missed or Added Letter

Sometime while I type i forget to type one letter so that case must be covered, I did it using word horizontal search for missing letter.

Code goes something like this:

get(first, second, index){
 look for letter first[index] in second[min delta index]
 return min delta index
}

When that is done we keep the returned index so we don't penalize one missing or added letter for all remaining letters.

Keyboard misses

While typing on keyboard I frequently miss my keys so that was also accounted by:

const rowDirection = firstLetter.row - secondLetter.row;
const rowDiff = Math.abs(rowDirection);
const rowAdjust = rowDirection * 0.5;
const colDiff = Math.abs(pos1.col + rowAdjust - pos2.col);
return rowDiff + colDiff;

So now I can fat finger my keyboard I much as I want and there was not a problem in suggesting right tags from the list that is already defined.

Adding Tests with Realistic Scenarios

How to test something like this, well I tested it partial and in general:
Partial test would be:

// Test for distance on eyboard
assert.equal(getKeyboardDistance('a', 'a'), 0)
assert.equal(getKeyboardDistance('a', 'A'), 0)
assert.equal(getKeyboardDistance('a', 's'), 1)
assert.equal(getKeyboardDistance('a', 'd'), 2)
assert.equal(getKeyboardDistance('b', 't'), 3)
assert.equal(getKeyboardDistance('q', 'm'), 9)

Whole test would be:

for(let [first, second, expect] of tests){
    let val = computeWordDifference(first, second)
    assert.ok(Math.abs(val- expect)<0.03,first+' '+second + ' e: '+ expect+' v: '+val)
}

Integration into an Application for Tag Recognition

When I got to the app integration, it was easy, I just searched all the tags on every key, if any of the tags is similar I would showed it.

There were few unexpected behaviors that required some work so I had to make an idea of the problem, while classical method would not give results I turned to some unorthodox approaches.

Large-Scale Testing with 4000 Words

A while back I made an app that combines text typing game with tetris game so I had a pretty good word library and I figured that I can test every word with another and find the similar ones or the ones that brake my code. It gave me some results that looked like Gaussian bell function:

I learned how to make this graph but I learned nothing about my project, so I wanted to see more.

Graphical Representation

I wanted to see every relation of every word to another in 2d, I had an physics/game engine laying around that is easily extendable since it is ECS system, and I have a chain system implemented for testing chain mold effect:

Interactive chain mold sim

On the other hand had perfect interface with new interaction function reedy to be employed:

Interactive math plotter

The force function (x-1)*(x^-1) in my system, and it says if something is too close <1 then push it hard, if something is too far then try to attract it slightly.

After just few hours I had something that I can play with, it was interesting to watch, but it was not enough. I added one input and my word from input would join all the words that were competing to be at the right spot in relation to its neighbors.

The end result:

Interactive words 2d

Conclusion

Sometimes you just don't know where one project could lead. "word-difference-calculator" was part of one project, then it become a toy and a headache, then it inspired me to do some data science in the end it got its own game.

Final Thoughts

I feel very lucky that things panned out in this way, many project were touched in this journey, I had what was needed because I choose infrastructure and stick to it trough 10+ projects and 2+ years.

Thank you for reading!

The Way I Wished JavaScript Went - A New Year's Wish 🌲

Slobi — Tue, 05 Dec 2023 13:42:14 +0000

As we approach the new year, let's dive in a programming fantasy and evolution of JavaScript that seamlessly blends its prototype-based nature with a cleaner, more expressive syntax influenced by Rust. Picture a world where defining objects maintains the familiar prototype structure but is enriched with a syntax that brings joy to developers.

ES5-style Prototype Definition:

function Person(name) {
    this.name = name;
}

Person.prototype.print = function() {
    console.log(this.name);
}

In the well-known ES5-style prototype definition, we create a Person function and enhance its prototype with a print method. While this has been the JavaScript convention for a while, imagine infusing it with a syntax that's both cleaner and more expressive.

On JavaScript's Evolution

I think that JavaScript, post-ES5, went off course with its current definition. Unfortunately, I can't turn back time, and the inertia from other languages, combined with the current state of JavaScript, is too great. People tend to favor what is familiar, a landscape is filled with millions of packages and hundreds of super-set languages attempting to address the complexities that are created by a "bad patch".
But that can't stop us wishing!

The New Year's Wish:

// Prototype Definition
prototype Person {
    name: string;
}

// Trait Declaration
trait Printable {
    print();
}

// Trait Implementation for Person
trait Printable for Person {
    print() {
        console.log(name);
    }
}

// Type-checked,converted and sanitized
let myPerson: Person = { name: "John Doe" }; 
print(myPerson);
// this allow for recommendation
// of all objects in scope that support print
// To avoid ambiguity, opt.:
print<Printable>(myPerson);
// This should be allowed
myPerson.print();

In this wishful vision, the Person prototype is defined in a concise and readable manner using explicit syntax, eliminating constructor boilerplate. To maintain JavaScript's extensibility and composability, traits are introduced.

Traits in JavaScript?

Yes, imagine traits seamlessly integrated into JavaScript. In this wish, we use the trait keyword to declare a Printable trait with a print method. We then apply this trait to the Person prototype, allowing it to inherit and implement the behavior.

Type Checking

The usage example demonstrates not only a cleaner syntax but also introduces type checking. The variable myPerson is explicitly declared as a Person type, ensuring type safety during compilation/interpretation (who knows!). Additionally, the print function showcases how type ambiguity can be resolved, offering a more robust and predictable development experience.

This syntax harmoniously combines the best of both worlds, returning the prototype-based structure familiar to older JavaScript developers while introducing a clean and expressive syntax. The result? A wishful JavaScript that's not only powerful but also a joy to write and read.

Who knows what the future holds for JavaScript? Perhaps wishes like these might find their way into the language, making the developer experience even more delightful. 🍀

I know this proposition can be unfavorable to many, so bring your toughs to the table and lets discuss. 🔥

Until then, let's keep dreaming and coding! 🚀✨