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

Каждый раз, когда нужно передать кому-то файл или пароль, выбор бесит: WeTransfer и аналоги видят всё, почта и телеграм хранят файл в плейнтексте вечно, PrivateBin только для текста. Хотелось простого: бросил файл, получил ссылку, а сервер физически не может его прочитать. И чтобы сервер был мой. Так появился share·me, self-hosted сервис, который шифрует файлы и текст прямо в браузере (AES-256-GCM), а ключ кладёт в URL-фрагмент, который браузер никогда не отправляет на сервер. Внутри: Rust/axum, Next.js, потоковое шифрование больших файлов и пара граблей, на которых я споткнулся.

10 новых российских продуктов для цифровизации работы клубов и сообществ, умного поиска с ИИ для интернет-магазинов, установления прямых контактов с клиентами, анализа и управления корпоративными знаниями, мягкой нейрокоррекции для детей и взрослых и многого другого. Битва за «Продукт недели» началась!

Product Radar — здесь каждую неделю публикуются лучшие онлайн-сервисы и железки от русскоязычных команд.

Платёж не прошёл. Отключить пользователя сразу или подождать? Если подождать, то сколько и на каких условиях? Разбираем механику grace-периода изнутри: состояния подписки, поведение доступа для B2C и B2B, цепочку уведомлений и технические подводные камни.

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

Нашел простенькую сказку — «Колосок» — и стал искать, как в целом можно генерировать видео-контент своими руками.

Если вам было интересно погенерировать видео на открытых моделях и посмотреть, что из этого получится — эта статья как раз про это. Можно наглядно посмотреть результат

Anti-corruption layer в учебниках выглядит как одна аккуратная коробка между чужой системой и вашей: всё чужое остаётся снаружи, внутрь проходит только то, что уже переведено на язык вашего домена. Граница ровная, как по линейке. Почти за год, что мы вытесняли 10-летний Rails-монолит на .NET, такой ровной границы я не увидел ни разу – ни у себя, ни, кажется, у кого-то ещё на живом проекте.

Понятно это стало в первую же неделю. Мы открыли таблицу exercises и нашли в одной JSONB-колонке 14 разных форм одного типа задания, слепленных за 10 лет. Смаппить это в новые DTO как есть – и новая модель отрастит ровно ту же форму, что у Rails. “Нужен ACL”, подумали мы. Только, как выяснилось на практике, не один.

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

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

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

В прошлой статье про ГИГАХРУЩ мы показали игру как живой weird-проект: браузерный survival horror / ARPG без движка, ассетов и спокойной жизни.

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

Разберем, как ГИГАХРУЩ устроен под бетоном: один активный клеточный этаж, typed arrays, плоские сущности, WebGL raycasting, A-Life, самосбор как мутация мира, сохранение, ограничения и MESH PASS как render-only объем поверх клеточной симуляции.

В предыдущей части цикла разобрали 13 таблиц REDB: как устроены objects, values, structures, как RTTI-хранение значений отличается от старого EAV-паттерна, зачем нужен scheme_metadata_cache. Если не читали — начните с неё, без понимания схемы дальше тяжело.

В этой статье — то, что обычно идёт следующим вопросом: «А индексы где? У вас же значения всех полей лежат в одной таблице. Любой WHERE — это Seq Scan по миллионам строк».

Это статья 1.1, а не 2 — потому что она прямое продолжение разговора про физическое хранение. Глубокое погружение в C# — это статьи 3-5 цикла: Code-first схемы (SyncSchemeAsync<T>), CRUD (SaveAsync/LoadAsync), LINQ-транслятор. Здесь разговор остаётся в плоскости БД и DDL.

Цифры, на которые опираемся, — с реального прода: TSUM, логистическая система, обслуживает движение грузовиков и заказов через РЦ.

