Найти в Дзене
На KubeCon 2026 прямо со сцены заархивировали
https://github.com/kubernetes/ingress-nginx Это не значит, что все перестанет работать завтра. Но это очень четкий сигнал, куда все движется. Фактически, этим дали официальный старт активному переходу на Gateway API: https://kubernetes.io/docs/concepts/services-networking/gateway/ Ingress как подход никуда мгновенно не исчезнет - слишком много продакшена на нем. Но стратегически: Почему это важно. Ingress всегда был немного "как получилось": Gateway API это попытка сделать это системно: И если смотреть вперед, то смотреть уже нужно в сторону Gateway API...
5 дней назад
В чате моего Telegram-канала интересовались полезными правилами и ссылками про то, как общаться в команде. Я собрал все воедино что у меня было и подготовил документ, который можно as is забирать в ваши процессы onboarding'а. Можно импортировать в Notion. MD универсален по сути, поэтому проблем с применением не возникнет Документ у меня в Telegram-канале: t.me/...kii или через поиск в Telegram по запросу «Сергей Озеранский».
6 дней назад
ТСПУ блокирует TLS к иностранным хостам на Cloud.ru (ru.AZ-3)
Обнаружил интересное поведение при развертывании VPS на Cloud.ru Evolution в зоне доступности ru.AZ-3. Сервер не может установить TLS-соединение с иностранными хостами - handshake зависает после отправки Client Hello. Пообщавшись с людьми, выяснил, что поймать такой ip в Cloud.ru можно поймать в любой зоне доступности, есть случае когда в ru.AZ-3 работает и наоборот, как в моем случае. Сервер: Cloud.ru Evolution, ru.AZ-3, Ubuntu 24.04 ASN: AS208677 "Cloud Technologies" LLC (Cloud.ru) Проверка DNS...
1 неделю назад
Наткнулся на то, что теперь добавлю к списку ресурсов для онбординга (например, уже давно в списке nohello.net stopsloppypasta.ai - четко отражает правила поведения с LLM Больше постов у меня в Telegram-канале: t.me/...kii или через поиск в Telegram по запросу «Сергей Озеранский».
1 неделю назад
Поведенческие интервью на senior позиции
Немного мыслей про поведенческие интервью на senior позиции. На первый взгляд этот этап может показаться самым простым, ведь уже много кругов ада пройдено и остается только "поболтать". Хотя на этом этапе часто принимается финальное решение. На таких интервью обычно не проверяют технологии. Проверяют как вы работаете как инженер уровня senior. 1. Зону ответственности Важно не “мы сделали”, а что сделал именно ты. Плохая формулировка: “мы разрабатывали высоконагруженную систему”. Лучше: “я отвечал за архитектурное решение для …”. Интервьюеру нужно понять где именно был твой вклад и уровень влияния...
2 недели назад
Еще подготовил свои ИМХО на тему: Что должен найти при анализе кода main.py Я взял просто три уровня инженера - Junior, Middle, Senior. Вот что у меня получилось - gist.github.com/...190 Больше постов у меня в Telegram-канале: t.me/...kii или через поиск в Telegram по запросу «Сергей Озеранский».
2 недели назад
Помните, мы играли в игру. У меня дошли руки, наконец-то, сделать результат того, как я вижу этот код (из задачи) в продакшене. Улучшать можно бесконечно, поэтому я написал такой код, который у меня не вызывает вопросов по моим критериям к продакшен коду. Для себя я поставил условия использовать максимально нативный Python, что и получилось. В проде я бы кое чем обвесился и кода возможно немного стало меньше, но главное это архитектура самого решения. Плюс я сделал допущение, что у нас нет внешних зависимостей, таких как Vault, чтобы хранить безопасно секреты, поэтому "по-старинке", в env. И еще допущение - тесты. Я держу в голове, что они написаны. Но я не писал в данном решении. Но после теперь их намного проще писать. И по хорошему при рефакторинге тесты пишутся до рефакторинга. Теперь сам код - gist.github.com/...a29 Тут подробное описание diff'a - gist.github.com/...166 Повторюсь, сколько людей - столько мнений, но теория программирования она одна. Хотя ее тоже можно интерпретировать по разному, главное соответствие требованиям, которые изначально заложены. Больше постов у меня в Telegram-канале: t.me/...kii или через поиск в Telegram по запросу «Сергей Озеранский».
2 недели назад
Law of Demeter. Закон Деметры в программировании
Чуток теории программирования принесу позже. Уверен, что это все любят. Law of Demeter. Law of Demeter (Закон Деметры), если описать его в одной фразе - "не лезь во внутренности чужих объектов". Пример: Уже лучше Но, как мы любим, есть нюансы. В примере выше запах кода просто скрыт теперь через функцию или там могла быть property. Поэтому надо думать немного шире. Принцип не столько про то, чтобы "не было много точек". Много точек - это просто запах кода, по которому можно понять чуть больше. Суть в связности...
2 недели назад
Шел 2024 год. И у меня подгорало на текущем на тот момент месте, поэтому я решил посмотреть рынок. Я уже жил в эмиграции, но локального работодателя искать не хотел. Причины простые: деньги и язык. Лидерские роли без локального языка - отдельный квест, а по компенсации часто грустно. Плюс не всегда есть удаленка, а в Валенсии ИТ есть, но его объективно немного. Был вариант искать среди экспат-компаний, например на Кипре, но без релокации. И тут тоже не все готовы, особенно когда речь про Tech Lead и выше. Самый понятный и рабочий вариант - РФ-компания. Да, рубль. Но процессы и люди понятны. Плюс у многих бигтехов уже есть юрлица в СНГ, и вывод дохода на европейский счет давно не проблема. В 2024 году это уже не какая-то серая схема, а нормальная операционная реальность. Но поиск был в режиме "просто посмотреть". И в этот момент мне пишет HR из большого РФ бигтеха. Компания известная, продуктом пользовались, я думаю, почти все. Тогда она мне реально нравилась: сильная инженерная и продуктовая культура, открытость, публичные митапы. Я по возможности их посещал, общался с лидами и инженерами. Отдельно импонировало то, что часть их внутренней документации была выложена публично как OSS. Можно было изучать практики, забирать подходы, применять у себя. Это редкость для бигтехов в РФ. Сейчас уже отношусь к компании нейтрально, просто перестал следить. В эмиграции фокус сместился, и пересечений стало меньше. Интересный момент: в тот момент мне написало сразу несколько HR. Они не штатные, ведут разные проекты внутри одной компании. Классика. И еще деталь - с некоторыми первый контакт был еще в 2023 году. Тогда я отказался от интервью, потому что не планировал менять работу. Но показательно, что сильных кандидатов не забывают. Даже если ты однажды сказал нет. Я решил пройти процесс. Было заявлено 4 этапа: 1. HR-интро 2. System Design - спроектировать решение с нуля 3. Платформа (я не знаю почему там дали такое название этому этапу) - кодинг (именно кодинг!) на Python 4. Кейс-интервью HR-интро сложно не пройти, это нужно очень еще постараться, как мне кажется. Первые два технических этапа прошел уверенно. Хорошая обратная связь, без замечаний. Процесс растянулся на месяц с августа по сентябрь. Потом я снова переезжал, взяли паузу. Вернулись к процессу уже в декабре. К этому моменту я успел дважды сменить локацию. Что это означает? Позицию не закрыли. И я по-прежнему был им интересен. Последний этап - кейс. Домашняя подготовка. Дают задачу и список рекомендаций. Структура понятная, но не новая. Не новая потому что, к кейс интервью подходил так же как это делал в обычной жизни на работе. То есть тут важно то, что я не подсраивался под кейс и не придумывал - делал часть своей работы. И что еще важно, делал то, что реально показать и обсудить за 1 час интервью. То, что действительно важно. В итоге - отказ. Причина: "в кейсе не хватило глубины проработки". Честно? Меня это разозлило. Но сейчас злит не потому, что я там не работаю. Сейчас я рад, что не работаю там. В первую очередь рад потому, что считаю, что любое событие, позитивное или нет, привело меня к тому, где я сейчас. А сейчас я счастлив во всем. Злит другое - поверхностность формулировки. После всех этапов, где я проходил как сильный кандидат, получить обобщенное "недостаточно глубоко". Ну нет... Да, я сделал таблицу приоритизации, а не roadmap. Но это вопрос формы, а не сути. Внутренние стандарты отображения изучаются за 30 минут после выхода в компанию. Это не системный пробел. Если копнуть глубже, там скорее вопрос ожиданий по уровню бизнес-погружения, продуктового мышления и степени детализации. Но это уже про интерпретацию. Но говорить мне про недостаточность бизнес-погружения, человеку, который предоставил HR документ с достижениями для бизнеса с цифрами (много кто ведет такой документ?). Тому, кто делал стартап и прогорел, кто имел свой бизнес... Кейс-интервью - это не всегда про качество решения. Часто это про совпадение ожиданий. Можно быть достаточно сильным и не попасть в картинку в голове конкретного интервьюера. Это жизнь. Но раздражает.
3 недели назад
Как я работаю с System Design на менторинге
Недавно разбирали с кандидатом задачу - реализовать трекинг машины. Казалось бы, просто "покажи точку на карте". Но именно такие задачи хорошо показывают, умеет ли человек думать как инженер, а не как кодер. Вот структура, которую я использую и которую рекомендую отработать до автоматизма: Что я часто вижу у кандидатов: Хороший system design это не знание паттернов наизусть...
4 недели назад
Развитие инженера почти неизбежно выходит за рамки одного только кода.
Развитие инженера почти неизбежно выходит за рамки одного только кода. Если смотреть шире, одно из логичных направлений роста - понимание облачных решений. И это не просто расширение набора навыков. Это рост масштаба мышления, эрудиции и понимания того, как технологии работают в реальной среде и даже то, как решение связано с бизнесом и за каждой технологией и решением стоят реальные деньги. Пока мы находимся только в плоскости разработки, мы мыслим кодом: функции, классы, архитектура сервиса, язык, фреймворк, производительность компонента. Это важный слой. Но это не вся система. Особенно для сеньора и выше...
4 недели назад
А вы видели новую версию Stack Overflow? beta.stackoverflow.com Больше постов у меня в Telegram-канале: t.me/...kii или через поиск в Telegram по запросу «Сергей Озеранский».
1 месяц назад