Картинка, приложенная к оригинальному посту. Заголовок "Китай сравнился с Антропиком в кибербезопасности, перезапустив ИИ-гонку". Остальной текст — вода.
Сладкий миф про очередное доминирование США в хайтехе продержался недолго, считанные месяцы. Очередной Deepseek-moment.
Напомню суть.
У США в подземных бункерах (ну как в кино голливудском, много полупрозрачных экранов и решительный негр с орденскими планками, требующими операцию на ключице) не только давно уже стоят самолёты 7-го поколения с боевыми лазерами, но и есть сверхмощные ИИ-модели, которые — если их выпустить наружу — всё стремительно перехакают и погрузят мир в хаос. Данное супероружие США сдерживают, потому что всех жалеют, ведь иначе суперИИ влёт найдёт по 157 уязвимостей во всём софте, сайтах и сервисах, всё автоматически переломает и наступит апокалипсис. Просто ребята из Белого Дома ответственные, добрые, жалеют остальных, отсталеньких таких да тупеньких.
Заход тупой и маркетинговый, придуман чтобы поддержать тезис об американском сверхдоминировании в ИИ-отрасли, видно это было сразу и по неуклюжим попыткам доказать сие (все демонстрации "смотрите как может" были то с оговоркой "у модели исходный код того что она ломает был", то с прочими подобными), и по алогичным тезисам "раз оно переполнение буфера в коде нашло то в интернете буквально на произвольный сервис издали натравить если, и номер порта выдать, то сто тысяч таких же сразу найдёт".
Ну а теперь аналогичную штуку выпустили китайцы, только с открытыми весами, для публичной эксплуатации. Уровня, достаточно для того, чтобы американские СМИ и исследователи сквозь зубы были вынуждены признать "ну примерно такое же, да, ну конечно послабее, но почти".
Такое убивает всю тему инвестиционной привлекательности, т.к. "у нас будет суперпродукт, весь мир будет сидеть на подписочках и к нам будут ежемесячно течь миллионы, а то и сотни миллионов тарифных выплат по 50-100-200 баксов, поэтому вот у нас такая капитализация, базирующаяся на потенциальной Ниагаре выплат" становится мифом. Циклопическая конструкция "в США будут датацентры за триллионы долларов, в них будут супермощности, и все будут платить туда, потому что ну а вариантов никаких, остальные-то отстали на 50-100 лет" натыкается на "массовый пользователь не будет, если есть примерно такое же, но на порядок-два дешевле".
Bugpocalypse откладывается; массовое IT получит возможность прогонять продукты через системы, выгребающие баги и уязвимости, без подсадки на рекуррентные платежи американским сервисам. Потенциальный эффект "сейчас супермодель выйдет и найдёт море дыр в продуктах, всё пропало, единственный вариант — купить у США доступ и проверить" сглаживается, местами до нуля.
Интересно какой новый миф для оправдания космических (хотя слово неправильное — на космос копейки идут на фоне вложений в ИИ-сервисы) хотелок и обещалок будет придуман. Как-то объяснять что всё это отобьётся по деньгам ведь нужно. Что вместо красивого "у вас всех просто ИИ, а у нас в тайном бункере сверхмегамонстрИИ-хакер, которого мы на цепях еле удерживаем" будет.
К вечеру шея колом, между лопаток тянет, поясница ноет. Знакомо каждому, кто проводит день за компом. Дальше сценарий один и тот же: лезешь гуглить, и интернет хором советует — делай гимнастику, разминайся каждый час, вот тебе пять упражнений для спины.
Совет правильный. И почти никто его не выполняет. Я не выполнял. Сейчас расскажу почему — и про то, что в итоге реально помогло.
Две крайности, между которыми пусто
Есть два полюса.
Слева — сидеть колом. Часами в одной позе. Тело не двигается, мышцы каменеют, к вечеру всё ноет. И вот тут главное недоразумение: болит не от «неправильной» позы, как принято думать, а от застоя. Врачи давно это формулируют просто: вредна не поза, вреден застой. Лучшая поза — следующая.
Справа — гимнастика. Встать, выделить время, сделать подходы. В теории помогает. На практике её забрасывают через неделю.
Между этими полюсами — пропасть. И именно в ней живёт решение, которое почти никто не проговаривает вслух.
Подвижность вместо гимнастики
Середина оказывается до смешного простой: просто не застывать. Не садиться по линеечке, не выделять время на зарядку — а почаще менять положение прямо в процессе работы. Откинулся, поёрзал, переложил ногу, потянулся за кружкой. Мелкие естественные движения, вплетённые в обычный день.
Это и есть подвижность. Не отдельное занятие, на которое надо себя загонять, а свойство того, как ты сидишь.
Почему это приживается, а гимнастика — нет
Вот тут самое интересное. Гимнастика держится на двух вещах, и обе предательски кончаются.
Первая — сила воли. Зарядка требует дисциплины. А дисциплину человек теряет ровно тогда, когда замотался и завален работой — то есть именно в те дни, когда сидит дольше всего и спина страдает сильнее. Система, которая работает только пока ты на пике ресурса, не работает вообще.
Вторая — время. Надо прерваться, встать, отвести минуты. Когда горит дедлайн, эти минуты выкраивать не из чего.
Подвижность не требует ни того, ни другого. Менять позу можно не вставая из-за стола, за пару секунд, не выпадая из задачи. Ноль воли, ноль времени сверху. Поэтому подвижность реально приживается, а гимнастика — нет. Дело не в том, что она «полезнее». Дело в том, что её реально соблюдать каждый день, а не первую неделю.
Одна загвоздка – память
В потоке работы ты не замечаешь, что застыл. Влип в задачу — и очнулся через два часа с деревянной шеей. Память тут плохой помощник: чем интереснее работа, тем глубже залипаешь.
Я долго пытался решить это банально — таймеры, напоминалки в телефоне. Не работает: таймер звенит, ты его смахиваешь и сидишь дальше. Он не знает, застыл ты или как раз потянулся минуту назад. Просто долбит по расписанию, бесит и идёт в игнор.
Хотелось, чтобы напоминало не по таймеру, а по факту: засёк, что реально не двигаешься, — тогда и пнул. Готового такого не нашёл.
Поэтому на выходных собрал себе сам: штука открывается в браузере, через веб-камеру замечает, когда долго не меняешь положение, и мягко подсказывает подвигаться. Видео никуда не уходит — всё считается прямо на твоём устройстве, наружу ничего не улетает. И показывает не дурацкий «процент правильной осанки», а сколько и насколько разнообразно ты за день двигался.
Силу воли и память забирает на себя программа. От тебя — просто поменять позу, когда подсказала.
Зачем пишу
Сделал в первую очередь под себя, шея реально стала к вечеру живее. Сейчас ищу таких же — кто день за компом и кого достало.
Если актуально и хочешь потыкать — пишите в комментах, скину ссылку.
Снова показываю как вести разработку «голыми руками» — без IDE, документации и даже интернета. На этот раз с помощью «пользовательской» Ubuntu Linux и OpenJDK.
Поскольку современные разработчики постоянно жалуются на завышенные требования технических интервью вообще и на мою «дурную практику» написания кода от руки в частности — показываю на личном примере как все это работает.
Жертвам «слабой памяти» посвящается.
Заодно узнаете как можно вести разработку на Java хоть в чистом поле — в самолете, в поезде или на закрытом объекте, без подключения к интернету и документации.
Видео
На этот раз для большего угара помимо статьи было записано и видео, где показан весь процесс «полевой разработки» на Java, с одним только JDK:
Для большей чистоты эксперимента был взят Live-образ Ubuntu Desktop 24.04.3 LTS, записан на флешку, флешка вставлена в один из рабочих ноутбуков, который затем с нее был загружен.
Таким образом получилась абсолютно чистая система, без средств разработки и с отключенной сетью.
Из инструментов у нас будет лишь текстовый редактор и JDK.
И все.
Что будем писать
Самое простое что можно написать в таких полевых условиях — реверс-шелл HTTP-сервер. На самом деле написать можно много чего, особенно если посмотреть в каталог demo внутри OpenJDK:
Набор демо-проектов из состава OpenJDK 24
Здесь и далее скриншоты из другой системы (Manjaro), чтобы не заморачиваться с их перебрасыванием из Live-системы и добавлением в статью. Тем не менее на видео все описываемые в статье шаги и весь код вбиваются каноничным способом — полностью вручную, на чистой системе, загруженной с Live USB.
Демо
Упомянутый выше каталог demo содержит набор довольно серьезных примеров проектов, которых вам вполне хватит для начальной стадии изучения или в качестве основы для какого-нибудь прототипа, особенно если никаких других инструментов и интернета — нет.
Так выглядит демо-проект Notepad, реализующий простейший текстовый редактор:
Окно отладки справа — часть демо‑проекта.
Так выглядит демо Metalworks, с простейшей реализацией мульти-оконной системы (MDI):
Обратите внимание на меню Theme, даже у демо-проекта есть скины!
Напоминаю, что вся эта благодать находится внутри стандартной поставки любой версии JDK, начиная с незапамятных времен 8й версии.
Все демо-проекты содержат исходный код в архивах src.zip и собираются без внешних зависимостей.
К сожалению каталог с демо иногда вырезается ментейнерами дистрибутивов линукса ради экономии места и переносится в отдельный пакет, который пользователи разумеется забывают установить.
Ручная разработка
В ролике в записи показано как автор последовательно вводит и запускает в работу примерно такой код:
// разумеется я не помню названий абсолютно всех // импортируемых классов, поэтому тут стоит '*' importjava.io.*; importjava.net.*; import java.util.concurrent.*;
publicclass MyWebServer {
staticvoid handle(Socket s) { // метод getId() устарел, поэтому его использование в // последних версиях JDK выдает предупреждение System.out.println("Thread: %d" .formatted(Thread.currentThread().getId()));
// самое сложное место, которое удалось повторить на записи // далеко не с первой попытки try(PrintWriter out = new PrintWriter(s.getOutputStream()); BufferedReader in = new BufferedReader( new InputStreamReader(s.getInputStream()));) { // поскольку используется чтение и запись строк а не байт - читаем // строку целиком, т.е. до символа \n String l = in.readLine(); // тут просто показываем в консоль System.out.println(l); // этим простым способом читаем только строку запроса, // которая идет первой, пропустив все заголовки // \r\n (пустая строка) - признак завершения запроса while (l==null || l.isEmpty() || "\r\n".equals(in.readLine()));
// тут мы 'в лоб' сравниваем строку HTTP-запроса целиком // так она выглядит до работы парсера if ("GET /test HTTP/1.1".equals(l)) { // поскольку мы реагируем только на один url '/test' // формируем ниже статичный ответ String data = "Hello from alex0x08 at "+ new Date(); // так выглядят стандартные поля ответа в 'raw' виде, без обработки out.println("HTTP/1.1 200 OK"); // 'close' дает указание браузеру разорвать соединение // с сервером сразу после получения данных out.println("Connection: close"); // поскольку мы отдаем строку - ставим MIME тип 'text/plain' out.println("Content-Type: text/plain"); // опционально отдаем размер данных out.println("Content-Length: " + data.length()); // пустая строка - признак начала блока с данными out.println(); // отдаем сами данные out.println(data); } else { // во всех остальных случаях формируем ответ 404 out.println("HTTP/1.1 404 Not Found"); out.println("Connection: close"); out.println(); } // нужно обязательно вызывать поскольку PrintWriter кеширует данные out.flush(); } catch (Exception e) { e.printStackTrace(); } finally { // в любом случае закрываем клиентский сокет try {s.close();} catch (Exception ee) {} } } // стартовый метод приложения publicstaticvoid main(String[] args) throws Exception { System.out.println("Starting.."); // тоже сложное место, которое было непросто ввести по памяти ExecutorService p = Executors.newFixedThreadPool(10); // создание 'серверного' сокета, который будет прослушивать // указанный порт // поскольку хост не указан - будут прослушиваться все (0.0.0.0) ServerSocket ss = new ServerSocket(8089); // бесконечный цикл, который нужен тк метод accept() - блокирующий // и выход из него произойдет после получения входящего подключения while (true) { // получен клиентский сокет Socket s = ss.accept(); // запуск асинхронной обработки p.execute(() -> handle(s)); } } }
Комментариев в той версии кода, который был показан на записи разумеется нет, они были добавлены уже после — для большего понимания.
Данный исходный код реализует простейший многопоточный веб-сервер на Java, который отвечает лишь на один URL /test и отдает заранее заданную строку с датой.
Как видите даже столь небольшого количества строк достаточно, чтобы можно было подключиться из современного браузера Chrome:
Компиляция выполняется как и в записи всего одной командой:
После чего появится один единственный class-файл c совпадающим именем. Поскольку пакеты не использовались, для запуска достаточно указать в качестве classpath текущий каталог:
java -cp . MyWebServer
Но это все лирика и понты.
Когда кончается человеческая память
Разумеется невозможно запомнить абсолютно все и рано или поздно вы столкнетесь с названием метода или класса, которые надо где-то подсмотреть.
Для примера, автор при записи видео столкнулся с таким в двух местах:
длинные классы-обертки над потоками (stream) сокета и сложное название статичного метода, создающего экземпляр ExecutorService.
И то и другое получилось правильно ввести далеко не с первой попытки.
Возвращаясь к ситуации когда нет доступа к интернету и полноценной среды разработки, зато на машине есть JDK — показываю что можно сделать в этом непростом случае.
Невероятно но факт:
подсмотреть названия системных классов и методов можно.. в самом JDK!
Вот это поворот!
В последних версиях JDK появилась интересная утилита jimage, которая находится в каталоге bin (там же где и главные бинарники java и javac).
С помощью этой штуки можно легко посмотреть полные названия всех системных классов:
Листинг системных классов JDK с полными именами.
Правда знание полного имени класса не всегда помогает, поскольку в JDK много вложенных системных классов, которые по идее вызывать снаружи не надо.
Команда для запуска:
jimage list $JAVA_HOME/lib/modules |less
Где переменная JAVA_HOME указывает на каталог с установленной JDK:
Так вы увидите названия всех системных классов, но что делать с методами?
Вытаскиваем сигнатуры методов
Тут тоже есть решение, поскольку эта же самая утилита позволяет распаковывать jmod-файлы в которых находятся системные классы JDK:
А еще одна утилита javap позволяет посмотреть метаданные class-файла, в том числе сигнатуры всех методов:
cd /opt/src/tmp/jre javap java.base/java/nio/Bits.class
Так выглядит результат:
Вот этого уже с запасом хватит для полевой разработки в условиях крайнего Севера.
Если у вас есть реальный, не "нарисованный" опыт разработки на Java, двух этих трюков будет достаточно для работы в поезде или самолете или на чужом компьютере — в тех местах и обстоятельствах, где нет подготовленного рабочего места.
Исходники JRE
Если вам совсем повезет, в каталоге JDK/lib будет находиться файл src.zip, внутри которого будут исходники всех системных классов JRE:
«Повезет» — потому что также как и demo, этот файл часто удаляют ментейнеры дистрибутивов Linux, с переносом в отдельный пакет. Но разумеется если он присутствует, то поможет гораздо больше чем все приседания с javap.
В распакованном виде:
Внутри находится исходный код всех классов Java, используемых в JDK:
cat java.base/java/io/Bits.java |less
Для примера, так выглядит исходный код класса java.io.Bits, который мы просматривали выше с помощью javap:
Как видите тут есть все, включая комментарии.
Эпилог
Смысл такой «полевой разработки» — в первую очередь глумеж над джунами проверка реальных практических навыков, которые находятся в голове у программиста, а не где‑то в интернете. К сожалению ныне можно констатировать, что такие навыки являются большой редкостью и мало кто из кандидатов, которых я когда-либо собеседовал могли осилить написание хотя‑бы трети подобного кода.
Кстати в нашем Телеграм-канале выложено первое техническое видео, где впервые получилось проверить всю эту идею.
Для ЛЛ: Системное администрирование – это про управление сервисом, а не только docker compose up
«Проект "Феникс": Роман об ИТ, DevOps и о том, как помочь бизнесу победить» — фундаментальная книга Джина Кима, Кевина Бера и Джорджа Спаффорда, в которой была представлена концепция DevOps. Первоначально опубликовано в январе 2013 года
Книга «что такое девопс инженер и где его место в системе управления производством» вышла 13 лет назад. Сама концепция существовала с момента появления приложений.
Почему это вдруг стало важно примерно лет 10 назад в РФ и лет 15 назад в США? Потому что это помогает зарабатывать деньги. А вы думали зачем?
В мире энтерпрайза концепция «совместной работы» существовала с момента появления проектов, которые один человек не может сделать физически. То есть где-то с начала 20 века. В мире электроники, малого и среднего бизнеса можно отметить: IBM AN/FSQ-7 Combat Direction Central (1955 год) и Semi-Automated Ground Environment (SAGE) (1958 год), из которых потом вырос интернет. Apache Subversion (svn) – 2000 год FreeBSD jail – 2000 год Git – 2005 год. Microsoft Team Foundation Server (TFS) и Visual Studio Team System (VSTS) – 2005 год.
К 2020 году профессия сформировалась, в том числе в РФ. Сформировала мем про заработок в 300кк/наносек, своих мемных персонажей (например, Хрыча), итд. И .. нельзя сказать, что умерла. Скорее, участники разбились на две фракции: - дешевая, где кандидатов (работников) много, и они за пределами своей RUN команды, не могут почти ничего - дорогая, активно разбежавшаяся в (на) Кипр, Сербию, Черногорию, Германию, Ирландию, итд. Частично Тбилиси, Кутаиси. Часть осталась в РФ. Очень было смешно, когда Экспресс 42 в итоге слился с Флантом. То есть, еще в 2023 году рынок галерной разработки \ девопс в РФ схлопнулся настолько, что двум командам было не выжить.
Середины «качества и оклада» нет, середина не нужна.
По моему опыту, из «низшей» лиги в «высшую» переходит 2 кандидата из 10 «девопсов». Если брать совокупный отсев, то : из 1000 человек – 900 могут пользоваться «техникой». Назовем их «Сотрудники» из 1000 человек – 200 могут быть «ИТ шниками». Назовем их «помошники сисадмина». из 200 «ИТ шников» 20 могут стать «системными администраторами уровня мидл», или девопсами «мидл, которого нельзя пускать к проду». Но из них получаются хорошие ИТ менеджеры, если прокачан скилл «красноречие» и «убеждение». Из 20 сотрудников «уровня мидл» можно получить 2 сотрудников: одного технического сеньора (лида) и одного лида с функциями менеджера. Проблема, и очень большая, в том, что на уровне «мидл» и «сеньор» приходится качать не только знание «ключей к командам, записанных в руководстве», но и организацию труда. И постоянно читать «что там нового».
И на этом месте в РФ, и не только в РФ, происходит и кассовый, и технический разрыв.
В чем это выражается?
Рассмотрим жизненный цикл двух сотрудников, Васи и Пети. Оба примерно одной (отсутствующей) квалификации в начале жизненного цикла. Оба идут на работу на «первую линию», обоим везет – у них в команде есть вменяемый ментор, который заинтересован в быстром развитии персонала, чтобы свалить на них побольше работы, а самому учиться или чилить. Со стороны всегда выглядит как «чилить».
Вася. Быстро учит базу, основные команды, основные ситуации, и дальше не особо учится «оплачиваемым навыкам». Работает по своему графику 8/5. Потом, чтобы заработать «побольше, как ему кажется» уходит на работу в сменах, сутки – двое, и считает, что чему-то учится. В пределах своей работы – уважаемый специалист.
Петя. Быстро учит базу, основные команды, основные ситуации, и дальше пытается учиться. И встречается с проблемой: для смены работы или спрашивают существенно больше, или предлагают больше работать «в часах». И тут скрывается ловушка: кажется, что спрашивают столько, что выучить нельзя, и может только повезти. Это не так, выучить то, что спрашивают на интервью, можно. НО. Только если ты с этим каждый день работал самостоятельно. Чтобы работать самостоятельно, нужно чтобы тебя взяли на работу и научили, а чтобы взяли на работу, надо пройти интервью. Замкнутый круг, с первого взгляда. Два стула из классической загадки. И та самая вилка на втором интервью.
Важно понимать, что оба варианта развития важны и нужны. Не всем хочется и можется учиться, люди не равны, и играть в рулетку иногда страшно, иногда невозможно. Ничего плохого в этом нет, Бесплатных завтраков не бывает, There ain't no such thing as a free lunch, TANSTAAFL
Но важно понимать и то, что «само» ничего не произойдет. Нужно делать хоть что-то. И, зачастую (почти всегда), вовсе не то, что предлагается в квестах про стулья и вилки.
Поэтому для развития нужно:
Первому уровню, до docker compose start включительно, можно и нужно научиться самостоятельно
Для развития в направлении devops/ML, нужны: - Загранпаспорт - Работающие социальные скиллы - Разговорный английский на 5 баллов (максимальный балл - 9.0) . Он же FCE. Он же B2 по CEFR. - Минимум одна поездка на Кипр, туристом. - Минимум одна поездка в Таиланд, точнее в Паттайю, точнее Walking street, туристом - Водительские права категорий A, B. Обе категории нужны. - Чтение тематических каналов и чатов - Пет проект «как у больших, только на k3s, proxmox, и домашней видеокарте». Со всеми свистелками и перделками – графаня, графаня локи, эластик, итд.
Дело не в том, что «самому не выучиться». Самому выучиться, но текущее состояние рынка труда таково, что нужны социальные связи, и постоянная демонстрация, что ты не мудак. Дело не в том, что «чего я там не видел в Паттайе», дело в том, что «видел сам». Другая ментальность, другая реальность, расширение кругозора, итд. И, говоря про Паттайю, повышение наблюдательности и, особенно после местных шоу, снятие сакральных скреп, и отрешение от духовности и навязанной идентичности, а местами и от идемпотентности. И, как следствие, улучшение характера и прекрасный аппетит.
Английский в этом списке нужен затем, что актуальной литературы на русском по теме не было, нет, и не будет. «Литература» есть. Актуальной нет.
Где тут кассовый разрыв ? Везде. Бизнес хочет работника "чтобы все умел, и недорого", и в то же время другой бизнес предлагает в 2 раза больше, за тот же пакет знаний. НО, поскольку у второго бизнеса отвратительные HR, то ты про такую вакансию узнаешь, только будучи "в общем коллективе".
Важное отличие «рассказов от HR» и «рассказов от преподавателей в РФ» от реальности находится именно тут.
В теории считается, что если ты хороший (очень хороший) специалист, и твои технические навыки не вызывают никаких сомнений, то тебе не нужны социальные скиллы. Минимум два популярных сериала (Компьютерщики и Теория большого взрыва) построены вокруг «персонажей с отсутствующими социальными навыками». В реальности на любом уровне, и чем выше уровень, тем чаще, тебе приходится больше заниматься людьми, чем техникой. Следующая часть как раз будет «Про прибыль, и как же они не понимают».
Подводя итог
Лет 15-20 назад я думал, что существует 5-10 технических направлений, в которых достаточно «научиться» и дальше «жизнь удалась». Наверное, 20 лет назад, в 2006 году, так и было. И в школе, и в институте, учат именно так – что «успех» это «демонстрация технических знаний» экзаменатору. В школе и институте это именно так, критерий успеха – сданный экзамен.
В жизни критерии и метода чуть иные.
При этом нужность технической базы никто не отрицает, но крайне важно понимать, что лозунг «учись учиться самостоятельно», это не просто лозунг. Вкатиться просто. Для переката выше нужно уметь, хотя бы с 5-10 раза, не только составить собственный учебный план, не только иметь силу воли и следовать ему, но и решать вопросы не только техническим путем.
Читать эти 6 книг нужно именно в таком порядке, по мере выхода книг. Остальные читать в любом порядке.
1 Фредерик Уинслоу Тейлор . Принципы научного менеджмента Удивительно, но по запросу «тейлор научная организация труда читать онлайн» книга будет не второй ссылкой, а четвертой.
2 «Мифический человеко-месяц, или Как создаются программные системы» (англ. The Mythical Man-Month: Essays on Software Engineering)
Можно читать даже комментарии, где пишут, что автор ничего не понимает, либерал и вредитель. Но, среди членов клуба зануд он считается опасным интеллектуалом.
6 Билл Гейтс. Бизнес со скоростью мысли
PS. Про ML как отдельный процесс так ничего и не написал. Видимо, у меня есть представление, что devops занимаются и AI, и ML. Хотя правильнее было бы поговорить про команду по внедрению изменений, но извините, так вышло.
В наши дни с помощью AI можно довольно быстро превратить идею в рабочий сервис. Достаточно нормально сформулировать проблему, объяснить, как ты видишь решение, и дальше сидеть с чашкой чая, наблюдая, как агент делает то, ради чего раньше нужно было искать разработчика, писать ТЗ, спорить про стек и проводить созвоны.
А в периоды масштабных изменений, меняющих привычный ритм жизни, появляется массовая потребность в сервисах, которые ещё полгода назад выглядели бы странными или никому не нужными. Сложив одно с другим мне захотелось попрактиковаться в вайб-кодинге.
А что если сделать сервис по мониторингу топлива?
В связи с непростой ситуацией на заправках официальная информация о наличии топлива и ограничениях вроде бы поступает. Проблема в том, что она размазана по новостным сайтам, Telegram-каналам, региональным чатам, заявлениям топливных сетей и комментариям водителей.
Где-то пишут, что в регионе ввели лимит, где-то ограничения есть только у конкретной сети, где-то бензин есть, но только АИ-92. Какие-то сети не наливают в канистру, а на АЗС очередь или уже закончилось топливо.
Карта станций АЗС
Мне захотелось сделать сервис, где можно быстро посмотреть ситуацию по конкретной заправке: есть ли топливо, какие виды доступны, сколько стоит, есть ли очередь, какой лимит и можно ли залить в канистру.
Так появилась идеяFuel detector— сервиса для мониторинга ситуации с топливом в России.
Какую проблему решает
Региональная ситуация с топливом
Главная мысль сервиса простая: если информация меняется быстро, её должны обновлять люди на местах.
Один водитель заехал на АЗС, увидел, что АИ-95 закончился, но дизель есть. Обновил статус. Следующий человек уже видит эту информацию и может выбрать другую заправку или спокойно ехать туда, если ему подходит дизель.
Fuel detector помогает смотреть ситуацию не только на уровне региона, но и на уровне конкретной АЗС. Потому что даже внутри одного города и одной сети заправок ситуация может отличаться.
MVP за три вечера
Я описал проблему прямо в Codex внутри VS Code: что нужно сделать, какие данные собирать, как должна работать логика сервиса и какие сценарии будут у пользователя.
Логику работы тоже сделал агент. Я выступал скорее как продуктовый редактор и постановщик задачи: объяснял, что должно происходить, проверял, где неудобно, уточнял механику и дорабатывал структуру.
Вайб-кодинг на максималках
Через 3 часа у меня уже был прототип на локальном сервере. Причём с базой АЗС, собранной из OpenStreetMap.
Ещё два вечера ушло на интерфейс, доработки и парсинг полной базы заправок.
Сейчас на сайте можно смотреть и добавлять статусы по 23 000 заправкам в 89 регионах РФ. Да, база не идеальная и не полная, но потихоньку заполняется. Собственно, как и положено нормальному MVP: работает, местами криво, но уже полезно.
Что можно указать по АЗС
В карточке АЗС пользователь может добавить:
доступные виды топлива и его наличие
цену, если она известна
наличие очереди
лимит в литрах на одну машину
возможность заправки в канистру
комментарий по ситуации на месте.
Ситуация на отдельно взятой заправке
Также у заправок есть графики статусов. Они помогают видеть динамику: всё стабильно, стало хуже или ограничения уже сняли.
Это полезно не только водителям, но и для общей картины по регионам и сетям. Когда данные начинают собираться в одном месте, становится видно, где проблема точечная, а где история уже похожа на системную.
Что дальше
Улучшения по вашей обратной связи
Насыщение данными
Приложения на Android и iOS, очевидно, тоже без единой строчки кода
Чем больше людей будут оставлять актуальную информацию, тем полезнее станет сервис. В идеале Fuel detector должен превратиться в живую карту заправок, где можно быстро понять, что происходит прямо сейчас.
Привет всем пикабушникам) Сижу давненько на данном ресурсе, читаю истории других людей, но ни разу сам не создавал какой либо пост. Вот наконец-то решился попробовать , так сказать узнать мнение людей.
Если ли смысл в данное время изучать программирование с нуля? Да и еще в 35 лет))) сам работаю электромонтёром, но эта работа уже совсем не доставляет удовольствия. Хочется каких нибудь перемен, например попробовать себя в новой профессии)
Что можете посоветовать? И вообще стоит в таком возрасте суваться в такую индустрию?
Еще одна поучительная история из жизни с Linux, специально чтобы вы потеряли сон и покой, узнав что такое вообще возможно.
Тот самый баг, смотрит на вас с экрана.
Вводная
Эмм с чего бы такого начать, чтобы не испугать раньше времени и не заставить устанавливать *BSD.
Есть на свете одна компания, которой мы помогаем с ИТ и есть у нее несколько виртуальных серверов на Ubuntu Linux, используемых для половых утех разработки и тестирования.
Ubuntu там использовалась нормальной (для сервера) LTS‑версии, но в какой‑то момент — в погоне за патчами безопасности ее обновили до текущей.
Не совсем «текущей-текущей», которую используют разработчики Ubuntu для обкатки новых версий дистрибутива, а просто без долгой поддержки — примерно то, что ставят себе обычные пользователи Ubuntu Linux на домашние компьютеры.
Все происходило летом 2025 года, поэтому речь про версию 25.04 Ubuntu Linux, которая использует ядро 6.14 (запомните этот важный момент):
Баг
Однажды сисадмин компании-заказчика заметил слишком частую и сильную нагрузку на CPU, создаваемую процессом snapd, который является частью пакетного менеджера Snap.
Скриншот был взят из сети, поэтому «шакальего» качества;)
Эта проблема с перегрузкой CPU для snapd мягко говоря не нова — «проклятый snapd» гадил линуксоидам с момента своего появления на свет и вообще видимо был не придуман а ниспослан свыше, в качестве кары за грехи.
Нет, это не осеннее обострение, дело происходило летом.
Разумеется первым делом были опробованы стандартные методы решения, вроде снижения частоты проверок обновлений или полного отключения проклятого сервиса:
Отдельно порадовал ответ ИИ:
Дословно «снести и использовать что-то другое» — первый разумный совет от машины за всю историю развития искусственного интеллекта.
Дальнейшие изыскания привели в багтрекер snapd к упомянутому багу, где уже третий комментарий от разработчика snapd, с приложенной трассировкой вызовов показал что проблема именно в ядре:
Тут стоит добавить, что почти сразу встал вопрос проверки бага на локальной машине, поскольку на момент изучения ситуации локально все успело неоднократно обновиться, а отлаживать ядро Linux на сервере заказчика все же не очень хорошая затея.
Чуть ниже по переписке видно, что баг особо ярко проявляется на ноутбуке, работающем от батареи:
Так что решено было пробовать отловить именно в таких условиях.
На счастье, на машине осталась сборка 6.14 версии ядра с патчами от Xanmod, которая использовалась для статьи про l9ec.
В последние годы в проекте ядра Linux выпускается сильно много промежуточных релизов, поэтому на какой именно версии внутри 6.14 ветки что-то пошло не так еще пришлось выяснять:
Обратите внимание на загрузку CPU и блокировку выхода из приложения
Как видите, в очередной раз проблема прикладного сервиса уперлась в ядро операционной системы.
Патч целиком находится тут, место исправления выглядит как-то так:
Да, как видите ситуацию радикально исправляет буквально пара символов логической конструкции, главное знать где исправлять.
Текущее состояние
Формально проблема была решена еще летом этого года, патч попал в mainline и пакет с обновлением ядра от команды Ubuntu:
На осень 2025 года даже стабильная версия ядра Linux уже имеет версию 6.16 — т. е. паровоз разработки уехал очень далеко вперед от описываемых проблем:
Так что на момент написания данной статьи вы (по идее) не должны столкнуться с данной проблемой, а если и столкнетесь — все легко решается банальным обновлением версии ядра из пакетов дистрибутива.
При подозрении на описанный баг — попробуйте собрать тестовое приложение (см. выше) и запустить в своем окружении.
Если начнется 100% загрузка CPU запущенным процессом — проблема точно есть, поскольку в ядрах с патчем поведение тестового приложения отличается:
В исправленном ядре тестовое приложение немедленно завершится.
Что касается заказчика, поскольку решение а затем и патч были опубликованы довольно оперативно — раньше чем нам сообщили о проблеме, на время разборок с согласованиями и попаданием в mainline ядра, мы банальным образом перенесли патч вручную в ту версию ядра, которая использовалась на сервере.
Позже обновили уже штатными средствами дистрибутива до текущей актуальной версии.
Эпилог
Если вы не являетесь разработчиком ядра и не пишете патчи каждый день, засыпая в обнимку с отладчиком — т. е. далеки от реалий системного программирования, то из этой статьи сможете вынести несколько интересных выводов и внезапных открытий:
1. Linux — могила, *BSD - сила
Шучу, разумеется неподготовленным пользователям в BSD-системы лучше не лезть совсем, но задуматься (или хотя-бы просто знать) о реалиях функционирования Linux все же стоит. Чтобы факт выноса мозга ядру из прикладного ПО не стал для вас неприятным сюрпризом.
2. Граница между прикладкой и системной разработкой весьма абстрактна
Проще говоря — ее нетсовсем и в любой произвольный момент времени у вас есть неиллюзорный шанс наткнуться на баг ядра, даже программируя на JavaScript в браузере.
3. Любой уважающий себя сисадмин и DevOps должны знать С
Пусть на самом примитивном уровне, но хотя-бы собрать и запустить тестовое приложение, демонстрирующее проблему надо уметь. К сожалению все глубокие изыскания по теме «где оно тормозит» или «почему оно упало» рано или поздно приводят к коду на С и отладчику ядра.
И поверьте моему печальному опыту:
изучать эти штуки лучше днем и в спокойной обстановке, а не в режиме аврала и поздно ночью на работе в выходной день.
4. Считайте деньги, хотя-бы иногда
Описанная в статье проблема случилась в локализованном окружении (на собственных физических серверах компании), но точно такая же Ubuntu используется и облачными провайдерами вроде Amazon, где есть тарификация за использование ресурсов, в первую очередь CPU.
Как нетрудно догадаться, 100% загрузка процессора с интервалом в пять минут в облаке, если ее вовремя не заметить и не исправить — больно отразится на счете, который вам потом выставят.
Так что проверяйте загруженность, пиковых 100% в современных системах быть не должно, если только вы целенаправленно не занимаетесь вычислительными задачами.