My feed

Healthcare app development has skyrocketed in recent years, establishing itself as one of the most critical sectors in mobile product design. The demand surged dramatically with the start of the pandemic in 2020 when safety concerns forced the mass cancellation of in-person appointments, driving an abrupt shift toward remote consultations. Today, with the global market value surpassing $300 billion and annual downloads exceeding 300 million, the competition is incredibly fierce. Apart from that, healthcare apps are considered to be among the most complex and challenging software products to build from a UX design perspective. Launching a basic app is no longer enough – you must deliver a flawless, high-performance product that seamlessly caters to a diverse range of users, including patients of all ages and of different health conditions, doctors of various specialities and administrative staff. Above all, a premium healthcare app demands an impeccable interface that strictly adheres to both medical design principles and rigid digital health regulations. 

In this guide we’ve collected the core principles of healthcare UX, along with the typical challenges designers face and the key mistakes to watch out for.  

I wanted to buy Telegram Stars for less. For 1,000 Stars, SMMESE quoted $15.31, TgSuperstars $16.50, and MyStars.tg $16.67. Comparing prices led me to another question: what happens between paying a seller and receiving the Stars? I traced the process through Fragment and broke down the Python code for finding the recipient, preparing the payment, and confirming the purchase—the core of a Stars storefront.

We’re continuing our review of the March CommitFest for PostgreSQL 19. This third article in the series covers the changes related to our DBA3 and DBS courses.

As a reminder, here’s the plan for our coverage of the final PostgreSQL 19 CommitFest:

Part 5.1 (QPT)

Part 5.2 (DBA1, DBA2)

Part 5.3 (DBA3, DBS) – you are here 🙂

Part 5.4 (SQL, DEV1, DEV2)

For the earlier CommitFests, see: 2025-07, 2025-09, 2025-11, 2026-01.

I have a Flydigi Vader 5 Pro controller and its Charging Dock 2 Pro. The dock has 162 RGB LEDs, and the LEDs themselves are good, but the effects in Flydigi's Space Station app look cheap: slow animations step, gradients turn muddy in the middle.

I wondered whether the hardware or the software was to blame. Spoiler: the software. I figured out how the dock receives frames, rewrote the effects from scratch and made my own lighting editor.

We’re continuing our review of the March CommitFest for PostgreSQL 19. This second article in the series covers the changes related to our DBA1 and DBA2 courses.

As a reminder, here’s the plan for our coverage of the final PostgreSQL 19 CommitFest:

Part 5.1 (QPT)

Part 5.2 (DBA1, DBA2) – you are here 🙂

Part 5.3 (DBA3, DBS)

Part 5.4 (SQL, DEV1, DEV2)

For the earlier CommitFests, see: 2025-07, 2025-09, 2025-11, 2026-01.

We’re wrapping up our series of articles reviewing the changes in PostgreSQL 19. The previous articles covered the first four CommitFests: 2025-07, 2025-09, 2025-11, 2026-01.

Today we begin our review of the March 2026 CommitFest. Why «begin»? As in previous years, the March review is going to be a long one: the final CommitFest of the cycle is where many of the most important changes land. Such a review is hard not only to write but also to read all the way through 🙂. That’s why this time it’s split into four articles.

The first article covers everything related to query optimization, in other words, the topics of our QPT training course. The second will focus on changes more relevant to the DBA1 and DBA2 courses. The third will cover DBA3 and DBS. The fourth will look at new SQL features, as well as changes related to the DEV1 and DEV2 courses.

Codex Cloud runs coding tasks in a remote environment. You can ask it to explain a project, edit files, run checks, and prepare a GitHub pull request while your computer is asleep.

It was late in the evening. I had a splitting headache, a nasty cold made it hard to breathe, and the thermometer was stubbornly creeping upward. What can you even do in a state like that, when it feels like the Grim Reaper is right around the corner, already waxing its skis?

Our PostgreSQL backups looked healthy. The scheduled jobs completed, the files were there, and monitoring showed no errors. Then I tried restoring the database on a clean server. That simple test exposed problems our backup monitoring had never noticed.

AI visibility can be measured, but treating it as the equivalent of an SEO position creates a false sense of precision. In ordinary rank tracking, the thing being observed is relatively clear: a URL has an ordinal place in a search result under specified conditions. In AI search, what we usually call visibility is calculated from a sample of generated answers. Those answers may change when the same prompt is repeated, and the sources behind them may change even more. Recent studies have measured substantial run-to-run and day-to-day variation, while official documentation from Google, OpenAI and Yandex shows that the products themselves differ in crawling, retrieval and answer-generation pipelines.

For practitioners, this does not make AI visibility useless. It changes what the percentage means. I find it more useful to read a figure such as 42% as a sample statistic: under a defined set of prompts, platforms and measurement rules, the brand appeared in 42% of the observed answers. That number becomes more useful when you keep the methodology stable, repeat measurements, preserve platform-level data instead of hiding it inside one average, and read visibility together with Share of Voice, answer sentiment, attributable AI referral traffic, external publication reach and branded traffic. This is especially important in the cases that cause the most questions in real projects: a brand appears in ChatGPT but not in another system, or the reported visibility remains almost flat for a month and then jumps by 20–30 percentage points several weeks later.

A green build that produces a 15-byte index.html is a strange thing to look at. The file contains exactly this:

In this article, I'll show how I updated NVIDIA drivers manually and automated the process using a DaemonSet and NVIDIA GPU Operator.

I'll also explain the problems we faced with pre-installed drivers and how I solved them.

