Словарь редких IT-терминов #27

Баглог задач — бэклог разработчика, который не умеет кодить.

#ithumor #comics #it #itfun #dododevjokes

Новая Tech Company

Мы решили выделить IT команду Додо в отдельную технологическую компанию. Мы перестаем быть командой, которая развивает Dodo IS для бизнеса пиццы, мы становимся компанией, которая развивает Dodo IS для рынка франшиз. 

Нам нужно научиться управлять IT не как командой внутри структуры Додо, а как компанией внутри Dodo Brands. У нас есть клиенты на внутреннем рынке, их уже три (Додо, Дринкит, Донер 42), есть своя система управления, найма и развития людей, работа с приоритетами, стратегия развития Dodo IS. В технологической платформе мы имеем потенциал даже создавать свои продукты. Все это позволит сделать наши процессы и работу эффективнее и прозрачнее и поможет нам быстрее развивать бизнес в рамках Dodo Brands.

Я когда думал обо всем этом, оказалось, от меня давно ждут управления IT как компанией, нежели командой. За все время в Додо я, хоть и фокусировался на технических вещах, но все же было много других направлений, порой слишком много. Теперь будет проще, у нас появится CTO, фокус которого будет строго на технике. Даже когда описывали роль, больше фокусировались на том что ему НЕ придется делать 🙂

А название я пока не напишу, а то вдруг заспойлерю.

В июне мы решили подробно и обстоятельно описать систему Dodo IS и написали статью «История архитектуры Dodo IS: путь бэкофиса». В ней рассказали о монолите 2016 года, и о том, как его разгружали долго и тяжело. Большинство комментариев к статье сводилось к вопросу «Зачем переписывать архитектуру и делать такие масштабные и долгие изменения?» Поэтому в этой статье продолжим историю, заодно ответив на вопросы. Расскажем, как начиналась разработка Dodo IS, как выглядела изначальная архитектура, как появлялись новые модули, и из-за каких проблем пришлось всё менять.

Словарь редких IT-терминов #28

Хантико — HR, который очень долго не может нанять кандидата.
#ithumor #comics #it #itfun #dododevjokes

Как стать контрибьютором в Open Source проект?
Поучавствовать в Dodo Hacktoberfest! У нас в Dodo Engineering есть Open Source проекты, мы любим сообщество и хотим его развивать. Но когда мы только запускали проекты в Open Source — было страшно и непривычно. Поэтому мы решили запустить месячный (в октябре) Open Source марафон, в котором мы будем помогать вам делать первые шаги в Open Source сообщество, а заодно его развивать.

Что надо делать?
1. Регистрируйтесь на марафон Dodo Hacktoberfest.
2. Вносите вклад в наши публичные репозитории (в закреплённые). Единица вклада — принятый PR, код, который попал в репозиторий. Отдельным вкладом в проекты также считаются принятые ISSUE (те, что не были закрыты сразу по причине бессмысленности).
3. Мы будем давать обратную связь по вашему коду и помогать улучшить его.
4. По итогам месяца топ контрибьютеры получат призы.

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

Мы хотим, чтобы Open Source сообщество росло и крепло не только внутри Dodo Engineering, но и снаружи. Присоединяйтесь к марафону, вступайте в чат в Телеграмм, который посвящён нашим Open Source проектам — будем развивать сообщество вместе!

Словарь редких IT-терминов #29

Авралопитек — человек, который кидает в тебя задачками с просроченными дедлайнами.
#ithumor #comics #it #itfun #dododevjokes

Domain-Driven Design (DDD) или предметно-ориентированное проектирование — набор правил, которые помогают проектировать ПО со сложной бизнес-логикой быстрее, чем без него. Но в самом DDD много абстракций и понятий. Всё ещё усложняется тем, что статей с разбором принципов и понятий DDD много (не считая трех разноцветных книг), а вот реальных примеров — не очень. Из-за этого на него страшно смотреть, не то, что внедрять. Чтобы убрать немного сомнений, мы написали статью о том, как с помощью DDD мы решили у себя большую проблему с «бумажными» ревизиями. Будем рады, если материал поможет, когда задумаетесь о DDD или даже захотите применить в своём проекте.

Словарь редких IT-терминов #30 – continuous debugging

Главное, что работает.
#ithumor #comics #it #itfun #dododevjokes

Почему разработчики контрибьютят в Open Source проекты?

Чтобы узнать ответ на вопрос в мае мы провели опрос на эту тему. Первые три популярных причины:

— получать эмоции от пользы их кода/продукта;
— развиваться, как профессионал;
— решать свою проблему, используя какую-либо Open Source библиотеку.

Ответы практически совпадают с нашими принципами. Поэтому тогда же, в мае, мы запустили Dodo Open Source. На дворе октябрь, и Open Source в Dodo Engineering развивается, да так, что дорос до Dodo Hacktoberfest — Open Source марафона.

Марафон идёт весь октябрь, а до конца месяца две недели, значит самое время:

👉 зарегистрироваться;
🧩 внести вклад в наши публичные репозитории;
🗣 получить обратную связь по вашему коду;
🎊 по итогам месяца получить приз (мерч), как топ-контрибьютер.