В предыдущей статье я рассказал, как писал скрипт мониторинга системы с нуля от идеи до рабочего инструмента с меню, цветным выводом и уведомлениями в Telegram. Там же выяснилось, что большинство проблем при написании bash-скриптов возникает не из-за сложной логики, а из-за незаметных ошибок: забытых токенов-заглушек, тихих падений через pipe, команд которые молча возвращают не то. Именно тогда я понял, что echo для отладкиэто каменный век.

Скрипт мониторинга написан и работает. Теперь поговорим о том, что делать, когда он перестаёт работать или ведёт себя странно. Я собрал инструменты и приёмы, которые реально меняют то, как работать с bash. Не абстрактный список из документации, а вещи которые я использую сам и которые несколько раз спасали в ситуации «скрипт упал на проде, надо найти за пять минут».

Для тех, кто спешит: быстрая шпаргалка

Система продуктивности Один большой текстовый файл OBTF - исследуем какие фишечки можно навесить концепцию в эпоху ИИ.

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

Привет! Меня зовут Дмитрий. Я делал несколько проектов в разных сферах, но все они заканчивались на стадии MVP, хоть и по разным причинам: идея стала никому не нужна, команда выгорела или не хватило скиллов довести до результата.

Поэтому новый проект я начал с намерением дойти до реального работающего продукта с клиентами.

Первое с чего я начал — поиск идеи. Тут есть разные подходы, но один из тех что точно работает: решить боль свою или кого-то из близкого окружения. И если таких людей будет много, то идея стоит усилий.

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

Большинство этих примеров родилось в эпоху до C++11, когда у языка ещё не было ни умных указателей в стандарте, ни move-семантики, ни constexpr, ни концептов, и приходилось руками собирать из шаблонов и перегрузок некоторые кострукции, которые в более поздниях стандартах язык даёт почти бесплатно. Многие идиомы, примеры и идеи стоит читать в двух смыслах сразу, как исторический артефакт, объясняющий «почему старый код выглядит вот так», и как живой приём, который всё ещё применяется в движках и играх.

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

Когда я собирал оглавление Game++, раздел про идиомы, идеи, паттерны и механизмы C++ планировался шестым и завершающим, и должен был занять страниц сто, по одной на каждый пункт, но чем дальше я собирал материал, тем яснее становилось, что каждая секция тянет за собой историю, а каждая история требует контекста, а каждый контекст в игрострое никогда не бывает простым. В итоге текст разросся до размеров, при которых он просто сломал бы структуру книги, и мне пришлось выбирать между «урезать до неузнаваемости» и «отпустить жить отдельно». Пришлось выбрать второе.

Перед вами то, что могло бы стать половиной Game++, но стало самостоятельным материалом. Здесь собраны идиомы, идеи, паттерны и механизмы C++, которые сложились в сообществе за несколько десятилетий и продолжают жить в кодовых базах игровых движков, иногда под своими именами, иногда под другими, иногда вообще без имён, потому что их давно перестали объяснять. У большинства имена все же есть, есть и история с ответом почему именно так, а не иначе.

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

Как обычно, я сидел и думал, как бы уменьшить расходы токенов в Claude Code.. Рефлексировал содержимое сессий, исследовал вместе с самим Claude Code и наткнулся на интересную штуку.
Сначала я было хотел написать свой писатель файлов из под клода, вместо Write. Но подумал, что это будет слишком напряжно, если делать это в клоде, поддерживать, и так далее.
Но для редактирования файла его надо читать(обязательно! Как минимум в Claude Code) - что логично. Вопрос: а сколько его надо читать? Конкретно сколько строк его надо читать? Теоретически весь? А практически? Для замены, к примеру, одной строки?!
И да, Read читает по-разному, Но всегда больше одной строки(мелкие файлы читаются за один Read)..Ок, а обязательно ли для редактирования читать весь файл(или куски)? И вот вот тут-то нас ожидает сюрприз! Для снятия "защиты" файла от редактирования (в сессии Claude Code) достаточно прочитать ОДНУ строку указанного файла:):)
Если у тебя есть средство поддержки актуальности теста файла(я намекаю на code-index), то снятие гейта в модели будет выглядеть примерно как:

