Друзья, наша компания давно смотрит в сторону Open Source. И мы наконец-то оформили и открываем первую платформенную библиотеку, которая теперь будет развиваться как open-source проект.

И пока Миша Кумачёв пишет статью об этом, мы хотим дать вам микро вводную по теме. О том, как мы относимся к понятию Open Source в Dodo, расскажем в постах с хештегом #dodoopensource.

Для начала мы решили определить, что для нас 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

Недавно Олег Блохин рассказал о смысле математики простыми словами и очень милой картинкой. Не поделиться этим с вами было бы просто преступлением.
___________

🚀 В чём практический смысл математики?

Первое слово названия моей специальности в дипломе – «математик», и, хотя по работе мне не приходится брать интегралы или проецировать прямые на поверхности, я математику люблю, что-то решаю в свободное время и всячески стараюсь про неё рассказывать окружающим. Популяризировать, короче.

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

🦉Итак. Какая практическая польза от математики?

1. 😛 Математика – это язык, которым все другие дисциплины описывают окружающий мир.

Чем бы ты ни занимался: экономикой, физикой, биологией, историей, маркетингом, экономикой, искусством. Законы, которые ты открываешь могут быть широко применимы, если они могут быть выражены языком математическим или близким к математическому.

Сам язык математики очень богат, гораздо богаче, чем привычная алгебра или геометрия. И очень лаконичен. И его можно расширять. Парой строчек по 5-10 символов можно описать закон динамики популяции хищников и травоядных в замкнутой системе или задачу о колебании струны.

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

2. 🛠 Математика даёт аппарат для исследования описаний реального мира.

Когда ты сформулировал какое-то явление мира на языке символов (= на языке математики) – ты абстрагируешься от исходного явления и волен использовать самые невероятные методы для его исследования. Таким образом, например, появились мнимые числа и бесконечномерные пространства при решении задач физики. Никто не в праве тебя осудить, если твои формальные действия приводят к решению.

3. 💡 Математика даёт делать грандиозные выводы о реальном мире, по результатам исследования нескольких закорючек на бумаге

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

🐰Итого. Нахрена нужна математика в реальном мире?
1 – это язык для описания мира 😛
2 – это аппарат для исследования описания 🛠
3 – это механизм для формулирования выводов и предсказаний💡

И картинка!

Друзья, сегодня вечером в моем инстаграме состоится интереснейший прямой эфир с ИТ-директором или 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».