Java конференция с английскими корнями. Продолжение мегаобзора

    Нам с mpryakhin, моим коллегой из CleverDATA, удалось съездить в британскую столицу на Java-конференцию  – Jax London 2017. На прошлой неделе вы уже читали о Chaos Engineering, lambda выражениях, катастрофичных багах и Continuous Delivery Java приложений в контейнерах.

    А здесь, во второй части обзора, вас ждёт рассказ о том, как построить карьеру по собственному плану, а не как придётся; как с помощью метрик оптимизировать работу над новым функционалом. Вы также узнаете о тонкостях построения высоконагруженных систем обработки событий и найдете полезные ссылки для работы с Ethereum смарт-контрактами при помощи Java API.




    День третий. Профессиональный рост в нужном направлении и контроль процесса разработки с помощью метрик


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

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

    «The Long Road» by Sandro Mancuso


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

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

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


    Источник

    Большая компания может предложить сотруднику много вариантов построения карьеры, заинтересовать его миллионами различных KPI. Но бывает так, что сотрудник, продвинувшись по карьерной лестнице на несколько позиций, оказывается разочарован. Потому что он строил свою карьеру в соответствии с KPI, которые были целью компании, а не со своими собственными планами. И тогда ему придется спуститься на пару ступеней вниз.

    Отсюда вывод: периодически стоит притормозить и оценить свою деятельность с позиции своих долгосрочных целей, понять, насколько наши текущие действия помогают нам в достижении наших целей и требуют ли цели корректировки на основе того опыта, который мы приобрели по мере их достижения.

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

    Стоит учесть и стратегические моменты: позицию компании на рынке (как локальном, так и международном), ее цели и амбиции, бизнес-домен, в рамках которого компания ведет свою деятельность, и наиболее важный аспект – команду специалистов, частью которой вам предстоит стать.

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

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

    Другие размышления Sandro Mancuso – в видеозаписи его доклада.

    «Measuring the DevOps: The Key Metrics that Matter» by Anders Wallgren


    При разработке программного обеспечения мы, бывает, настолько увлекаемся идеей, что все остальное для нас перестает существовать. Идея видится пылающим факелом, мы тянем к нему руки. Кажется, успех уже совсем близко, но вот внезапно земля уходит из под ног, горящий факел оказывается недосягаемой звездой, а мы остаемся один на один со своим продуктом и вопросом «Что же пошло не так?»

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

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

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

    Итак, часть времени, которое мы отводим себе на выполнение задачи, мы тратим не совсем так, как ожидалось изначально, но не всегда бывает понятно, куда же именно оно уходит. А когда мы что-то плохо понимаем, проще всего начать собирать какую-то информацию о нашей деятельности. Здесь метрики нам в помощь. Подробнее обо все этом нам поведали специалисты компании Electric Cloud.



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

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

    Но вернемся к метрикам, а точнее их типам:

    • эффективность процесса разработки и внедрения фич;
    • влияние фич на удовлетворенность клиентов;
    • влияние фич на продукт и наш бизнес;
    • удовлетворенность сотрудников.

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

    Как правило, любой процесс разработки новой фичи можно свести к следующему набору этапов разработки (pipeline).

    Картинка кликабельна:



    Итак, перед нами пять этапов разработки типового проекта:

    • разработка;
    • тестирование;
    • деплоймент;
    • внедрение;
    • сопровождение.

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

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

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

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

    • Стоимость привлечения нового клиента. Если новые фичи актуальны для рынка, окружения, своевременно обновляются и количество багов довольно мало, то и степень лояльности ваших клиентов увеличивается, растет ваша популярность на рынке и, как следствие, снижается стоимость привлечения нового клиента.
    • Прибыль. Здесь все довольно просто: увеличение количества клиентов, снижение издержек на сопровождение.
    • Доля рынка. Всегда полезно трезво оценивать окружающую обстановку.

    Продукт должен удовлетворять целям ваших клиентов/пользователей. Здесь метрики следующие.

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

    В Google есть правило: если влияние изменений невозможно оценить с точки зрения business value, такие изменения делать нецелесообразно. Из-за этого все вокруг покрыто метриками.

    Часть описанных подходов мы сами используем при разработке нашего продукта (1DMP). Самое приятное – это то, что, имея часть этих метрик на руках, мы можем количественно и качественно оценивать те или иные изменения, которые мы вносим в процесс разработки/внедрения и сопровождения нашего продукта. Это позволяет нам с каждой итерацией производить более тонкую настройку процесса и быстрее двигаться к цели.

    Более детально с данной темой можно ознакомиться в видео докладчиков.

    «Scaling Event Sourcing for the IoT and mobile» by Lorenzo Nicora


    Последний доклад этого дня обещал рассказать нам о тонкостях, нюансах и подходах, применяемых при построении высоконагруженных систем обработки событий. Описание доклада пестрило множеством терминов: появившихся относительно недавно (reactive design patterns, actor model), и более фундаментальных, применяемых многими, но от этого не менее интересных (DDD, CQRS, Event Sourcing).

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

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

    Всем известны проблемы масштабирования типовой информационной системы при возрастании нагрузки. Как правило, узким местом служит сервер БД, который плохо масштабируется при интенсивной записи.



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

    У данного решения есть один большой недостаток. Как только мы добавили промежуточный буфер, мы потеряли гарантию того, что две операции, выполненные с точки зрения клиента последовательно, дойдут до нашей БД в той же самой последовательности, т.е. консистентность системы может быть нарушена.

    Итак, у нас есть некий источник событий, последовательность которых имеет значение. Мы хотим продолжать масштабироваться горизонтально, но при этом для нас важна консистентность данных и транзакционность их изменений. DDD (Domain-Driven Design) нам в помощь.

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

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

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



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

    На помощь приходит подход CQRS (command-query responsibility segregation), из названия которого понятно, что процессы записи и чтения разведены по разным углам. Поскольку система имеет полный лог событий, рожденных в ходе воздействия пользователей на нее, не составит труда перечитать этот лог в любом виде, оптимизированном под задачу чтения.



    Но не стоит забывать, что система распределена между различными инстансами приложения, которые могут находиться на разных серверах. Это добавляет накладные расходы на маршрутизацию запроса на нужный инстанс приложения, на котором доступен процесс, обрабатывающий запросы к данному доменному объекту. В свою очередь, это приводит к повышенной чувствительности системы к репартиционированию.

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

    В части случаев источник запросов не может гарантировать последовательность и порядок запросов, например, датчики IoT устройств и сигналы, которые они отправляют. Часть времени эти устройства могут находиться offline или в режиме энергосбережения (они буферизируют информацию в себе и периодически отправляют ее на сервер).

    Также хорошим примером могут быть различные мобильные игры, которые предоставляют свой основной функционал, если устройство вне сети. При ее появлении они отправляют статистику об игроке на сервер для ее последующего учета в игровых механиках. В данном случае обработка входящего запроса сводится к его базовой валидации и записи в большое аналитическое хранилище для проведения дальнейшей аналитики. Это позволяет избавиться от хранения состояния в сервисе и стандартным образом горизонтально масштабировать сервис обработки запросов. Данный подход известен как Weak Write Сonsistency.



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

    Более подробно с данной тематикой можно ознакомиться в видео доклада.

    Так совсем незаметно для нас пролетел третий день конференции. Основная часть докладов осталась позади. Голова была полна мыслей, а выданные блокноты исписаны заметками. Остаток вечера мы провели в одном из пабов Лондона за кружкой хорошего эля и куском вкуснейшего стейка.

    Совет тем, кто прилетел в Лондон не только ради конференции
    Программа конференции оказалась насыщенной, и мы не хотели упустить ничего интересного, поэтому для изучения города оставалось только вечернее время. Прогулка по вечернему или ночному Лондону оставляет самые яркие впечатления.

    После десяти вечера улицы потихоньку пустеют, на них загораются фонари, заполняя все вокруг теплым желтым светом, а в окнах домов можно заметить гостиные, полные книг. Все это создает ощущение, что ты идешь в теплых тапочках по страницам произведений Артура Конан Дойла или Чарльза Диккенса, настраивает на особенный лад.



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

    Мы прошлись мимо музея Мадам Тюссо, по знаменитой улице Ноттинг Хилл, видели настоящие английские парки и пришли к мнению, что нам обязательно стоит приехать сюда в будущем, чтобы иметь побольше времени на ознакомление с культурным наследием Англии в светлое время суток.


    День четвертый. Blockchain с использованием Java




    «Developing Java Applications on the Blockchain with web3j» by Conor Swensson


    По ходу семинара Конор рассказал о основных вехах развития blockchain технологий. Доклад оказался довольно подробным, и было интересно узнать, что один из трендов в мире blockchain, над которым уже работают многие корпорации, – построение распределенного приватного blockchain. Кроме того, часть из технологических решений уже оформилась в библиотеки и framework-и, и собралась под зонтиком Hyperledger Foundation, образованного при участии Linux Foundation в 2015 году.

    В ходе семинара мы узнали о базовых принципах работы blockchain на примере сети Etherium. Кодовая база семинара строилась на основе открытой библиотеки web3j, которая является мостиком между смарт-контрактами, написанными на Solidity и Java машиной.

    Участники семинара выполнили следующие задачи:

    • завели себе тестовый кошелек;
    • подключились к тестовой сети;
    • написали простейший смарт-контракт и опубликовали его в Ethereum Blockchain;
    • написали небольшой сервис, взаимодействующий с опубликованным смарт-контрактом.

    Так как все материалы проведенного семинара находятся в публичном доступе на github, каждый может так же, как и мы пройти данный семинар и разобраться во всех нюансах работы Ethereum смарт-контрактов при помощи Java API.

    В публичном доступе появилось видео с содержанием, аналогичным семинару.

    В заключение


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

    • +28
    • 2,5k
    • 6
    ГК ЛАНИТ 223,25
    Ведущая многопрофильная группа ИТ-компаний в РФ
    Поделиться публикацией
    Комментарии 6
    • +2
      Спасибо, интересно. С удовольствием прочитал обе статьи. Вы наверняка были на подобных российских конференциях. Расскажите, чего не хватает нашим (а есть ощущение, что не хватает) или чему у наших можно поучиться? Есть ли ощутимые отличия по контингенту и по уровню спикеров?
      • +2
        Мы обычно весной ходим на JPoint, и осенью пару лет назад довелось побывать на Highload++.

        Посетив конференцию в Лондоне, мы были приятно удивлены, осознав, что наши конференции ничем не уступают зарубежным: ни по контенту, ни по самому формату. Я бы даже сказал, что на наших конференциях делают бОльший упор на шоу и оформление, что также идет на пользу.

        По сравнению с нашими конференциями, где выступают в основном технические специалисты крупных компаний, на Jax London было множество технических спикеров, которые имеют свой бизнес в UK или Европе и занимаются консалтингом в различных технических сферах. Это не хорошо и не плохо, но разница в подаче контента и его содержании заметна. Насчет уровня спикеров, я думаю, как и везде, были сильные доклады, и были доклады довольно поверхностные, но это все довольно субъективно.

        По контингенту: у меня сложилось ощущение, что аудитория конференции была в целом на 5-7 лет старше, чем у нас.
        • +1
          Понял вас. Круто и приятно такое слышать о российских. Спасибо за разъяснения!
          • +2
            Надо заметить, что у нас есть два отличных огранизатора конференций — это JUG.RU(Joker, JPoint, DotNext, HolyJS и т.д.) и «Конференции Олега Бунина»(HighLoad++, РИТ++ и т.д.).
            Думаю, во многом благодаря им у нас столь неплохой уровень конференций.
            • 0
              Полностью с Вами согласен, они задают высокую планку

        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

        Самое читаемое