Мало просто сменить свою сферу работы на IT, желательно еще и стать хорошим разработчиком. Бывший тимлид и консультант Александр Усков рассказывает, как понять, что перед вами плохой разработчик и что с ним вообще можно делать

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

Этой статья раскрывает концепции Middleware в ASP.NET Core. К концу этой статьи вы получите четкое представление о следующих моментах:

- Что такое Middleware?

- Почему порядок расположения Middleware имеет значение?

- Методы Run, Use и Map.

- Как создать собственное Middleware?

- Как реализовать просмотр каталогов с помощью Middleware?

Привет, Хабр!

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

Привет, Хабр! Сегодня мы расскажем о том, как подходили к созданию сообщества практики по автоматизации DevOps CI/CD в Сбере. Рассмотрим предпосылки, методологии и лучший мировой опыт, который использовали, а также ключевые проблемы и ошибки. В этой статье опытом делится Рашид Галиев – руководитель группы развития методологии DevOps и внедрения инженерных практик CI/CD, эксперт команды ядра сообщества DevOps в Сбере.

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

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

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

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

Только что опубликовал в русской википедии перевод статьи Deployment environment.

Публикую этот перевод здесь также. Замечания и комментарии приветствуются.

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

Подозреваю, что есть инструменты, чтобы делать мою работу лучше, но я о них не знаю и не очень понимаю, где их достать;

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

Тяжело даются one-on-one, фидбек и общение, особенно когда надо поговорить не про работу, а про что-то еще.

То есть многие просто не знают, что делать, когда становятся тимлидами: сначала им сложно и некомфортно, у них не получается или получается не то, а ожидания бизнеса и команды не очень понятны. А потом им непонятно, как можно те самые sotf skills развивать, если каждый one-on-one отнимает массу сил. 

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

Привет, Хабр! Сегодня публикуем не совсем обычный для нас текст: решили сделать полезный гайд для новичков в код-ревью. Разобрались, кому нужна и не нужна эта практика, а еще — каких ошибок лучше избежать на старте.

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

• Введение в веб-разработку, что было раньше и что сегодня
• Начало создания веб-проекта
• Этап первый – процесс написания кода
• Этап второй – тестирование кода
• Этап третий – сборка проекта
• Этап четвёртый – развёртывание (deploy) кода
• Итоги
• Основные возможности PHP-фреймворка Laravel
• Полезные ссылки

• можно ли git «подстроить» под тот процесс разработки, который мне нужен?
• будет ли менеджер и заказчик удовлетворён этим процессом?
• будет ли легко работать разработчикам?
• смогут ли новички быстро включиться в процесс?
• можно ли процесс относительно легко и быстро изменить?

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

Привет! Я тимлид команды «Добро» в «Сравни.ру», мы занимаемся разработкой сервиса по подбору кредитных продуктов. 

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

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