Kurgan-Telecom Ru | Информационные технологии

С точки зрения Древней Греции, это «привлекательные существа, в верхней своей части, выглядящие как женщины, а снизу, как птицы. Они обладали невероятно сладкоголосым голосом, благодаря которому, пение сирен завораживало и увлекало несчастных мореплавателей на погибель» — где-то примерно так надо было бы начать наш рассказ, если бы мы захотели вспомнить ещё раз мифы. Но... Мы то расскажем не про это! :-)

Идея написать эту статью возникла у меня не спонтанно. Проект цифрового рубля привлёк моё внимание ещё в тот период, когда я работал в Федеральной налоговой службе. Теперь, будучи человеком свободным от обязательств госслужащего я решил поглубже разобраться в этой теме и высказать свое мнение и видение того как Цифровой рубль способен трансформировать всю систему денежных расчетов.

В статье я опишу как цифровой рубль встроен в существующую экономическую и управленческую модель, какие задачи он решает для государства и какие последствия может иметь для бизнеса и граждан, в том числе с точки зрения контроля финансовых потоков и через фискальные механизмы.

Я предлагаю рассматривать цифровой рубль не как абстрактную валюту будущего, а как инфраструктурное решение, способное изменить логику платёжных отношений и баланс ролей в финансовой системе.

Меня зовут Виталий и я пишу уже который год самую большую книгу по математике для 4– 11 классов, а так же автор поста (рекомендую почитать) о ней. Пишу я ее в LaTeX и считаю, что современный учебник не должен быть черно-белым, а так же должен быть удобен для использования и учеником и учителем. Здесь я собрал вторую часть фишек, которые я использую (что-то чаще, что-то реже). Надеюсь, вы найдете что-нибудь полезное для себя:)

Постараюсь все подробно описать, но не гарантирую идеального кода. Компиляция в основном с помощью pdflatex, но есть места, где требуется lualatex. Для себя я сделал около 35 стилевых файлов для использования в преамбуле, но тут я написал полный код чтобы в каждом случае можно было запустить "из коробки".

Первая часть тут

Вот вы покупаете б/у сервер у компании, которая закрывается. Никто не знает точно, сколько он стоит, но есть ощущение, что сделка возможна.

Всё это отлично покрывается теорией игр.

Вам нужно две границы:

1. За сколько максимум вы готовы его купить. Это можно посчитать по предполагаемому износу, цене б/у комплектующих и цене аналогов.

2. За сколько минимум его могут продать. Надо посмотреть на ситуацию их глазами: они распродают оборудование, не хотят возиться и готовы на быструю сделку.

Разница между вашей максимальной ценой и их минимальной — это и есть ZOPA. То есть Zone of Possible Agreement, или зона возможного соглашения. Это пространство между вашей точкой ухода и точкой ухода продавца, то есть диапазон, в котором торговаться вообще имеет смысл.

ZOPA существует, если максимальная цена покупателя ВЫШЕ или равна минимальной цене продавца. Если нет — сделка невозможна.

Вам надо:

— Понять, существует ли ZOPA вообще.

— Постараться выяснить границы ZOPA (особенно точку ухода оппонента).

— Добиться результата внутри ZOPA, который будет максимально близок к вашей цели.

Вторая важная концепция — BATNA. Это лучшая альтернатива. Например, если вы идёте к руководителю на переговоры по повышению зарплаты, возможно, надо выяснить Best Alternative. Если вы придёте просто так, с аргументом «я хорошо работаю», ваша лучшая альтернатива — остаться на текущей зарплате. Это слабая BATNA. Но если вы придёте с офером от другой компании на 30% выше, ваша BATNA — это переход на новую, высокооплачиваемую работу. Либо вы выбесите руководителя и эйчара, либо покажете, что есть чёткое основание, куда торговаться, и ваша ценность на рынке подтверждена.

Вы можете управлять BATNA, добавляя что-то в сделку, например, «В этом году я активно менторил джунов, так как никто из коллег не мог выступать наставником. В другой компании за менторство мне предложили +15% к окладу, но я бы хотел обсудить новые условия нашего с вами сотрудничества». В общем, давайте покопаемся ещё немного в теории игр на практике. В том числе про то, как готовиться к переговорам по зарплате.

