defer panic

🦄 Опубликовал платформу для гайдов и первую статью

https://golang.guide/

Надеюсь, вам понравится, я очень старался ☀️

Там всего один единственный гайд — первая часть серии статей про Планировщик. Даже если вы читали оригинальную статью, или смотрели ролик, всё равно советую перечитать — тут полный ремастер и режисёрская версия с интерактивом 👍

Остальные статьи уже в работе. Буду выпускать их по мере сил.

Советую читать с десктопа — там пока больше фич, чем на мобилке.

Если заметите какие-то баги или проблемы — пишите, поправлю.

Новость из немного другого мира: Эрин Катто, автор легендарного* физического движка Box2D, какое-то время назад очнулся и объявил, что пилит новый движок. Собственно, на днях вышла первая версия Box3D — в каком-то смысле то же самое, но для 3D-игр и приложений.

Как только вышел первый релиз, люди сразу побежали портировать его под разные таргеты. Классический порт — на JS. Но есть, например, и интеграция Box3D с Unity. Последний для трехмерной физики по умолчанию использует Nvidia PhysX, на который все жалуются, в том числе из-за производительности. С Fable 5 реализация интеграции заняла около 20 минут вместо недель, по словам автора. Есть еще версия от Апанасика.

Рассказ Эрина о новом движке: youtu.be/jr_Fzl2XwKU

С чего вдруг я решил про это написать? Моё начало карьеры было тесно связано с геймдевом, поэтому для меня это довольно знаковое событие.

*На Box2D работают такие игры золотой эпохи инди, как Angry Birds, Limbo, Crayon Physics Deluxe, Happy Wheels, Shovel Knight и многие другие. Примечательно, что главные механики почти всех этих игр как раз строятся вокруг физики. Также Box2D отвечает за двухмерную физику в Unity и во многих других игровых движках.

Я решил провести эксперимент и написать что-то на абсолютно незнакомом языке для абсолютно незнакомой (с точки зрения разработки) платформы.

Критерии такие:
• Это что-то полезное как минимум лично для меня
• Можно будет выложить публично
• Сложнее чем менеджер тудушек, но не слишком
• Не враппер для LLM
• Не требует затрат на инфраструктуру

В итоге посмотрел в сторону проблемы разделения рабочего и нерабочего контекстов. Собственно, для работы и для личных дел я использую либо разные профили в браузерах, либо разные браузеры. Особенно в сервисах, где у меня есть как рабочая, так и личная учётка.

В определенной степени проблема уже решена за меня. Какое-то время я пользовался Multi-Account Containers в Фаерфоксе. Но всё-таки часть сервисов, особенно рабочих, работает в Фаерфоксе ну прям раздражающе плохо и сильно хуже, чем в Хромиуме. В Арке очень круто реализованы профили и переключение между ними, а также фича под названием Air Traffic Control — когда по правилам на основе доменов браузер сам открывает ссылку в нужном профиле. Это было почти идеальным решением. Но... не буду напоминать вам, в каком состоянии сейчас Арк и The Browser Company. К тому же концептуально кажется, что подобная штука должна существовать снаружи конкретного браузера: вдруг я хочу все личное в Сафари, рабочее в Фаерфоксе, а Гугл Мит, так уж и быть, в Хроме, потому что он нигде больше нормально не работает?

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

Так родилось приложение TrafficWand для Мака. По сути я взял за основу идею Air Traffic Control из Арка, вынес в отдельное приложение и дал ей некоторое развитие. Например, TrafficWand умеет не просто раскидывать ссылки на основе правил, но еще и как бы обучаться: есть режим, в котором программа спрашивает, где открыть ссылку и запоминает это в виде правила. Кроме этого есть мета-профили/прокси-профили или алиасы — возможность один раз создать сущности типа Personal и Work, в них определить браузер и профиль браузера, а уже в правилах ссылаться на алиасы, а не конкретный браузер или профиль.

Приложение, кстати, нативное и навайблено написано на Свифте.

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

Сайт: https://trafficwand.app
Гитхаб: https://github.com/trafficwand/trafficwand

🥂Большой выпуск про PaaS — как Avito и Plata строят платформу для разработки / GoGetPodcast

- Видео
- Ссылки на аудио-площадки

Когда-то давно я часто ходил на IT конференции, и один из немногих запомнившихся мне докладов был про PaaS Авито. Очень впечатлило, как у них там по нажатию одной кнопочки происходят сложные автоматизации процессов.

К сожалению, поработать у них и пощупать это руками мне так и не довелось, поэтому я решил пообщаться с лидом команды DevSupport их платформы — Владом. А чтобы было ещё интересней, мы с моим бывших коллегой Ильдаром сравнили всё это с начинаниями в Plata, которая тоже активно строит свою платформу.

Участники:

- Владислав Сикач, тимлид команды DevSupport в Авито
- Ильдар Карымов  , инженер команды Developer Experience в Plata

🟢Все ссылки, упомянутые в выпуске, и разборы сложных понятий есть на сайте подкаста

#gogetpodcast