Присоединяйтесь к марафону — будем развивать сообщество вместе!
#opensource #dodoopensource

21 октября 2020 года.

Создана компания Dodo Engineering! 🥳

Начинается новая глава в нашей истории. Скоро расскажe об изменении ролей и о новом CTO.

PS. Число 21, видимо, с нами навсегда 🙂

Что случится, если отказаться от отдельной команды тестирования и перевести всех QA в команды разработки?

На первый взгляд, будет хорошо: разработчики будут писать автотесты сами, ошибки — предотвращаться «в зародыше», а QA работают над качеством. Но на «второй взгляд» всё может оказаться не так: никто не будет думать о качестве, автотестами никто не будет заниматься, а у разработчиков без команды тестирования станет только больше работы. Именно с таким проблемами мы столкнулись, когда «разогнали» команду тестирования. Причина проблем в том, что мы не спрогнозировали последствия второго порядка и не были готовы к ним готовы. Сейчас мы их исправляем и можем об этом рассказать. Как работала команда QA раньше и как работает сейчас, какой урон тестированию нанесла «реорганизация» команды, что такое последствия второго порядка, как они возникают и как попробовать их предугадать, чтобы не было так больно., мы описали в статье.

Словарь редких IT-терминов #31 – ждуниор разработчик

В каждом есть немного ждуниора.
#ithumor #comics #it #itfun #dododevjokes

Когда говорят «Open Source», обычно первые ассоциации — это Ричард Столлман и Линус Торвальдс. Но Open Source начался не с них. Когда в 50-х учёные и инженеры писали ПО, например, для IBM 701, они безвозмездно обменивались результатами своего труда и работали над улучшениями программ своих коллег. Тогда еще не было проприетарного (закрытого) ПО, но Open Source проекты уже были. Это было задолго до Столлмана и Торвальдса. В истории Open Source было много интересного: программы для «Оборонного калькулятора», коммерциализация UNIX, письмо Билла Гейтса, манифест GNU, Linux и миллиардные сделки покупок Open Source компаний. Мы попробовали разобраться в истории и узнать с чего начался Open Source, какие события способствовали его развитию и почему без Open Source IT не был бы таким, какой он есть.

Если вам интересен Open Source, то, возможно, наш взгляд на историю тоже будет занимателен.

В проекте Dodo Open Source пополнение — kubectl shovel

Kubectl shovel — это плагин для kubectl, позволяющий собирать диагностику с .NET Core приложений, запущенных в Kubernetes, например, для анализа производительности или утечек памяти. При этом с плагином нет необходимости вносить какие-либо изменения в эти приложения.

Он может работать с приложениями .NET Core 3.0+ и кластерами Kubernetes с Docker runtime. Поддерживаются диагностические инструменты dotnet-gcdump и dotnet-trace.

О проекте.
— Автор проекта — Антон Каймакчи.
— Репозиторий GitHub.
— Установить можно через krew.
#opensource #dodoopensource

Новый CTO в Dodo Engineering

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

В Додо развиваться может каждый. В 2015м в Додо пришел Паша Притчин, пришел разработчиком. Был в Core-команде, занимался сайтом, системой аутентификации, переводил куски Dodo IS на .NET Core, собирал команду один раз, второй раз, третий раз и каждый раз умудрялся делать свои команды все сильнее и сильнее! Затем перешел в команду Платформы и в 2019м возглавил ее, усилив развитие SRE-практик и стабильности Dodo IS.

В декабре 2020 он становится новым CTO в Dodo Engineering. За все это время я убедился в главном – Паша один из самых надежных людей, которых я встречал.

PS. Паша, я знаю, ты это читаешь. С тебя статья о том как пройти путь от разработчика до CTO 🙂

Словарь редких IT-терминов #32 — хоронимки.

Тун-ту-ду-ду-тун-тун...
#ithumor #comics #it #itfun #dododevjokes

Программирование — творческая работа. Но в ней много рутины: поиск, перемещение и редактирование текста (читай кода), создание файлов, написание часто повторяющихся конструкций. Рутина — часть рабочего дня, но тратит время и выматывает — такое точно счастья не приносит.

Команда, в которой работал наш iOS-разработчик Саша Спиричев, над этим задумалась и полтора года назад стала практиковать изучение шорткатов, хоткеев, сниппетов и файловых шаблонов в Xcode. Например, распечатывали листы с расширенными командами (базовые уже знали) и держали их под рукой, чтобы учить. Это вошло в практику и теперь даже стало частью онбординга. А чтобы принести пользу не только своей команде, Саша описал все команды (и опыт) в большой статье. Получилась «методичка» по командам в Xcode, которая поможет iOS-разработчикам работать эффективнее. Добавляйте в закладки, чтобы посмотреть при случае (а навигация в статье поможет быстро найти то, что нужно).

Энергия — самое главное для предпринимателя. У предпринимателя всегда есть энергия взяться и что-то сделать, принять на себя ответственность. Их не отпугивают риски. И они могут заставить людей поверить в то, чего ещё нет, — как раз для этого и нужна энергия.

https://news.microsoft.com/ru-ru/features/Fyodor-Ovchinnikov/