Каждый январь нагрузка на инженерные команды растёт. Больше функций, ускоренные релизные циклы, повышенные требования к надёжности. Ваше новогоднее обещание наверняка звучало как «работать умнее, а не усерднее», но обычно это лишь утешительное клише, которое мы повторяем себе прямо перед тем, как снова засидеться допоздна, чиня сломанный пайплайн.

В 2026 году «работать умнее» наконец-то означает подключить агента к процессу.

Не для автодополнения. Не для подсказок. Для исполнения.

Вы описываете, что вам нужно, простым языком. Claude Code читает вашу кодовую базу, пишет продакшн-код, запускает тесты и интегрируется с вашими инструментами. Вы тратите меньше времени на шаблонный код и больше - на архитектурные решения.

Это руководство покажет вам, как строить реальные системы с Claude Code.

Есть две категории программистов. Первая пишет тесты, вторая работает. Шутейка, конечно, на троечку, но в каждой байке, застрявшей в пабликах мёртвых заархивированных форумов, под пылью и нафталином, — можно нащупать слой гранита настоящей правды. Модное ныне «покрытие кода тестами» напоминает попытку оклеить айсберг новогодней мишурой — вроде и весело, но Титаник все равно пойдет на дно.

Я собираюсь рассказать о том, как правильно тестировать код в изоляции (интеграционные тесты — зверь из соседнего вольера, и о нем — в другой раз). Для этого нам потребуется пара определений. Фаззинг (от английского fuzzing) — это способ тестирования, при котором программе скармливают огромные объемы случайных, полуслучайных или вообще намеренно испорченных данных, с надеждой выявить уязвимости или баги. Изначально этот метод применялся в академической среде для поиска дыр в безопасности, но быстро перекочевал в руки здравомыслящих разработчиков. Property-based testing, в свою очередь, представляет собой подход к тестированию, где вместо проверки конкретных примеров типа «дважды два — четыре» мы формулируем общие свойства системы. Например: «если функция принимает список и возвращает список, то длина результата не должна превышать длину входа». А дальше уже инструмент генерирует тысячи, миллионы вариантов входных данных и проверяет, соблюдается ли это условие.

Бывает так: специалист закрывает сложные задачи, подхватывает чужие таски и выруливает релизы в срок. В трекере у него больше всего задач, к нему тянутся коллеги за помощью. Но когда речь заходит о повышении зарплаты или грейда — его фамилию даже не вспоминают. Через какое-то время появляется ощущение несправедливости и вопрос: «Что ещё нужно сделать, чтобы меня наконец заметили?».

Меня зовут Яна Шаклеина, 8 лет в ИТ. Начинала карьеру как разработчик, работала в сопровождении, потом начала всё совмещать с обязанностями руководителя. Не с первого раза, но получила руководящую должность и сейчас работаю CPO в Outlines Tech. Делюсь опытом со стороны исполнителя и руководителя, каких специалистов не повышают и почему, даже если они объективно лучше других, и что с этим можно сделать.

За прошлый год я запустил 5 сервисов с LLM под капотом. Каждый следующий сервис получался лучше предыдущего: мы оттачивали архитектуру, оптимизировали core микросервиса на FastAPI, быстрее выходили на MVP и ловили меньше багов.

Но довольно быстро стало понятно: LLM‑сервисы сложно интерпретировать. Для бизнес команды они выглядят как black box. Для инженеров — как набор плохо воспроизводимых состояний.

В этой статье я поделюсь практиками, которые:

— упрощают интерпретацию поведения LLM;

— делают работу сервиса прозрачной для Product Owners и SME;

— ускоряют разработку и итерации без передеплоев.

В компаниях с несколькими продуктами знания о коде и архитектуре почти неизбежно расползаются. Часть живёт в репозиториях, часть — в статьях с архитектурными решениями, часть — в корпоративной базе знаний (в нашем случае — Confluence). На небольшом масштабе это выглядит как порядок. Но по мере роста начинают проявляться системные эффекты.

Появляется дублирование функционала с разными подходами. Сложнее становится погружаться в новый продукт при кросс-командных переходах. Поиск по каждому репозиторию и каждому пространству документации по отдельности — медленный и утомительный. В итоге вопросы уходят к «знающим людям», которые постепенно превращаются в узкое горлышко.

Мы столкнулись с этим в явном виде и сформулировали задачу так: дать разработчикам и системным аналитикам быстрый и актуальный поиск по всей кодовой базе компании с возможностью диалога через универсального агента.