⚙️ Лучшие практики в Go: разбираем на Podlodka Go Crew

Пишете на Go и хотите узнать, как закладывать надёжную основу для своих проектов? С 1 по 5 июня Podlodka Go Crew вместе с 2ГИС проведут сезон «Лучшие практики в Go». Организаторы собрали сильную программу с акцентом на живой опыт и прикладные кейсы.

Вот несколько сессий, на которые советуем обратить внимание:

🚀 «Практика Go оптимизаций: растем вместе с нагрузкой», Алексей Акулович — про то, как сервис растёт до миллионов RPS, оптимизацию CPU, grpc и protobuf, а также про собственный GC поверх гошного.

🏗 «Эволюция структуры Go-проекта: как 30 человек пушат в один репозиторий», Кирилл Возжеников — как развивается продуктовый монорепозиторий и строятся хорошие архитектурные практики.

🧩 «Как и зачем писать свой CDC на Go», Юра Саргсян — когда приходится выходить за стандартные решения: Postgres, Kafka, гарантии доставки и подводные камни логической репликации.

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

🎟 И это ещё не всё — смотрите полную программу на сайте и забирайте билет!

Для подписчиков скидка 500 р по промокоду: deferpanic_7

#партнерскийпост

Вышел Zed 1.0

Не обращайте внимания на версию — Зедом можно было пользоваться уже очень давно. Зед был моим «вторым» редактором последние несколько лет, периодически меняясь с Вимом. Где-то с начала этого года или конца предыдущего это мой единственный редактор. В том смысле, что я в этом году ни разу не запустил ни GoLand, ни Visual Studio Code.

Зед одновременно невероятно быстрый и отзывчивый (по ощущениям примерно как Саблайм) и фичастый, как Visual Studio Code. И это не форк последнего, а буквально написанный с нуля редактор. Авторами Атома, кстати. И так как он написан с нуля, это позволило разработчикам перепридумать UX в некоторых местах в лучшую сторону.

Я могу долго рассказывать, почему если вы поставите Зед, вам больше не нужен будет никакой другой редактор или IDE. Но лучше поставьте и попробуйте сами.

Есть блог Not a Number, в котором автор не просто пишет туториалы, а делает их интерактивными. Посты там в основном про фронтенд, но есть, например, и про написание собственной key-value базы данных.

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

Эмулятор x86-процессора на CSS. Без джаваскрипта вообще. Можно запускать свои программы.

Ждем doom.css?

https://lyra.horse/x86css/

🧬 Proposal: Generic Methods для Go

Robert Griesemer (один из авторов языка) открыл proposal, который многие считали невозможным. Go FAQ буквально говорил:

> We do not anticipate that Go will ever add generic methods

Но теперь — возможно, добавят 👍

Суть в том, что раньше дженерик-методы блокировались по цепочке: если методы могут принимать параметры типов, значит и методы интерфейсов тоже должны. А это не знали как реализовать эффективно — в Go тип реализует интерфейс неявно, поэтому компилятор не может знать заранее, для каких конкретных типов нужно будет скомпилировать метод.

Ключевой сдвиг в мышлении: метод — это не только способ реализовать интерфейс. Метод — это функция, привязанная к типу, удобная для организации кода и читаемая слева направо. Эти две вещи ортогональны.

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

type Reader struct{ … }
func (*Reader) Read[E any]([]E) (int, error) { … }

Reader не реализует io.Reader — и это нормально. Зато метод полезен сам по себе.

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

————

Дискуссия горячая — 156 комментариев. Кто-то радуется, кто-то боится усложнения языка, классика. За то и люблю наше сообщество ✨

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

За я или против? Честно, не знаю — вопрос действительно непростой, если вникать глубоко в проблематику и доводы обоих сторон. Поэтмоу я предпочитаю делегировать столь сложные вопросы бородатым мужчинам — я в них верю! ❤️

Посмотрим, примут ли. Но сам факт, что Griesemer это открыл — уже хороший сигнал.

🟢Кстати, тема дженериков довольно забористая, и понимаю что не все поймут, что тут вообще имеется в виду. Если хотите, я напишу пост с более простым объяснением и разбором этой темы.

#proposal #generics

Пару недель назад собрал на коленке штуку, которая обходит rss-фиды сайтов с новостями индустрии развлечений, выбирает по разным признакам самые интересные статьи и постит мне в отдельный канал.

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

Все что угодно может пойти не так или сломаться, но если интересно, заходите в @glashatai_feed

Для ясности: речь про https://containers.dev

Бог рандома решил, что проходки получают @GoracioNewport @sir_sohich

Поздравляю! Стучитесь за призами в личку канала

🤖 AI в практике разработчиков: новый сезон Podlodka AI Crew

«Мы поигрались с промптом, но пока не внедряли» — часто разговоры про AI в разработке заканчиваются именно так.

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

С 16 по 20 февраля у Podlodka AI Crew пройдёт сезон «AI-агенты в разработке»: проверенные рабочие сценарии от практиков индустрии.

