Изменение 30 строк кода ядра Linux позволяет повысить сетевую эффективность Linux и увеличить пропускную способность на 45% без увеличения задержек.
В основе разработки лежит исследование Карстена и его бывшего студента Питера Цая.

«Мы ничего не добавляли – просто изменили порядок выполнения операций, что значительно улучшило использование кэша процессора в дата-центрах», – объясняет Карстен.

Источник

Кто работал с perforator?

#цитата #codemonsterslog

Написал
1 Заклинателю приложений
Хагакурэ:

Всю свою жизнь учись. Каждый день становись более искусным, чем был вчера, а завтра — более искусным, чем сегодня. Совершенствование не имеет конца.

Осознанность в разработке — это кибер-имплант, который нужно установить как можно раньше.

Непрерывное улучшение. Бесконечный цикл, простой алгоритм и клятва самому себе, который выполняется в вечности.
Каждый раз оптимизируй себя.

Ты видишь как важные и простые принципы буквально пронизывают киберпространство?

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

https://codemonsters.team/codebook/

Читать полностью

#codebook #codemonsterslog

Японцы знают толк в развлечениях.
Собираю GUNDAM
BAN
DAI

Пойду напишу код

Ты что собираешь?

#codemonsterslog

😱 Что значит быть инженером в новых реалиях? И какой смысл мы вкладываем в эти слова — расскажем на GPB CONF уже через неделю!

22 апреля в Москве пройдет ИТ-конференция от Газпромбанк.Тех 🤯

Что вас ждет?

🔵Хардовый трек — для тех, кто в проде с закрытыми глазами. Обсудим реальные кейсы нашего банка и как мы создаём системы, которые работают стабильно и эффективно. 

🔵В ламповом софтовом треке поговорим, как растить инженеров, внедрять изменения и работать с сопротивлением команд и представителями бизнеса.

А в экспозоне у вас будет возможность погрузиться в специфику каждого направления — от мобильной разработки до кибербеза и продуктового дизайна 🤒

Участие абсолютно бесплатное! Просто зарегистрируйтесь и получите персональный билет с подробной программой.

Ждем вас на GPB CONF! 😎

Наш канал в телеге
#codemonsterslog

Эксперименты в DevOps приводят к временным странным ландшафтным образованиям.
Комп на полу, админ на полу - классика

Часто рано утро я программирую.

Ты сидел/лежал на полу настраивая свой сервачок?

#codemonsterslog

Вчера придумал, пока с инженерами продумывали как оптимизировать конвейер.

лучшая инженерная практика bypass

#codemonsterslog

Симбиоз с машиной при разработке. Компонентные тесты.

Киберпространство в срезе кодописи изменяется стремительно.

Иллюзия:

#gardener@core: закрываю глаза, обдумываю API компонента, проговариваю контекст, открываю глаза и вижу в git async api 3.0 спецификацию.

Я установил пару ИИ-имплантов в виде Claude и Cursor.
VS Code в сочетании с cursor меня очень порадовал на практике.
Возврат в IntelliJ IDEA теперь ощущается как деградация.
Горячие клавиши, молниеносные переходы между кодом и терминалом, древо проекта слева — интерфейс стал продолжением нервной системы.

С машиной я взялся за старый учебный сервис.

Задача: вшить компонентные тесты в проект

Читать полностью

#codemonsterslog #tests #componenttests

О важности коммуникации в IT: встреча со студентами Бауманки

Пообщался в Бауманке со студентами и рассказал им о сложностях коммуникации на работе. В конце было много интересных вопросов.

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

Код - побочный эффект коммуникации.

Часто бывает, что побочный эффект коммуникации - кот в мешке без ручки.

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

Мне нравится думать об этом через фразу:

Make me fucking care

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

Читать полностью

#codemonsterslog #community

Если пропустил, JB выпустил сырой официальный LSP для VS Code

@d_r_q, спасибо за подсказку. Уже на тесте.

#codemonsterslog

О том, как "пять минут" превратились в тот самый production deployment

Сидели, завтракали. Я вскочил и побежал записывать идею, сказал Вике:
— Я через пять минут вернусь.
— Хорошо, не забудь.
Я подумал, как можно забыть вкуснейший блин с яблоком и спешелти кофе. Я поставлю таймер на 5 мин и все.

На самом деле он не вернулся через пять минут.

