Друзья, сегодня вечером в моем инстаграме состоится интереснейший прямой эфир с ИТ-директором или CTO компании Dodo - Сашей Андроновым. О чем будем говорить? О будущем и настоящем. О разработке, новых технологиях, стеках, agile и scrum, waterfall и менеджменте в ИТ в целом)

Додо - это все-таки IT-компания? Что такое "цифровая трансформация"? Как устроена разработка, процессы, структура IT, команды в Додо? Какую систему мы строим? В чем наша большая цель, долгосрочное видение и текущие вызовы? Какие преимущества получает наш бизнес благодаря системе Dodo IS? В чем заключается роль CTO? Как мотивировать разработчиков? Зачем программисты в Додо готовят пиццу и работают на кассе? И многое другое.

Приходите вечером в моей уютный инста :)

instagram.com/silauma

В чём роль owner'а open-source проекта?

Несмотря на то, что open-source проект – продукт коллективного интеллектуального творчества, без owner'a он существовать не может. Продолжаем серию постов #dodoopensource и сегодня рассказываем про роль owner'а проекта.

Owner’ом проекта может быть как один, так и несколько человек из компании, которые хотят развивать проект. Важно понимать, что open-source проект накладывает ряд обязательств на его владельца:

1. Owner – это явное принятие ответственности. Owner отвечает за развитие проекта. К нему придут в случае проблем или вопросов по проекту.
2. Project ownership – это работа. Работа, которая делается как в рабочее, так и нерабочее время. К этому нужно быть готовым.
3. Owner – хранитель культуры проекта и комьюнити вокруг него.
4. Owner – публичное лицо при общении с комьюнити. Развитие комьюнити – важная задача owner’а.

Какие функции должен выполнять owner?

1. Формировать видение и определять границы. Если, например, проектом является платформенная библиотека, то задача owner’а решить, какой функционал должен быть в неё включен, а какой находится за scope’ом этой библиотеки.
2. Формировать правила работы с репозиторием: правила оформления release notes, issues, оформление PR.
3. Ревьюить PR’ы и самостоятельно развивать проект. Качество кода библиотеки – его ответственность вне зависимости от того, кто этот код написал.
4. Отвечать на issues.
5. Самостоятельно создавать issues, если нашлись баги или захотелось сделать новые доработки по проекту.

А вы готовы взять на себя роль owner'a open-source проекта?

HIRING IS BACK!

Нет времени объяснять, просто сдувайте технопыль со своих резюме и отправляйте их нам на HR@dodopizza.com или сразу @Darja_Mamlygina, с сегодняшнего дня мы возобновили найм!

Словарь редких IT-терминов #09: cyberflasher (от русск. киберэксгибиционист).

Поздравляем c #GeekPrideDay!

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

Живите долго и процветайте!

Вся правда о СТО Додо или 42 честных фидбека от разработчиков

В честь ДР Саши Андронова мы собрали в Slack уютный закрытый чатик на нашу компашку из 100 человек и накидали диджитальных поздравлений от самого сердца.

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

Книга Конрада Кокосы на русском языке. Над переводом трудилось русскоязычное .NET-сообщество.

Наш разработчик Евгений Биккинин тоже приложил руку к этому изданию, вычитав несколько глав. Поэтому, если у вас будут какие-то претензии, можете писать их Жене. Он обещал объяснить, почему вы неправы (*это сарказм*).
__________

Два посткриптума:

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

2. А если хотите заняться переводами иностранных публикаций о платформе .NET на русский язык — вступайте в чат переводчиков DotNetRu.

Три... два... один... Запускаем проект Dodo Open Source!

Мы давно задумывались о том, что нам как компании нужно инвестировать в Open Source и вносить вклад в комьюнити разработчиков. И начинаем мы с платформенной библиотеки для повышения надёжности HttpClient’а.

*О предпосылках создания первого open-source проекта Додо читайте в статье Миши Кумачёва.

О проекте:

— Библиотека называется Dodo.HttpClient.ResiliencePolicies.
— Исходный код доступен на GitHub.
— Распространяется как NuGet-пакет.

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

F&Q по Open Source для начинающих

1. Я написал маленькую внутреннюю библиотеку, кому она может быть интересна? Зачем её выкладывать в Open Source?

Когда вы писали свою библиотеку, вы решали какую-то конкретную проблему в компании. Если эта проблема возникла у вас, то почему вы считаете, что её не может быть у других? Такие вещи можно и нужно публиковать.

2. Я выложил проект в Open Source, в issues меня попросили добавить фичу X, но мне кажется, что это out-of-scope моего проекта.

Это совершенно нормальная история. Адекватная реакция – рассказать своё видение развития проекта, объяснить, что фича X не ложится в это видение и закрыть тикет. Важно понимать, что любые open-source проекты мы делаем в первую очередь для себя, для того, чтобы они решали нашу проблему. Мы отдаём миру наш проект таким, какой он есть, со своими плюсами и минусами. Нет задачи удовлетворить требованиям всех разработчиков мира. Говорить нет – нормально. В конце концов, если человеку нужно, то он сделает себе fork и добавит фичу или выберет другую библиотеку.

