Гость второго выпуска Run Loop — подкаста о тех, кто делает продукты своими собственными руками — Егор Бугаенко. Расспросим его о цели создания своей криптовалюты Zold. Узнаем, почему для ее написания используется Ruby. Поговорим сразу о многом, начиная от распорядка дня и книг, заканчивая провокационными вопросами о качестве работы программистов. И напоследок обсудим, что разработчики, не умеющие участвовать в Open Source проектах, скоро станут никому не нужны.
Ведущие: Илья Царев, Алексей Милеев, Роман Бусыгин.
Илья Царев занимается iOS разработкой в Альфа-банке, выступает на различных митапах и конференциях.
Алексей Милеев разрабатывает Android версию App in the Air, ведет Telegram-канал по Android разработке, и курирует доклады на AppsConf.
Роман Бусыгин — ведущий разработчик Яндекс.музыки для iOS, часто выступает на конференциях и участвует в подкастах.
В гостях: Егор Бугаенко — основатель и CEO компании Zerocracy, разрабатывающей AI-роботов для управления программистами; ООП-фундаменталист; автор «Elegant Objects» — серии книг об объектно-ориентированном программировании; создатель Cactoos, Takes Framework, JCabi и Rultor, а еще блогер и филантроп.
Алексей: Расскажи о себе, чем ты занимаешься.
Егор: Я в основном программирую и управляю программистами. Это две сферы моей деятельности.
Илья: Скажи, пожалуйста, как ты это совмещаешь. В какой момент ты управляешь разработкой, а в какой программируешь? Расскажи, пожалуйста, про свою компанию подробнее.
Егор: Наша компания называется Zerocracy и представляет собой биржу фриланса, где с одной стороны подключены фрилансеры, программисты, тестеровщики, дизайнеры и всевозможные другие технические таланты. А с другой стороны заказчики, которым эти таланты нужны, и они хотят выполнять софтверный проект.
Ключевым ядром площадки является автоматизированный искусственный интеллект. Это робот — чат-бот, который управляет процессом разработки. Он ставит задачи программистам, собирает от них результаты, платит им деньги, оценивает качество их работы и организует весь development process. Изначально я сам написал этого робота, искусственный интеллект. Сейчас я в его разработке принимаю незначительное участие, продолжает дорабатывать и усовершенствовать команда разработчиков.
Я — СЕО компании Zerocracy. Основное мое время уходит на это. В области программирования у меня есть несколько проектов, которые я активно разрабатываю. Один из них, это наш пилотный проект zold.io. Это созданная нами внутри нашей компании, криптовалюта, которая является альтернативой существующим блокчейн решениям. Я — архитектор этого решения. Я не единственный, кто работает над ним, но я архитектор. Этот продукт интересен тем, что написан в текущей версии на Ruby.
Проект zold.io представляет собой альтернативный способ решения проблемы распределенных платежей. Блокчейн — это достаточно известное, широко популярное решение по организации распределенных данных на серверах с нулевым доверием. Мы предложили свое решение, которое не использует блоки, чейны и всё то, что есть в блокчейн. Мы по-своему решаем эту проблему. Нам кажется, что наше решение тоже интересно. Это то, в чём я занимаюсь активным программированием.
Роман: Егор, очень интересно услышать о блокчейн. Это очень вычислительно сложная штука. Ты используешь Ruby, который знаменит своей медлительностью. Практически все стараются его избегать на крупных проектах. Расскажи, пожалуйста, почему Ruby?
Егор: У нас не блокчейн. У нас Cryptocurrency, но не блокчейн. Очень часто люди соединяют два понятия. Им кажется, что криптовалюта = блокчейн. Эти вещи могут быть в одном пакете, как в биткоине, например, но на самом деле блокчейн — это всего лишь способ хранения данных на множестве серверов с нулевым доверием к каждому индивидуальному серверу. Блокчейн — это действительно технология или способ хранения данных, которая требует серьезных скоростей и вычислительных ресурсов.
В нашем проекте не используется блокчейн. Поэтому были важны другие аспекты. Для нас скорость вычисления играет не первую роль. Я написал статью в нашем блоге, которая так и называется "Why Ruby?" и указал три пункта, которые отвечают на этот вопрос.
Поэтому — Ruby.
Цель созданной криптовалюты
Алексей: Какую цель вы преследовали, когда создавали свою криптовалюту, когда создавали золото?
Егор: У нас было несколько мотивов, цели появились позже. Скажу откровенно, что первый мотив был мотив чисто технический. Было интересно решить такую техническую задачу. Я инженер и техник, решение сложных технических задач доставляет мне удовольствие.
Я много слышал о блокчейне и о том, что криптовалюта сейчас всё популярнее и популярнее. Вопрос рынка — это вопрос экономики. Меня он не очень интересовал, меня больше интересовал вопрос техники. То есть, как так они делают блокчейн решения, что мы доверяем системе, которая не имеет централизованного сервера и центральной точки контроля. Поскольку все говорят о блокчейне, мне было интересно попробовать по-своему эту проблему решить. Такой чисто технический челлендж: давайте попробуем, должно получиться.
Получилось не сразу. Три месяца не получалось, но в итоге решение было найдено. Оно сейчас уже работает, и мы даже этой валютой уже платим программистам, которые работают на нашей платформе. Транзакции идут вживую, хотя пока никакой рекламы не было, но для нашего внутреннего пользования, в production режиме, но на небольших транзакциях мы ее обкатываем.
Второй мотив большие экономический. Нам не нравились существующие способы оплаты труда программистов, которые работают на платформе Zerocracy. На текущий момент мы используем PayPal и Bitcoin. В обоих случаях транзакции достаточно дорогие. Нам приходится платить большие комиссии для перечисления средств программистам, а в Zerocracy микроплатежи. За микротаски мы платим программистам микроплатежами вплоть до нескольких десятков центов. Как известно, PayPal, Bitcoin в этом плане очень дорогие и не подходят для микротранзакций. На биткоине комиссия за одну транзакцию будет порядка 50 центов, на PayPal 30-40 центов. Это очень дорого, если вся сумма транзакции 1 доллар. Поэтому экономическим мотивом было сделать платежное решение, которые было бы во много раз дешевле и очень хорошо подходило бы для микроплатежей, а не для больших платежей, как в биткоине.
Цели появились недавно. она состоит в том, чтобы с помощью криптовалюты, этого финансового инструмента привлечения инвестиционных средств к проекту, привлечь достаточное количество средств на платформу Zerocracy. Используя привлеченные средства, мы хотим поднять размеры оплат труда программистов, работающих на платформе. И таким образом сделать эту платформу привлекательной для большего круга профессиональных разработчиков.
Сейчас на платформе, к сожалению, нет таких больших бюджетов, чтобы платить разработчикам 100-150 долларов в час. С нашей моделью управления — microtasking, microbudgeting — всё на микроуровне, у нас ориентированная на результат работа на микроуровне. Поэтому очень важно, чтобы люди работали и хотели работать на результат, а не просто проводить время в проекте, как это часто происходит в других моделях разработки, в том числе в Agile. Для того чтобы модель стала привлекательной, людям нужно много платить. Мы пришли к такому выводу. В традиционной модели человек привык работать за 15-20 долларов в час, но когда платят за 8 рабочих часов в независимости от того, что он делал эти 8 часов. В нашей же модели он вынужден предоставить 8 блоков результата, чтобы получить оплату за 8 часов. Соответственно, 15 долларов в час уже неинтересно, потому что астрономически восьми часов, за которые платят при полном рабочем дне, люди обычно работают 15-20% времени. Всё остальное время уходит на чтение новостей, на отдых, и другие параллельные вспомогательные активности. В нашем случае эти активности не оплачиваются.
Мы понимаем, что в нашей модели часовая ставка должна быть в 5-10 раз выше, чем традиционная. Таких средств у нас пока нет. С помощью криптовалюты Zold мы планируем через финансовый крипторынок, через интерес к новому платежному средству привлечь инвестиционные капиталы и использовать их для повышения тарифов наших разработчиков. Это даст буст этой платформе, маркетинговый рычаг, с помощью которого в последствии мы сможем привлечь ценных клиентов.
Как проходит рабочий день
Алексей: Ты упомянул, что как инженеру, тебе нравится решать сложные задачи. Давай еще немного поговорим о тебе. Как обычно проходит твой рабочий день?
Роман: Я чуть-чуть конкретизирую. Возможно, ты просыпаешься и сразу работаешь. Я предлагаю не ограничивать рабочий день моментом прихода в офис.
Егор: Во-первых, офиса у меня нет: я никуда не прихожу. Во-вторых, я не работаю. То есть я не воспринимаю то, что я делаю, как работу, и не воспринимаю себя как человека офиса. Я наслаждаюсь теми вещами, которые я делаю. Я их делаю, потому что они мне нравятся, а не потому что я пришел в офис и должен что-то сделать, выполнить какие-то задачи. Мне просто нравится то, чем я занимаюсь.
К счастью, у меня есть проекты, в которых я могу получать удовольствие от программирования или от управления этими процессами. Поэтому я просыпаюсь, открываю ноутбук и смотрю, чем бы порадоваться, чем бы занять себя в ближайшие 16 часов. Кофе я не пью, я пью чай, поэтому сначала чай, потом ноутбук.
У меня часто спрашивают, как я организую свое время. Я пытаюсь его организовывать, но у меня это плохо получается. Я часто опускаю руки и просто делаю то, что хочется. Зачастую, это наиболее эффективный способ организации своего времени. Я всегда стараюсь слушать свои внутренние желания и делать только то, что мне хочется, а не то, что надо. Обычно, то, что хочется, вывозит меня в правильном направлении.
Алексей: Ты акцентировал внимание на том, что ты не человек офиса. Ты никогда не работал в офисе или же было время, но потом ты переключился на свои задачи?
Егор: У меня был офис. Я работал в офисах не один год. Мне кажется, что эта работа для меня лично стрессовая и депрессивная. Она вгоняет меня в депрессию значительно быстрее, чем я почувствую какую-то эффект от офиса.
Я понимаю, зачем нужны какие-то места, где можно выпить кофе и поваляться на диванах. Я понимаю, зачем нужны кальянные и рестораны. Я понимаю, зачем нужны места, где можно проводить время. Но я абсолютно не понимаю, зачем нам сидеть рядами, смотреть в мониторы и ходить за кофе в определенную точку, потом возвращаться и опять сидеть на том же месте. Мне кажется, это неразумно. Есть масса других мест, где интереснее и более комфортно работать: в кафе, дома, на природе. Я не вижу смысла в объединении людей в такие офисные пространства. В последних книгах я достаточно много и серьёзно критикую вообще идею организации и мотивации людей на работу путём соединения их территориально. Эта концепция соединения людей в одном месте и направления их в одно русло, чтобы они делали что-то одно и совместно что-то достигали, на мой взгляд, должна уйти в прошлое. Сейчас нет в этом особой необходимости, есть качественные способы связи, хороший софт, качественные инструменты управления. Нам просто не нужно больше сидеть вместе для работы.
Роман: Я чуть-чуть уточню, когда я говорил про офис, я имел в виду работать на кого-то. Работал ли ты на кого-то и чем ты начал заниматься для себя? В какой момент и почему случился переход с работы по найму к работе на себя?
Егор: Я немного работал по найму, но я никогда не работал на кого-то. Я всегда работал на себя. Вопрос в том, кто мне платит деньги, на чьи средства я это делаю. Это меняется в определённые моменты моей жизни. Когда-то это оплачивала одна компания, потом другая. Сейчас мою работу оплачивают мои клиенты. Завтра это могут оплачивать мои инвесторы, послезавтра читатели моей книги. Вопрос «Откуда приходят деньги?» всегда имеет варианты. На этот вопрос всегда может быть разный ответ. Я всегда работал только на себя.
Мне тяжело себе представить, чтобы я свое время, свои усилия и свою энергию тратил на что-то, что достанется потом кому-то другому. Для меня это неприемлемо. Это будет меня очень сильно демотивировать, и я продержусь очень недолго: пару дней, может быть пару недель, но буду стараться вырваться из этого. Находясь в офисе, работая на чьём-то проекте, делая что-то, что выглядит как работа для кого-то, я всегда работаю на себя. Я нахожу, чем это занятие может мне лично быть полезным. Если я в проекте, и в нем нужно поставить новую систему deployment, мне за это платят, то я обязательно эту систему сделаю так, чтобы я потом о ней мог где-то написать, рассказать, чтобы я мог какой-то Open Source продукт из нее вынести, чтобы я мог что-то для себя лично в этом вынести. Дальше вся работа над этой системой у меня выглядит, как работа на себя. Заказчики тоже получат, конечно, в итоге работающую систему. Но в первую очередь выгоду получу лично я. Так я всегда делаю.
Илья: Егор, скажи, пожалуйста, если у тебя нет какого-то места, куда ты ходишь работать, то всё равно ты выбираешь: сегодня ты в кафе, завтра дома или на природе. У тебя есть расписание или ты просто просыпаешься и, куда хочется, туда идешь?
Егор: Скорее, куда хочется. Я стараюсь это не планировать, потому что если слушать свои желания и внутренние, часто необъяснимые мотивы, то в итоге получится лучше. Не знаю, возможно, кому-то было бы удобней наоборот, идти по графику, по плану, но я стараюсь прислушиваться к внутреннему голосу, который говорит: «Надоело дома, пойдем куда-нибудь». Я беру ноутбук и просто выхожу. Иногда я просто иду по улице и захожу в любое кафе, которое увижу, что-то заказываю и три-четыре часа, пока ноутбук не сядет, работаю. Потом мне надоедает, и я возвращаюсь домой.
Code Ahead
Алексей: Ты упомянул свою последнюю книгу. Она называется «Code Ahead». Давай, Егор, попробуем кратко в одном предложении сформулировать, о чём твоя последняя книга.
Егор: Хороший вопрос. Действительно в начале июля назад вышла книга, которую я писал дольше, чем все остальные, потратил на ее написание 8 месяцев. Суммарно она стартовала 1 год и 8 месяцев назад. Я долго готовился, а потом почти 8 месяца писал, многое переписывая, изменяя и выбрасывая целые главы. Усилий приложил много. Я не могу судить, что получилось. Мне было бы интересно услышать фидбэк, но на Amazon отзывов пока нет.
Что интересно, «Code Ahead» — художественная книга. То есть она написана не техническим языком, там есть персонажи и некий сюжет, диалоги, монологи, разговоры. Но при этом это, конечно, смешанный жанр. Я не видел такого до этого, но выбрал такой жанр. В свободном художественном изложении большое количество технических и научных ссылок. Персонажи разговаривают между собой, и по ходу диалога к их утверждениям, замечаниям и фактам, о которых идет речь, внизу страницы идёт большое количество сносок, которые подтверждают, либо опровергают заявления, сделанные персонажами.
Всего в книге больше трехсот таких ссылок на книги, статьи, научные статьи и все остальное. Я соединил художественный жанр и чуть ли не полунаучный. Как получилось — не знаю. Попробуйте купить и почитать. Мне кажется, что интересно. Я ее прочитал много раз, чего с предыдущими книгами не происходило. Предыдущие книги я написал, один раз прочитал и опубликовал. Эту я прочитал рез десять.
Роман: Чтобы писать книги, нужно читать очень много книг, прокачивать себя в этом направлении. Егор, что бы ты мог посоветовать почитать нашим читателям, но не из того, что написал ты, а другое. Что первое приходит в голову?
Егор: В моем блоге есть статья, которая называется «My favorite books». Там 16 книг, которые я однозначно рекомендую прочитать. Это книги, которые я читал ни один раз. Они для меня ценные, и я к ним часто возвращаюсь. Помимо этого, я бы рекомендовал книгу «Code Ahead». Процентов десять из тех трехсот ссылок отмечены специальным значком звездочкой. Остальные ссылки просто подтверждают факты, либо опровергают их. Ссылки со звездочкой — это литература, которую я бы однозначно рекомендовал прочитать и даже не один раз.
Доклад на AppsConf
Илья: Расскажи, пожалуйста, о теме своего доклада. Скоро ты будешь выступать на AppsConf, про что ты будешь рассказывать?
Егор: Я буду предлагать взглянуть на ситуацию с программированием и с его качеством, и попытаюсь предложить свое решение этого конфликта. Конфликт заключается, как мне кажется, в том, что стандартные ожидания менеджмента, технического и организационного, от программистов сводятся к тому, что программист должен писать код, в котором нет ошибок. Это ожидание достаточно традиционное и популярное. Я его встречал и в реальной практике, и в литературе, и могу привести несколько ссылок на книги, где сказано, что хороший программист пишет код, в котором нет багов. Если использовать эту концепцию, как фундаментальную и от неё отталкиваться, то на практике мы очень быстро приходим к проблеме: что делать, чтобы программисты писали код без ошибок? Как найти хорошего программиста и что делать, если программист плохой?
Есть два решения:
Нанимаем хороших, с одной стороны, а с другой стороны пугаем плохих, чтобы они стали хорошими. Такой подход я встречаю повсеместно. В докладе я попытаюсь предложить альтернативное решение, которое работает в нашей компании и в наших проектах мы работаем. У нас положительное отношение к багам. Мы считаем, что ошибки и дефекты, которые программисты создают, это естественная составляющая любого процесса создания программного продукта. Ошибки нужны, они должны быть, они необходимы. Нужно таким образом построить систему контроля качества, выявления этих ошибок и недопущения попадания этих ошибок в Production, чтобы в итоге были довольны и заказчики, и программисты. Нужно исключить элемент страха, который присутствует у программистов, которым рассказывают, что баги — это плохо. При этом сделать так, чтобы качество всё-таки было высокое. Я предложу такой подход и разложу его на составляющие.
Почему такая тема
Алексей: Скажи, пожалуйста, как родилась такая тема доклада? Какая ситуация произошла, что ты понял существование этого конфликта, осознал необходимость его разрешить и предложил свое решение?
Егор: Мы работаем с фрилансерами. У нас этот конфликт очень острый и, наверное, острее, чем в других компаниях. Поэтому для нас его решение является вопросом жизни или смерти проекта. Фрилансеры — это достаточно хаотичные ребята, в основном недисциплинированные, достаточно трудно управляемые и часто сменяемые. Это люди, которые приходят в проект, уходит из него. В нашем случае проект может за три месяца поменять команду несколько раз целиком. Поэтому для нас этот вопрос был очень важен.
Как сделать так, чтобы люди, приходящие в проект случайно, со стороны, неизвестно надолго ли, всё равно выдавали такой код, с которым мы бы могли остаться даже после потери этих программистов, даже после смены команды на 100%? Кроме того, чтобы мы могли выжить после смены команды, нужно сделать ещё и так, чтобы эти люди могли контрибьютить на высокой скорости. Фрилансер, приходя к нам в проект, должен иметь возможность быстро включиться и начать отдавать код, а потом быстро уйти из проекта. У нас такие экстремальные условия. Так было задумано и сейчас так всё и происходит. Возник вопрос, как сделать так, чтобы этот программист, не испытывая никаких эмоций к проекту, не пытаясь сделать его лучше по каким-то своим внутренним мотивам, не пытаясь даже глубоко вникнуть в проект, а просто желая заработать какие-то деньги на коротком отрезке времени, при этом всё равно выдавал нам такого качества код, как мы хотим. И у нас это получается. Мы решили эту задачу с помощью методов, о которых я расскажу в докладе. Я этим не просто поделюсь на конференции, не просто потому что интересно поделиться достижением, а я собираюсь использовать это еще и как способ информирования программистов на будущее.
Роман: Егор, это очень провокационная тема. Всякий раз, когда я слышу про тяп-ляп и в Production, разработчики мало задумываются про архитектуру, про какие-то концептуальные вещи. Получается, что с микрозадачами в проекте никто совершенно не думает про высокоуровневые архитектурные вещи? Ведь невозможно за короткий отрезок времени придумать большое что-то, скелет проекта?
Егор: Да, действительно, у нас не всё в микрозадачах. Скелет проекта создается архитектором. Архитектор его делает при старте проекта собственными усилиями, затрачивая на это незначительное количество времени, но делает это, как цельный блок работы, который может занять неделю—две. Потом проект живет своей жизнью. Архитектор, оставаясь в проекте, может проконтролировать, чтобы архитектура не расползлась, просто делая Code review. По нашему опыту архитектору достаточно быть центральным, таким финальным Code review-ером, который получая contribution от программистов, на него накладывает вето, либо допускает в Production.
Разработка мобильных приложений
Роман: Егор, а есть ли в твоем портфолио мобильные приложения и используется ли такой подход при их разработке?
Егор: Лично я не мобильный разработчик. Поэтому я не являюсь архитектором ни одного мобильного приложения. Но у нас на платформе есть проекты, где люди разрабатывают мобильные приложения.
Роман: Я думаю, не мне одному будет интересно поймать тебя потом в кулуарах и расспросить, как же этот подход применяется при разработке мобильных приложений
Егор: Я часто слышу вопросы такого плана: «Применяется ли это в разработке Big Data приложений? Можно ли это применить в искусственном интеллекте?» Я не вижу большой разницы между приложениями, разными доменами, доменными зонами, где используется приложение. Какая нам разница, мобильное это предложение или web. Там всё равно есть архитектура, код. У этого кода есть строки, классы и методы. Значит, это можно разбить на микроинкременты и дальше просматривать их по отдельности, анализировать качество и принимать один за другим сотнями, тысячами, десятками тысяч. Поэтому я не вижу большой разницы между мобильным приложением и Big Data предложением.
Помощь людей в проектах
Илья: Егор, у тебя очень интересный профиль на GitHub, у тебя более 1700 фолловеров и более 300 звёздочек, куча репозиториев и проектов. Ты участвуешь в очень большом количестве проектов. Скажи, как ты находишь людей, которые тебе помогают с ними? Они приходят сами, ты что-то специально делаешь или это вообще всё твои сотрудники, которым ты платишь деньги?
Егор: Во-первых, это сообщество не вчера появилось. Я с 2009 года активно пишу код на GitHub. Я написал, может, миллион строчек кода. Я ежедневно пишу какой-то код, в основном в Open Source виде, практически нет ничего, что было бы в закрытом режиме. Код любых проектов, которые лично я делаю, я всегда стараюсь открыть. У меня было такое желание и пять лет назад, и когда я начинал на гитхабе, и до этого, и сейчас.
Мне кажется, чем больше разработчик делает в открытом виде, тем это лучше для него, для его работодателя, для компании и для всего сообщества. Я вообще такой активный адепт и евангелист Open Source. Я считаю, что закрытый код это пережиток прошлого. Он, конечно, существует. К нам часто приходят программисты, которые показывают пустой гитхаб-аккаунт и говорят, что они очень профессиональные программисты, просто у них нет ничего в открытом коде, потому что они последние 10 лет работали в закрытом режиме. Мы стараемся таких программистов не брать, потому что у нас большой опыт работы с такими ребятами. В основном всё заканчивается тем, что они не умеют работать в Open Source экосистеме.
Они могут быть хорошими программистами, могут уметь писать алгоритмы, понимать в Java и технологиях обработки данных, но они не умеют общаться в экосистеме, не умеют быть частью системы разработки программного продукта. А это, на мой взгляд, является значительно более важным качеством в современном рынке, чем алгоритмы и способы обработки данных. С алгоритмами мы как-нибудь справимся, найдем, их много написано — мы разберёмся. Это проблема менее тяжелая, чем умение сделать так, чтобы твой pull request в итоге попал в production.
Большинство людей просто не умеют работать в экосистеме Open Source. Они присылают pull request. A когда ты им в этот pull request пишешь комментарии, то они тебе звонят по телефону и пытаются объяснить, почему ты не прав. У них нет навыка, нет дисциплины и коммуникации в Open Source проекте. Они не понимают, что не каждому программисту можно позвонить и не каждому программисту можно задать вопрос. Они не понимают, что программист может быть в проекте сегодня, а завтра его уже там нет. Не надо никому звонить, пиши в гитхабе. Если ты спрашиваешь у человека напрямую, а завтра этот человек ушёл из проекта, вся информация, которой вы обменялись, утеряна, и ты просто потерял время. Поэтому у этих людей нет дисциплины работы через код. Они не умеют его документировать, не умеют по нему писать комментарии, не умеют работать в ветках. Они не понимают, как выглядит deployment, что его надо поддерживать вместе с кодом. У них нет огромного количества навыков, которые делают из кодера программиста.
У меня есть статья на эту тему, где я писал, обращаясь к читателю: «Определись, ты кодер или программист? Либо ты умеешь писать код, либо ты действительно умеешь быть частью проекта по разработке программного продукта». Это совершенно разные вещи. Просто кодер — это 15% успеха, остальные 85% — это умение работать в команде. Я говорю сейчас не об умении сидеть в офисе, пить кофе и дружить с коллегами по работе. Я говорю о том, чтобы быть членом живой команды, в которую приходят и уходят люди, в которой меняются технологии, возникают конфликты. Неумение делать это — это огромный недостаток современного рынка.
На нашу платформу в день приходит десять новых человек. Девять из десяти просто не умеют этим заниматься, они обычные кодеры. У них нет этого навыка. Я виню в этом офисы, отсутствие открытого кода, еще их лень и отсутствие информации. Многие люди работают в закрытом коде и гордятся этим. Я, обращаясь к таким людям говорю: «Это твоя вина, твой недостаток. Ты тратишь свое время, сидя в закрытом коде, не выходя в Open Source, не вытаскивая какие-то куски из этого кода в Open Source».
Найдите способ вытащить какую-то библиотеку из вашего закрытого кода. Найдите способ сделать что-то такое в открытом коде. Выйдите в Open Source, сделайте себе аккаунт на GitHub и Stack Overflow. Будьте публичным человеком, тогда вы увидите, что такое работать с открытым кодом. Когда случайные люди будут писать вам, где вы не правы, когда вам будут присылать pull request-ы, на которые вы не будете знать, что ответить, когда вы будете делать pull request-ы. Тогда вы станете частью этой экосистемы, за которой будущее. Закрытый код — это прошлое. Офисная работа — это прошлое. Пройдет 10-15 лет, и эти люди станут никому нужны, как Кобол программисты. Нужны будут люди, которые есть на GitHub.
Автоматический deployment
Алексей: Егор, перед тобой каждый день встают самые разные задачи по коду, по управлению. Расскажи, пожалуйста, про какую-нибудь задачу, которая вызвала у тебя неимоверную радост. Неважно, это было что-то сложное или простое. Что тебе очень понравилось из последнего?
Егор: Я даже собираюсь на эту тему тоже сделать в ближайшее время доклад. Понравилось то, что за мои 25 лет программирования я еще не видел. Наша система криптовалюты состоит из большого количества серверов. В настоящий момент у нас их не так много — 70, но, тем не менее, это 70 серверов. Они принадлежат совершенно неизвестным для меня людям, это анонимные пользователи. На каждом сервере установлено наше программное обеспечение — Zold, Ruby gem, который стоит на каждом сервере.
Я разработал систему deployment, что когда версия обновляется на одном из серверов, то остальные сервера автоматически себя рестартуют, обновляют свою версию и стартуют заново. В разработке это было интересно. Я не могу этим 70 людям написать e-mail, как это делает Bitcoin, и сказать, что нужно обновиться и поставить новую версию. Каждый из майнеров биткоина должен руками обновить свою версию. У нас такой возможности нет и мне не хотелось делать так. Хотелось сделать так, чтобы я обновлял версию одним кликом, и тут же вся сетка меняла свою версию. Анонимные сервера, мне неподконтрольные, сами автоматически обновляются на следующую версию. Было очень здорово увидеть, как это стало работать в живом режиме. Я захожу на неизвестные мне машины через фронтенд, и вижу, как они щёлк-щёлк-щёлк одна за другой меняют версию, и за 5-7 минут вся сетка обновляется. Вот это было интересно увидеть. Я такого автоматического deployment без прямого контроля с обратной связью в своей жизни не делал. Я это когда-нибудь покажу на конференции, как это технически работает. Я думаю, что будущее за системами, которые состоят из анонимных участников и при этом работают под общим контролем, не имея человека вообще в этой схеме.
Илья: Я хочу напомнить, что Егора можно будет увидеть на конференции AppsConf, которая пройдет 8-9 октября в Москве. Приходите, задавайте вопросы, слушайте доклад Егора.
Егор: Да, обязательно приходите. Обо всем, что я сегодня сказал, в докладе будет более подробно. Я расскажу, как именно мы достигаем своих целей, покажу реальные примеры. Думаю, это воодушевит вас.
Спасибо вам, дорогие слушатели и читатели, увидимся в новых выпусках.
Ведущие: Илья Царев, Алексей Милеев, Роман Бусыгин.
Илья Царев занимается iOS разработкой в Альфа-банке, выступает на различных митапах и конференциях.
Алексей Милеев разрабатывает Android версию App in the Air, ведет Telegram-канал по Android разработке, и курирует доклады на AppsConf.
Роман Бусыгин — ведущий разработчик Яндекс.музыки для iOS, часто выступает на конференциях и участвует в подкастах.
В гостях: Егор Бугаенко — основатель и CEO компании Zerocracy, разрабатывающей AI-роботов для управления программистами; ООП-фундаменталист; автор «Elegant Objects» — серии книг об объектно-ориентированном программировании; создатель Cactoos, Takes Framework, JCabi и Rultor, а еще блогер и филантроп.
Алексей: Расскажи о себе, чем ты занимаешься.
Егор: Я в основном программирую и управляю программистами. Это две сферы моей деятельности.
Илья: Скажи, пожалуйста, как ты это совмещаешь. В какой момент ты управляешь разработкой, а в какой программируешь? Расскажи, пожалуйста, про свою компанию подробнее.
Про компанию
Егор: Наша компания называется Zerocracy и представляет собой биржу фриланса, где с одной стороны подключены фрилансеры, программисты, тестеровщики, дизайнеры и всевозможные другие технические таланты. А с другой стороны заказчики, которым эти таланты нужны, и они хотят выполнять софтверный проект.
Ключевым ядром площадки является автоматизированный искусственный интеллект. Это робот — чат-бот, который управляет процессом разработки. Он ставит задачи программистам, собирает от них результаты, платит им деньги, оценивает качество их работы и организует весь development process. Изначально я сам написал этого робота, искусственный интеллект. Сейчас я в его разработке принимаю незначительное участие, продолжает дорабатывать и усовершенствовать команда разработчиков.
Я — СЕО компании Zerocracy. Основное мое время уходит на это. В области программирования у меня есть несколько проектов, которые я активно разрабатываю. Один из них, это наш пилотный проект zold.io. Это созданная нами внутри нашей компании, криптовалюта, которая является альтернативой существующим блокчейн решениям. Я — архитектор этого решения. Я не единственный, кто работает над ним, но я архитектор. Этот продукт интересен тем, что написан в текущей версии на Ruby.
Проект zold.io представляет собой альтернативный способ решения проблемы распределенных платежей. Блокчейн — это достаточно известное, широко популярное решение по организации распределенных данных на серверах с нулевым доверием. Мы предложили свое решение, которое не использует блоки, чейны и всё то, что есть в блокчейн. Мы по-своему решаем эту проблему. Нам кажется, что наше решение тоже интересно. Это то, в чём я занимаюсь активным программированием.
Почему Ruby
Роман: Егор, очень интересно услышать о блокчейн. Это очень вычислительно сложная штука. Ты используешь Ruby, который знаменит своей медлительностью. Практически все стараются его избегать на крупных проектах. Расскажи, пожалуйста, почему Ruby?
Егор: У нас не блокчейн. У нас Cryptocurrency, но не блокчейн. Очень часто люди соединяют два понятия. Им кажется, что криптовалюта = блокчейн. Эти вещи могут быть в одном пакете, как в биткоине, например, но на самом деле блокчейн — это всего лишь способ хранения данных на множестве серверов с нулевым доверием к каждому индивидуальному серверу. Блокчейн — это действительно технология или способ хранения данных, которая требует серьезных скоростей и вычислительных ресурсов.
В нашем проекте не используется блокчейн. Поэтому были важны другие аспекты. Для нас скорость вычисления играет не первую роль. Я написал статью в нашем блоге, которая так и называется "Why Ruby?" и указал три пункта, которые отвечают на этот вопрос.
- Ruby очень компактный язык по сравнению с другими языками, которыми я владею: Java, C++ и JavaScript. Код на Ruby значительно короче и его легче написать. То, что на Java занимает 100 строк кода, на Ruby может уместиться в 20.
- Благодаря его компактности, Ruby очень удобен для экспериментов. Решение было создано не сразу, несколько месяцев было потрачено на пробы, ошибки и неработающие версии. Соответственно, много переписывалось. Было бы менее удобно это делать и неоднократно переписывать на Java.
- На Ruby очень удобная система deployment, инсталляции и реинсталляции версии, которой нет, например, в Java. Для JavaScript есть npm, а на C++ и Java если такие системы и есть, то они платформозависимые. Ruby — кроссплатформенная система и очень удобна для реинсталляции новых версий. Для нас это очень важно, потому что мы имеем дело с комьюнити контрибьюторов, которые находятся на разных платформах, они нам не подчинены. Система по определению распределенная и анонимная. Поэтому нам очень важно было, чтобы наше решение было легко инсталлировать.
Поэтому — Ruby.
Цель созданной криптовалюты
Алексей: Какую цель вы преследовали, когда создавали свою криптовалюту, когда создавали золото?
Егор: У нас было несколько мотивов, цели появились позже. Скажу откровенно, что первый мотив был мотив чисто технический. Было интересно решить такую техническую задачу. Я инженер и техник, решение сложных технических задач доставляет мне удовольствие.
Я много слышал о блокчейне и о том, что криптовалюта сейчас всё популярнее и популярнее. Вопрос рынка — это вопрос экономики. Меня он не очень интересовал, меня больше интересовал вопрос техники. То есть, как так они делают блокчейн решения, что мы доверяем системе, которая не имеет централизованного сервера и центральной точки контроля. Поскольку все говорят о блокчейне, мне было интересно попробовать по-своему эту проблему решить. Такой чисто технический челлендж: давайте попробуем, должно получиться.
Получилось не сразу. Три месяца не получалось, но в итоге решение было найдено. Оно сейчас уже работает, и мы даже этой валютой уже платим программистам, которые работают на нашей платформе. Транзакции идут вживую, хотя пока никакой рекламы не было, но для нашего внутреннего пользования, в production режиме, но на небольших транзакциях мы ее обкатываем.
Второй мотив большие экономический. Нам не нравились существующие способы оплаты труда программистов, которые работают на платформе Zerocracy. На текущий момент мы используем PayPal и Bitcoin. В обоих случаях транзакции достаточно дорогие. Нам приходится платить большие комиссии для перечисления средств программистам, а в Zerocracy микроплатежи. За микротаски мы платим программистам микроплатежами вплоть до нескольких десятков центов. Как известно, PayPal, Bitcoin в этом плане очень дорогие и не подходят для микротранзакций. На биткоине комиссия за одну транзакцию будет порядка 50 центов, на PayPal 30-40 центов. Это очень дорого, если вся сумма транзакции 1 доллар. Поэтому экономическим мотивом было сделать платежное решение, которые было бы во много раз дешевле и очень хорошо подходило бы для микроплатежей, а не для больших платежей, как в биткоине.
Цели появились недавно. она состоит в том, чтобы с помощью криптовалюты, этого финансового инструмента привлечения инвестиционных средств к проекту, привлечь достаточное количество средств на платформу Zerocracy. Используя привлеченные средства, мы хотим поднять размеры оплат труда программистов, работающих на платформе. И таким образом сделать эту платформу привлекательной для большего круга профессиональных разработчиков.
Сейчас на платформе, к сожалению, нет таких больших бюджетов, чтобы платить разработчикам 100-150 долларов в час. С нашей моделью управления — microtasking, microbudgeting — всё на микроуровне, у нас ориентированная на результат работа на микроуровне. Поэтому очень важно, чтобы люди работали и хотели работать на результат, а не просто проводить время в проекте, как это часто происходит в других моделях разработки, в том числе в Agile. Для того чтобы модель стала привлекательной, людям нужно много платить. Мы пришли к такому выводу. В традиционной модели человек привык работать за 15-20 долларов в час, но когда платят за 8 рабочих часов в независимости от того, что он делал эти 8 часов. В нашей же модели он вынужден предоставить 8 блоков результата, чтобы получить оплату за 8 часов. Соответственно, 15 долларов в час уже неинтересно, потому что астрономически восьми часов, за которые платят при полном рабочем дне, люди обычно работают 15-20% времени. Всё остальное время уходит на чтение новостей, на отдых, и другие параллельные вспомогательные активности. В нашем случае эти активности не оплачиваются.
Мы понимаем, что в нашей модели часовая ставка должна быть в 5-10 раз выше, чем традиционная. Таких средств у нас пока нет. С помощью криптовалюты Zold мы планируем через финансовый крипторынок, через интерес к новому платежному средству привлечь инвестиционные капиталы и использовать их для повышения тарифов наших разработчиков. Это даст буст этой платформе, маркетинговый рычаг, с помощью которого в последствии мы сможем привлечь ценных клиентов.
Как проходит рабочий день
Алексей: Ты упомянул, что как инженеру, тебе нравится решать сложные задачи. Давай еще немного поговорим о тебе. Как обычно проходит твой рабочий день?
Роман: Я чуть-чуть конкретизирую. Возможно, ты просыпаешься и сразу работаешь. Я предлагаю не ограничивать рабочий день моментом прихода в офис.
Егор: Во-первых, офиса у меня нет: я никуда не прихожу. Во-вторых, я не работаю. То есть я не воспринимаю то, что я делаю, как работу, и не воспринимаю себя как человека офиса. Я наслаждаюсь теми вещами, которые я делаю. Я их делаю, потому что они мне нравятся, а не потому что я пришел в офис и должен что-то сделать, выполнить какие-то задачи. Мне просто нравится то, чем я занимаюсь.
К счастью, у меня есть проекты, в которых я могу получать удовольствие от программирования или от управления этими процессами. Поэтому я просыпаюсь, открываю ноутбук и смотрю, чем бы порадоваться, чем бы занять себя в ближайшие 16 часов. Кофе я не пью, я пью чай, поэтому сначала чай, потом ноутбук.
У меня часто спрашивают, как я организую свое время. Я пытаюсь его организовывать, но у меня это плохо получается. Я часто опускаю руки и просто делаю то, что хочется. Зачастую, это наиболее эффективный способ организации своего времени. Я всегда стараюсь слушать свои внутренние желания и делать только то, что мне хочется, а не то, что надо. Обычно, то, что хочется, вывозит меня в правильном направлении.
Алексей: Ты акцентировал внимание на том, что ты не человек офиса. Ты никогда не работал в офисе или же было время, но потом ты переключился на свои задачи?
Егор: У меня был офис. Я работал в офисах не один год. Мне кажется, что эта работа для меня лично стрессовая и депрессивная. Она вгоняет меня в депрессию значительно быстрее, чем я почувствую какую-то эффект от офиса.
Я не понимаю, зачем в современном мире нужны офисы как таковые.
Я понимаю, зачем нужны какие-то места, где можно выпить кофе и поваляться на диванах. Я понимаю, зачем нужны кальянные и рестораны. Я понимаю, зачем нужны места, где можно проводить время. Но я абсолютно не понимаю, зачем нам сидеть рядами, смотреть в мониторы и ходить за кофе в определенную точку, потом возвращаться и опять сидеть на том же месте. Мне кажется, это неразумно. Есть масса других мест, где интереснее и более комфортно работать: в кафе, дома, на природе. Я не вижу смысла в объединении людей в такие офисные пространства. В последних книгах я достаточно много и серьёзно критикую вообще идею организации и мотивации людей на работу путём соединения их территориально. Эта концепция соединения людей в одном месте и направления их в одно русло, чтобы они делали что-то одно и совместно что-то достигали, на мой взгляд, должна уйти в прошлое. Сейчас нет в этом особой необходимости, есть качественные способы связи, хороший софт, качественные инструменты управления. Нам просто не нужно больше сидеть вместе для работы.
Роман: Я чуть-чуть уточню, когда я говорил про офис, я имел в виду работать на кого-то. Работал ли ты на кого-то и чем ты начал заниматься для себя? В какой момент и почему случился переход с работы по найму к работе на себя?
Егор: Я немного работал по найму, но я никогда не работал на кого-то. Я всегда работал на себя. Вопрос в том, кто мне платит деньги, на чьи средства я это делаю. Это меняется в определённые моменты моей жизни. Когда-то это оплачивала одна компания, потом другая. Сейчас мою работу оплачивают мои клиенты. Завтра это могут оплачивать мои инвесторы, послезавтра читатели моей книги. Вопрос «Откуда приходят деньги?» всегда имеет варианты. На этот вопрос всегда может быть разный ответ. Я всегда работал только на себя.
Мне тяжело себе представить, чтобы я свое время, свои усилия и свою энергию тратил на что-то, что достанется потом кому-то другому. Для меня это неприемлемо. Это будет меня очень сильно демотивировать, и я продержусь очень недолго: пару дней, может быть пару недель, но буду стараться вырваться из этого. Находясь в офисе, работая на чьём-то проекте, делая что-то, что выглядит как работа для кого-то, я всегда работаю на себя. Я нахожу, чем это занятие может мне лично быть полезным. Если я в проекте, и в нем нужно поставить новую систему deployment, мне за это платят, то я обязательно эту систему сделаю так, чтобы я потом о ней мог где-то написать, рассказать, чтобы я мог какой-то Open Source продукт из нее вынести, чтобы я мог что-то для себя лично в этом вынести. Дальше вся работа над этой системой у меня выглядит, как работа на себя. Заказчики тоже получат, конечно, в итоге работающую систему. Но в первую очередь выгоду получу лично я. Так я всегда делаю.
Илья: Егор, скажи, пожалуйста, если у тебя нет какого-то места, куда ты ходишь работать, то всё равно ты выбираешь: сегодня ты в кафе, завтра дома или на природе. У тебя есть расписание или ты просто просыпаешься и, куда хочется, туда идешь?
Егор: Скорее, куда хочется. Я стараюсь это не планировать, потому что если слушать свои желания и внутренние, часто необъяснимые мотивы, то в итоге получится лучше. Не знаю, возможно, кому-то было бы удобней наоборот, идти по графику, по плану, но я стараюсь прислушиваться к внутреннему голосу, который говорит: «Надоело дома, пойдем куда-нибудь». Я беру ноутбук и просто выхожу. Иногда я просто иду по улице и захожу в любое кафе, которое увижу, что-то заказываю и три-четыре часа, пока ноутбук не сядет, работаю. Потом мне надоедает, и я возвращаюсь домой.
Code Ahead
Алексей: Ты упомянул свою последнюю книгу. Она называется «Code Ahead». Давай, Егор, попробуем кратко в одном предложении сформулировать, о чём твоя последняя книга.
Егор: Хороший вопрос. Действительно в начале июля назад вышла книга, которую я писал дольше, чем все остальные, потратил на ее написание 8 месяцев. Суммарно она стартовала 1 год и 8 месяцев назад. Я долго готовился, а потом почти 8 месяца писал, многое переписывая, изменяя и выбрасывая целые главы. Усилий приложил много. Я не могу судить, что получилось. Мне было бы интересно услышать фидбэк, но на Amazon отзывов пока нет.
Что интересно, «Code Ahead» — художественная книга. То есть она написана не техническим языком, там есть персонажи и некий сюжет, диалоги, монологи, разговоры. Но при этом это, конечно, смешанный жанр. Я не видел такого до этого, но выбрал такой жанр. В свободном художественном изложении большое количество технических и научных ссылок. Персонажи разговаривают между собой, и по ходу диалога к их утверждениям, замечаниям и фактам, о которых идет речь, внизу страницы идёт большое количество сносок, которые подтверждают, либо опровергают заявления, сделанные персонажами.
Всего в книге больше трехсот таких ссылок на книги, статьи, научные статьи и все остальное. Я соединил художественный жанр и чуть ли не полунаучный. Как получилось — не знаю. Попробуйте купить и почитать. Мне кажется, что интересно. Я ее прочитал много раз, чего с предыдущими книгами не происходило. Предыдущие книги я написал, один раз прочитал и опубликовал. Эту я прочитал рез десять.
Роман: Чтобы писать книги, нужно читать очень много книг, прокачивать себя в этом направлении. Егор, что бы ты мог посоветовать почитать нашим читателям, но не из того, что написал ты, а другое. Что первое приходит в голову?
Егор: В моем блоге есть статья, которая называется «My favorite books». Там 16 книг, которые я однозначно рекомендую прочитать. Это книги, которые я читал ни один раз. Они для меня ценные, и я к ним часто возвращаюсь. Помимо этого, я бы рекомендовал книгу «Code Ahead». Процентов десять из тех трехсот ссылок отмечены специальным значком звездочкой. Остальные ссылки просто подтверждают факты, либо опровергают их. Ссылки со звездочкой — это литература, которую я бы однозначно рекомендовал прочитать и даже не один раз.
Доклад на AppsConf
Илья: Расскажи, пожалуйста, о теме своего доклада. Скоро ты будешь выступать на AppsConf, про что ты будешь рассказывать?
Егор: Я буду предлагать взглянуть на ситуацию с программированием и с его качеством, и попытаюсь предложить свое решение этого конфликта. Конфликт заключается, как мне кажется, в том, что стандартные ожидания менеджмента, технического и организационного, от программистов сводятся к тому, что программист должен писать код, в котором нет ошибок. Это ожидание достаточно традиционное и популярное. Я его встречал и в реальной практике, и в литературе, и могу привести несколько ссылок на книги, где сказано, что хороший программист пишет код, в котором нет багов. Если использовать эту концепцию, как фундаментальную и от неё отталкиваться, то на практике мы очень быстро приходим к проблеме: что делать, чтобы программисты писали код без ошибок? Как найти хорошего программиста и что делать, если программист плохой?
Есть два решения:
- нанимать «хороших программистов»;
- из плохих делать хороших путем усиления негатива вокруг самой идеи ошибки или бага, который которые они потенциально могут создать.
Нанимаем хороших, с одной стороны, а с другой стороны пугаем плохих, чтобы они стали хорошими. Такой подход я встречаю повсеместно. В докладе я попытаюсь предложить альтернативное решение, которое работает в нашей компании и в наших проектах мы работаем. У нас положительное отношение к багам. Мы считаем, что ошибки и дефекты, которые программисты создают, это естественная составляющая любого процесса создания программного продукта. Ошибки нужны, они должны быть, они необходимы. Нужно таким образом построить систему контроля качества, выявления этих ошибок и недопущения попадания этих ошибок в Production, чтобы в итоге были довольны и заказчики, и программисты. Нужно исключить элемент страха, который присутствует у программистов, которым рассказывают, что баги — это плохо. При этом сделать так, чтобы качество всё-таки было высокое. Я предложу такой подход и разложу его на составляющие.
Почему такая тема
Алексей: Скажи, пожалуйста, как родилась такая тема доклада? Какая ситуация произошла, что ты понял существование этого конфликта, осознал необходимость его разрешить и предложил свое решение?
Егор: Мы работаем с фрилансерами. У нас этот конфликт очень острый и, наверное, острее, чем в других компаниях. Поэтому для нас его решение является вопросом жизни или смерти проекта. Фрилансеры — это достаточно хаотичные ребята, в основном недисциплинированные, достаточно трудно управляемые и часто сменяемые. Это люди, которые приходят в проект, уходит из него. В нашем случае проект может за три месяца поменять команду несколько раз целиком. Поэтому для нас этот вопрос был очень важен.
Как сделать так, чтобы люди, приходящие в проект случайно, со стороны, неизвестно надолго ли, всё равно выдавали такой код, с которым мы бы могли остаться даже после потери этих программистов, даже после смены команды на 100%? Кроме того, чтобы мы могли выжить после смены команды, нужно сделать ещё и так, чтобы эти люди могли контрибьютить на высокой скорости. Фрилансер, приходя к нам в проект, должен иметь возможность быстро включиться и начать отдавать код, а потом быстро уйти из проекта. У нас такие экстремальные условия. Так было задумано и сейчас так всё и происходит. Возник вопрос, как сделать так, чтобы этот программист, не испытывая никаких эмоций к проекту, не пытаясь сделать его лучше по каким-то своим внутренним мотивам, не пытаясь даже глубоко вникнуть в проект, а просто желая заработать какие-то деньги на коротком отрезке времени, при этом всё равно выдавал нам такого качества код, как мы хотим. И у нас это получается. Мы решили эту задачу с помощью методов, о которых я расскажу в докладе. Я этим не просто поделюсь на конференции, не просто потому что интересно поделиться достижением, а я собираюсь использовать это еще и как способ информирования программистов на будущее.
Роман: Егор, это очень провокационная тема. Всякий раз, когда я слышу про тяп-ляп и в Production, разработчики мало задумываются про архитектуру, про какие-то концептуальные вещи. Получается, что с микрозадачами в проекте никто совершенно не думает про высокоуровневые архитектурные вещи? Ведь невозможно за короткий отрезок времени придумать большое что-то, скелет проекта?
Егор: Да, действительно, у нас не всё в микрозадачах. Скелет проекта создается архитектором. Архитектор его делает при старте проекта собственными усилиями, затрачивая на это незначительное количество времени, но делает это, как цельный блок работы, который может занять неделю—две. Потом проект живет своей жизнью. Архитектор, оставаясь в проекте, может проконтролировать, чтобы архитектура не расползлась, просто делая Code review. По нашему опыту архитектору достаточно быть центральным, таким финальным Code review-ером, который получая contribution от программистов, на него накладывает вето, либо допускает в Production.
Разработка мобильных приложений
Роман: Егор, а есть ли в твоем портфолио мобильные приложения и используется ли такой подход при их разработке?
Егор: Лично я не мобильный разработчик. Поэтому я не являюсь архитектором ни одного мобильного приложения. Но у нас на платформе есть проекты, где люди разрабатывают мобильные приложения.
Роман: Я думаю, не мне одному будет интересно поймать тебя потом в кулуарах и расспросить, как же этот подход применяется при разработке мобильных приложений
Егор: Я часто слышу вопросы такого плана: «Применяется ли это в разработке Big Data приложений? Можно ли это применить в искусственном интеллекте?» Я не вижу большой разницы между приложениями, разными доменами, доменными зонами, где используется приложение. Какая нам разница, мобильное это предложение или web. Там всё равно есть архитектура, код. У этого кода есть строки, классы и методы. Значит, это можно разбить на микроинкременты и дальше просматривать их по отдельности, анализировать качество и принимать один за другим сотнями, тысячами, десятками тысяч. Поэтому я не вижу большой разницы между мобильным приложением и Big Data предложением.
Помощь людей в проектах
Илья: Егор, у тебя очень интересный профиль на GitHub, у тебя более 1700 фолловеров и более 300 звёздочек, куча репозиториев и проектов. Ты участвуешь в очень большом количестве проектов. Скажи, как ты находишь людей, которые тебе помогают с ними? Они приходят сами, ты что-то специально делаешь или это вообще всё твои сотрудники, которым ты платишь деньги?
Егор: Во-первых, это сообщество не вчера появилось. Я с 2009 года активно пишу код на GitHub. Я написал, может, миллион строчек кода. Я ежедневно пишу какой-то код, в основном в Open Source виде, практически нет ничего, что было бы в закрытом режиме. Код любых проектов, которые лично я делаю, я всегда стараюсь открыть. У меня было такое желание и пять лет назад, и когда я начинал на гитхабе, и до этого, и сейчас.
Мне кажется, чем больше разработчик делает в открытом виде, тем это лучше для него, для его работодателя, для компании и для всего сообщества. Я вообще такой активный адепт и евангелист Open Source. Я считаю, что закрытый код это пережиток прошлого. Он, конечно, существует. К нам часто приходят программисты, которые показывают пустой гитхаб-аккаунт и говорят, что они очень профессиональные программисты, просто у них нет ничего в открытом коде, потому что они последние 10 лет работали в закрытом режиме. Мы стараемся таких программистов не брать, потому что у нас большой опыт работы с такими ребятами. В основном всё заканчивается тем, что они не умеют работать в Open Source экосистеме.
Они могут быть хорошими программистами, могут уметь писать алгоритмы, понимать в Java и технологиях обработки данных, но они не умеют общаться в экосистеме, не умеют быть частью системы разработки программного продукта. А это, на мой взгляд, является значительно более важным качеством в современном рынке, чем алгоритмы и способы обработки данных. С алгоритмами мы как-нибудь справимся, найдем, их много написано — мы разберёмся. Это проблема менее тяжелая, чем умение сделать так, чтобы твой pull request в итоге попал в production.
Большинство людей просто не умеют работать в экосистеме Open Source. Они присылают pull request. A когда ты им в этот pull request пишешь комментарии, то они тебе звонят по телефону и пытаются объяснить, почему ты не прав. У них нет навыка, нет дисциплины и коммуникации в Open Source проекте. Они не понимают, что не каждому программисту можно позвонить и не каждому программисту можно задать вопрос. Они не понимают, что программист может быть в проекте сегодня, а завтра его уже там нет. Не надо никому звонить, пиши в гитхабе. Если ты спрашиваешь у человека напрямую, а завтра этот человек ушёл из проекта, вся информация, которой вы обменялись, утеряна, и ты просто потерял время. Поэтому у этих людей нет дисциплины работы через код. Они не умеют его документировать, не умеют по нему писать комментарии, не умеют работать в ветках. Они не понимают, как выглядит deployment, что его надо поддерживать вместе с кодом. У них нет огромного количества навыков, которые делают из кодера программиста.
У меня есть статья на эту тему, где я писал, обращаясь к читателю: «Определись, ты кодер или программист? Либо ты умеешь писать код, либо ты действительно умеешь быть частью проекта по разработке программного продукта». Это совершенно разные вещи. Просто кодер — это 15% успеха, остальные 85% — это умение работать в команде. Я говорю сейчас не об умении сидеть в офисе, пить кофе и дружить с коллегами по работе. Я говорю о том, чтобы быть членом живой команды, в которую приходят и уходят люди, в которой меняются технологии, возникают конфликты. Неумение делать это — это огромный недостаток современного рынка.
На нашу платформу в день приходит десять новых человек. Девять из десяти просто не умеют этим заниматься, они обычные кодеры. У них нет этого навыка. Я виню в этом офисы, отсутствие открытого кода, еще их лень и отсутствие информации. Многие люди работают в закрытом коде и гордятся этим. Я, обращаясь к таким людям говорю: «Это твоя вина, твой недостаток. Ты тратишь свое время, сидя в закрытом коде, не выходя в Open Source, не вытаскивая какие-то куски из этого кода в Open Source».
Найдите способ вытащить какую-то библиотеку из вашего закрытого кода. Найдите способ сделать что-то такое в открытом коде. Выйдите в Open Source, сделайте себе аккаунт на GitHub и Stack Overflow. Будьте публичным человеком, тогда вы увидите, что такое работать с открытым кодом. Когда случайные люди будут писать вам, где вы не правы, когда вам будут присылать pull request-ы, на которые вы не будете знать, что ответить, когда вы будете делать pull request-ы. Тогда вы станете частью этой экосистемы, за которой будущее. Закрытый код — это прошлое. Офисная работа — это прошлое. Пройдет 10-15 лет, и эти люди станут никому нужны, как Кобол программисты. Нужны будут люди, которые есть на GitHub.
Автоматический deployment
Алексей: Егор, перед тобой каждый день встают самые разные задачи по коду, по управлению. Расскажи, пожалуйста, про какую-нибудь задачу, которая вызвала у тебя неимоверную радост. Неважно, это было что-то сложное или простое. Что тебе очень понравилось из последнего?
Егор: Я даже собираюсь на эту тему тоже сделать в ближайшее время доклад. Понравилось то, что за мои 25 лет программирования я еще не видел. Наша система криптовалюты состоит из большого количества серверов. В настоящий момент у нас их не так много — 70, но, тем не менее, это 70 серверов. Они принадлежат совершенно неизвестным для меня людям, это анонимные пользователи. На каждом сервере установлено наше программное обеспечение — Zold, Ruby gem, который стоит на каждом сервере.
Я разработал систему deployment, что когда версия обновляется на одном из серверов, то остальные сервера автоматически себя рестартуют, обновляют свою версию и стартуют заново. В разработке это было интересно. Я не могу этим 70 людям написать e-mail, как это делает Bitcoin, и сказать, что нужно обновиться и поставить новую версию. Каждый из майнеров биткоина должен руками обновить свою версию. У нас такой возможности нет и мне не хотелось делать так. Хотелось сделать так, чтобы я обновлял версию одним кликом, и тут же вся сетка меняла свою версию. Анонимные сервера, мне неподконтрольные, сами автоматически обновляются на следующую версию. Было очень здорово увидеть, как это стало работать в живом режиме. Я захожу на неизвестные мне машины через фронтенд, и вижу, как они щёлк-щёлк-щёлк одна за другой меняют версию, и за 5-7 минут вся сетка обновляется. Вот это было интересно увидеть. Я такого автоматического deployment без прямого контроля с обратной связью в своей жизни не делал. Я это когда-нибудь покажу на конференции, как это технически работает. Я думаю, что будущее за системами, которые состоят из анонимных участников и при этом работают под общим контролем, не имея человека вообще в этой схеме.
Илья: Я хочу напомнить, что Егора можно будет увидеть на конференции AppsConf, которая пройдет 8-9 октября в Москве. Приходите, задавайте вопросы, слушайте доклад Егора.
Егор: Да, обязательно приходите. Обо всем, что я сегодня сказал, в докладе будет более подробно. Я расскажу, как именно мы достигаем своих целей, покажу реальные примеры. Думаю, это воодушевит вас.
Спасибо вам, дорогие слушатели и читатели, увидимся в новых выпусках.