Да. Так и не вернулся. Таймер прозвенел фоном. Не помню как его отключил.
Делал презентацию по результатам аудита команд.

Классический случай "just one more commit".

Рефакторинг

Рефакторинг — непрерывный процесс. Садовник следит за садом каждый день (код это или люди).
Так и я проверяю, как команды следуют стратегическим целям. Что у них творится в git, что пишут в тикетах в джирке.

Как говорят британские девелоперы:

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

У некоторых заканчиваются вилки и они начинают есть хлопья руками.

P.S. Блин с яблоком остыл. Блин.

// TODO: implement breakfast.reheat() method
// FIXME: wife.mood = null
// Known issue: Food temperature decreases over time. Won't fix — working as designed.

#codemonsterslog

Дорогая, работа с AI-агентом превратила меня в супермена.
Или супер-мема — сейчас это почти одно и то же.

Я учусь и создаю автоматизацию в разы быстрее. Это новый темп, новый стиль работы.

Помнишь «Джонни-мнемоника»? Как главный герой перевозил информацию в чипе, встроенном в череп? История материализовалась. До нас доходят фрагменты через текстовые каналы.

Где-то китайские специалисты везут 50 ТБ обученных моделей в самолёте из стран с более свободным интернетом. В неоновых лучах Токио якудза с лазерной нитью крадёт первоклассный датасет сверхновой нейросети и перепродаёт через даркнет военным подрядчикам. Проклятая Арасака.

А я тут со своим Go и unit-тестами — как уличный самурай с клавиатурой вместо катаны.

В отражениях небоскрёбов мегаполиса стильные корпораты в дизайнерских костюмах везут обученные модели в гоночных суперкарах. Машина улучшает машину. Recursive enhancement. БУМ.

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

Быстрее тестирую гипотезы, исследую новые направления. Это прорыв. Digital awakening.

Я не могу объяснить всё — слишком много переварить. Я на эмоциях.

Даже читаю больше и быстрее.

Погнали к коду

Читай мой лог про то, как я за 5 часов написал сервис с тестами, прокачал CI и получил море эндорфинов.

#codemonsterslog
#code

Что я сделал за 3 х 45 мин
код теста на геркин API Unleash
коммиты эксперимента и пошаговых улучшений кодовой базы
сразу улучшил фундамент, потом вкатил анлишь
https://git.codemonsters.team/guides/mq-rest-sync-adapter/-/commits/feature/component-tests-unleash

Добавил тесты интеграции с Unleash

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

Что такое тогл/ фича-флаг/ фича-тогл?

Фича-флаг (feature flag/toggle) — это механизм, который позволяет включать или выключать функциональность в приложении без изменения кода и без нового деплоя.

Простая аналогия
Представьте выключатель света в комнате:

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

пример кода:


if (featureToggles.isFeatureEnabled("wallet-balance-workflow")) {
refactoredBalanceFlow(message)
} else {
legacyBalanceFlow(message)
}

sorry(нет):
Я с подозрением отношусь к проектам спроектированным полностью на TypeScript, JS. Оно идет инзутри моего нутра. Я понимаю, что это просто инструмент. Но это не самый хороший для бэка вариант.

С апи я помучался немного. Агент тоже не сразу справился, но я его научил.
API Unleash содержит ошибки в доке, например
API создания фичи описано с кодом 200 в ответе.
https://docs.getunleash.io/reference/api/unleash/create-feature
по факту 201.

Интеграция в компонентном тестировании с Unleash позволяет
сколь угодно тестировать сервис. И это просто.
Включая и выключая тоглы програмно по API прописываешь на геркине тест сервиса:

| включил тогл
| прогнал тест фичи
| выключит тогл
| прогнал тест фичи

Фича готова к установке

Автоматизавтор:
Дополнительно проверил есть ли мэтч с тоглами локального компонентного теста и с анлиш на stage, prod
чтобы не катить с тоглами, которых нет в мастер-системе - обеспечил согласованность.

P.S.
Есть несколько интересных проектов, на которые можно обратить внимание:

Flagsmith

Стек: Django/Python (backend), React (frontend)
Популярность: Активно развивается, хорошее сообщество
Простота: Есть облачная версия и self-hosted
Особенности: REST API, webhooks, интеграции

GrowthBook

Стек: Node.js/TypeScript (backend), Next.js (frontend)
Популярность: Новый, но быстро растущий
Простота: Фокус на A/B тестировании
Особенности: Интеграция с аналитикой, статистический движок

