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

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

Я составил список своих задач и разбил их на категории. Кстати говоря, добрую половину этих задач я повесил на себя сам.

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

1. В монолите концентрировалось большое количество бизнес-процессов, которые охватывали сразу несколько потребителей: пользователей облачной платформы, сейлз-менеджеров (через CRM-систему), администраторов, обработчиков метрик. Получилась такая одна большая точка отказа сразу для 4 групп бизнес-процессов.
2. Каждый бизнес-процесс потребляет свой объем ресурсов. Например, для обработки метрик нужно 5 подов (чтобы запараллелить и ускорить обработку), для администрирования хватит и одного. Так как у нас все в одном сервисе, при масштабировании монолита мы будем ориентироваться на самый «прожорливый» бизнес-процесс. Часть ресурсов будет просто простаивать.
3. Хотелось добиться гранулярности, чтобы независимо писать и деплоить код для каждого бизнес-процесса. И не переживать, что какие-то изменения в одном бизнес-процессе неожиданно отрикошетят в соседний.

Я занимаю должность СТО уже около десяти лет.

К настоящему времени у меня сложилась довольно четкое понимание того, кто такой CTO, что делает CTO успешным, а что - нет.

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

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

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

Меня зовут Владимир Точилин, я работаю в группе развития рекламных продуктов и стабильности. Вместе со своим коллегой, Александром Самусенко, я расскажу, как мы создали новый инструмент realtime-детекции разладок в проде рекламных технологий. Мы работаем с системой, где на отдельные кластеры нагрузка превышает 1000000 RPS. 

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

Может ли kubernetes сделать жизнь админов небольших и средних компаний проще или же это шайтан-машина для кровавого enterprise и оголтелых стартапов?

Всем привет, меня зовут Ростислав, я занимаю должность Front Lead в компании ДомКлик. Хочу поделиться с вами опытом создания Web Core команды и сразу ответить на следующие вопросы:

• Необходима ли такая команда в компании?

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

• Выгодно ли внедрять такую команду?

Безусловно. Изначально было сложно измерить и спрогнозировать выгоду от её создания, все расчеты, P&L были на словах, в цифрах — только примерные предположения. Спустя год мы можем посчитать сэкономленное время, профиты, и все расчеты говорят о том, что это было не зря.

• На долгую перспективу ли эта команда?

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

• Чем эта команда занимается?

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

Начало

Eloquent ORM кажется простой, но под капотом существует много полускрытых функций и менее известных способов. В этой статье я покажу вам несколько трюков.

Привет, Хабр! Вот уже почти 5 из 10 лет я совмещаю работу сетевиком с любимым хобби — подкастом про IT. За это время наш сервер для аудиотрансляций развивался, менялся и оказался полезен не только нам, но и коллегам. Недавно я правильно клонировал нашу сборку на базе Linux для радио ЦОД.fm в DataLine и решил поделиться своими наработками со всем сообществом.

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

Есть такой продвинутый инструмент Scrutinizer CI.

Для OpenSource он абсолютно бесплатный и платный для приватных репозиториев.

Вы о нем слышали, наверное, а если нет, то лично я использую его для анализа кода на различного рода уязвимости, а также в качестве замены статическому анализатору типа Psalm, ну и для покрытия конечно же, т.к. при довольно простой сквозной интеграции с GitHub оно внедряется в ваши PR и можно ревьюить код, наблюдая покрытие по аналогии с Cubertura в GitLab.

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

Поэтому я решил поделиться с вами своим опытом интеграции со Scrutinizer CI, рассказать о нюансах и тд...

Привет!

Саша Инкин и я регулярно пишем на Хабр статьи по Angular. Почти все они основаны на нашем опыте разработки большой библиотеки компонентов.

Эту библиотеку мы развиваем, перерабатываем и дополняем уже несколько лет, а свои идеи проверяем на нескольких десятках проектов Тинькофф Бизнеса и внутренних систем компании. Мы рады сообщить: выложили нашу библиотеку в открытый доступ!

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

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

Продолжу выкладывание примеров использования GitHub'а как инструмента обучения.
Рассмотрим версию работы нескольких команд над одним большим проектом с подпроектами.

Сталкиваясь с неопределенностью в процессе разработки, нам стоит пересмотреть взгляды на то, что для нас значит "двигаться быстро".

Если вы только начали изучать React, для отработки основных концепций этого фреймворка можно создать простое приложение. Первое, что приходит в голову, — это приложение для составления списка дел или покупок. С него и начнем. Основные концепции React изложены в официальной документации на сайте, а в предыдущих записях моего блога можно найти ссылки на другие руководства по работе с React.

Запустите VS Code или любой другой редактор кода. Для создания React-приложения наберите в терминале команду:

В рамках современной микросервисной архитектуры мы можем разделить микросервисы на две основные группы в зависимости от их взаимосвязи и взаимодействия. Первая группа представляет из себя внешние микросервисы, которые напрямую доступны пользователям. В основном это API на основе HTTP, которые используют обычные текстовые сообщения (JSON, XML и т. д.), оптимизированные для использования сторонними разработчиками, использующие передачу репрезентативного состояния (REST) ​​в качестве коммуникационной технологии. 

Распространенность и хорошая поддержка REST играют решающую роль в успехе внешних микросервисов. OpenAPI предоставляет четко определенные спецификации для описания, создания, использования и визуализации REST API. Для таких API существуют системы управления API, которые обеспечивают безопасность, ограничение скорости, кеширование и монетизацию наряду с реализацией бизнес-требований. В качестве альтернативы REST API на основе HTTP можно использовать GraphQL, но это уже тема для отдельной статьи.