В этой статье я расскажу, как мы построили локальный RAG-сервис, оформили его как MCP-сервер и подключили к IDE. Подход будет полезен командам с большим количеством репозиториев, внутренней документацией и требованиями к безопасности.

Использование чужих графических наработок может привести к суду. Таких примеров — масса. Расскажем о самых примечательных.

Поиск работы — это процесс, который ломает психику.

Ты можешь быть крутым сеньором, знать кишки JVM или архитектуру Kubernetes, но чтобы получить оффер, ты вынужден играть в странную игру:

— Ну, чего ты копаешься! Иди быстрей!
Малыш изо всех сил пытается успевать своими мелкими бегом за размашистыми шагами молодой мамы. Личико превращается в глаза, полные слёз и тревоги.

— Не видишь, я занят! – говорит молодой папа, на секунду отвлекаясь от смартфона к подбежавшей дочери-дошколёнку. На лице девочки радость моментально осыпается в печаль. – Я же говорил – если я читаю – не нужно меня отвлекать!
Дочь, опустив голову, плетётся в песочницу.

В дикой природе у детёнышей зверей возможны четыре сценария отлучения от родителей:
1. детёныш-зверёныш родился слабым и зверомама сама выталкивает его из норы или гнезда, сберегая ресурсы – еду и своё внимание – для здоровой части потомства. Слабый – значит не годен!
2. зверёныш получил травму, которую мама не может вылечить. Царапину она может зализать, а перелом – нет. Простудившегося малыша мама может отогреть, а от серьёзной болезни у неё таблеток нет. Немощный – не годен!
3. зверёныш отстал от мамы, уводившей потомство от угрозы. Или, к примеру, обезьяныш, уцепившийся за маму, не удержался, пока она скакала с пальмы на пальму. Хилый – не годен!
4. мать не вернулась в нору, в гнездо. Она погибла или, по каким-то причинам решила не возвращаться. Такое бывает в природе, например – она слаба и не может выкормить потомство. Табло загорается и в этом случае:
— Я не годен, поэтому мама меня бросила!

Во всех четырёх сценариях детёныши-зверёныши погибают – от голода, болезней или хищников.
Поэтому разлука с матерью – самый сильный страх у всех детёнышей. В их сознании чётко отпечатано – разлука=смерть.

Моя прошлая статья об уроках развития стартапа в Кремниевой Долине внезапно набрала больше 80к просмотров за неделю – поэтому пишу продолжение! Напомню, что в прошлом году я завершил семилетнюю историю своего стартапа (AI writing assistant): $1.35 млн инвестиций, 300 тысяч пользователей и экзит в компанию-единорога.

Но за фасадом сделки скрывались пару лет «идеального шторма»: падение выручки, потеря второго бизнеса и неприятный развод. В этой статье я расскажу, как управлял жизнью во всем этом хаосе, используя всего один Google-док вместо сложных систем.

А чтобы материал стал еще полезнее, в начале я собрал хаки от Джесси Итцлера — серийного предпринимателя, ультрамарафонца и просто миллиардера (продал компании Баффету и Coca-Cola). 

Его метод неплохо дополняет мой и построен на тех же принципах. Поехали!

Продолжение статьи о разработке стекового процессора с оригинальной архитектурой.
Здесь мы занимаемся инфраструктурой - ассемблером, компилятором С и эмулятором процессора.

Про функцию Аккермана тоже будет, она используется в качестве теста.
Уж извините за кликбейтный заголовок.

Эту фразу из "Макбета" Шекспира автор осмелится перевести как "благодаря зуду на кончиках моих пальцев может появиться что-то очень странное".

Изначально хотелось всего-лишь ознакомиться с Verilog, но, "опасное это дело, выходить за порог: стоит ступить на дорогу и, если дашь волю ногам, неизвестно куда тебя занесет".

Занесло в сторону процессора с собственной архитектурой. Автор давно неровно дышит в сторону стековых процессоров, здесь так же присутствуют раздельные конвейеры для потоков управления/исполнения и расширяемая упаковка кода.

Надеюсь, это окажется кому-то полезным, так же как когда-то автору был полезен игрушечный hoc из книги Кернигана и Пайка "Unix - программное окружение".

Дисклеймер. Хотя в статье представлены некоторые наработки, она не претендует на готовое решение. Её цель — описать идею и подход к созданию открытой библиотеки, а также привлечь внимание к проблемам, с которыми сталкиваются разработчики игр. Автор является профессиональным программистом, однако разработка игр остаётся для него областью хобби.

