My feed

Hello, Habr!

For many IT professionals, the ultimate personal finance setup involves a massive Google Sheet or a complex Notion database. I completely understand this approach: when you spend your entire day sitting in front of a monitor, entering data into a cell takes two seconds.But 7 years ago, my reality was entirely different. I was an entrepreneur, and my workday meant constant movement. I was driving, visiting warehouses, meeting partners, or checking production floors. I was 100% mobile, and the only tool I always had on hand was my iPhone.

In that fast-paced rhythm, traditional finance trackers and spreadsheets simply fall apart. Here are typical scenarios from my life back then:

I wanted to see what actually changes when the same small data-processing program travels through four generations of programming languages. So I built it in BASIC, C, Pascal and Python, kept the algorithm as similar as possible, and compared not only execution speed but also memory use, binary size, debugging time and the amount of code I had to keep in my head. C was fast. Python was short. Those parts were predictable. BASIC and Pascal were where the experiment became interesting.

In light of recent events (restrictions, slowdowns, bans) — “this isn’t allowed,” “this is for the best,” “strictly in the interest of your security,” and so on — the market for proxy providers has grown exponentially in just the last couple of years. 

To be fair, the ”proxy boom” hit right during the golden era of the 2020s, and overall, the growth trend continues to rise. In fact, I believe in the next few years, we will witness a total revolution in automation and related services. Reimagining, repackaging, and rolling out new features — I’m certain we have yet to peak in abilities.

However, the larger the market grows, the breakdown of components becomes much more interesting — to analyze the players, categorize them into subgroups, and highlight the favorites, mid-tier options, and underperformers. There are plenty of services out there, and a good chunk of them are incredibly inefficient and inaccurate. Since I have hands-on experience with many of these players, I'll share my firsthand knowledge, in hopes of it being useful to others.

LLMs hallucinate — everyone has seen what it looks like. The model reports, confidently and coherently, with the right intonation and terminology, something that isn't there. Engineers treat this as a bug: one being fixed, one about to be fixed.

It won't be. This is not a technical fault but an inherent property of language, which the machine has made visible.

Candy AI is the most complete package — consistent image generation, animated replies and the widest feature set in one subscription. If you would rather stay inside Telegram and skip registration entirely, AIGirl and Lucid Dreams do the same job in a mini app. If voice matters, OurDream is the only one here that treats it as a real feature.

The category has split in two. On one side, web platforms selling images, video and voice on top of chat. On the other, Telegram mini apps selling nothing but conversation and winning on friction: no download, no email, no card. Both are represented below, judged on the same six criteria.

What do 1C queries, IN (VALUES ...) constructs, and the innocent expression x + 0 have in common? They can all turn a millisecond query into a multi-minute wait because PostgreSQL's standard planner "trips" over them. We break down how the pgpro_planner extension rewrites tricky parts of the query tree into a friendly form before the optimizer picks a bad plan — and why some of these fixes have already made it into vanilla PostgreSQL 18.

AI-generated code often looks cleaner than code written by a tired developer at 2 a.m. It has sensible names, neat layers, comments, tests and even error handling. The problem starts when the code meets something the prompt forgot to mention: two requests at once, a repeated webhook, a cancelled task or a database failure halfway through an operation.

This article is about bugs that stay invisible during a normal code review. I took several ordinary backend tasks, generated working solutions and then tried to break them with timing, retries and bad input. The code compiled. The tests were green. Some of it was still unsafe.

I am glad to present a new tool that I built, with Codex gpt-5.6.

Progressive Web App - mean that you can "install" it to your desktop or mobile screen - this is a web app - outside of App Stores.

Free and open source.

Without backend - just direct calls to Wikidata. Without an account.

You are welcome to share your feedback.

Currently this is the list only - no map, see related project https://wikishootme.toolforge.org/

https://vitaly-zdanevich.github.io/wikidata-nearby-pwa/

My name is Anton Omelianenko and I’m head of software development. A manager runs a team so that it delivers results for the business. To judge how well people are handling their work, a manager needs data and a system for assessing it. In software development this is harder than it looks.

