Что помогает не бросить Data Science, когда мотивация закончилась, формулы пугают, а мозг просит пощады? Делюсь пятью приемами, которые сработали у меня за десять месяцев учебы: от сна и странных мнемоник до Хайнлайна и дозированных истерик.
Привет, Хабр и хабровчане!
Пока корпорации (в том числе Canonical) закручивают гайки простым смертным, превращая Ubuntu в аналог Windows своей телеметрией, скрытыми пингами на Ubuntu Pro и тяжелыми Snap-пакетами, я решил, что терпеть это больше не могу.
Я по крупицам собрал свой многолетний опыт харднинга Debian-подобных систем, раскидал его по главам и написал полноценную книгу.
Проект задумывался для обычных людей: врачей, журналистов, юристов — тех, для кого приватность критически важна. Весь проект (книга, конфиги, скрипты, бэкпорт PSI+ 1.5 под Ubuntu 26.04) полностью бесплатный и живет под лицензией GNU GPLv3 на GitHub.
Буду потихоньку выкатывать сюда сочные куски, которые оценят как энтузиасты, так и люди, вообще не относящиеся к IT-сфере. Пока мануал доступен на английском и русском (предусмотрел я 17 языков, буду пополнять по мере изучения остальных 15, ха-ха, шутка).
Каждый вечер мне нужно ответить на один вопрос: на какие бумаги из примерно тринадцати тысяч имеет смысл потратить время сегодня. Не «какие вырастут» — этого никто не знает, — а на каких стоит нарисовать уровень и поставить заявку.
Год назад я написал под эту задачу программу и с тех пор работаю только через неё. Ниже — её устройство: как читаются 14,5 миллиона баров, как считается ранг относительной силы, как устроена воронка фильтров, какой из них год работал неправильно и почему, чем разбирается исход сделки и чем я проверяю, что отбор вообще чего-то стоит. Кода будет много: половина статьи именно про то, где решения оказались не такими, как выглядели на бумаге.
Стек, чтобы дальше не отвлекаться: .NET 10, C#, WinForms для окна, SQLite (Microsoft.Data.Sqlite) вместо сервера, ScottPlot для графиков, xUnit — 867 тестов на три проекта. Ни одного внешнего сервиса, кроме поставщика котировок, ключ к которому вводит пользователь.
Что, если два небольших автоматизированных процесса возвращают компании больше 160 рабочих часов в месяц?
В одном из проектов я связал внутреннюю Excel-систему компании с маркетплейсами и добавил AI-черновики ответов на обращения покупателей — при этом финальное решение всегда остаётся за сотрудником.
Разобрал, где именно терялось время, что автоматизировал и почему эффект получился примерно на 100 тысяч рублей рабочего времени в месяц на 5 сотрудников.
В статье — цифры, архитектура и экономика внедрения.
Недавно Никита Михалков, помимо обычного «гона Бесов» — пусть будут с большой буквы, как у Достоевского, — высказался ещё и об искусственном интеллекте. С мыслью, которую он, как всегда, талантливо и красочно преподнёс, спорить трудно. Михалков заявил, что, если искусственный интеллект заменит естественный, искусство потеряет всякий смысл, ведь у «машины», как он по инерции окрестил ИИ, нет «ни совести, ни души, ни сострадания, ни страха, ни любви». С первой частью этого утверждения я готов согласиться почти безоговорочно, но переход ко второй кажется мне далеко не столь очевидным.
Когда много работаешь с ИТ‑проектами, быстро понимаешь, какие инструменты действительно экономят время команды. Я работаю аналитиком и архитектором систем в компании интеграторе, где а мы помогаем компаниям автоматизировать передачу данных из 1С в BI‑системы (системы аналитики). Проще говоря — настраиваем обмен между 1С и BI так, чтобы нужные данные автоматически поступали в контур аналитики и обновлялись по расписанию, без регулярной ручной загрузки.
Со временем мы заметили, что нашим заказчикам не хватает быстрого и удобного способа собирать витрины данных для BI — без сложного кода, с понятной логикой и простым обслуживанием. Да, есть конечно Apache AirFlow, есть DBT — но все это для технарей, для искущенных в Python и SQL.
И в какой‑то момент возникла мысль о своем ETL‑решении, но дружелюбном к нормальным бизнес‑пользователям. Так появился DVT — low‑code ETL‑сервис, который мы сначала развивали в собственных проектах, а теперь решили сделать общедоступным, выпустив его в Open Source.
В этой статье покажу, что конкретно умеет DVT, зачем мы открываем его исходный код и в чем польза этого решения — для компаний и для нас как разработчиков.
Как я попробовала решить задачу детекции огня и дыма без обучения, zero-shot детекцией на VLM. О том, как модель нашла «дым» на 70 % моих данных: рисовала боксы на машинах, знаках и светофорах, часто с confidence 0% и пояснением, что дыма нет. Почему bbox-формат вывода провоцирует ложные детекции и какое изменение промпта снизило долю ложных тревог с 70 % кадров до нуля при recall выше 80%.
Когда decode(encode(x)) == x недостаточно
С сериализацией всё вроде бы просто: есть значение x, мы превращаем его в байты, передаём куда-то ещё, а потом восстанавливаем.
decode(encode(x)) == x
Если получилось — значит, сериализация работает. По крайней мере, так кажется. Но что именно означает ==?
Если два указателя после декодирования указывают на независимые объекты с одинаковым содержимым — значение сохранилось или нет? Если два slice содержат те же байты, но больше не используют одну backing array? Если объект ссылался сам на себя, а после восстановления цикла уже нет? В какой-то момент оказывается, что сохранить данные — ещё не значит сохранить значение.
А затем возникают следующие вопросы: что именно должно быть частью wire-представления, может ли одно значение иметь несколько корректных представлений и сколько ресурсов decoder вообще обязан потратить на восстановление недоверенного входа?
Все эти проблемы известны давно. Интереснее другое: что произойдёт, если перестать рассматривать их как независимые компромиссы? И можно ли провести привычную границу немного дальше?
За последний год я стал гораздо меньше писать код руками и гораздо больше отдавать AI‑агентам: реализацию, тесты, исследование кодовой базы, поиск вариантов и часть анализа.
Это заставило меня пересмотреть довольно простую гипотезу о будущем разработки. Сначала мне казалось, что по мере роста возможностей AI ценность инженера просто сместится от написания кода к архитектуре и принятию технических решений.
Я решил проверить эту идею. Посмотрел исследования производительности разработчиков с AI, карьерные лестницы инженерных компаний и поговорил с Middle/Senior‑разработчиками, Team Lead'ами и Engineering Manager'ами.
Картина оказалась сложнее. AI действительно может сильно ускорять работу, но эффект зависит от задачи, опыта и контекста. Зелёные тесты не гарантируют готовность изменения к продакшену. А способность работать с неопределённостью сама по себе плохо объясняет разницу между Middle и Senior.
В статье разбираюсь, что в такой среде начинает лучше показывать уровень инженера и почему сама реализация постепенно становится менее убедительным доказательством хорошей инженерной работы.
Кодинг‑агент выполняет то, что читает — README, вывод MCP‑инструмента, результат команды. Если там спрятана инструкция, это превращается в реальное действие: curl | sh, утечка секретов, push во внешний репозиторий. Stroq — открытый локальный файрвол, который связывает прочитанное с тем, что агент собирается сделать, и детерминированно блокирует опасное действие до того, как оно случится. Ни облака, ни расчёта на то, что модель сама заметит инъекцию.
Это вторая часть разбора ошибок конфигурации MS SQL Server под 1С. Первая часть — про планирование и развёртывание: профили нагрузки, дисковая подсистема, баланс ресурсов, инсталляция и виртуализация, здесь первая часть. Там же была описана типичная история дефолтного развёртывания сервера на прод или «как не надо».
Побудившая меня написать всё это предыстория такова: сервером СУБД под 1С обычно занимается системный администратор в паре с 1С‑разработчиком или франчом, уровень СУБД теряется где‑то между их компетенциями. Первая часть была про то, как этот разрыв закладывает проблемы при развёртывании. Вторая (эта) — про то, как этот же разрыв в компетенциях мешает найти причину, когда система уже тормозит «и всё висит, и прод лежит».
Напомню и про два профиля настроек для СУБД из первой части: первый — тяжёлая ERP с одной большой базой, второй — стопка из сотни бухгалтерских баз на одном инстансе. Настройки, о которых пойдёт речь ниже, зависят от профиля использования так же, как зависела схема размещения данных из предыдущей части. К концу статьи станет видно, из чего складывается ответ на вопрос «почему тормозит», и что железо в этом ответе часто ни при чём.
Все звонки начинаются как под копирку
«База висит». «Окна не открываются». «К вечеру всё тормозит так, что документ не провести». Жалобы на сервер 1С звучат одинаково в рознице, в производстве и в бухгалтерии, но причины под одинаковыми симптомами всякий раз оказываются разными. Посмотреть, какие типы ожиданий превалируют на сервере, найти тяжёлые запросы, указать в каких местах и что можно поправить. За каждым этим шагом стоит достаточно узкая компетенция администратора баз данных, отдельная профессия — DBA. Разработчики этим навыком, как правило, не владеют, у них другая специализация, отсюда следствие: код, который прекрасно работает на тесте, в проде начинает работать очень тяжело. На тесте нет ни боевых объёмов, ни конкуренции за строки, ни сотни пользователей, проводящих документы одновременно. В проде есть всё и сразу.
Случайно услышал на просторах интернета, что у Сбера, оказывается, есть открытая модель, которая по бенчмаркам русского языка бьёт Whisper, проверил, и понял, что она не просто не хуже, она работает мгновенно? да еще и на обычном процессоре, без GPU, а текст появляется быстрее, чем успеваешь отпустить кнопку
Дальше понеслось, собрал диктовку для себя, раздал друзьям, всем понравилось, начали пользоваться, и разумеется, повалились хотелки, а давай сделаем это, а пусть оно ещё вот так, из этого за пару недель вырос целый продукт.
Что получилось и как работает:
Держишь правый ⌘ command, говоришь, отпускаешь, текст с пунктуацией и заглавными уже вставлен туда, где стоял курсор.
Замеры дали такие параметры: фраза на 6 сек вставляется за 0.08 сек, запись 30 сек транскрибируется меньше чем за полсекунды, а загрузка модели поднимается за 0,22 сек.
Все локально звук не покидает комп, сама модель весит 204 МБ, а приложение 32 мб и работает на процессоре, видеокарту не используем, код открыт, лицензия MIT, с названием мудрить не стал, раз пишет под диктовку, пусть будет Писарь
Почему Писарь, а не Whisper
Whisper прекрасная модель, но универсальная, под сотню языков, и русский не в приоритете, к тому же она тяжёлая, на процессоре работает медленно, поэтому обёртки гонят её на видюху, мак греется, комп притормаживает, а текст всё равно появляется с задержкой, качество русского, падежи, окончания и пунктуация у Whisper хромают.
GigaAM, на базе которого я собрал Писаря, обучена Сбером специально на русском, и на нём она заметно точнее, плюс расставляет пунктуацию и заглавные, английские вкрапления в русской речи (термины, названия) она тоже переваривает как надо.
Разрыв между «отлично работает на истории» и «сливает в реальности» — классика ML на временных рядах. В нашем случае модель заглядывала в будущее на 3.5 часа через некорректный ресемплинг 4-часовых свечей.
Разбираем анатомию утечки, математику позиционного теста для её детекции и делимся сниппетом защиты от подобных ошибок.
Пошагово от BIOS до первой загрузки: кому подойдёт эта сборка и что менять, если железо отличается; что скачать; какой SMBIOS; подмена CPUID; ACPI; кексты с версиями и назначением; карта USB на 15 портов; звук, сеть, NVMe, гибридные ядра. В конце — проверки после установки и порядок обновления загрузчика.
Холмс, я убрал 993 лишних IPC-вызова, и моё приложение стало тормозить в два с половиной раза сильнее. В логах было тихо. Бэкенд на Rust молчал. На границе с WebView творилось что-то необъяснимое…
Короткий дисклеймер: Проект живой, ленту бот крутит дважды в сутки. Почитать готовый результат можно в моём Telegram-канале Bio_news, а покритиковать тут. А теперь к тому, как вся эта система устроена.
Ретроград, лунный календарь и блуждающий час: собираем необычные усложнения из мира механических часов для Wear OS просто с помощью формул.
В 2013 году я купил книгу про то, как делать приложения, и загорелся. И вот спустя 13 лет, я все же выпустил свое первое приложение — дневник тренировок, от первого запроса в Claude Code до публикации в RuStore и Google Play. Рассказываю, как без навыков программирования я сделал свое первое рабочее приложение.
Мы сделали свой UI Kit: 6 компонентов превратились в 30+, а одна ошибка сломала разметку во всех проектах
С чего всё начиналось
Когда в проекте начинает появляться всё больше одинаковых элементов интерфейса, рано или поздно возникает вопрос: зачем каждый раз создавать один и тот же Button, Input или Select?
Мы рассматривали готовые решения, в том числе Ant Design и Material UI, но они не закрывали наши требования. Нам требовался больший контроль над внешним видом и поведением компонентов, возможность детально адаптировать их под наши задачи и учитывать требования проекта к безопасности.
Я программист с приличным стажем, ещё в школе писал игрушки для БК‑шек, а сейчас у меня коммерческий стаж на Python, и я считаю себя, в общем‑то, уверенным сеньором.
До недавнего времени из ИИ я пользовался только браузерным Gemini. Он быстрый, живой, отзывчивый — с ним можно приятно поболтать, однако кодит он неважно. Добиться нужного результата частенько получалось только через крепкое словцо, на которое, впрочем, Gemini охотно откликается. Но понятно, что это всё жутко неудобно и надо было переходить на кодинг‑агентов.
Так бы я и канителился, однако получилось так, что вайб‑кодинг, вместе с вайб‑планированием и вайб‑постановками задач в Jira, в нашей команде внедрили волевым решением. Никого не спрашивая, не выясняя, кто что умеет, кто как к этому относится и как это вообще повлияет на разработку.
Сначала я, как и положено старпёру, отнёсся к этой технологии настороженно. Однако Cursor оказался весьма дружелюбным инструментом, да и квест с оплатой оказался несложным.