3. В моей библиотеке не реализован какой-то функционал. Означает ли это, что я не могу выложить её в Open Source до тех пор, пока не сделаю законченный продукт?

Развитие любого проекта – это бесконечный процесс. Всегда что-то будет не реализовано. Совершенно нормально выложить ваш open-source проект и в issues составить список дальнейших доработок и заниматься ими постепенно.

На этом вступительная часть постов #dodoopensource завершается.

Рассказывать дальше про новые open-source проекты в Dodo?

Три правила жизни: Не молчи. Предлагай. Делай.

Именно в таком порядке.

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

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

2. Предлагай. Научились не молчать, теперь давайте предлагать идеи. Это второй этап. Путь от первого этапа ко второму обычно быстрый. Есть проблема и есть варианты решений. Всегда есть, надо просто пофантазировать.

Если вы смотрели фильм Дудя про Долину, там один из героев говорит: «Если вы не знаете, что делать, сделайте два варианта. А лучше три». И вот эта простая мысль: увидел проблему, подумай о трёх вариантах её решения и рассказывай её всем вместе с этими тремя вариантами. Easy.

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

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

Почему? Да хрен его знает почему :) Ничего сложного в этом, на самом деле, нет, просто делайте и всё. Поставьте себе на телефон логотип Nike со слоганом!
______________

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

#cto #ctododo

А какое правило ближе всего вам?

💬 — не молчи.
🙋🏻‍♂️ — предлагай.
👊🏻 — делай.

Словарь редких IT-терминов #10: GetTaras.

*Смешнее некоторых кусков кода могут быть только комментарии к этому коду, но это уже совсем другая история.

Ушла эпоха. 2016-2020 гг. В мае мы удалили последний наш эластик с прода. Впереди нас ждёт новая эра — эра Кусто.

***

А что не так с Эластик?
1. Очень дорого. Частично приходилось платить в долларах.
2. Работали по системе Iaas+Paas низкого качества, что требовало постоянного внимания и поддержки.
3. Бас-фактор — только один человек в компании по-настоящему знал, как управляться с эластиком.
4. За свои деньги работает слишком медленно и умирает.

Что хорошего в Azure Data Explorer (Kusto)?
1. Дешевле.
2. Полноценная PaaS модель.
3. Легко масштабируется. Например, можно скейлить кластер вниз на ночь и возвращать обратно утром.
4. Работает быстрее и надёжнее.
5. Можно хранить логи дольше (планируем год) и не потерять при этом производительность.
6. Удобная интеграция с другими сервисами.
7. Вся мощь колоночной БД в твоих руках.
8. Гибкие настройки на все случаи жизни.
9. Посредник между Кусто и Кибаной в Open source, а значит мы сами сможем сделать нужные фичи.

Пока ребята из DE or DIE определяются с датой третьего митапа про управление данными, мы хотим поделиться с вами видео и материалами с предыдущих двух.

***
1. Версия для настоящий гиков на GitHub.

2. Версия для ненастоящих гиков:
— Какие дата инженеры бывают и чего от них все хотят? (Николай Марков).
— Что под капотом у Яндекс.Такси? (Евгений Ермаков).
— Обзор Lambda- и Kappa-архитектур (Егор Матешук).
— Как устроена платформа управления данными в Яндекс.Маркет? (Денис Хуртин).
***

Следите за анонсом следующего митапа в этой группе или в чате сообщества «DE or DIE».

А вам интересно узнать больше про управление данными и Data Engineering?

Книги, которые рекомендует наш СТО

Есть несколько книг, которые Саша Андронов считает очень полезными. Сейчас он расскажет: что это за книги и чем они цепляют.

1. The phoenix project (Gene Kim, Kevin Behr, George Spafford). RU, EN.

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

2. Netflix. Сильнейшие (Patty McCord). RU, EN.

О чём: она о том, как Netflix 14 лет строил свою культуру свободы и ответственности. Прочитав её, кажется: вот же он — рецепт успешной культуры! Только между строк там постоянные упоминания, мол, ребята, мы ГОДЫ шли к этим идеям и внедряли их. Кстати, про Netflix есть ещё одна книга, её пока не читал, но стоит. Называется «That will never work».
Оценка СТО: обязательно к прочтению People Leadership Team.

3. The everything store (Brad Stone). RU, EN.

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

4. Leading (Alex Ferguson). RU, EN.

О чём: книжка подойдёт не всем, полное удовольствие получите только, если болеете футболом. Советую почитать даже фанатам Ливерпуля, так как книга действительно о человеке, который на протяжении 26(!) лет тренировал одну футбольную команду. 13 побед в Английской Лиге и 2 Лиги Чемпионов. Футбольные команды проходят циклы роста, затем падают. Игроки стареют и уходят, их надо заменять, работать с молодежью, создавать конкуренцию и растить лучших. Как работать с людьми, как уметь их настроить, как стать для них тем лидером, за которым они пойдут.
Оценка СТО: опционально к прочтению.

______________________

Недавно Саша завёл свой телеграм-канал про технологии, развитие senior и lead-разработчиков, найм и менеджмент в IT и будет рад видеть вас там, присоединяйтесь!

В этом году вы прочитали хотя бы одну книгу?

Когда думаешь, что ты умнее базы данных...