This article covers three questions: why classic metrics fail when assessing developers, how to measure performance properly and what to do when an employee may not be working only for you.

A personal technical retrospective about moving away from framework-first development, reducing client-side JavaScript, using server-rendered HTML, and treating browser APIs as architectural tools rather than outdated limitations.

A normal code review comment usually sounds harmless.

Rename this variable. Move this method. Add a test. Remove the duplicate condition. But sometimes an experienced developer leaves a much shorter comment: No.

Not maybe. Not could we simplify this. Just a clear rejection of the entire approach.

For a junior developer, this can feel strange. The code compiles, tests pass, the implementation is readable, and the ticket requirements seem complete. Why throw it away?

I started saving such cases after one of my pull requests was rejected for the third time in a week. The goal was not to prove that the reviewer was wrong. I simply wanted to understand what experienced engineers noticed before everyone else.

Over several months, I collected review discussions from backend services, internal tools, queue consumers, APIs, and data-processing jobs. I removed comments about formatting and naming. Only full design-level rejections remained.

The result was a small catalogue of professional paranoia.

And honestly, most of it was useful.

On June 28, 2025, the European Union’s transition period for the European Accessibility Act ended. For a broad range of commercial services—online stores, banks, transport, and telecom—web accessibility stopped being a matter of goodwill.

Technically, the requirement comes down to EN 301 549 and, for the web, WCAG 2.1 Level AA. You cannot learn WCAG by reading it: half the criteria sound perfectly clear while leaving it completely unclear what exactly should be written in the markup.

Some of our projects fall under the new requirements, and it is not only front-end developers who need to relearn their habits. Designers set contrast and focus order, analysts write error messages, and testers need to know what to check manually.

That is how a project of 20 exercises emerged. In each one, the page looks fine at first glance. It is broken only from an accessibility perspective: headings skip levels, a div with a click handler acts as a button, a label sits next to an input but is not formally associated with it. You edit the markup and immediately see the result as the page rebuilds on the fly. Everything runs directly in the browser, and both your code and progress stay in localStorage: a11y-exercises.github.io

Developer tools are often introduced through documentation, release notes, and online demos. That is enough to explain features, but it is not always enough to help people use a new tool in a real project.

Deleting code sounds easy until the code belongs to a running product.

A function may have no direct callers but still be loaded through a plugin registry. A serializer may look duplicated but quietly preserve an old field name used by one customer. A command may not appear in analytics because it runs from cron at 3:10 a.m. on the first Sunday of each month. Python makes this even more fun because imports, decorators, entry points, reflection, monkey patches, and strings can all become hidden edges in the dependency graph.

The project in this story was a multi-tenant reporting backend written in Python. It accepted events, stored normalized records, generated reports, exported CSV and JSON files, and delivered them through HTTP, email, and object storage. Nothing huge. Around 140 API endpoints, 46 background tasks, PostgreSQL, Redis, and a queue.

The repository contained 62,914 lines of Python excluding tests and migrations.

That number was not the actual problem. The problem was that a small change in report filtering could require edits in the API schema, a service class, a repository, a filter translator, a query builder, an export adapter, and several nearly identical tests. The system had layers, but the layers did not reduce complexity. They distributed it.

The first plan was a rewrite. Fortunately, that plan died before production did.

Instead, the question became much simpler: How much code can disappear while externally observable behavior remains unchanged?

That wording changed the whole project.

At some point, ChatGPT stopped feeling like a tool and started feeling like a reflex.

Need a parser? Ask ChatGPT.
Strange exception in a background worker? Ask ChatGPT.
Forgot how a lock behaves under contention? Ask ChatGPT.
Need to rename a method? Apparently, that also required artificial intelligence.

Nothing looked wrong on the surface. Tasks were moving. Pull requests were getting merged. The code usually worked. Sometimes it even looked cleaner than what I would have written from scratch. But there was a small problem. A few days later, I often could not explain why a certain solution was built that way. I remembered the task, the final code, and maybe the prompt. The reasoning in between was missing.

