Книга Конрада Кокосы на русском языке. Над переводом трудилось русскоязычное .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 и будет рад видеть вас там, присоединяйтесь!

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

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

Что такое «вкусная пицца»?

А что такое вкусная пицца для вашего друга? А теперь представьте, что у вас 12 миллионов друзей в 13 странах мира и вам нужно выпустить линейку вкусных пицц для них всех.

Мы решили эту задачу и написали статью, в которой есть ответы на извечные вопросы:

1. Чем больше начинки, тем вкусней?
2. Горячее точно лучше холодного?
3. Где твои крылья, которые так нравились мне?

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

Мы выходим за рамки и начинаем делать комиксы с внешними авторами. Если вы знаете прикольные IT-словечки — присылайте, будем рисовать.

А за первый выпуск-коллаборацию огромное спасибо Антону Катаеву из Advase Digital!

Мы обнаружили, что в #sailormoonredrawchallenge не хватает версии в пиксель арте и решили это исправить. Но и этого нам было мало, поэтому мы попросили Лёшу Берёзку (воина iOS-разработки) покосплеить. Зачем? По фану.

Кто получился лучше всех?

❇️ — Пиксель Мун.
🌙 — Сейлор Мун.
🍃 — Берёзка Мун.

HIRING IS BACK! Срочно в номер две горячие вакансии.

1. iOS-developer (Нижний Новгород).
Ключевой фокус: проект по оформлению заказов в наших ресторанах через приложение. Сначала запустим в России, а потом и в других странах (Германия, Чехия, Польша).
Узнайте больше у Дельгиры (@Delunko) или тут.

2.Scrum master (Process / People lead) (Москва).
Ключевой фокус: выстраивание процессов в плотном взаимодействии с Product owner и Tech lead.
Узнайте больше у Саши (@alexpanev) или тут.

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

#iosdeveloper #scrummaster #itvacancy