👀 В программе:
• единый AI-workflow для разработчика
• автоматизация стендапов и работы с документацией
• Claude Code, субагенты для кодинга
• практические кейсы внедрения AI в SRE
• подходы к созданию промптов с насыщенным контекстом

Формат — классический для Podlodka Crew: 5 дней, 10+ спикеров, 10 сессий и закрытое комьюнити в Telegram.

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

👉🏻Если тема AI в разработке вам интересна и хочется меньше хайпа, больше дела — держите ссылку.

😉Также проходки получат два случайных человека, которые расскажут в комментах о том, как они используют AI в разработке. Результат — на выходных.

#партнерскийпост

Вышел Go 1.26. Релиз с виду небольшой, но интересный:

• в new можно теперь передавать выражения
• go fix теперь запускает модернайзеры — тулы для авто-исправления кода согласно новым стандартам (например, замена strings.Split на итератор strings.SplitSeq внутри for-range). Обещают позже раскрыть больше подробностей в блоге
• новый сборщик мусора теперь включен по умолчанию
• pprof научился находить утекшие горутины

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

Один из таких архетипов — «инфраструктурный решала». Извините, лучше названия нет и не будет. Так вот, такой разработчик отлично разбирается в СУБД, очередях, кэшах и прочих хранилках и молотилках. Он знает, как строчки в табличке мапятся на страницы на диске. Он может рассказать всё про блокировки и уровни изоляции. Он действительно решал все эти проблемы на практике, по крайней мере он так звучит и может так же уверенно отвечать на вопросы, уходящие вглубь. Нередко от таких кандидатов возникает ощущение, что они знают и умеют больше меня.

Но вот кандидату задается вопрос не про СУБД или что-то вокруг, а про, внезапно, программирование. Причем вопрос необязательно про специфику конкретного языка. Тут-то вся уверенность куда-то исчезает. Теперь почти все ответы строятся на робких предположениях и на том, что кандидат где-то когда-то прочитал или услышал.

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

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

Мой любимый пример — постгрес. С одной стороны, это самая популярная, народная СУБД. С другой — полиэтиленовый пакет с абстракциями, вытекшими наружу из-за того, что пакет дырявый. Причина, по которой на любом техническом интервью есть секция, посвященная отдельно постгресу, — сложность, которую он должен как бы скрывать, но в итоге просто превращает в другую сложность. Нельзя просто создать индекс и рассчитывать, что постгрес будет его использовать. Почему? Потому что постгрес умный и может решить, что индекс ему не нужен, и пройти сексканом будет быстрее и лучше. Что? Да! И как бы да, часто он в этом прав. Но это лишь один пример одной из множества неочевидных деталей внутреннего поведения СУБД, о которой необходимо знать, чтобы не попасть впросак. Да и насчет «прав» я погорячился — быстрее всё равно не стало, зато появилось что расследовать. И в конце концов, его никто не просил этого делать.

Сумма всей сложности в замкнутой системе остаётся постоянной — как ни старайся её перекладывать из одного угла в другой.

Поэтому в глазах индустрии умение именно программировать больше не имеет такого значения. Точнее, может, и имеет, но сам процесс происходит в большей степени не в коде, а в других местах: базе данных, кубернетесе, очереди или слаке. Плохо ли это? Я не знаю. Опять же, какая разница, если задачи решаются, цели достигаются и при этом качественно? А что если нужно будет сделать всё то же самое, но вместо WhoopSQL будет нужен PoopSQL? Пока опыт подсказывает, что в таких случаях решалы чаще всего впадают в ступор — в отличие от тех, кто учился программировать, а не быть оператором.

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

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

Я к вам с пятничными вакансиями. На этот раз не про Go, но я знаю, что меня читают не только гоферы и не только разработчики.

Ищем QA-инженеров-автоматизаторов для мобильного приложения на Свифте и на Котлине.

Что за команда/продукт?
Команда CAA (Cards & Accounts) — это продуктовая команда, отвечающая за бэкенд и фронтенд функций, связанных с обработкой платежей, включая наши наиболее важные экраны, отображающие основную информацию о счете, картах, выписках и кэшбэке. Кроме того, эти же данные предоставляются CRM-сервисам. Главная задача команды — сделать взаимодействие наших клиентов со своими счетами и картами в приложении удобным и приятным.

Я сам до недавнего времени был частью Cards & Accounts. Могу сказать, что одна из самых крутых и профессиональных команд, в которых мне довелось поработать.

Что предлагаем:
- Помощь в переезде в один из наших хабов — на Кипр, в Испанию, Сербию или Казахстан — с поддержкой для сотрудника и его семьи.
- Гибкий график работы из одного из наших офисов или удаленно.
- Медицинское страхование.
- Бюджет на образование: языковые курсы, профессиональное обучение и сертификация.
- Бюджет на оздоровление: компенсация расходов на поддержание психического здоровья и физическую активность.
- Отпускные: 20 дней ежегодного отпуска и оплачиваемый больничный.

Чтобы откликнуться, можно заполнить форму на странице вакансии или написать мне в личку.