Now that I have a plotter, I am fully experimenting with ways of algorithmic image stylization. To achieve what is attached, a Minimum Spanning Tree algorithm was used. Essentially, it converts an image into stochastic rasterization – that is, where it’s darker, there are more dots, and then connects the dots with lines so that all points are connected in a single network, the total length of all lines is minimal, and there are no closed loops (meaning it’s precisely a “tree” with branches, not a “web”).
And this is what I do with each of the CMYK channels, then combine the result into a color picture. On this picture, there seem to be no other colors except for these four CMYK ones, but in reality, there is a bit because some smoothing has crept in.
Printing such on a plotter, of course, is difficult, I will be waiting forever, but I am getting the hang of it, I have already printed the first color picture (it turned out so-so. Well, the first pancake is always lumpy. Comments below)
I would have never thought that I would enjoy working in the same place for an entire decade. What’s the secret? At EPAM, I am always evolving: projects change one after another, never letting me get bored.
I am currently on a project at a giant company: over 100 thousand employees and revenue of 30 billion dollars. Before this, it was the automotive industry — a behemoth with a staff of 175 thousand and a turnover of 150 billion. Somewhere around, there was a contract with a company of 80 thousand employees and 35 billion in revenue. True scale and genuinely serious challenges. And earlier, there were cosmetics brands, biotech, and the oil sector. In total, more than 20 projects of various calibers. Despite having over 100% workload every single day. And it seems that this year, I had more vacation than usual, yet still less than I could have taken. I traveled to Costa Rica, Mexico, Seattle, Antalya.
The point is, at each new place you learn something, sometimes from scratch. And that’s freaking awesome. It gives much more energy than if I had been “rooted” in any of these corporations for all 10 years. Perhaps, from a purely financial standpoint, people who stayed in one place at these companies earned more than me, but money isn’t the priority if it means sacrificing interest and enthusiasm. Living life at a job from which you are utterly exhausted is a questionable pleasure.
Last year at EPAM was maximally intense, and I sincerely hope that 2026 will not slow down.
What I did on the plane to/from vacation and sometimes in between: 3D visualization and editing volleyball schemes for Nadya (she’s a coach). This court in the attached image freely rotates, players can be placed on it, and the ball and player paths are shown – all in 3D.
The ball’s trajectory is calculated so that it does not cross the net when moving from A to B (Bezier formula). Players can take several poses – right now there are hastily made poses for serve, attack, block, pass/receive. Interestingly, in the code: I had to write a bit of “volleyball brains”. The system itself calculates the ball’s trajectory through Bezier curves so that it always passes over the net. Moreover, the height of the launch depends on the type of action: for an attack, the ball “launches” from a higher point than for a pass. I also added auto-rotation: the 3D model itself turns its face to where, according to the scheme, it needs to pass or run.
The longest and most difficult task was creating the 3D model of a female volleyball player. To generate a realistic volleyball player, I used the tripo3D service. It gave me a model in a neutral pose (for free). Theoretically, you can then use Blender and the Rigify plugin to attach an armature to it and move its arms and legs, which would recalculate the model.
However, in reality, this approach does not work well: the AI-generated model contains a large number of geometric errors, which the renderer forgives but Rigify does not. They can be roughly divided into two types — incorrect polygon normals and issues with non-manifold geometry, which are significantly more challenging to fix. Inside the body, there may be “floating” clusters of polygons or intersecting surfaces. When Rigify tries to calculate weights (which bone affects which part of the skin), this internal noise confuses the algorithm, and as a result, the weights are distributed chaotically (for example, moving the arm might start pulling the mesh on the stomach). Plus, the model is slightly asymmetrical.
Non-manifold is a geometry error where the topology of an object ceases to be correct in terms of a three-dimensional body: edges may belong to more than two polygons, polygons may only touch at vertices or edges without a common volume, and “hanging” surfaces or zero thickness may appear inside the model. Such geometry formally does not describe a closed volume, causing problems with rigging and deformations. Moreover, the model needs to be simplified because millions of polygons are not needed for rendering in real-time in a browser.
I fixed these using MashLab, additionally refining by hand (“with a file”). In the end, the model turns out slightly different from the original almost everywhere. The original model had “skin” in the form of textures – the face, shirt, and shorts had to be colored. How to transfer all this to a simplified model? For that, there’s a special operation in Blender called Baking. This also involves some tricks. In the end, it didn’t transfer perfectly, but perfection isn’t necessary yet.
Next, we attach the armature to the “joints”, and after about three hours of figuring out why everything does not work as it should, it finally worked. I made four poses, and now each circle (player) can be told which pose it is in.
I’ll also need to make dynamic changes to the uniform colors – that shouldn’t be difficult. There’s also an idea to transfer poses from photographs – this is more complicated, but generally feasible. Using MediaPipe/AlphaPose, you can detect key points in 2D, then some models like HMR/HybrIK can “lift” flat coordinates into 3D space, outputting relative joint rotation angles. The resulting data can be attempted to be projected onto a Rigify skeleton. Since the proportions of the generated volleyball player and the person in the photo may not match, that’s exactly why Inverse Kinematics (IK) is used. This part is quite complex, but overall it’s not strictly necessary – just interesting to figure out and make something functional.
Tomorrow is the flight to Costa Rica, and here I am creating (or created) a volleyball playbook editor for Nadya. As a coach, she prepares for her sessions and leaves behind hundreds of pages of text with diagrams on each page. The text is handwritten, and theoretically, it’s simple to convert to a digital format, but converting the diagrams into high-quality vector format is exhaustive—there are so many. So, I decided to make the software yesterday. And today, the first version is ready to use. This is a diagram editor, somewhat remotely similar to a diagram editor. Also got to dig into the fabric framework.
The process looks like this. Gemini/ChatGPT through an API can convert hand-drawn diagrams into a structure that my program understands. Then we open this file in the program, and tweak a bit if necessary. Or maybe even redraw from scratch – for simple diagrams, it’s even easier. There are four types of objects – player, cone, target, text. Any can be connected with arrows, solid or dashed, labeled with text or numbers or not, in any chosen color, straight or curved. If you touch an object with the mouse, all connected arrows will follow.
The result can be saved in a file. You can open a template and based on it create something new. You can generate a Python script – yesterday it was still relevant, today generally not needed anymore – high-resolution SVG/PNGs are made directly from this app (yesterday they were made separately in Python).
It’s clear why you wouldn’t just ask Gemini/ChatGPT to do something for ready-made vector editors: firstly, they are too flexible and limiting LLM’s imagination is quite difficult. As a result, you get stylized, unusable images. Here, instead, there is a framework consisting of four objects and that’s all, LLM knows about it and only generates what can be represented with them. Secondly, this framework operates with objects, not elementary vector primitives.
Overall, this is the first step towards my idea of an automatic diagramming system based on descriptions. Where you give an LLM a diagram description, and it consistently generates what is written in the description, and if you make any corrections, they will be taken into account during regeneration.
We’ve all encountered it — the “Main Excel Spreadsheet Managing the Business.” The very one B2B companies use to calculate million dollar quotes. It has 12 tabs, 1000+ nested formulas, and zero documentation. For ten years, it had “quick fixes” slapped on and constants hidden away. It’s no longer just a file, but a living organism that no one fully understands except for the guy who quit years ago. That’s how puzzled I was. Moreover, there was uncertainty whether even half of the formulas were needed, or if they were vestiges of the past.
I was tasked with transferring this logic into code so that it was all computed by software. The Excel file seemed to have everything it needed, but in reality — it was a complicated black box. 1069 formulas.
The challenge was in how to translate a thousand interdependent formulas into clean code without losing any edge cases.
Here’s what I ended up doing.
Instead of rewriting everything from scratch at once with uncertain prospects of bug proliferation, I used a strategy of lazy computations and mocks.
I built a structure on Groovy that mimicked Excel’s behavior. Each computation (from a cell) I defined as a function that executed only when it was called. And the functions were a multidimensional dictionary.
I started from the end of the computation graph: from results to inputs. If a formula depended on something I hadn’t yet written, I “mocked” it in the code, simply substituting the value from the Excel sheet.
Bit by bit I replaced these mocks with real logic. Comparing the output of my code to the Excel at each step, I could clearly see where my logic diverged.
In other words, I moved from the result to the input data. At each step, it was clear which mocks needed to be turned into code, and I could compare version +1 with version -1 — the result had to match. As soon as all mocks were replaced with calls — the task was done.
The real “secret ingredient” was the dynamic nature of Groovy for creating a multidimensional map of functions. Instead of static variables, I used a deeply nested structure, where each “leaf” was a closure. This allowed access to any part of the table — be it an input parameter, a config constant, or a complex intermediate result — through a simple, unified syntax, and some components were dynamic.
x -> calculate[“Group”][“Subgroup”][it][“Someparameter”]() * conf[“someConstant”]()
}
}
Using dynamic keys and closures, I could iterate through product groups or data sets. Since these were dynamic functions, not stored values, the entire system worked like a living graph of dependencies.
Testing was possible right from the start of transferring the formulas. The charm was that you were kind of addressing a cell through syntax like calculate[“Totals”][“A”](), but in reality, you were launching an entire tree of calculations at that moment. And this was incredibly convenient for debugging.
In two weeks, the “Black Box” was transformed into a transparent, modular library with clear logic, which produced exactly the same result as the original table.
P.S. Of course, all the data in all the screenshots are thoroughly obfuscated, or rather, written from scratch for this text.
Oh, I just solved a really cool problem. It’s tricky to explain though. But I’ll try.
So, the client has 10 search websites. They all use one index but throw different queries at it. To what the user enters, a very long and complex query is added, generated by a module on Sitecore. It includes template and page IDs that need to be included or excluded. Ultimately, it’s impossible to understand what’s going on there. There could be ten opening brackets and some randomly closing ones, but it worked with Coveo. Reformatting helped, but not much.
And each site has its own version of this. Meanwhile, the same IDs appear periodically. I first tried to manually figure this out, but it was a nightmare. Nothing helped. There are also nested conditions. For example, “exclude this template” not globally, but only if that field equals one.
Here’s what I did:
I wrote a script that parses this textual “mess” into an abstract syntax tree (AST). This allowed to turn an unreadable string into a structured JSON object, where it’s clear: here’s AND, there’s OR, and here — a specific condition.
Then I turned these conditions into Boolean algebra formulas. Using the SymPy library, I “fed” these formulas to simplification algorithms. Mathematics itself eliminated duplicates, collapsed excessive nesting, and removed conditions that are logically absorbed by others. As a result, the “trees” became flat and understandable.
In the attachment — the original tree and the simplified one.
To be sure that I didn’t break anything during simplification, I wrote a test generator. It takes the simplified logic, puts it back into a working curl, and checks whether the number of found documents (totalCount) matches the original request. The numbers matched — meaning, the logic is preserved 100%.
Having simplified and standardized structures for each site in hand, I built a comparison matrix. The script analyzed them and highlighted Common Core — conditions that are guaranteed to be required (or prohibited) on all sites without exception, and Specifics — unique “tails” that distinguish one site from another.
In the attached screenshot: REQ means that the condition is guaranteed to be met for any document that goes through this request. NOT — definitely not met. OPT — the condition is present in the request, but it’s not strict by itself. It only works in conjunction with something else. “.” — the condition is not mentioned in the request at all.
For 3 sites it responds instantly, for 10 it takes about 30 minutes.
And of course, all data in all screenshots are thoroughly obfuscated.
I’m checking out what open data we have in our county to play with data analysis over the weekend, and discovered, for instance, an open database of all 1.5 million trees in the county. The screenshot shows just a tiny part around my house.
While figuring out neural networks, I decided to come up with a game-related task for myself. What if I find some ready-made games, and train a neural net to predict moves based on the board situation. Said and done. Of course, generating code is faster with LLM, but I wrote the detailed assignment myself and designed the architecture on my own. In 40 minutes (!) from the idea to the result, I already had a working solution that, at least in the first half of the game, does not mess up too much.
In the screenshot is CuteChess – it works with any chess engine, and in my case, it’s a simple Python script. The script takes the board situation and feeds it to the model. It selects the top 5 moves, and only these top 5 are analyzed deeply for several moves ahead and assesses the position. That is, the neural network suggests possible moves based on the analysis of 20,000 games (534,453 positions). From the results, the best is chosen. It uses the minimax algorithm for this, if that means anything to anyone (it didn’t to me, so Gemini here helped me)
How the model is trained. On the lichess website, you can download games, there are hundreds of gigabytes. I took a file with 800,000 played games from the year 2014. From these 800,000, I select 20,000, specifically looking with a script for games where the result is not a draw (1-0 or 0-1). Next, I calculate the difference (Winner_Rating minus Loser_Rating). It’s not the best metric, but it’s better than nothing. The bigger this difference, the more “confident” the win should be (the strong punish the weak). Thus, I get 20,000 such games.
“Ignoring the moves of the weak” (to avoid teaching the model bad play) is implemented during the training stage of the model. Essentially, the logic is: “If it’s White’s turn now, and White won this game — we learn. If it’s Black’s turn now, and Black lost — we skip and don’t teach the net this move.”.
The neural network is trained in batches of 128 positions at a time. The network receives a board position as input and outputs 4096 — the probability assessment for each possible move.
Selecting games takes about 5 minutes. Training the model on my computer takes about 10 minutes for 20,000 games. You could leave it to train on 100K or a million, and it would definitely be better. No need anymore – I figured it out 🙂
I am currently experimenting with training simple neural networks – primarily to automate the existing toolkit, and some things just seem like magic.
There is a database of 32,000 names. There is a neural network filled with random numbers. I start training, with only this list of names as input. The first layer of the neural network is embeddings, and I set the number of dimensions to 2 for easy visualization. And after 200,000 iterations of training, the system clearly separates vowels from consonants, and for some reason, places the letter “q” slightly apart from other consonants. It seems that this is because the letter ‘q’ almost exclusively predicts the letter ‘u’ (Queen, Quincy, Quentin).
It also very reliably separates vowels and consonants in Russian names. In Russian names, the letters b and l are somewhat away from the other consonants, as are the soft and hard signs (well, that’s understandable).
I wonder how it works. If trained on a normal corpus of texts, the difference would be very clear. Why are vowels separated from consonants? Apparently, from the network’s mathematical perspective, ‘a’ and ‘o’ serve the same function: they “trigger” the prediction of the consonant following them, so the alternation of vowels and consonants is to blame. But damn, it’s interesting 🙂
And since the model can predict the next letters, you might try running it on Russian. On a model with 30-dimensional embeddings, it invents names like: Byaketta, Afsena, Erakey, Zasbat, Daraya, Gaiomahad, Rain, Razhul, Gzhatsiy, Reben, Vureb, Durodira, Turuzhul, Regravgava, Razsan, Gabila, Avganzh, Raksi, Khalebkokhorta, Rather. The model – for those who understand – is this: input of 6×33 characters (because we take up to 6 characters of context), encoded into embeddings of 60, goes to a layer of 100 neurons, and from there back to 33 characters. Some nonsense, but at least it’s clear how it all works at all levels.
Hi, I'm Rauf Aliev. 