Dodo Engineering

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

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

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

А какое правило ближе всего вам? 💬 — не молчи. 🙋🏻‍♂️ — предлагай. 👊🏻 — делай.

Три правила жизни: Не молчи. Предлагай. Делай. Именно в таком порядке. 1. Не молчи. Для начала надо научиться не молчать о проблемах. Это первый этап, и он уже может принести пользу. У многих есть стереотип, мол «критикуешь-предлагай». Он, конечно, хороший и имеет смысл, но если ты не знаешь, что делать, но понимаешь проблему — молчать хуже. Даже могут наехать, мол, ну ты молодец, проблему высказал, а предлагаешь-то что? И вот тут надо понимать, что даже одно озвучивание проблемы, этот навык «видеть проблемы» — уже дорогого стоит. Одно озвучивание проблемы уже может тригернуть изменения, запустить целую цепочку событий, которые приведут к чему-то значимому и, собственно, решению проблемы, не важно, какого она размера. В начале 2019-го у нас создалась платформа вокруг объединённых команд инфраструктуры и команды ядра в разработке. А всё началось просто с проблемы, которую кто-то высказал. Человек просто высказывал мысли и не молчал. 2. Предлагай. Научились не молчать, теперь давайте предлагать идеи. Это второй этап. Путь от первого этапа ко второму обычно быстрый. Есть проблема и есть варианты решений. Всегда есть, надо просто пофантазировать. Если вы смотрели фильм Дудя про Долину, там один из героев говорит: «Если вы не знаете, что делать, сделайте два варианта. А лучше три». И вот эта простая мысль: увидел проблему, подумай о трёх вариантах её решения и рассказывай её всем вместе с этими тремя вариантами. Easy. 3. Научились придумывать способы решений, теперь переходим к действиям. Это самый сложный переход. Осознать, что ты реально можешь сделать любые изменения. Если не сам, то с помощью кого-то другого. Не своими руками, так чужими, но главное — сделать. В данном контексте перейти от слов к действиям — это как завести мотор, дальше уже дело техники и мастерства вождения. Этот переход в сознании реально дается сложнее всего, особенно это видно по людям, которые сейчас больше ориентируются в менеджмент, нежели в технику. Почему? Да хрен его знает почему :) Ничего сложного в этом, на самом деле, нет, просто делайте и всё. Поставьте себе на телефон логотип Nike со слоганом! ______________ Этот пост написал наш СТО — Саша Андронов, за что ему огромное спасибо. Планируем каждую неделю делиться с вами мыслями этого мудрого, как черепаха, человека. #cto #ctododo

На этом вступительная часть постов #dodoopensource завершается. Рассказывать дальше про новые open-source проекты в Dodo?

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 составить список дальнейших доработок и заниматься ими постепенно.

О проекте: — Библиотека называется Dodo.HttpClient.ResiliencePolicies. — Исходный код доступен на GitHub. — Распространяется как NuGet-пакет. Мы будем очень рады, если эта библиотека окажется вам полезной. И, разумеется, в этой библиотеке есть ещё над чем поработать, так что ваши Issues и PR приветствуются.

Три... два... один... Запускаем проект Dodo Open Source! Мы давно задумывались о том, что нам как компании нужно инвестировать в Open Source и вносить вклад в комьюнити разработчиков. И начинаем мы с платформенной библиотеки для повышения надёжности HttpClient’а. *О предпосылках создания первого open-source проекта Додо читайте в статье Миши Кумачёва.

Книга Конрада Кокосы на русском языке. Над переводом трудилось русскоязычное .NET-сообщество. Наш разработчик Евгений Биккинин тоже приложил руку к этому изданию, вычитав несколько глав. Поэтому, если у вас будут какие-то претензии, можете писать их Жене. Он обещал объяснить, почему вы неправы (*это сарказм*). __________ Два посткриптума: 1. О самом проекте и том, с какими трудностями сталкиваются переводчики и разработчики, делая хорошие переводы узкоспециализированной, технической литературы на русский язык – читайте в статье на Хабре. 2. А если хотите заняться переводами иностранных публикаций о платформе .NET на русский язык — вступайте в чат переводчиков DotNetRu.

Вся правда о СТО Додо или 42 честных фидбека от разработчиков В честь ДР Саши Андронова мы собрали в Slack уютный закрытый чатик на нашу компашку из 100 человек и накидали диджитальных поздравлений от самого сердца. Получился такой забавный и трогательный портрет, что мы решили поделиться им с вами. В этой статье вся правда о том, что же он за человек такой — СТО Додо.

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

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

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

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

В чём роль 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, если нашлись баги или захотелось сделать новые доработки по проекту.