(кусок кода сессии)

Read C:\MCP-Servers\code-index\Cargo.toml (lines 2-2)

Read C:\MCP-Servers\code-index\CHANGELOG.md (lines 2-2)

Read C:\MCP-Servers\code-index\CHANGELOG_EN.md (lines 2-2)

Read C:\MCP-Servers\code-index\README.md (lines 2-2)

Read C:\MCP-Servers\code-index\README_RU.md (lines 2-2)

(это я готовил к выкладке очередной апдейт code-index.
Почему (2-2)? Сам не знаю, в промте указано (1-1), но везде модель ставит 2-2. Тайна сия великая есть:)).

И потом просто в темпе пулемета вызываются команды Edit.

Следовательно, в контекст тебе НЕ сыпятся куски файлов(которые тебе не нужны), и контекст остается максимально чистым.

Как сделать изменения, вносимые с помощью LLM, управляемыми, проверяемыми и воспроизводимыми.

Программные ассистенты LLM продемонстрировали значительную ценность, но в основном для отдельных разработчиков. Внутренняя ИТ-организация Thoughtworks использует их для своих команд и разработала метод и рабочий процесс, называемый структурированной разработкой на основе промптов (Structured Prompt-Driven Development, SPDD). В одноименной статье Вэй Чжан и Джесси Цзе Ся, опубликованной на сайте Мартина Фаулера, описывается простой пример этого рабочего процесса с подробностями на GitHub. Этот рабочий процесс рассматривает промпты как артефакт первого класса, хранящийся вместе с кодом в системе контроля версий и используемый для согласования разработки с потребностями бизнеса. Авторы обнаружили, что разработчикам для эффективной работы необходимы три ключевых навыка: согласованность, подход «сначала абстракция» и итеративный анализ.

Казалось бы, что все давно про экономическую безопасность написано, но хочется написать снова.

Казалось бы, сколько можно писать про ИИ, но здесь действительно помогло и гармонично влилось в процесс. При этом я убежден, что ИИ в большинстве случаев может сэкономить время, но не деньги, а половина красивых проектов (точнее рассказов про них) с ИИ - не окупились.

Когда мы говорим об успехе творческих проектов, часто обсуждают качество работы, талант автора или удачную идею.

Но на практике между созданием продукта и его признанием лежит огромный пласт задач, которые не имеют прямого отношения к творчеству:

В данной статье рассмотрена модель корабельного привода который состоит из дизельной установки, генератора и электродвигателя вращающего винт, модель построена с помощью Engee

Последние месяцы я наблюдаю одну и ту же картину. Бизнес массово бросился оптимизировать сайты под нейросети, число запросов по теме GEO-оптимизации в Wordstat за январь 2026 года выросло в тысячу раз год к году. Внутренняя аналитика Morizo фиксирует рост спроса на текстовую модернизацию сайтов на 27% за квартал. Пока весь рынок переписывает контент под ИИ-ассистентов, я предлагаю остановиться и задать неудобный вопрос: а вашему бизнесу это вообще нужно?

Звук сегодня является важным интерфейсом. Работа с чат-ботом своей "ИИшечки" упрощается в разы. Кроме того, помимо вайб-кодинга - есть еще и обычная жизнь - с совещаниями, лекциями, собраниями, которых столько, что не успеваешь фиксировать все, о чем было обсуждение. С этими мыслями, а также увидев потрясающий по своей внешней эстетике приборчик - был заказан ИИ-диктофон PLAUD. Но. Ограничения для России такие, что заплатить за сервис (ок 20 тыс. руб.) - не получилось. Но, уже появилось желание и даже потребность в удобном цифровом распознавании. Конечно, были установлены все простые приложения на телефон, а также распознавание в Telegram, но все это было не то. Сформилировал требования, которые у меня есть: