Привет, Хабр! Я Федор Щудло, team lead и fullstack-разработчик. Всего я в разработке 15 лет, из них 11 в роли team lead.

Три года назад я сменил работу и занялся проектом, состояние которого можно описать кратко: ему 25 лет.

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

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

Как результат, разработка шла с большими накладными расходами (все делали долго), и с высокими рисками (выкатили и разломали прод). А команда при этом работала на износ.

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

За многие годы моей карьеры я столкнулся с множеством вызовов и уникальных ситуаций, которые позволили мне глубоко погрузиться в мир гибкого управления проектами. Думаю, статья будет полезна РМ’ам всех уровней.

В целом, эти методологии и инструменты – это более чем просто методы управления проектами; они представляют собой стратегии выживания и процветания в мире, где изменения – это новая норма.

Гибкость в управлении проектами – это способность адаптироваться к меняющимся условиям и требованиям без потери эффективности. Использование правильных инструментов и техник может значительно улучшить адаптивность команд и проектов.

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

Эта статья — о секции по проектированию систем, которая стала появляться на собеседованиях в российских компаниях. В ней за час предлагается проработать дизайн highload системы по функциональным и нефункциональным требованиям, тем самым предъявив эксперту свои знания сразу из множества областей.

Я поделюсь своими впечатлениями от участия в этом формате, рассмотрю проблемные моменты и предложу, что с ними можно сделать.

Ory Kratos - современный cloud native сервер идентификации с поддержкой PassKeys, MFA, FIDO2, TOTP, WebAuthn, с возможностью управления профилями, схемами пользователей, входом через внешние сервисы, регистрацией, восстановлением аккаунта, с поддержкой passwordless входа. Написан на Go, headless, API-first.

Целью этой статьи не является сравнение с другими популярными сервисами идентификации, которые дальше будут упомянуты, но будет рассмотрен основной функционал и мой опыт использования в пет-проектах.

Недавно меня спросили, какие фреймворки обратной связи я знаю. Я растерялся и сходу вспомнил только бутерброд, а также то, что хвалить нужно публично, а ругать — приватно. Это заинтриговало меня: какие же существуют практики для правильной обратной связи?

Давайте рассмотрим гипотетическую ситуацию: коллега принёс в офис кота, и тот поцарапал ваш ноутбук. Как правильно дать обратную связь, используя разные фреймворки?

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

Вместе с HR BP компании TAGES Маргаритой Рачкулик разбираемся, как двигаться по карьерной лестнице быстро и уверенно, правильно отслеживать и оценивать свой рост, а также выбирать верные шаги для достижения карьерных целей.

На рынке не так много книг, которые помогают начинающим тимлидам, которые еще вчера писали код и строили архитектуру, понять, как нужно приступать к работе с людьми и строить свое развитие по ветке управления. Это, естественно, две популярные книги: "Мама, я тимлид!  Практические советы по руководству IT-командой" Перескоковой Марины и "Как пасти котов. Наставление для программистов, руководящих другими программистами" Дж. Ханк Рейнвотера.

И вот на свет вышка книга: "Become an Effective Software Engineering Manager: How to Be the Leader Your Development Team Needs", которую Издательство Питер @ph_piter перевело как: "Карьера Software Engineering Manager. Эффективное управление командой разработчиков ПО". Не нужно пугаться позиции "Software Engineering Manager" - это именно что тимлид в понимании рынка РФ. И эта книга по своей сути является такой же отправной точкой в карьере начинающего тимлида, как и две предыдущие, но немного иначе!

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

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

Всем привет!

Сегодня хочу поделиться с вами личной историей преодоления и теми инструментами, рекомендациями и выводами по планированию, которые я нашла на своём непростом пути управления временем и командой, личными ресурсами и эффективностью.

Я приведу импровизированный кодекс, который поможет вам выбраться из ямы микроменеджмента и захлёстывающего с головой потока задач, или, если вам повезло, то понять как в него не попасть. Так что если вы управленец/менеджер/тимлид, то вам должно пригодиться. Но сразу скажу, некоторые рекомендации могут быть специфичными, чисто агентскими.

Хочу поделиться этой инфой потому, что знаю, что где-то на свете сейчас сидит, обняв коленки, менеджер/тимлид, который просто очень хочет на ручки и чтоб его обняли, а не вот это всё 😢

Коллега - я с тобой ✊ Держись, ты разберёшься и станешь сильнее и опытнее, чем был.

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

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

В большинстве учетных систем, типа нашего СБИС, рано или поздно возникает проблема быстрого отображения реестра, в который по просьбам бизнес‑пользователей накручено несколько комбинируемых фильтров с очень редкой выборкой, ну никак не ложащихся в вашу красивую структуру базы данных и индексов базовой таблицы реестра — что‑нибудь типа "список продаж покупателям, чей день рождения выпадает на 29 февраля".

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

Всем привет. Меня зовут Нина Пакшина, я разработчик “Лента Онлайн” и часть операционной команды в сервисе доставки продуктов.

В данной статье на примере языка Go я расскажу о том, как мы внедряли Kafka в связке с Schema Registry и Protobuf в качестве формата сообщений.

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

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

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

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

Что же делать? Конечно, призвать на помощью железную машину — пусть она сама ищет баяны.

Аннотация

PostgreSQL 16: Часть 3 или Коммитфест 2022-11

Вышел очередной обзор Павла Лузанова. Самое интересное из первых коммитфестов можно прочитать в предыдущих статьях серии: 2022-07 (ru / en), 2022-09 (ru / en).

Postgres-сообщество и образование

Что для вас PostgreSQL-комьюнити?

Живёт своей жизнью затея Райана Буза (Ryan Booz) - его Пятнецы (PGSQL-Phridays). На 3-м этапе этого флеш-моба ход Пэта Райта (Pat Wright). В отличие от обычных пятниц и PG-пятнец Шона Томаса, PGSQL-пятнецы случаются раз в месяц, и эта, 3-я пятнеца в 2022-м последняя. И вот вопрос: желающих приглашают ответить на вопрос: What is the PostgreSQL community to you?

Postgres - один из крупнейших open source проектов. Он создавался многие года. Кодовая база накопилась огромная. Мне, как программисту, всегда было интересно как он работает под капотом. Но не про SQL пойдет речь, а про язык на котором он написан. Про C. 

С общей архитектурой можно ознакомиться здесь

Для начала поймем, что происходит до входа в главный цикл сервера.

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

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

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