This post is written for people, deep in compiler or dsl development, require parsing often, build complex configurations or engines from scratch. This tool is designed to parse most context-free languages with little effort. Furthermore it is done with philosophy:

1. Static generation. No generate in runtime

2. No dependecies, generated parser should be easy to setup

3. Multi-language output

4. Semantic actions and error handling alongside grammar without bloating it

5. Flexibility to use in trivial and very large projects

6. Easy to use, working out of box API

Another wave has swept through Telegram channels. Scientists have found a pain vector in LLMs. AI can suffer. How artificial is artificial intelligence? Should we establish ethical rules for how we treat AI?

This article is an analysis of what the scientists actually wrote and what conclusions follow from it.

Imagine a client submitting an order. The server inserts the row and commits the transaction. Just before the response reaches the client, the connection disappears. The client sees an error. The database contains a perfectly good order.

What should the client do now?

Retrying is reasonable from its point of view. The client cannot see the commit. But if the server treats the retry as a new operation, there are now two orders. This failure has nothing to do with a slow database or a broken transaction. The transaction did exactly what it was supposed to do. The ambiguity sits between the commit and the response.

I wanted to make that gap visible in a small program. It uses SQLite as a stand-in for the order database and deliberately raises a connection error immediately after committing. There is no HTTP server in the program; the returned status codes represent the responses an API would send. This keeps the experiment focused on the database state and the client's uncertainty.

One evening, while idly scrolling through a popular online marketplace, I happened upon an electronic lock with a fingerprint scanner. The description painted a picture of a nearly perfect device for a low price: biometric authentication, water resistance, and some sort of "unique" microchip. It sounded convincing, but a researcher's nature is to question marketing claims rather than take them at face value. So, naturally, the very next day, the lock was on my desk. From there, a familiar pattern emerged: one interesting device soon leads to a few more... 

My name is Denis Astafiev, and I am a lead hardware security researcher at Bastion—a Russian cybersecurity company. As part of my job, I regularly disassemble  various devices to see if the manufacturer's claims on the box hold up.

Today, we'll be examining three biometric locks to find the weak spots in their security.

Let me be clear: the goal of this article is not to subject a cheap Chinese lock to an exhaustive, lab-grade analysis at all costs. Instead, I want to use a simple, accessible example to show how a basic hardware security audit is typically conducted and why it's best to start with the simplest attacks, not the most complex ones.

Windows event logs in EVTX format are a key source of telemetry for incident response. They provide evidence of attacker activity on a host and are often the only remaining record of what happened during account compromise, lateral movement, or persistence attempts.

Attackers often try to destroy these logs by clearing them with wevtutil cl, encrypting them, or wiping disks. Ransomware operators increasingly target entire virtual machine disk images, including VDI, VMDK, and VHDX files. The file system of the affected volume may become inaccessible or too badly damaged for standard tools to mount: for example, if the master file table (MFT) has been destroyed or the partition table is missing.

One option is to reconstruct the file system manually by locating lost partitions and recovering deleted files. However, this takes time and may still leave gaps in the event history or severely corrupted EVTX files. This is where carving comes in — a byte-level search for EVTX signatures in raw data from a disk or volume image, a memory dump, a pagefile, or a VSS snapshot. It can recover surviving event data without relying on the file system.

At the Positive Technologies Expert Security Center, our Incident Response team (PT ESC IR) prioritizes automated artifact parsing to detect malicious activity and reconstruct incidents faster. Our processing pipeline is written primarily in Go. We could not find a suitable open-source library that combined EVTX parsing and carving. Existing parsers either crash regularly or consume too much memory, which hinders automation. We developed our own library that parses intact EVTX files, recovers data even when checksums do not match or files are corrupted, and performs event carving from bit-for-bit copies, memory dumps, and virtual disk images.

After experimenting with connection pool behavior, I wanted to test another assumption that looks harmless on dashboards.

If two workloads have the same average request rate, are they really equivalent from the database point of view?

At first, it seems reasonable.

If one service receives 1,000 requests per second on average and another also receives 1,000 requests per second, both appear to place roughly the same load on PostgreSQL.

But averages remove timing.

And timing is exactly where queues appear.

So I built a controlled queueing simulation of a Go service talking to PostgreSQL through a connection pool.

This was not a benchmark of PostgreSQL itself. I deliberately kept the model simple because I wanted to isolate one variable: the arrival pattern.

The total amount of traffic stayed the same.

Only the timing changed.

One workload was smooth.

The other arrived in bursts.

The average RPS was identical.

The model behaved very differently.

This article explains how to build an ML platform on top of Kubernetes for data analysts. It covers JupyterHub as the main entry point, S3-compatible object storage for datasets, CSI-based bucket mounting, and an automated infrastructure that simplifies data access, experimentation, and machine learning workflows.

Hi all! I'm Andrey Kuznetsov, and I work on ML in cybersecurity. In our community, FalsePositive, we break down research papers and keep up with what's new in ML. Now we're launching BlueSec, an open competition where AI agents investigate security incidents. Each agent starts with a single piece of evidence, reconstructs the attack on its own and delivers a verdict. The platform scores it on accuracy and how few tool calls it needs. If you work with LLMs and agents, this is a chance to test your skills and your agent's on problems at the intersection of ML and cybersecurity, a field that I think is undergoing even more change than software development.

The competition runs online from September 25 to October 10, and you can join from anywhere in the world. The final will be held in Moscow and St. Petersburg, both on-site and online. Sign up on the website.

In this post I'll cover: why we built this kind of competition, how the tasks and scoring work, where to start if you've never built an agent or investigated an incident.