Все привет! Меня зовут Денис Боровиков. Сейчас живу в Берлине, разрабатываю поиск в Zalando.

Zalando - это крупнейший онлайн-магазин одежды в Европе, всего работает около 1000 разработчиков.

Из технологий используется практически всё :) В том числе и BigData, программирование GPU и так далее.

До этого довелось работать в разных компания, из заметных это hh.ru и Deutsche Bank.

На этой неделе хотелось бы ещё разок пройтись по наболевшим темам :)

@backendsecret говорят отношение к работникам в заландо потребительское. это правда ?

Начну про то, как устроена разработка в Zalando, так как это весьма необычно.

Так вот организация построена на внедрении демократических принципов

У команд полная автономия и большинство решений принимаются голосованием внутри.

Команда решила писать на Erlang? Так тому и быть!

Но права даются с ответственностью - команда самостоятельно отвечает за тестирование и деплой.

@mkn8rd @backendsecret Заландо это круче Яндекса ;) Самая быстрорастущая компания в Европе за все времена.

Каждой команде дается отдельный AWS аккаунт, дальше все в твоих руках :)

Хочешь Lisp? Отлично, но успевать за сроками, деплоить и саппортить тебе, так что решай сам.

Другая особенность это то, что у тебя 2 босса. Один это обычный босс, второго ты выбираешь себе сам

Что-то вроде народных депутатов :) Подход называется Radical Agility.

Ну да бог с этим манагерством, поговорим про технологии :)

Другая интересная штука у нас - это деплой

Для деплоя используется опен-сорсный тул - stups.io, разработанный у нас.

Его изюминка - immutable стеки. Ansible/Salt - вчерашний день :) Собираешь Docker образ, и специльной тулзой раскатываешь.

Тулза создает новый стек. Тестируешь, если все ок, то трафик (или часть) льешь на новый стек. Старый потом убивается.

Продолжая тему деполя. Основной формат деплоя - Docker. Что бы обеспечить иммутабельность деплоя пришлось сделать свою докер-репу.

Отличие кастомной репы в том, что запрещены SNAPSHOT-теги. Соответственно новый деплой это всегда новый тег в докере

Так же имеется репозиторий проектов (Kio). Через него аппрувятся релизнутые образы. Без аппрува Docker-образ просто не раскатается по проду

И естественно последнее время мой основной подход к построению систем - это микросервисы

При миграции на микросервисы самая типовая проблема - это дезинтеграция данных.

Раньше ты мог сджойнить 2 таблицы в бд, а теперь они под управлением разных сервисов. Что же делать, %username%?

@backendsecret а как же изменение модели данных и миграции?

@backendsecret GraphQL обертка вокруг всех сервисов!

Как-то я сегодня еще не троллил @jsunderhood и @backendsecret. Не порядок! Надо исправлять! План не выполнен!

Так, продолжаем мусолить микросервисы :) Сейчас это не делает только ленивый, но все же.

Часто спрашивают, а какой язык хороший / плохой для современного бекенда. Так вот с микросервисами выбор свободней

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

@backendsecret twitter.com/php_ceo/status…

И вообще, чего в конце концов хотят разработчики - они хотят свободы, как и все нормальные люди. #философияотпрограммирования

@ipronix @backendsecret деньги и власть — это ресурсы. Личная и профессиональная свобода — цели в индивидуальном образовательном проекте.

Продолжая измышлизмы: а какой прок работодателю от свободы программиста, скажет %username%. И выдаст в себе советикуса обыкновенного :)

Монетизация свободы. Win-win, как говорят консультанты.

@Fedor_Sukhov @backendsecret на начальных этапах смысла ноль, особенно если компания маленькая. Надо просто писать хороший монолит.

Так, повышаем градус холивара :) Сегодня поговорим про выбор технологий

Лично я выбираю comprehensive решения. IDE - IDEA, язык - Scala. Сейчас объясню почему

Я считаю выгодным изучать технологии, которые сложно учить, но потом получаешь профит

Да, забыл, любимые ОС - Linux и Mac OS X

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

Что можно не съев пуд соли делать тоже, что и старшие коллеги

Сейчас меня совершенно не пугают толстые мануалы и сухие спецификации.

Да, тут надо оговориться, что технология должна быть сложной не из-за костылей, а из-за фич.

Вообще самое замечательное в Scala - это комьюнити. Одерский супер спец в языках. TypeSafe делает чудесный стек.

@backendsecret Одерский супер-спец, но никто же спорить не будет с тем, что Scala — по факту — не получилась с точки зрения pl design.

В общем Scala это такой Haskell, который раз, и в прод!

@rubyunderhood @backendsecret @89__bo @mr_mig_by КГБ отправляет мне ивенты через телефонную розетку

Сегодня хотелось бы обсудить тему образования

Тут у меня нет какого-то определённо мнения, ибо сам пытаюсь разобраться

Так вот, в Москве ВО разработчика рассматривалось как что-то опциональное. Хорошо если оно есть и хорошо если вуз именитый

Но вот в Берлине многие коллеги, и особенно начальство имеют не только ВО, но и PhD

У меня ВО есть, но PhD нет, из-за этого я немного комплексую

Интересно было бы послушать мнение тех, кто уже долго работает в Европе на этот счёт, насколько здесь PhD критично в перспективе

@backendsecret точнее требовался или инженер,или магистр,т.к.у немцев,как и у нас,на бакалавров часто смотрят косо - зародыши специалистов

Например у нас изучение чего либо на работе считается рабочим временем

Более того самообразование является обязательным, у каждого есть план и куратор

Работодатель заинтересован в развитии людей. Опять же win-win ситуация

Вот там в реплаях пишут примерно про одно, что работодатель не заинтересован и т.п. Мне это хорошо знакомо

Есть очень здоровский совет. Не работайте с мудаками. Компания должна стремится к win-win, а не win-fail ситуации.

Многие софтвернве компании - это кошмар. Но другие компании существую. Показать вам что они есть я и вижу своей бескорыстной целью

Насчёт стартапов у меня мнение такое: если вас зовут в стартап, соглашайтесь только за опцион и/или должность. Больше там ловить нечего.

@backendsecret опцион И должность. А у опциона еще вестинг и клифф. А еще налоги…
Вывод делаем сами.

@backendsecret вообще фронтендеры всем нужны. А набирают жквери-погроммистов.
А мне потом расхлебывай…

@backendsecret от и я об этом - мир сильно разнообразный

@backendsecret @anton_davydov @dcromster @rubyunderhood я не замечаю экспансии ноды на бэке. фронт на сервере—да, бэка мало. но это ощущения

There are two types of programmers in the world; those who put commas at the end of key/value pairs:

foo: “bar”,

and there are idiots.

Сегодня выходной, а это значит, что хакерам не нужно писать код

Хотел бы обсудить тему full stack разработки

Мне кажется что найм full stack разработки может быть только ограниченным.

Full stack звучит очень заманчиво, но проблема в том, это очень редко когда человеку по-настоящему интересно и то и то

Обычно у фронта и бека совсем разное мышление. Фронту интересно получать осязаемый результат. Бек больше тяготеет к решению головоломок.

Из того что я видел, full stack в масштабах компании идёт хорошо когда либо бек простой, либо фронт простой, или вообще проекты простые

В случае простого фронта бекендеры просто на коленке делают фронт и так далее.

@backendsecret а ещё можно full stack + backend. Это позволяет снять с бекендера простые задачи и сосредоточиться на сложных.

@backendsecret команда разработчиков должна быть full-stack , а не команда full-stack разработчиков

В целом мне думается, что золотая середина, когда нет перегибов и есть и узкие специалисты разного профиля и full stack.

@backendsecret поддержу негатив. Из моего опыта вывод в цитате: "бабе - цветы, дитЯм - мороженое"

Всем привет. Сегодня расскажу про оценку сроков, так как это у меня не плохо получается

Начать нужно с того, зачем нужна оценка сроков. Нужна она для приоритезации

Приоритет = Полезность / Срок, получаеться менеджменту что бы решить что мы делаем в первую очередь необходима оценка сроков

Как сроки оценивать НЕ надо: оценивать не должен тот, кто ставит задачу.

Каждую задачу можно решить бесконечным количеством способов, и срок непосредственно зависит от выбранного способа

Поэтому второе НЕ: не надо оценивать саму постановку задачи, это пальцем в небо

Нужно предложить один, а ещё несколько способов решения, и дать оценки для них.

Про закладывание рисков я думаю и так все знают, я обычно умножаю на 2.

Есть тонкий момент, если на ходу продумать решение задачи не получается и как решать не ясно, по сути срок сказать нельзя

Ни в коем случае нельзя фантазировать на счёт оценки сроков. Если не знаешь - возьми время на ресеч, и оценивай это время.

Как только понимание сроков меняется, лучше немедленно сообщить менеджменту и вместе решить что делать дальше. Замалчивать нельзя.

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

Сроки оценивать можно и нужно!

@backendsecret @mr_mig_by второй уровень по dev.by/pages/programm…

@kmmbvnr @backendsecret либо 1.4 по этой шкале: michaelochurch.wordpress.com/2013/04/22/ger…

@backendsecret вот ещё хорошая практика:

@strizhechenko @backendsecret чувааак, все менеджеры "имеют идею” как это сделать, но не умеют ни малейшего понятия как “сесть и сделать"

Время прощаться. Всем спасибо за внимание, было круто! С вами был @borovikov До новых встреч!