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

Система продуктивности Один большой текстовый файл 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, но все это было не то. Сформилировал требования, которые у меня есть:

Для тех, кто уже читал: переписана 2-я часть (после чёрточки).

Помните огромную школу английского English First (EF)? В нулевые в одной только Москве было больше ста филиалов. Цены были высокие, но бедные семьи буквально на последние деньги отправляли детей туда учиться. Такой бизнес был… чё ж развалились-то?

В последние годы своего господства EF стали символом некачественного преподавания. У репетиторов, которые непосредственно занимались реабилитацией пострадавших, «инглишфёрст» было ругательным словом. Плохие отзывы офлайн, восторженные – онлайн, реклама повсюду. Репутация догнала их и раздавила: в начале 20-х от былого хайпа оставалось лишь несколько филиалов.

В те же годы в Москве была популярна школа Speak Up. Тоже много сияющих офисов, дорого, бестолково + они прославились совсем уж нечистоплотными практиками отъёма денег у населения. После их закрытия был большой скандал, даже с коллективными исками.

Есть похожие истории про ещё существующие школы, но о них я помолчу.

Итого. Эти две школы ограбили невероятное количество людей, но годы идут, а ни особых комментариев, ни аналитических статей с серьёзным осмыслением произошедшего я как-то не заметил. Поэтому многие даже не поняли, что их ограбили – просто тихо решили, что «языки – не моё». Что это было? Как такое удалось провернуть?

В этих школах учились глупые люди? Не только. В них училось много умных людей, некоторые даже в обеих. В Москве вообще максимальная концентрация толковых, развитых людей: лучшие ВУЗы + лучшие специалисты исторически съезжаются, знакомых экспертов подтягивают с периферии. Дело не в критическом мышлении – им просто сказали то, что они хотели услышать. Нам всем ведь очень, очень хочется однорукого экономиста простых, понятных решений.

Исследователи «Лаборатории Касперского» опубликовали подробный разбор вредоносного ПО Argamal, распространяемого на специализированных ресурсах вместе с хентай-играми. Данная вредоносная кампания была обнаружена в этом году, хотя некоторые связанные с ней DLL-файлы существовали как минимум с 2024 года.

Игры с вредоносным довеском, как правило, заливались на публичный файлообменник, ссылки на который публиковались на тематических веб-сайтах. Распространялись они и через торрент-трекеры. Во всех случаях это был архив с полностью функциональной игрой, которая дополнялась модифицированной библиотекой ffmpeg.dll.

В конце цикла я прогнал скрипт по своим логам Claude Code и увидел число, в которое сам не сразу поверил. За 25 дней, с 24 апреля по 19 мая, я сжёг 17,4 миллиарда токенов. Один человек, 344 сессии, 75 587 ответов ассистента, 176 695 строк транскриптов. Посчитайте это по тарифам API, и выходит 39 651 доллар. Около 3,17 миллиона рублей. Примерно 1586 долларов в день. Почти всё это Opus, самая дорогая модель на рынке.

В этой статье мы начинаем погружение в одну из фундаментальных тем цифровой обработки сигналов (ЦОС) — дискретное преобразование Фурье (ДПФ). Именно ДПФ служит математической основой для понимания более сложных методов спектрального анализа и является отправной точкой для изучения всех остальных видов преобразования Фурье в ЦОС. Будет рассмотрено ДПФ действительных сигналов.

Материал построен так, чтобы объединить теорию, наглядные графики и практический код на Python.

Тема преобразования Фурье в ЦОС обширна и многогранна, поэтому я разбил материал на несколько частей. В первой части мы сосредоточимся на базовых принципах, интуитивном понимании алгоритма и его реализации.

Краткое содержание статьи. Часть 1

В ней поэтапно разбираются фундаментальные понятия, необходимые для понимания ДПФ:

Аналоговые и дискретные сигналы — краткое введение, объясняющее разницу между двумя типами сигналов. В статье используются только дискретные сигналы, поэтому эта тема кратко рассмотрена.

Корреляция и ортогональность функций — ключевые понятия, лежащие в основе ДПФ. Именно эти свойства позволяют разложить сложный сигнал на отдельные частотные составляющие.

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

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

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

Последние месяцы я гонял другой подход: не «чат, который пишет код», а AI-команда, которая закрывает полный цикл разработки — от формулировки задачи до выката на прод, с планированием, постановкой тикетов, код-ревью, тестами на dev-окружении и автоматическим деплоем. Между этапами ничего не разваливается, потому что система устроена примерно как нормальная команда людей, только роли играют саб-агенты.

В этой статье разберу архитектуру целиком: из чего она собрана, почему именно так, и где проходят границы, за которые я агентам выходить не даю. В качестве подопытного — мой pet-проект, обычный Telegram-бот на Go (MongoDB, Kubernetes). Что именно он делает — выходит за рамки статьи; важно, что это работающий продакшен с реальными пользователями, а не песочница.

Готовиться к Go-собеседованию по списку с GitHub — значит знать ровно то же, что знают все остальные. Интервьюеры это чувствуют сразу. В этой статье — 10 вопросов, которые реально задают на Golang Junior собеседованиях, с разбором так, как это объяснили бы вам после интервью на обратной связи.

Всем привет. Хотелось бы поделиться своей историей выпуска Android-приложения для изучения китайского языка.

С чего всё начиналось

Всё началось с того, что я как-то решил начать изучать китайский язык. Всё произошло неожиданно и рандомно. Для начала я решил поизучать, какие есть приложения и источники для изучения языка. Как оказалось, каких-то нормальных особо нет, тем более русскоязычных. На данный момент существуют различные приложения по типу HelloChinese, SuperChinese - они, конечно, классные, но стоят дофига денег. Без подписки они бесполезные. Лучше уж нанять репетитора за такие деньги. А если нет денег на репетитора, то можно достать старый добрый Anki. Я всегда ненавидел Anki за его неудобство, за кривой UX/UI, за долгое создание карточек и за слабое разнообразие. Поэтому я сразу понял, что с помощью Anki изучать мне будет сложно и неприятно. Поэтому было решено создавать своё приложение: без подписок, с интервальным изучением, с большим количеством тренировок и, конечно же, по большей части с офлайн-функциональностью. Было придумано название приложения - Abuchi.

Выбор технологий

Сам я Golang-разработчик, который перешёл с Java, поэтому изначально я думал выбрать обычный Kotlin. Однако из-за ненависти к Java/Kotlin всё же решил выбрать Flutter, так как мне там больше нравится синтаксис и в целом написание кода.

Начало разработки

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

Для тренировки произношения я решил использовать библиотеку Vosk, так как там есть легковесная модель под Android и в целом она работала лучше, чем тот же Whisper, если оценивать по характеристикам "размер-качество".

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

Но что общего между профессиональным спортсменом и человеком, который по 8–10 часов в день работает за компьютером? И почему боли в спине все чаще становятся проблемой даже у тех, кто далек от спорта? В этой статье расскажу, почему обратил внимание на E-station и какие особенности рабочей станции считаю важными с точки зрения врача-реабилитолога.

Перезалив. Хабр в очередной раз посчитал две ссылки на рабочий прототип рекламным объявлением - спасибо! Удалены все ссылки на продукт, за исключением исходников на githubе. Приятного чтения.

Зачем предприятия ведут учёт? Отчётность перед ФНС? Или может воронка клиентов? Сотни ответов российского рынка учётных систем на этот простой вопрос.

Какой толк от зелёной воронки лидов, каждый из которых в сухом остатке является убыточным? Какой смысл в причесанной отчётности без банального понимания рентабельности вашего дела?

Год назад я невольно стал заложником терзающих мой разум раздумий о смысле учётных систем. Так был написан первый, второй… пятый модуль мультитенантной ERP-подобной системы для малого бизнеса (Go + pgx | Next.js + TS), вопреки рынку ставящей именно модуль финансов в центр системы.