Продумывая программную архитектуру различных прототипов игр на Unity 3D, решил поделится рядом соображений и заодно структурировать, и описать свой подход к реализации архитектуры. Конечно, очень редко можно договорится о соблюдении некоторой архитектуры при разработке. Тут как правило две проблемы в описании архитектуры как законченной сущности, и её понимании другими.

Нам потребуется многослойное понимание проблемы, к сожалению, язык последовательно синхронный и не позволяет сразу дать всесторонние описание. Но начнем мы с более простого, с описания частной проблемы, концепции класса AgentPoint, для глубины понимания я буду давать ссылки, изучение которых позволит понять проблему детализировано. В статье же скорее останется лишь легковесное описание, не рассчитывайте на глубокое понимание, если не пройдете по ссылкам. Но тем не менее я попробую, основы объяснить прямо тут.

История с тем, что украинский президент установил на 7 января «День программиста» слегка взбудоражила общественность, но не с той стороной, которую я считаю самой интересной.

Вобщем, сперва будет рассказ о том, откуда берутся всякие там «Международные дни» и какова их ценность, а затем будет вопрос, на который я не смог найти ответа.

Представьте: вы пишете "перезапусти продакшн-сервер" в Telegram, и система не просто понимает запрос — она знает, какой именно у вас сервер, что на нём запущено, кто будет затронут простоем, и предлагает конкретный план действий. Без панелей управления, без SSH, без поиска в документации.

Это не шизофреническая фантазия. Это ICNLI (Infrastructure Contextual Natural Language Interface) — открытый стандарт, который мы разработали и уже внедрили в production на десятки серверов.

Представьте ситуацию: вы выбираете между Intel Core i9 и Apple M2 (как пример двух мощных систем). Один потребляет 300 Ватт и греется как печка, другой — 30 Ватт и работает от батареи 20 часов. Один показывает 200 FPS в играх, другой — 90, но в три раза эффективнее. Один стоит $600, другой — встроен в ноутбук за $2000. Кого вы выберете?

С Новым Годом и добро пожаловать в Gas Town!

Gas Town - это новый взгляд на IDE для 2026 года. Gas Town помогает вам справиться с рутиной запуска множества экземпляров Claude Code. Вещи теряются, трудно отследить, кто чем занимается, и так далее. Gas Town помогает со всей этой рутиной и позволяет вам сосредоточиться на том, над чем работают ваши Claude Code.

В этом посте "Claude Code" означает "Claude Code и все его идентичные конкуренты", то есть Codex, Gemini CLI, Amp, Amazon Q-developer CLI, бла-бла-бла, потому что именно этим они и являются. Клоны. Индустрия - это постыдная детская футбольная команда, гоняющаяся за форм-фактором CLI Claude Code образца 2025 года, вместо того чтобы создавать то, что будет дальше.

Я пошел вперед и создал то, что будет дальше. Сначала я предсказал это еще в марте в статье Месть начинающего разработчика. Я предсказал, что кто-то свяжет верблюдов Claude Code вместе в колесницы, и это именно то, что я сделал с Gas Town. Я приручил их настолько, что вы можете продуктивно использовать 20–30 штук одновременно на постоянной основе.

Gas Town имеет свое мнение - во многом как Kubernetes или Temporal, на которые Gas Town похож, по крайней мере, если прищуриться так сильно, что глаза почти полностью закроются. Я включу сравнения как с k8s, так и с Temporal в конце этого поста. Немного удивительно, насколько они похожи, несмотря на радикально разные основы.

Но сравнение должно служить предупреждением: Gas Town сложен. Не потому, что я этого хотел, а потому, что мне приходилось добавлять компоненты до тех пор, пока он не стал самодостаточной машиной. И те части, которые у него теперь есть, ну, они выглядят так, как будто Kubernetes спарился с Temporal, и у них родился очень уродливый ребенок.

Но это работает! Gas Town решает проблему MAKER (Ханойская башня из 20 дисков) вообще элементарно. Просто генерируешь по формуле "цепочку" на миллион шагов - и готово. Вчера ради интереса прогнал 10 дисков за несколько минут: доказал, что тысяча шагов для нас - это не проблема, хотя в статье MAKER говорится, что нейронки ломаются уже через несколько сотен. На 20 дисков закладываю часов 30. На этом мой импровизированный TED Talk окончен.

Все это обретет полный смысл, если вы дочитаете до конца следующих 23 страниц.