That bothered me more than I expected.

So I set a simple rule: for six months, no ChatGPT, no Copilot Chat, no AI-generated code pasted into production. Documentation, source code, issue trackers, books, debuggers, profilers, and search engines were allowed. AI assistants were not.

The experiment started as a way to test my own dependence. It ended up changing how I design APIs, debug systems, read unfamiliar code, and even write comments.

The idea appeared after a normal working evening went slightly wrong.

I opened a repository, started a build, and noticed that nearly every useful action required a connection to somebody else’s server. The source code was hosted remotely. The CI runner was remote. Package metadata came from remote registries. Test files were downloaded from object storage. API collections were synchronized through a cloud account. Documentation lived in another browser tab. Even code completion waited for a remote model.

My laptop was powerful enough to compile the project, run several databases, and heat the room better than the radiator. Still, it behaved more like a terminal connected to a collection of external services.

So I made a simple rule for one month:

The main development workflow had to remain usable with the network disconnected.

I did not try to recreate the entire Internet in Docker. Public package registries, operating system updates, and communication tools were still allowed during planned synchronization periods. But coding, commits, builds, tests, documentation, API experiments, and basic code review had to work locally.

The first assumption was that this would mostly be a Docker Compose exercise.

It was not.

The containers were the easy part. The difficult part was discovering all the invisible contracts hidden inside a normal cloud-based workflow.

Recipes for building a truly autonomous neural network surface in the information space on a regular basis. More often than not, the methods and approaches coincide regardless of the author. And although they look original, most of them have in fact been formalized with the help of LLMs — and LLMs, as we know, work very well with existing knowledge.

In this article I will analyze the main techniques being proposed and the faulty foundation they rest upon.

Literature review, comparison, and analysis of existing solutions constitute a significant part of a thesis manuscript.  In the last three years, AI chats have dramatically intervened in the thesis preparation workflow. The ability of AI chats to analyze and compare discourages students from acting as the primary drivers of research and instead encourages their passive reliance on AI-generated content. This situation makes manuscripts eclectic and lacks focus. The theoretical part disconnects from the computational experiments. As a result, the audience is reluctant to read students' manuscripts. Ironically, they use AI chats to summarise the manuscripts to extract their main contributions. We are proud to say that our thesis works do not suffer from this AI distortion. We are grateful to our students, especially our bachelor’s and master’s alumni, who have carefully prepared and successfully defended their theses, producing clear, well-founded, and meaningful results. Our thesis manuscripts are designed for public discussion and rigorous scientific analysis. Each thesis presents a clear research idea grounded in the fundamentals of machine learning. It includes a theoretical justification, a repository with the source code of the computational experiments, and slides. Videos of the pre-defence sessions are uploaded to our YouTube channel “Intelligent Systems”: Bachelors & Masters.

Our office has roughly one hundred employees, but for a long time we had no proper help desk process. Requests arrived through email, corporate chat, phone calls, and random conversations in the hallway. It always felt as if most of the day was spent dealing with servers, networks, backups, and serious incidents.

To check whether that impression was accurate, I logged every support request for one month. I measured active work time, recorded the cause of recurring problems, tracked waiting periods, and counted how often a new request interrupted something already in progress.

Over 22 working days, I recorded 496 contacts. After merging duplicate reports related to the same issue, those contacts became 421 separate support episodes.

The most surprising result was not the total number of requests. It was the damage caused by short five‑minute tasks constantly breaking longer technical work into small, nearly useless fragments.

This article explains how I collected the data, why average resolution time is often misleading, how I automated Windows workstation diagnostics with PowerShell, and how I processed the resulting event log using Python and PostgreSQL.

We build a Tiny Language Model from scratch in pure Node.js without TensorFlow or PyTorch, implementing neurons, autograd, embeddings, self-attention, FFN, backpropagation, and SFT while observing how individual weights and entire matrices change during training.