Друзья, сегодня вечером в моем инстаграме состоится интереснейший прямой эфир с ИТ-директором или CTO компании Dodo - Сашей Андроновым. О чем будем говорить? О будущем и настоящем. О разработке, новых технологиях, стеках, agile и scrum, waterfall и менеджменте в ИТ в целом) Додо - это все-таки IT-компания? Что такое "цифровая трансформация"? Как устроена разработка, процессы, структура IT, команды в Додо? Какую систему мы строим? В чем наша большая цель, долгосрочное видение и текущие вызовы? Какие преимущества получает наш бизнес благодаря системе Dodo IS? В чем заключается роль CTO? Как мотивировать разработчиков? Зачем программисты в Додо готовят пиццу и работают на кассе? И многое другое. Приходите вечером в моей уютный инста :) instagram.com/silauma

И картинка!

Недавно Олег Блохин рассказал о смысле математики простыми словами и очень милой картинкой. Не поделиться этим с вами было бы просто преступлением. ___________ 🚀 В чём практический смысл математики? Первое слово названия моей специальности в дипломе – «математик», и, хотя по работе мне не приходится брать интегралы или проецировать прямые на поверхности, я математику люблю, что-то решаю в свободное время и всячески стараюсь про неё рассказывать окружающим. Популяризировать, короче. Многие путают математику с алгеброй, геометрией, арифметикой. Она состоит из них, но не является ими. Так же как город состоит из домов, людей и инфраструктуры, но каждая из этих частей – ещё не есть город. 🦉Итак. Какая практическая польза от математики? 1. 😛 Математика – это язык, которым все другие дисциплины описывают окружающий мир. Чем бы ты ни занимался: экономикой, физикой, биологией, историей, маркетингом, экономикой, искусством. Законы, которые ты открываешь могут быть широко применимы, если они могут быть выражены языком математическим или близким к математическому. Сам язык математики очень богат, гораздо богаче, чем привычная алгебра или геометрия. И очень лаконичен. И его можно расширять. Парой строчек по 5-10 символов можно описать закон динамики популяции хищников и травоядных в замкнутой системе или задачу о колебании струны. Если ты сможешь описать свой вопрос, задачу, проблему на этом языке – её поймут в любой стране мира именно так, как ты задумал. Со всеми нетривиальными свойствами и исключительными случаями. Никаких разночтений или споров. Кроме того, некоторые описания неожиданно совпадают. Например, динамика популяций животных описывается очень похоже на колебания груза на пружинке! 🦊 2. 🛠 Математика даёт аппарат для исследования описаний реального мира. Когда ты сформулировал какое-то явление мира на языке символов (= на языке математики) – ты абстрагируешься от исходного явления и волен использовать самые невероятные методы для его исследования. Таким образом, например, появились мнимые числа и бесконечномерные пространства при решении задач физики. Никто не в праве тебя осудить, если твои формальные действия приводят к решению. 3. 💡 Математика даёт делать грандиозные выводы о реальном мире, по результатам исследования нескольких закорючек на бумаге После того, как ты опишешь и исследуешь своё описание мира при помощи производных, интегралов, дифференциальных уравнений и всевозможных методов, ты можешь вернуться и проинтерпретировать результаты своих изысканий. И, если ты хорошо выбрал модель, то ты можешь предсказывать будущее. 🐰Итого. Нахрена нужна математика в реальном мире? 1 – это язык для описания мира 😛 2 – это аппарат для исследования описания 🛠 3 – это механизм для формулирования выводов и предсказаний💡

Для начала мы решили определить, что для нас open-source проект через набор критериев, которым он должен соответствовать. В итоге получился список из шести пунктов: 1. В первую очередь у проекта должен быть owner. Это может быть как один, так и несколько человек. 2. Проект не должен содержать никакой бизнес логики, специфичной для конкретной компании. 3. У проекта должно быть реальное применение в повседневной работе. Выкладывать в Open Source «мертвые» решения, которые уже не используются, не имеет смысла, так как их придётся поддерживать искусственно, а этого никогда никто не будет делать. 4. У проекта должен быть публичный репозиторий на GitHub, и вся работа над ним ведётся публично (документация в wiki или README, issues, releases и т.д.). 5. Если артефактом open-source проекта является NuGet, npm или любой другой пакет, то он должен публиковаться в публичном репозитории пакетов от имени компании. 6. Проект нужно вести на английском языке. Это необходимое ограничение, чтобы быть доступными всему миру, ведь мир IT разговаривает на английском. В следующем посте разберём роль owner'а проекта. А пока будем ждать от вас фидбек по критериям open-source проектов, всё ли мы учли или забыли что-то крайне важное? #dodoopensource