Flagr

Этот инструмент я покручу следующим.

Стек: Go
Популярность: Используется в Checkr
Простота: REST API, простое развертывание
Особенности: Легковесный, хорошая производительность
Client Libraries
(нет Java)
Language Clients
Go goflagr
Javascript jsflagr
Python pyflagr
Ruby rbflagr

#codemonsterslog

Ну что, Оптимус.
Дэйкстра в книге
«Дисциплина программирования»
1976 года меня очаровал с первой главы в послании от автора про перделки и свистелки в программировании:

Наверняка разочаруются все те, кто отождествляет трудность программирования с трудностью изощренного использования громоздких и причудливых сооружений, известных под названием «языки программирования высокого уровня» или — еще хуже! — «системы программирования». Если они сочтут себя обманутыми из-за того, что я вовсе не касаюсь всех этих погремушек и свистулек, могу ответить им только одно: «А вполне ли вы уверены, что все эти погремушки и свистульки, все эти потрясающие возможности ваших, так сказать, «мощных» языков программирования имеют отношение к процессу решения, а не к самим задачам?» Мне остается лишь надеяться, что, несмотря на употребление мною мини-языка, они все же прочтут предлагаемый текст.

А тем временем, Оптимус, некоторые инженеры (так называемые инфлюенсеры) не видят целесообразности в Соглашении Наименований (Name Conventions) при стандартизации работы команд.
Но это уже другая увлекательная история, брат.

#codemonsterslog

Как Cursor устроен изнутри. Часть 1 / Хабр

https://habr.com/ru/articles/919636/

#dev2dev

Делегирование — скользкая дорожка

Как не стать бутылочным горлышком в своей организации, мыслить масштабно и понимать, что происходит в развитии своих направлений — работа далеко не очевидная. Я решил для себя, что должен продолжать «марать руки» как инженер.

Убежден: тех-лид должен продолжать «марать руки». CTO тоже может марать руки - этого очень не хватает в работе.

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

Проблема «царя во дворце»

Проблема мистера «Царь во дворце» часто кроется в том, что он считает свою работу чисто стратегической. Думать масштабно и делегировать результаты своих размышлений подчиненным. Так поступают многие и теряют доверие.
О таких часто говорят на разных уровнях: «Ну все понятно, ему хорошо.
Но его не видно, и он ничего не делает».

Если только делегируешь — значит, забыл, что значит работать по-настоящему.
Мне нравится смотреть на свои направления как в стратегии (я про Starcraft, но скорее про Dawn of War 2): наблюдаю, куда движутся команды, что у них происходит в каналах коммуникации, вижу проблемные участки или нарушения коммуникации, спускаюсь на дропподе, погружаюсь в проблему до самой земли и даже до червей в земле. Ищу ключевые проблемы и работаю над тем, чтобы помочь команде увидеть общую картину, чтобы на основе стратегии применять тактику, а не просто бежать и делать.

Важность понимания корня проблемы

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

Самое плохое, что может быть — когда тех-лиды и старшие инженеры от лени, возможно от эго и упоения своей властью превращаются в обычных ленивых менеджеров, которые только распределяют задачи и посредственно обучают свои команды (или вовсе не обучают). У них нет времени «замарать руки», вникнуть в проблемы, и они вечно находят отговорки в чрезмерном количестве встреч и кучи другой «полезной» работы.

Вместо того чтобы остановиться и подумать: может, стоит перестать делать кучу бесполезной работы и подумать, какие ключевые проблемы стоит решить и кому.
Задай вопрос: куда мы идем и зачем? Что мы тут строим?

тех-лид с чистыми ручками

Тех-лид, твоя работа — показывать делом и учить младших разработчиков. Ради всего святого, это же очевидно! Если ничего не делаешь, сидя на стуле в кабинете, с чего взял, что твоя команда начнет шевелиться вдохновенно и искать точки достижения успеха?
ТехЛид - это не про пенсию и покой. Это про другой уровень задач.

Если прораб ничего не умеет делать руками и появляется на стройке лениво пару раз в неделю, о каком качестве работы может идти речь в срок?
Какой толк от твоих эпизодичных умных речей?
Как ты поймешь, где у тебя проблемы? Где кривые руки, а где кривой процесс?
На ретроспективах? смешно.
Младшие разработчики порой просто не догадываются, что система должна и способна работать иначе.

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



#codemonsterslog