Русский
Русский
English
Статистика
Реклама

Конференции

Перевод Конференция QCon. Овладение хаосом руководство Netflix для микросервисов. Часть 4

26.06.2020 00:04:47 | Автор: admin
Джош Эванс рассказывает о хаотичном и ярком мире микросервисов Netflix, начиная с самых основ анатомии микросервисов, проблем, связанных с распределенными системами и их преимуществ. Опираясь на этот фундамент, он исследует культурные, архитектурные и операционные методы, которые ведут к овладению микросервисами.

Конференция QCon. Овладение хаосом: руководство Netflix для микросервисов. Часть 1
Конференция QCon. Овладение хаосом: руководство Netflix для микросервисов. Часть 2
Конференция QCon. Овладение хаосом: руководство Netflix для микросервисов. Часть 3

В отличии от operational drift, внедрение новых языков для интернационализации сервиса и новых технологий, таких как контейнеры, это сознательные решения добавить новую сложность в окружающую среду. Моя группа операционистов стандартизировала асфальтированную дорогу лучших технологий для Netflix, которые запекались в заранее определенных наилучших практиках, основанных на Java и EC2, однако по мере развития бизнеса разработчики стали добавлять новые компоненты, такие как Python, Ruby, Node-JS и Docker.



Я очень горжусь тем, что мы первыми сами выступали за то, чтобы наш продукт отлично работал, не дожидаясь жалоб клиентов. Все начиналось достаточно просто у нас были операционные программы на Python и несколько бэк-офисных приложений на Ruby, но все стало намного интересней, когда наши веб-разработчики заявили, что намерены отказаться от JVM и собираются перевести веб-приложение на программную платформу Node.js. После внедрения Docker вещи стали намного сложнее. Мы руководствовались логикой, и придуманные нами технологии стали реальностью, когда мы внедрили их для клиентов, потому что они имели большой смысл. Расскажу вам, почему это так.

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

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

Логично было взять эти endpoints и вытянуть их из API-сервиса. Для этого мы создали компоненты Node.js, которые запускались как небольшие приложения в контейнерах Docker. Это позволило изолировать любые неполадки и сбои, вызванные этими node-приложениями.

Стоимость этих изменений достаточно велика и складывается из следующих факторов:

  • Инструменты повышения производительности. Управление новыми технологиями требовало новых инструментов, потому что UI-команда, использующая очень удачные скрипты для создания эффективной модели, не должна была тратить много времени на управление инфраструктурой, она должна была заниматься только написанием скриптов и проверкой их работоспособности.
    Инсайт и сортировка возможностей ключевым примером являются новые инструменты, необходимые для выявления информации о факторах производительности. Нужно было знать, на сколько % занят процессор, как используется память, и сбор этой информации требовал разных инструментов.
  • Фрагментация базовых образов простая базовая AMI стала более фрагментированной и специализированной.
  • Управление узлами. Не существует доступной готовой архитектуры или технологий, которые позволяют управлять узлами в облаке, поэтому мы создали Titus платформу управления контейнерами, которая обеспечивает масштабируемое и надежное развертывание контейнеров и облачную интеграцию с Amazon AWS.
  • Дублирование библиотеки или платформы. Предоставление новым технологиям одних и тех же основных функций платформы потребовало ее дублирования в облачные инструменты разработчиков Node.js.
  • Кривая обучения и производственный опыт. Внедрение новых технологий неизбежно создает новые проблемы, которые необходимо преодолеть и извлечь из них уроки.

Таким образом, мы не могли ограничиться одной асфальтированной дорогой и должны были постоянно строить новые пути для продвижения своих технологий. Для снижения стоимости мы ограничивали централизованную поддержку и фокусировались на JVM, новых узлах и Docker. Мы расставляли приоритеты по степени эффективного воздействия, информировали команды о стоимости принятых ими решений и стимулировали их искать возможность многократного использования уже разработанных эффективных решений. Мы использовали этот подход при переводе сервиса на иностранные языки для доставки продукта интернациональным клиентам. Примерам могут служить относительно простые клиентские библиотеки, которые могут генерироваться автоматически, так что достаточно легко создавать Python-версию, Ruby-версию, Java-версию и т.д.

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

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



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



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



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

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



В конце выступления я коротко расскажу об организации и архитектуре Netflix. В самом начале у нас была схема под названием Electronic Delivery электронная доставка, представлявшая собой первую версию потоковой передачи медиаконтента NRDP 1.x. Здесь можно использовать термин обратный поток, потому что изначально пользователь мог только скачивать контент для последующего воспроизведения на устройстве. Самая первая платформа электронной доставки Netflix образца 2009 года выглядела примерно так.



Пользовательское устройство содержало в себе приложение Netflix, которое состояло из интерфейса UI, модулей безопасности, активации сервиса и воспроизведения, базирующихся на платформе NRDP Netflix Ready Device Platform.

В то время пользовательский интерфейс был очень прост. Он содержал так называемый Queque Reader, и пользователь заходил на сайт, чтобы добавить что-то в Queque, а затем просматривал добавленный контент на своем устройстве. Положительным было то, что клиентская команда и серверная команда принадлежали одной организации Electronic Delivery и имели тесные рабочие взаимоотношения. Полезная нагрузка была создана на основе XML. Параллельно был создан API Netflix для DVD бизнеса, который стимулировал сторонние приложения направлять трафик в наш сервис.

Однако Netflix API был хорошо подготовлен к тому, чтобы помочь нам с инновационным пользовательским интерфейсом, в нем содержались метаданные всего контента, сведения о том, какие фильмы доступны, что создавало возможность генерировать списки просмотра. У него был общий REST API, базирующийся на схеме JSON, HTTP Response Code, такой же, что используется в современной архитектуре, и модель безопасности OAuth то, что требовалось в то время для внешнего приложения. Это позволило перейти от публичной модели доставки потокового контента к приватной.



Проблема перехода заключалась во фрагментации, так как теперь в нашей системе функционировали два сервиса, основанные на совершенно разных принципах работы один на Rest, JSON и OAuth, другой на RPC, XML и механизме безопасности пользователей на основе системы токенов NTBA. Это была первая гибридная архитектура.

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



В связи с этим у меня был разговор с одним из старших инженеров компании, которому я задал вопрос: Что должна представлять собой правильная долгосрочная архитектура?, и он задал встречный вопрос: Вероятно, тебя больше волнуют организационные последствия что произойдет, если мы интегрируем эти вещи, а они сломают то, что мы хорошо научились делать?. Этот подход очень актуален для закона Конвея: Организации, проектирующие системы, ограничены дизайном, который копирует структуру коммуникации в этой организации. Это очень абстрактное определение, поэтому я предпочитаю более конкретное: Любая часть программного обеспечения отражает организационную структуру, которая его создала. Приведу вам мое любимое высказывание, принадлежащее Эрику Реймонду: Если над компилятором работают четыре команды разработчиков, то в итоге вы получите четырехпроходный компилятор. Что же, Netflix имеет четырехпроходный компилятор, и это то, как мы работаем.

Можно сказать, что в этом случае хвост машет собакой. У нас на первом месте не решение, а организация, именно она является драйвером архитектуры, которую мы имеем. Постепенно от мешанины сервисов мы перешли к архитектуре, которую назвали Blade Runner Бегущий по лезвию, потому что здесь речь идет о граничных сервисах и возможностях NCCP разделяться и интегрироваться напрямую в Zuul-прокси, API-шлюз, причем соответствующие функциональные куски были превращены в новые микросервисы с более продвинутыми функциями безопасности, воспроизведения, сортировки данных и т.д.

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


Немного рекламы


Спасибо, что остаётесь с нами. Вам нравятся наши статьи? Хотите видеть больше интересных материалов? Поддержите нас, оформив заказ или порекомендовав знакомым, облачные VPS для разработчиков от $4.99, уникальный аналог entry-level серверов, который был придуман нами для Вас: Вся правда о VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps от $19 или как правильно делить сервер? (доступны варианты с RAID1 и RAID10, до 24 ядер и до 40GB DDR4).

Dell R730xd в 2 раза дешевле в дата-центре Equinix Tier IV в Амстердаме? Только у нас 2 х Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 ТВ от $199 в Нидерландах! Dell R420 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB от $99! Читайте о том Как построить инфраструктуру корп. класса c применением серверов Dell R730xd Е5-2650 v4 стоимостью 9000 евро за копейки?
Подробнее..

Перевод Kонференция NDС London. Предотвращение катастрофы микросервисов. Часть 1

27.06.2020 16:12:41 | Автор: admin
Вы потратили месяцы, переделывая свой монолит в микросервисы, и наконец, все собрались, чтобы щелкнуть выключателем. Вы переходите на первую веб-страницу и ничего не происходит. Перезагружаете ее и снова ничего хорошего, сайт работает так медленно, что не отвечает в течение нескольких минут. Что же случилось?

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



Приветствую всех, я Джимми, и сегодня вы услышите, как можно избежать мегакатастроф при создании микросервисов. Эта история компании, в которой я проработал около полутора лет, чтобы помочь предотвратить столкновение их корабля с айсбергом. Чтобы рассказать эту историю должным образом, придется вернуться в прошлое и поговорить о том, с чего начиналась эта компания и как со временем росла ее ИТ-инфраструктура. Чтобы защитить имена невиновных в этой катастрофе, я изменил название этой компании на Bell Computers. На следующем слайде показано, как выглядела IT инфраструктура таких компаний в середине 90-х. Это типичная архитектура большого универсального отказоустойчивого сервера HP Tandem Mainframe для функционирования магазина компьютерной техники.



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

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

Первоначальный дизайн выглядел довольно симпатично и состоял из сайта верхнего уровня bell.com и ряда поддоменов для отдельных приложений: каталога catalog.bell.com, аккаунтов account.bell.com, заказов orders.bell.com, поиска товаров search.bell.com. Каждый поддомен использовал фреймворк ASP.Net 1.0 и собственные базы данных, и все они общались с бэкендом системы. Однако все заказы продолжали обрабатываться и выполняться внутри единственного огромного мейнфрейма, в котором оставался весь мусор, зато фронтенд представлял собой отдельные веб-сайты с индивидуальными приложениями и отдельными базами данных.



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



Все элементы адресовали вызовы друг другу, обращались к API, встраивали сторонние библиотеки dll и тому подобное. Часто случалось, что системы управления версиями хватали чужой код, запихивали его внутрь проекта, и затем все ломалось. MS SQL Server 2005 использовал концепцию линк-серверов, и хотя я не показал стрелками на слайде, каждая из баз данных также общалась друг с другом, потому что как бы нет ничего плохого в том, чтобы строить таблицы на основании данных, полученных из нескольких БД.

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



Самое смешное было то, что этот мейнфрейм был построен конкурентами Bell Сomputers и до сих пор обслуживался их техническими консультантами. Убедившись в неудовлетворительной работе своих приложений, компания решила от них избавиться и сделать редизайн системы.

Существующее приложение было в продакшене на протяжении 15 лет, что является рекордным для приложений на базе ASP.Net. Сервис принимал заказы со всего мира, и ежегодная прибыль от этого единственного приложения достигала миллиарда долларов. Значительную часть прибыли формировал именно веб-сайт bell.com. По черным пятницам число заказов, сделанных через сайт, достигало несколько миллионов. Однако существующая архитектура не позволяла никакого развития, поскольку жесткие взаимосвязи элементов системы практически не позволяли вносить в сервис никаких изменений.

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

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

Руководство Bell Сomputers приняло решение построить именно такую архитектуру, придерживаясь неких основных принципов. Во-первых, они отказались от дублирования данных, используя подход общего доступа к БД. Никакие данные не пересылались, напротив, все, кто в них нуждался, должны были обращаться к централизованному источнику. Далее следовали изолированность и автономность каждый сервис был независим от других. Они решили использовать Web API абсолютно для всего если вы хотели получить данные или внести изменения в другую систему, все это делалось через Web API. Последней важной вещью был новый главный мейнфрейм под названием Bell on Bell в отличие от мейнфрейма Bell, основанного на железе конкурентов.

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

Они поступили разумно, кинув все деньги на решение этой проблемы. Они установили самые современные серверные стойки со свитчами, использовали гигабитное оптоволокно, самое мощное серверное железо с сумаcшедшим объемом RAM, соединили все это, настроили и снова ничего! Тогда они начали подозревать, что причина может быть в таймаутах, поэтому зашли во все веб-настройки, все настройки API и обновили всю конфигурацию таймаутов до максимальных значений, так что оставалось только сидеть и ждать, когда с сайтом что-то произойдет. Они ждали, ждали и ждали в течение 9 с половиной минут, пока веб-сайт наконец-то загрузился.

После этого до них дошло, что сложившаяся ситуация нуждается в тщательном разборе, и они пригласили нас. Первое, что мы выяснили в течение всех 18 месяцев разработки так и не было создано ни одного реального микро все становилось только еще больше. После этого мы приступили к написанию post-mortem, известного также как regretrospective, или печальная ретроспектива, она же blame storm обвинительный штурм по аналогии с мозговым штурмом brain storm, чтобы разобраться в причине катастрофы.

У нас было несколько улик, одной из которых являлось полное насыщение трафиком в момент вызова API. Когда вы используете монолитную архитектуру сервиса, то сразу можете понять, что именно пошло не так, потому что у вас имеется трассировка к единственному стеку, которая сообщает обо всем, что могло вызвать сбой. В случае, когда куча сервисов одновременно обращаются к одному API, нет никакой возможности отследить трассировку, кроме как использовать дополнительные инструменты сетевого мониторинга типа WireShark, благодаря которым можно рассмотреть отдельный запрос и выяснить, что произошло при его реализации. Поэтому мы взяли одну веб-страницу и на протяжение почти 2-х недель складывали кусочки мозаики, совершая к ней самые различные вызовы и анализируя, к чему приводит каждый из них.
Посмотрите на эту картинку. Она показывает, что один внешний запрос побуждает сервис совершать множество внутренних вызовов, которые возвращаются обратно. Получается, что каждый внутренний вызов совершает дополнительные хопы, чтобы быть способным самостоятельно обслужить этот запрос, потому что не может больше никуда обратиться за получением нужной информации. Эта картинка выглядит бессмысленным каскадом вызовов, поскольку внешний запрос вызывает дополнительные сервисы, которые вызывают другие дополнительные сервисы, и так практически до бесконечности.



Зеленым цветом на этой схеме показан полукруг, в котором сервисы вызывают друг друга сервис А вызывает сервис В, сервис В вызывает сервис С, а тот снова вызывает сервис А. В результате мы получаем распределенный тупик. Единственный запрос создавал тысячу сетевых вызовов API, и поскольку система не обладала встроенной отказоустойчивостью и защитой от зацикливания, то запрос оканчивался неудачей, если хотя бы один из этих API-вызовов давал сбой.

Мы сделали некоторые математические вычисления. Каждый API-вызов имел SLA не более 150 мс и 99,9% аптайм. Один запрос вызывал 200 различных вызовов, и в наилучшем случае страница могла быть показана через 200 х 150 мс = 30 секунд. Естественно, это никуда не годилось. Перемножив 99,9% аптайм на 200, мы получали 0% доступность. Получается, что эта архитектура была обречена на провал с самого начала.

Мы обратились к разработчикам с вопросом, как же они не сумели разглядеть эту проблему на протяжение 18 месяцев работы? Оказалось, что они подчитывали SLA только для запущенного ими кода, но если их сервис вызывал другой сервис, они не считали это время в своих SLA. Все, что запускалось в пределах одного процесса, придерживалось значения 150 мс, но обращение к другим сервисным процессам многократно увеличивало суммарную задержку. Первый извлеченный из этого урок формулировался так: Распоряжаетесь ли вы своим SLA или же SLA распоряжается вами? В нашем случае выходило второе.

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



Если посмотреть на границы сервисов на предыдущей картинке, видно, что все они неправильные. Существует масса источников, которые советуют, как определять границы сервисов, и большинство делают это неправильно, как например, Microsoft на следующем слайде.



Эта картинка из блога MS на тему Как строить микросервисы. Здесь показано простое веб-приложение, блок бизнес-логики и база данных. Запрос поступает напрямую, вероятно, здесь имеется один сервер для веб, один сервер для бизнеса и один для БД. Если увеличить трафик, картинка немного поменяется.



Здесь появляется балансировщик нагрузки для распределения трафика между двумя веб-серверами, кэш, расположенный между веб-сервисом и бизнес-логикой и еще один кэш между бизнес-логикой и базой данных. Именно такую архитектуру использовала компания Bell для своего приложения балансировку нагрузки и blue/green развертывание, выполненное в середине 2000-х. До некоторого времени все работало хорошо, поскольку данная схема предназначалась для монолитной структуры.

На следующей картинке показано, как MS рекомендует осуществлять переход от монолита к микросервисам просто разделить каждый из основных сервисов на отдельные микросервисы. Именно при внедрении этой схемы Bell и совершили ошибку.



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

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

Они считали, что для перехода на микросервисы достаточно просто взять их внутреннюю инфраструктуру физического уровня N-tier и вставить в нее Docker. Давайте взглянем, как же выглядит традиционная архитектура N-tier.



Она складывается из 4 уровней: уровень пользовательского интерфейса UI, уровень бизнес-логики, уровень доступа к данным и база данных. Более прогрессивна DDD (Domain-Driven Design), или программно-ориентированная архитектура, где два средних уровня представляют собой доменные объекты и репозиторий.



Я попытался рассмотреть в этой архитектуре различные области изменений, различные области ответственности. В обычном N-tier приложении классифицируются различные области изменений, которые пронизывают структуру вертикально сверху вниз. Это Catalog, настройки Config, выполняемые на индивидуальных компьютерах и проверки Checkout, которыми занималась моя команда.



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

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

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

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

Теперь рассмотрим определение микросервисов:

  • микросервис имеет малый размер и предназначен для решения одной конкретной задачи;
  • микросервис автономен;
  • при создании архитектуры микросервиса используется метафора городской планировки town planning metaphor. Это определение из книги Сэма Ньюмана Создание микросервисов.

Определение Bounded Context взято из книги Эрика Эванса Domain-Driven Design. Это основной паттерн в DDD, центр проектирования архитектуры, который работает с объемными архитектурными моделями, разделяя их на разные Bounded Context и явно определяя взаимодействие между ними.



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

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

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



Итак, мы сказали ребятам из Bell Computers: Мы не сможем исправить ничего в созданном вами хаосе, потому что у вас просто не хватит для этого денег, но мы исправим всего один сервис, чтобы придать всему этому смысл. С этого места я начну рассказ о том, как мы исправили единственный сервис, чтобы он стал отвечать на запросы быстрее, чем через 9 с половиной минут.

22:30 мин

Продолжение будет совсем скоро


Немного рекламы


Спасибо, что остаётесь с нами. Вам нравятся наши статьи? Хотите видеть больше интересных материалов? Поддержите нас, оформив заказ или порекомендовав знакомым, облачные VPS для разработчиков от $4.99, уникальный аналог entry-level серверов, который был придуман нами для Вас: Вся правда о VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps от $19 или как правильно делить сервер? (доступны варианты с RAID1 и RAID10, до 24 ядер и до 40GB DDR4).

Dell R730xd в 2 раза дешевле в дата-центре Equinix Tier IV в Амстердаме? Только у нас 2 х Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 ТВ от $199 в Нидерландах! Dell R420 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB от $99! Читайте о том Как построить инфраструктуру корп. класса c применением серверов Dell R730xd Е5-2650 v4 стоимостью 9000 евро за копейки?
Подробнее..

Никаких кликов интервью с Джессикой Дин о командной строке, автоматизации и DevOps

06.07.2020 12:10:38 | Автор: admin


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


Осенью на нашей конференции DevOops выступала Джессика Дин. Она удивительно разносторонний человек в отношении платформ: обожает Linux, постоянно пользуется Mac и при этом работает в Microsoft. И она очень любит автоматизацию, скрипты и отказ от мышки настолько, что в её дотфайлах уже сотни коммитов.


В трансляции DevOops мы с Михаилом Дружининым (xomyakus) поспрашивали её и об использовании терминала, и о совмещении миров Windows/Linux/Mac, а поскольку дело было на девопс-конференции, к концу разговор свернул ещё и в сторону Kubernetes. А сейчас, прямо перед новым онлайновым DevOops, мне захотелось перевести это интервью на русский, чтобы оно было и в текстовом формате.


Текстовый вариант чуть сокращённый, если предпочитаете посмотреть исходное англоязычное видео, оно вот:



Евгений Трифонов: Я заглянул в твои дотфайлы на GitHub и оказался впечатлён


Джессика Дин: Большое спасибо! Да, это интересный проект, и он продолжает разрастаться, я постоянно добавляю к нему разное. Я фанатка автоматизации, штук, упрощающих любой процесс. Мои дотфайлы так или иначе связаны с этим. Их можно использовать и в Linux, и в Windows Subsystem for Linux (хоть WSL1, хоть WSL2), и на macOS. Они обращаются к 17 разным опенсорсным инструментам. Основная причина, по которой я всем этим занялась упрощение моего рабочего процесса как с точки зрения разработки, так и с точки зрения эксплуатации.


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


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


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


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


Если речь о моей собственной системе, то я установлю всё, что мне может понадобиться, со всеми зависимостями. Но если я использую чужую, то мне нужен только удобный CLI с комфортным интерфейсом я использую тему для zsh Powerlevel9k (да, я знаю, что уже появился Powerlevel10k), у меня на экране много полезной информации. И сейчас я подумала, что мне нужна установочная опция, где устанавливаешь только этот интерфейс без всех остальных зависимостей. Сейчас главное бутылочное горлышко здесь это время, которое требуется на установку всего.


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


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


Джессика: Порой бывает! У меня даже есть пост со словами Down the Rabbit Hole в заголовке.


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


Действительно, наступает момент, когда ты понимаешь, что решение заняло у тебя слишком много времени. На macOS это оказалось непросто, а если заняться реализацией ещё и для Linux с Windows, то не закончишь никогда. Есть определённые моменты, когда надо спросить себя: Какую пользу я извлеку из этого? Сколько времени сэкономлю, потратив 48 часов на написание штуки, которая экономит каждый раз по три секунды?.


Но ещё есть любопытство, потому что все мы инженеры: Но я ведь уже начал, я не могу сдаться!


Михаил Дружинин: И как тебе удаётся себя остановить?


Джессика: Иногда никак, иногда я пишу до трёх часов ночи! В других случаях я ищу чужой код. Я много занималась опенсорсом, и мне кажется, что мы лучше как инженеры, когда работаем вместе. Я знаю многих, кто любит начинать и писать с нуля и искать свои собственные ответы. Но я добавила в свои дотфайлы 17 других инструментов отчасти потому, что уже есть члены опенсорс-сообщества, у которых уже было что-то нужное мне. Я смогла использовать их код и добавить к нему что-то своё, внеся тем самым собственный вклад.


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


Евгений: У вас там целое сообщество людей, которые смотрят дотфайлы друг друга?


Джессика: Так и есть! Есть треды на Reddit об этом, есть видео в сети.


Ещё меня как-то упомянули в таком треде на Reddit как человека, который работает в Microsoft, пишет дотфайлы под Linux и macOS, выступает о Linux, получал и сертификаты Apple, и звание Windows MVP. Это было собрано в треде под грифом Мы не понимаем. Но я просто люблю работать с другими инженерами и мне неважно, на какой платформе кто работает! Я вношу свой вклад в сообщество dotfiles, до этого делала то же самое с PowerShell (ещё до выхода PowerShell Core, так что это было только для Windows). Сейчас забавно, когда мне приходится снова писать скрипты на PowerShell, столько отличий. Я просто люблю тусоваться в разных сообществах, и dotfiles одно из них.


Евгений: Интересно, что ты любишь Linux и работаешь в Microsoft. В этом нет противоречия, но, наверное, люди часто удивляются?


Джессика: Да! Потому что так было не всегда. Я каким-либо образом связана с Microsoft уже более 10 лет. Изначально работала на их подрядчика. И тогда была совсем другая эпоха с совсем другим руководством компании. Когда я пришла в кампус, у меня были iPhone и Mac и кто-то меня окликнул: Ты случайно не из тех, у кого Mac и iPhone? И я такая, пряча свой рюкзак и комп: Кто-нибудь! Срочно дайте мне Windows Phone! Сбегайте в музей! Я не хочу быть белой вороной! Даже в команде, с которой я работала, подшучивали, потому что меня все знали как любительницу Linux и Apple, хотя в то же время у меня был статус Windows MVP и сертификация.


Я тогда по работе занималась примерно тем же, что и сейчас делаю как advocate, но тогда делала это в онлайне мы называли это вовлечением через социальные сети. Моя работа заключалась в том, чтобы взаимодействовать с сообществом на популярных в IT интернет-ресурсах вроде Reddit и Spiceworks, общаться с теми, у кого были технические вопросы. Это было во времена Microsoft Deployment Toolkit и SCCM. Я помогала людям в этих сообществах, а в то же время была инженером интеграции систем Linux и чинила компьютеры Apple. Так что я всегда пересекала границы платформ. Но тогда это было нетипично.


Сейчас я в Microsoft уже почти 4 года и то, как изменилось направление внутреннего и внешнего развития, взрывает мне мозг каждый день. 10 лет назад я была полезна, работая на подрядчика Microsoft, но из меня вышла бы не очень хорошая сотрудница непосредственно для Microsoft, потому что я любила работать на Linux и Mac, и не собиралась от них отказываться. И 4 года назад они наняли меня после моего выступления о линуксовом веб-сервере. Я такая: Вы в курсе, что я только что говорила про Linux, да? Так что конфликта тут больше нет, хотя и есть определённое прошлое. Это уже совсем другой Microsoft!


Евгений: А что для такого человека, как ты, означало появление Windows Subsystem for Linux? Перевернуло ли это всю твою жизнь? :)


Джессика: Ну, моя главная система для разработки это по-прежнему Mac. Но у меня дома есть и Surface Book. И это действительно сказывается особенно теперь, с WSL 2 и опенсорсным Terminal. У меня может быть и PowerShell, и Ubuntu, и Fedora, и любые другие дистрибутивы, и я могу настраивать разные профили. Я работала с командой WSL с момента его появления.


Мой коллега, Скотт Хансельман, шутил, что он провёл нагрузочное тестирование моего блога, ретвитнув один из моих постов пару лет назад, когда у Windows 10 вышло Fall Creators с обновлением WSL. Шутка была в том, что в блог пришло так много читателей, что он упал и мне пришлось его поднимать. Это был пост о том, как можно взять терминал, дотфайлы, о которых мы говорили, и сделать так, чтобы на WSL всё выглядело идентично тому, что я запускаю на Mac и Ubuntu.


Это взорвало людям мозг. И до сих пор взрывает мозг мне! Мне не пришлось вносить никаких изменений. Код, который я использовала на Ubuntu такой же, какой я использовала на WSL. Поэтому у моих дотфайлов сейчас всего две ветки одна из них называется "WSL", но работает и на Linux, а другая для macOS. Я до сих пор влюбляюсь в свою работу, просто глядя на направление, в котором мы двигаемся. Объединение разработчиков всех платформ.


Евгений: Иногда я ввожу поисковые запросы не в браузере, а в терминале с помощью ddgr. Подозреваю, такой человек, как ты, тоже делает в терминале что-то, что обычно делают иначе?


Джессика: Это правда, особенно в отношении CI/CD-пайплайнов я работаю ещё в DevOps-команде, занимаюсь автоматизацией скриптами, и там могу делать проверки вроде открывается ли такой-то URL. И в моём докладе здесь, на DevOops, есть пример использования curl. Чтобы протестировать такие вещи, я сначала выполняю их локально в терминале до того, как помещу в пайплайн. А в итоге я ощущаю, что могу выполнять такие задачи эффективнее, потому что для меня становится естественным выполнять их из командной строки.


Я уже говорила про мои дотфайлы, что всегда хочу видеть в терминале определённую информацию, и в том числе хочу знать мои внутренний и внешний IP-адреса. Некоторые люди, чтобы узнать свой IP, идут на сайт вроде https://whatismyipaddress.com/. А у меня это просто часть терминала.


Когда-то я не была таким энтузиастом командной строки, и тогда задавала вопрос Зачем тратить столько времени, набирая что-то на клавиатуре. А потом поняла, что если однажды набрал что-то, и оно осталось в истории или было сохранено как функция, то вызвать это гораздо быстрее, чем кликать! Так что теперь мой личный бренд #noclickyclicky.


Михаил: Как ты к этому пришла? Как долго ты шла к осознанию, что печатать быстрее?


Джессика: Примерно 5-6 лет. Работая одновременно и с Linux, и с технологиями Microsoft, я деплоила приложения и с IIS, где было очень много кликанья, и с Linux, где было сплошное печатание. Каждый раз, когда разворачивала на Linux всё шло без проблем, а на IIS всё было гораздо сложнее. В итоге я начала писать скрипты на PowerShell так я ещё дальше зашла в автоматизацию. В общем, это был долгий путь.


Михаил: Какую часть своего рабочего дня ты проводишь в терминале сейчас?


Джессика: Terminal у меня всегда запущен, он всегда открыт в фоне. Я бы сказала, что непосредственно в нём не меньше 50 времени, возможно, больше. А поскольку я пользуюсь DevOps-инструментами, повсюду код: в Codefresh и Azure DevOps Serviсes YAML, в Jenkins Groovy Поэтому у меня ощущение, что я всё время живу либо в командной строке, либо в VS Code, и терминал всегда открыт.


Михаил: Ещё один вопрос, чтобы закрыть эту тему. Vim или Emacs?


Джессика: Vim.


Я знаю некоторых, кто предпочитает Pico, Emacs, nano Не могу представить, зачем может понадобиться работать в nano Я из тех сумасшедших, кто за Vim. А вы как? Vim или Emacs? И в tmux что используете, Ctrl+A или дефолтное Ctrl+B?


Михаил: Vim, Ctrl+B.


Евгений: Vim. К вопросу о нём: другой спикер Себастиан Дашнер сегодня рассказал нам, использует плагин Vimium в браузере и IdeaVim в IntelliJ IDEA. Ты чем-то подобным пользуешься?


Джессика: Нет. Самое нердовское, что я использую это плагин NERDTree. Он добавляет мне файловый менеджер слева и я могу нажать Ctrl+N, чтобы этот менеджер появлялся и скрывался. Ну и ещё я использую таблицу стилей в Vim. У меня есть моя обычная таблица стилей со шрифтами и цветными штуками для терминала, а в Vim свое цветовое оформление. Вроде бы сейчас использую схему wombat Ну, это всё в открытом доступе, можете сами проверить.


Евгени: Мне хочется делать как можно больше с клавиатуры, но хватает ситуаций, когда всё-таки берусь за мышку/тачпэд. А когда идёшь по жизни с девизом #noclickyclicky, какие сценарии могут вынудить всё-таки оторваться от клавиатуры?


Джессика: Мы же уже говорили про DevOps. Если я демонстрирую Azure DevOps и показываю общую картину того, как он работает (а это, по сути, система запуска задач), я открываю то, что мы называем визуальным редактором. Там список задач без всякого YAML, и я пользуюсь мышкой, чтобы его показать В общем, пользуюсь мышью для навигации в браузере, но когда делаю что-то с кодом, мои руки на клавиатуре.


Михаил: Вчера на BOF-сессии о будущем Kubernetes говорили как раз о том, что происходит переход к кликам в браузере, и больше не надо возиться с YAML, больше не нужно быть YAML-разработчиком, спасибо и на этом


Джессика: Прямо как с табуляцией и пробелами!


Михаил: GitHub также выпустил GitHub Actions он тоже визуальный с кликами. Что ты думаешь об этом направлении? Мне кажется, люди так позабудут о клавиатуре.


Джессика: Возможно, это просто говорит моя страсть к командной строке, но если вспомнить, как всё развивалось в последние 10-15 лет, мне кажется, что она никуда не денется.


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


Михаил: Сделать конфигурацию в UI, потом экспортировать в некий код, а потом продолжить что-то с ним делать.


Джессика: Потому что так я могу его ещё и проверить. Я могу разместить его вместе с моим исходным кодом, с моим приложением...


Михаил: посмотреть diff.


Джессика: Да, особенно. Если я собираюсь обновить мой пайплайн, мне нужно посмотреть разницу, что я изменила, особенно если пайплайн сломается. Мне нужна история. Я не уверена, что мы когда-нибудь отойдём от кода. Да, мы будем улучшать и упрощать его, в этом основная цель того же Kubernetes. Он был создан чтобы упрощать. Helm был создан, чтобы упрощать упрощённое. Есть другие инструменты такие как Draft и Skaffold, которые были сделаны, чтобы упростить и его.


В Microsoft у нас есть Azure Dev Spaces, который, судя по роадмапу, в будущем будет работать даже вне Azure, и он был сделан, чтобы работать с ещё большим уровнем абстракции, когда тебе не нужно беспокоиться про Docker или Kubernetes. У тебя просто может быть изолированная песочница. Как разработчице мне не нужно что-либо настраивать и мне не нужно иметь дело с кодом. Мы постоянно работаем над тем, чтобы упростить простое. Мне кажется, мы продолжим двигаться в этом направлении.


Михаил: Как ты думаешь, каким будет следующий конкретный уровень упрощения Kubernetes? На что бы ты поставила?


Джессика: Предсказательница из меня никакая! Я не знаю. Если мы вернёмся в прошлое, виртуализация уже была первым шагом абстракции. Больше не было нужды в физических машинах, теперь можно виртуализировать окружение. Потом при помощи контейнеров виртуализировали ядро и продвинули виртуализацию ещё дальше. Потом оркестрация стала способом управлять и продолжить абстрагировать. У нас есть Serverless. Теперь нас есть возможность объединить Serverless с оркестрацией.


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


Не всё нужно разбирать до такого мелкого уровня. Не всё надо запускать в Kubernetes. Люди говорят: Kuberenetes во все поля! Зачем? Келси Хайтауэр как-то твитнул, что лучшая часть понимания контейнеров и будущего направления их развития не в том, чтобы понимать, как ими пользоваться, а в том, чтобы понимать, когда ими пользоваться не надо. Мне кажется, это то направление, в котором нам нужно двигаться дальше.


Михаил: Просто перестаньте использовать лямбды, контейнеры, ВМ


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


Другой мой коллега, крупная фигура в Go коммьюнити, Эрик Сент-Мартин, известен своим высказыванием: Kubernetes это не Та Самая Вещь. Это вещь, которая поможет нам достигнуть следующей вещи, а потом та даст добраться до следующей. Это вечно продолжается. Но мы сможем понять, как попасть дальше, только если будем понимать, зачем что-то нам нужно, а почему оно нам не нужно.


Евгений: Вот на этом и остановимся, потому что время на интервью закончилось. Спасибо за ответы!


Уже сегодня в 17:00 стартует новая конференция DevOops: в этот раз в онлайне и пятидневная. Там без слова Kubernetes, конечно, тоже не обойдётся! А ещё будут легенда DevOps Джон Уиллис, ряд докладов про DevOps как культуру, любимец публики Барух Садогурский и многое другое смотрите полную программу, чтобы понять, сколько там актуального лично для вас.
Подробнее..

JPoint 2020 новый формат, новые возможности

04.07.2020 20:20:46 | Автор: admin
С 29 июня по 3 июля 2020 года в онлайн-формате прошла Java-конференция JPoint 2020. Информация о докладах, спикерах, особенностях проведения, впечатления от конференции всё это можно прочитать далее.



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

В предверии летнего блока конференций участники команды JUG Ru Group проделали титанический объём работы как административного, так и технического характера. Была создана онлайн-платформа для трансляции митапов и конференций. Также было проведено множество онлайн-встреч, в том числе Java-серия Первая чашка кофе с JPoint с интервью с участниками программного комитета и спикерами: Владимиром Ситниковым, Маргаритой Недзельской, Тагиром Валеевым, Олегом Докукой, Иваном Углянским и Алексеем Шипилёвым.

В блоге компании JUG Ru Group до летних конференций появилось множество интересных статей и интервью:

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

Открытие


Непосредственно перед открытием Алексей Фёдоров предоставил возможность увидеть пультовую Всевластья, помогающую организовать онлайн-конференции. После вводных слов и приветствия спонсоров конфереция была объявлена открытой.



Первый день


Прекрасным предисловием к интервью с James Gosling, отцом языка Java, стала статья, написанная phillennium. Беседу вели и задавали вопросы Андрей Дмитриев и Volker Simonis. Интервью получилось живое и эмоциональное, вызвавшее большой интерес у самого Джеймса. Было задано множество вопросов, от касающихся подробностей его прошлых проектов до отношения к популярному в настоящее время JVM-языку Kotlin. Безусловно, Джеймс является личностью, колоссальным образом повлиявшей на индустрию и внёсшей огромный вклад. Его присутствие в числе спикеров большая удача для конференции.



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



Доклад Precomputed data access with Micronaut Data от Graeme Rocher, автора Micronaut Framework. У данного спикера на конференции два доклада (доклад Micronaut deep dive был в этот же день чуть раньше, его я ещё планирую посмотреть). Очень полезным оказалось предварительное ознакомление с интервью, взятым недавно. В данном докладе было рассказано про Micronaut Data, легковесное решение для доступа к базам данных, выглядящее чрезвычайно привлекательно. После доклада Грэму вопросы слушателей и свои задавал Антон Архипов. На интересующий многих заданный Антоном вопрос, возможно ли использование Micronaut Data без всего остального из Micronaut Framework, был дан положительный ответ.



Второй день


В нативный код из уютного мира Java: Путешествие туда и обратно блестящий доклад Ивана Углянского на тему возможностей вызова из Java-кода процедур и функций нативных (native) библиотек. Всеобъемлющая ретроспектива существовавших до JNI альтернатив (JDK 1.0 NMI, RNI, JRI), популярных существующих сейчас (JNA, JNR, JavaCPP) и перспективных пока что экспериментальных (Panama, Sulong). Подробное сравнение всего современного вышеперечисленного (начиная с JNI) с большим количеством слайдов говорит об огромной проделанной работе. Очень удачные выбранные аналогии на тему произведений Толкиена: левый слайд (Шир) иллюстрирует милый и безопасный Java-код, правый слайд опасный нативный код (Мордор).



How to develop a successful Kubernetes native application using Quarkus небольшой пятнадцатиминутный доклад Alex Soto Bueno от компании RedHat, спонсора конференции. Доклад о разработке микросервисов с использованием Kubernetes и фреймворка Quarkus, детища RedHat.



Олег Шелаев является одним из тех спикеров, доклады которых всегда можно смело выбирать, зная, что совершенно точно будет интересно, увлекательно и полезно. Обладает редкой способностью просто объяснять очень сложные с технической точки зрения вещи. Доклад под названием Polyglot done right with GraalVM не стал исключением в этом смысле. В нём Олег продолжил раскрывать тему GraalVM, являясь developer advocate проекта GraalVM в OracleLabs. В данном докладе более полно была раскрыта направленность продукта на возможность одновременного применения различных языков программирования: API, шаблоны взаимодействия и прочие детали GraalVM. Ожидания от прослушанного полностью оправдались, отличный доклад.



Третий день


Всеволод Брекелов входит в команду JUG Ru Group, активно участвуя в проведении летнего блока конференций, к которому относится и конференция JPoint. Тем интереснее, регулярно видя его в роли ведущего конференций, было посмотреть доклад в его исполнении под названием Contract testing: Should or shouldn't? Ему очень удачно помогали Андрей Дмитриев, Владимир Плизга и Алексей Виноградов например, представление Владимиром докладчика в самом начале просто восхищает оригинальностью. Обсуждение было посвящено контрактным тестам, были последовательно продемонстрированы несколько подходов с использованием Spring Cloud Contract, Pact и Protocol Buffers. Получилось зажигательно и интересно.



Доклад Страх и ненависть в Scala и Kotlin interop от Маргариты Недзельской был посвящён проблемам взаимодействия кода, написанного на двух JVM-языках Kotlin и Scala. Название доклада является аллюзией на фильм Fear and Loathing in Las Vegas, им же достаточно оригинально был проиллюстрирован весь рассказ. Проблемы вызвали искреннее сочувствие, технические подробности были приведены весьма убедительные. Маргарите помогали Паша Финкельштейн и Евгений Мандриков, ведя беседу, озвучивая результаты голосований и задавая вопросы слушателей.



Четвёртый день


Ещё немного маленьких оптимизаций стал своеобразным продолжением доклада, сделанным на конференции Joker 2019 тем же автором, Тагиром Валеевым. Доклад первой части был посвящён улучшениям в строках, коллекциях и операциям с числами, в этот раз уже другим оптимизациям тоже в строках, коллекциях и теперь ещё и в reflection. Изменения, о которых было рассказано, произошли в версиях Java с 9 по 16. Традиционное глубокое понимание темы, множество результатов сравнений, характерные для докладов Тагира всё это было и в этот раз.



На Интервью и Q&A с Алексеем Шипилёвым интервьюеры Алексей Фёдоров и Иван Крылов поговорили и задали вопросы Алексею Шипилёву об особенностях работы в Red Hat, про используемые инструменты performance-инженера, про различия сборщиков мусора в Java, историю создания Shenandoah GC, об отношении к статьям с замерами производительности, мнении о GraalVM, про совместное использование jmh и async-profiler, о советах для молодых разработчиков и инженеров.



Пятый день


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



Внедрение open source-решений на примере Одноклассников: интервью Дмитрия Чуйко с Андреем Паньгиным. Одной из тем разговора стал переход компанией Одноклассники на использование дистрибутива Liberica JDK компании BellSoft, поэтому представляющий BellSoft Дмитрий Чуйко в качестве берущего интервью был весьма уместен. Также были упомянуты популярные проекты Андрея one-nio и async-profile, тоже являющиеся open source-решениями и вызывающие интерес и уважение.



Доклад Valhalla is coming от Сергея Куксенко был продолжение его же предыдущего доклада, сделанного им на Joker 2019. С конца октября 2019 года в разработке инлайн-типов произошли значительные изменения, подробно о которых было рассказано примерно с середины данного доклада. Сергей харизматичный спикер и высококвалифицированный инженер, доклады которого безошибочно всегда можно выбирать. Отлично дополнил доклад Иван Углянский, задававший вопросы и помогавший Сергею во взаимодействии со слушателями.



Прочие события


Кроме впечатляющей онлайн-платформы для стриминга конференций, всевозможных активностей во время их проведения к летним конференциям была выпущена новая версия веб-приложения, о котором ранее уже писалось в обзорах про конференции TechTrain 2019 и Joker 2019. Приложение доступно по ссылке, в репозитории на GitHub (ставьте звёздочки) имеется описание с информацией, включающей актуальную ссылку на веб-сайт.

Приложение, ранее бывшее только игрой по угадыванию спикера, теперь разделено на две части. В первой из них можно произвести поиск и просмотр информации обо всех конференциях JUG Ru Group, а также митапах Java-сообществ JUG.ru, JUG.MSK, JUGNsk. Содержится абсолютно та же информация, что и представленная на сайтах конференций и митапов. Доступны для удобного просмотра уже опубликованные видео и презентации докладов (ниже для примера показано отображение сведений об Антоне Архипове и об одном из его докладов).



В разделе со статистикой приведены сведения, которые могут заинтересовать как организаторов конференций, так и их участников: с какого времени проводится каждая из конференций или каждый из митапов, общая их длительность, количество конференций, докладов и спикеров, сколько из спикеров удостоено звания Java Champion или Most Valuable Professional (MVP). Можно щёлкнуть по картинкам для их увеличения (или посмотреть то же самостоятельно в веб-приложении по ссылке, приведённой выше).

Второй и третий скриншоты ниже показывают топ спикеров по количеству сделанных ими докладов (скриншот слева без учёта митапов, справа конференции вместе с митапами). Уверенную победу в обоих случаях (только конференции и конференции с митапами) одерживает Барух Садогурский, на втором месте Евгений Борисов. Третье месте в случае только конференций Кирилл Толкачёв, конференции с митапами Алексей Шипилёв.



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



Закрытие


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



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

Сезон летних конференций JUG Ru Group продолжается по-прежнему можно успеть присоединиться к оставшимся двум онлайн-конференциям DevOops (6-10 июля 2020 года) и Hydra (6-9 июля 2020 года). Есть возможность купить единый билет на все восемь конференций, видео докладов в этом случае становятся доступны сразу же после завершения конференций.
Подробнее..

Календарь онлайн-событий в сфере IT на июль 2020

01.07.2020 00:06:33 | Автор: admin
Если у вас в планах создать нечто гениальное до конца лета, июль точно стоит посвятить самообразованию. Собрала для вас свежую онлайн-афишу IT-мероприятий на ближайший месяц.

1 июля, 19:00 Вебинар Многопоточная очередь сообщений на С++

1 июля, 20:00 Вебинар Принципы мобильного тестирования

2 июля, 18:00 Онлайн-трансляция для тимлидов

2 июля, 17:00 Backend&Test Meetup

2 июля, 17:00 Innopolis Mobile MeetUp

3 июля, 13:00 Mobile Webinar Android

6 июля, 19:00 Онлайн-дискуссия о философии искусственного интеллекта

7 июля, 16:00 Безопасность WEB: Уязвимости авторизации

7 июля, 19:00 Онлайн-трансляция UX дизайн и архитектура

9 июля, 10:00 Бизнес-завтрак Управление мобильностью

15 июля, 18:00 Online IT HR meetup

16 июля, 12:00 Анализ данных с помощью Yandex Cloud Functions и Yandex Data Proc

16 июля, 20:00 Революционные нейронные сети 2020 года

21 июля, 16:00 Безопасность WEB: Ошибки бизнес-логики

22 июля, 18:00 Мини-Гипербатон Яндекса о качестве локализации программных продуктов

30 июля, 17:00 Geekhub Big Data Online Meetup
Подробнее..

Анонс Code Challenge недельное соревнование для настоящих разработчиков

06.07.2020 16:22:04 | Автор: admin

image


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


Когда: 6-12 июля
Где: онлайн


Что случилось?


Code Challenge первое открытое онлайн-соревнование от Контура для хардкорных инженеров. Уже сейчас открыта песочница, а сам контест начнётся вечером, в понедельник 6 июля, и продлится 7 суток. Вместе мы попытаемся прорваться к центру вселенной через вражеские корабли и планеты древних цивилизаций. Конечно, с помощью кода и квестов.


Если вы уже слышали про соревнования ICFP Contest, CodinGame или Google Code Jam, вам точно понравится то, что мы приготовили.


А в чём суть контеста?


В каждом уголке галактики непрерывно идут бои за первенство. В боях участвуют флоты под управлением тактических ботов. Мы будем программировать своего бота (на C#, JS, Python или 1С %)), управлять космическими кораблями, побеждать врагов и захватывать новые планеты. Прокачать тактического бота помогут артефакты древних цивилизаций, но найти их будет непросто: все они спрятаны и зашифрованы.


Почему это интересно?


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


Кто может участвовать?


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


Как стартануть?


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


Вечером 6 июля мы откроем портал для боевых отрядов и начнём Межгалактический бой. Ссылка на игру и ключи от песочницы прилетят капитанам команд на почту заранее. Будет время изучить правила и запустить свои корабли в первые тестовые полеты.


А если победим?


Командам, обыгравших всех остальных, мы подарим сертификаты на Ozon.


Герои меча Брезенхэма и магии Чебышёва, в бой!

Подробнее..

Контур стал организатором ICFPC 2020

07.07.2020 10:10:24 | Автор: admin

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


15 лет команда Контура участвовала в соревновании, а в этом году нас пригласили провести ICFPC 2020. Мы первая команда из России, которой доверили организацию, и это очень круто! Какую задачу мы приготовили пока секрет. Все участники узнают ее условия одновременно 17 июля, но уже сейчас в Твиттере можно увидеть некоторые спойлеры.




Почему нужно участвовать в ICFPC 2020


ICFPC командное соревнование. Соревнований для одиночек много: например, Facebook Hacker Cup и Google Code Jam. Если вам нравятся AI для игр, то codingame.com проводят отличные челенджи раз в 2-3 месяца. В одиночных соревнованиях топ обычно забит какими-то гениями, а в командных можно хорошо выступить за счет упорства и хорошей организации.


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


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


Задачи небанальные. Организатор соревнования меняется каждый год и старается превзойти предыдущего, поэтому задачи год от года становятся все интереснее. Обычно это университет, поэтому они добавляют в задачи отсылки к научным проблемам и классике computer science. Кроме того, ICFPC приурочен к научной конференции по функциональному программированию ICFP, и это влияет на задачи. Через раз приходится читать описания на функциональном псевдоязыке (не бойтесь, понятном для обывателей!), а потом программировать виртуальные машины и компиляторы.


Задача одна! За 72 часа команда неограниченного размера должна решить всего одну задачу. Но многогранную и трудную. Её нельзя решить оптимально, но можно решить лучше других команд. Самыми необычными и яркими задачами считаются задачи 2006 и 2007 годов, в которых балом правили виртуальные машины внутри виртуальных машин и а также реверс-инжениринг виртуальных машин.


Про некоторые задачи прошлых лет мы уже писали на Хабре. Если вы участвуете впервые, обязательно посмотрите текст green_hippo. Там Игорь рассказывает, как подготовиться, что посмотреть и послушать, чтобы набраться опыта и вдохновиться.


Подробности соревнования появляются в Твиттере. Там же скоро появится ссылка на регистрацию.


Желаем удачи!

Подробнее..

Почему онлайн-митаапы никогда не заменят оффлайн, что с этим делать и почему онлайн всё равно нужен

26.06.2020 16:08:22 | Автор: admin
Мне это надоело.
В прошлом году я был на 50+ митапах, нескольких конференциях и на паре хакатонов.
За последние пару месяцев я сходил на 30 онлайн-мероприятий разных форматов, и хочу рассказать, почему зря потратил это время, в чём проблема с онлайн (и офлайн) митапами и что мы можем сделать чтобы оказаться в чуть лучшем мире. Давайте по порядку.

Зачем приходить на митапы

Знания (доклады, контент)

Мы выбираем мероприятия по направлениям и темам, просим работодателя оплатить участие, мотивируя это получением новых знаний. И звать на митапы можно исходя из позиции прокачки экспертизы и получения знаний. Давайте посмотрим, с кем такие мероприятия конкурируют в онлайне:
  • Pluralsight библиотека на 7.000+ онлайн-курсов по разработке, облакам, МЛ, девопсу, безопасности и данным.
  • Coursera сборник онлайн-курсов, сертификаций и программ лучших университетов и компаний мира, 4.000 курсов.
  • Записи докладов с конференций на Youtube на русском и английском
  • Хабр. Серьезно, доклад это же видеоверсия статьи.

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

Развлечение/награда/отдых

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

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

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

Нетворкинг


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

Как на счёт онлайн-митапов? Нууу, примерно, никак. Чаще всего общения участников или нет совсем, или оно ограничивается чатом трансляции на ютуб. Нет личного общения, нет элемента знакомства, и даже в зум-афтерпати есть проблема из-за того, что все сидят в одной беседе и нет возможности познакомиться или углубиться в общении тет-а-тет.

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

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


Всё. Это основные цели для конференций и митапов. И онлайн-митапы проигрывают по каждому из этих направлений. Ну, по крайней мере, в теории. А что на самом деле?

Пруфы

В подсчете статистики нам поможет сайт https://meetups-online.ru/, на котором собраны почти все онлайн-события в ИТ. За первую половину мая прошёл 31 митап и можно по ним посмотреть доступность нетворкинга на мероприятиях. Вторую половину мая я пропустил потому что участвовал в РИТ++ и Podlodka Teamlead Crew, о которых скажу отдельно.

Методика

Сложно сравнивать офлайн и онлайн из-за разных механик, поэтому я просто выбрал те механики, которые связаны с обратной связью (от спикера, от аудитории, к спикеру) и позволяют митапу отличаться от его расшифровки в текст:
  1. Хорошая доступность без сложных регистраций и установки нетипичных для прикладной работы программ.
  2. Чат участников трансляции, в котором идёт беседа во время митапа.
  3. Возможность задать вопрос текстом в чате или на отдельном сайте.
  4. Возможность выйти в эфир и задать вопрос спикеру или обратиться к аудитории голосом.
  5. Обратная связь от аудитории и подстройка сценария разговора под актуальные для собравшихся темы. Это может быть и в голосовом обсуждении, и с помощью чата, если есть отдельный редактор, который мониторит канву обсуждения и скидывает ведущему и участникам актуальную информацию.
  6. Общий созвон всех участников, который убирает границу между спикером и аудиторией, а поучаствовать в обсуждении можно максимально просто.
  7. Техники для развития нетворкинга: BoF-сессии, общие интерактивные голосования.
  8. Приватность и уютность общения: случайный кофе, несколько тематических комнат по интересам в дискорде, привычный мессенджер вроде телеграма, в котором можно быстро перейти в личку.
  9. Оригинальные инструменты/форматы/техники, которые помогают стереть границу между участниками и дают больше возможностей для обмена опытом: единая Miro-доска, VR, стенды партнеров в онлайне.

Итоги

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

Что делать

Отличные новости! Выход есть. То есть, я попытался его найти.


Поддерживайте оффлайн-организаторов

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

Не организуйте митап ради митапа

Если вы организатор, то посмотрите на инструменты, которые могут улучшить UX вашего митапа. Zoom позволяет хорошо модерировать трансляцию и не разделяет аудиторию. В Discord есть возможность делать много разных тематических комнат и максимально быстро переключаться между ними, даже устанавливать его не понадобиться, можно пользоваться браузером. Miro даст общее пространство для рисования и стикеров участникам. Посмотрите на Slido и Mentimeter.

Одним из самых ярких впечатлений от РИТ++ было афтерпати в Spatial, который эмулирует пространство вечеринки в 2d. Можно запускать сразу несколько трансляций youtube в разных углах и собираться вокруг них, можно объединяться в компании и подходить к другим компаниям. Есть несколько тематических комнат, в каждой из которых собиралось сразу несколько кружков по интересам, перейти между ними можно очень быстро, а помогает ощутить себя в тусовке.

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

Сморите на новые форматы

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

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

23 мая прошёл онлайн-паб без докладов, только общение за столиками по интересам с экспертами, афтерпати и барные викторины в перерывах.

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

Давайте много честной обратной связи

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

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

Ещё не поздно рассказать своё мнение в большом опросе Нужны ли онлайны этим летом? И какие, если да.

Оставайтесь дома

Мы скоро встретимся, просто нужно немного подождать :)
Подробнее..

27 июня, стрим-конференция Кодинг будущего

25.06.2020 14:15:14 | Автор: admin
Привет!

Если вы читали наши предыдущие посты, то уже знаете про Alfa Battle для Java-разработчиков. Послезавтра в прямом эфире можно будет посмотреть финал чемпионата, с 12.00 до 18.00.

Параллельно стриму с финалом мы запустим стрим-конференцию под названием Кодинг будущего, где с партнерами чемпионата (Билайн и X5 Retail Group) поговорим о футуристических прогнозах в IT. От компаний будут ведущие разработчики и топ-менеджеры.



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

Основных модулей стрим-конференции у нас получилось 6 штук:

  1. AI
  2. Web-банкинг
  3. Growth hacking
  4. Mobile banking
  5. Продуктовый дизайн
  6. Архитектуры Java-проектов

А вот сами доклады и спикеры.

Начнётся стрим в 12:00, вместе со стартом чемпионата Alfa Battle

12:05
Футуристический прогноз: российская IT-индустрия завтра

Михаил Тюрганов, Руководитель дирекции развития цифровых сервисов, Альфа-Банк
Павел Дерендяев, Руководитель центра компетенций Java, Альфа-Банк


Модуль #1. Java Alfa Digital


12:15
Технологии и инфраструктура Альфа-Мобайл
Максим Шатунов / Java Tech Lead, Альфа-Мобайл, Альфа-Банк

12:35
Эволюция корпоративного банка
Никита Хренов / Ведущий разработчик, Альфа-Банк

12:55
Внутреннее устройство сайта alfabank.ru
Максим Чернухин / Архитектор направления, Альфа-Банк

Модуль #2. AI Билайн


13:15
Интеллектуальная обработка звонков в реальном времени
Донат Фетисов / Head of Architecture and Infrastructure department, Билайн

Модуль #3. X5 Retail Group


13:40
Цифровизация помидора

Руслан Каймаков / Head of Web&Mobile Development, X5 Retail Group

14:05
От Java до Scala на грузовике Х5

Вадим Ануфриев, Senior Scala Developer, X5 Retail Group

Модуль #4. Кодинг будущего


14:30
Дискусcионная панель Кодинг будущего

Иван Пятков / Директор по цифровому бизнесу, член Правления Альфа-Банка
Донат Фетисов / Руководитель департамента по архитектуре и инфраструктуре данных, Билайн
Антон Вальков / Директор по IT, член правления X5 Retail Group


Модуль #5. Alfa Digital Products


15:15
Alfa Digital: Новый взгляд на банкинг

Дамир Баттулин / Head of Digital Channels, Альфа-Банк

15:30
Web-банкинг в эпоху Mobile 1st

Нина Красавина / Digital product owner, Альфа-Банк

15:40
Voice UX. Практическая магия

Владимир Китляр / Digital CPO, Альфа-Банк
Елена Грунтова / Руководитель продукта в ML сервисах Яндекс.Облака


16:00
Как мы делаем из Альфа-Мобайл лучший мобильный банк в стране

Евгений Тонкошкуров /СРО Альфа-Мобайла, Альфа-Банк

16:15
Роль лида дизайнеров цифровых продуктов

Анастасия Попова / Руководитель направления продуктового дизайна, Альфа-Банк

16:30
Дизайн нового Альфа-Мобайла

Вячеслав Киржаев / Lead Product Designer, Альфа-Банк

16:45
Про страшные ругательства: Growth Hacking и Dual-track Agile

Илья Кузнецов / CPO Digital Innovations, Альфа-Банк

Модуль #6. Alfa Digital Products


17:00
Финиш чемпионата Alfa Battle


17:15
Интервью с Владимиром Верхошинским

Главный управляющий директор, член Наблюдательного совета Альфа-Групп

17:45
Подведение итогов и награждение победителей

Владимир Верхошинский

Подробнее..

DINS QA EVENING (online) почему тестировщик должен построить CICD и как обеспечить качество на большом проекте

26.06.2020 18:17:05 | Автор: admin
Приглашаем на онлайн-митап DINS QA EVENING, он состоится 9 июля в 19:00.

Этим вечером Дмитрий Красильников из DINS расскажет, почему именно тестировщик должен построить CI/CD, и объяснит, как это сделать. Дмитрий Борисов из Nexign поговорит об эволюции инструментов и подходов обеспечения качества на большом проекте.

Для участия, пожалуйста, зарегистрируйтесь.
Подробная программа и информация о спикерах под катом.

image


Программа


19:00-19:40 QAOps, или почему тестировщик должен построить CI/CD
Дмитрий Красильников, DINS


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

Доклад будет полезен ведущим специалистам и менеджерам.

Дмитрий Красильников Sr. QA Engineer. Хороший тестировщик и плохой человек. Вчера полностью ломал приложения для Smart TV, а сегодня держит в напряжении разработчиков компании DINS.

19:40-20:30 Развитие пайплайна разработки автотестов на примере большого проекта
Дмитрий Борисов, Nexign


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

Доклад будет интересен разработчикам автотестов и QA-тимлидам, которые заинтересованы в автоматизации проверок своего кода и упрощении процесса code review.

Дмитрий Борисов ведущий инженер-программист, TeamLead группы автоматизации интеграционного и системного тестирования в Nexign. Дмитрий с командой реализовали фреймворк автоматизации тестирования для bss-решения крупного мобильного оператора на Python и Robot Framework.

Как присоединиться


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

Как проходят встречи


Записи предыдущих митапов можно посмотреть на нашем YouTube-канале.

О нас


DINS IT EVENING это место встречи и обмена знаниями технических специалистов по направлениям Java, DevOps, QA и JS. Несколько раз в месяц мы организуем встречи, чтобы обсудить с коллегами из разных компаний интересные кейсы и темы. Открыты для сотрудничества, если у вас есть наболевший вопрос или тема, которой хочется поделиться пишите на itevening@dins.ru!
Подробнее..

Digital-мероприятия в Москве c 29 июня по 5 июля

29.06.2020 10:05:23 | Автор: admin

Подборка мероприятий на неделю


image

Практика Agile в data-driven проектах


  • 29 июня (понедельник)
  • онлайн
  • бесплатно
  • Наш митап будет полезен всем, у кого в компании развивается направление Data Science и AI. Всем приходится столкнуться с проблемой выстраивания процессов так, чтобы они протекали эффективно, с минимумом потерь и все участники data-команды работали слаженно.
    Эксперты расскажут о теории управления в соответствии с гибкими методологиями и приведут примеры реальной практики применения.

DESIGN DAY 2050


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

Марк Розин, Борис Зарьков, Игорь Стоянов, Евгений Капьев
в BellClub


  • 30 июня (вторник)
  • онлайн
  • бесплатно
  • Уход бизнеса в тень неизбежная правда жизни или этого можно избежать? Как играть с государством по новым правилам? Удастся ли полностью восстановить прибыль к концу года? Что изменилось в бизнес-процессах компаниях после возвращения к работе в новых условиях?

DevOps Quiz


  • 30 июня (вторник)
  • онлайн
  • бесплатно
  • Интеллектуальная онлайн игра на тему DevOps и все, что связано с этой методологией. Регистрация здесь.
    В игре участвуют команды от 1 до 6 человек. Будет несколько раундов. За правильные ответы команда получает баллы. Победителями объявляются 3 команды, набравшие больше всех баллов.

PitchMe Moscow


  • 30 июня (вторник)
  • Покровка, 47
  • бесплатно
  • Агентство инноваций Москвы запускает PitchMe Moscow проект поддержки технологических компаний. Если у Вас есть стартап, Вы ищете ресурсы для развития, инвестиции или партнеров, то бизнес-сессии PitchMe Moscow для Вас!

Digital Transformation and Innovation 2020


  • 01 июля (среда) 02 июля (четверг)
  • онлайн
  • бесплатно
  • Digital Transformation and Innovation 2020 идеальная среда для обмена бизнес идеями, сотрудничества и общения с коллегами. Форум наполнен идеями и практическими кейсами, благодаря которым вы обязательно разовьете свои профессиональные навыки по цифровому преобразованию.

Онлайн-митап Branded Video Content: вчера, сегодня, завтра


  • 02 июля (четверг)
  • онлайн
  • бесплатно
  • 2 июля в 18:00 приглашаем маркетологов, видеопродюсеров и других участников рынка на онлайн-митап Branded Video content: вчера, сегодня, завтра в рамках серии мероприятий ZOOMOUT by NewBiz.
    Поговорим о том, как создавать видеорекламу, которая будет драйвить ваш бизнес.

Как разрабатывать трендовый контент и находить баланс между круто, быстро и недорого.
Во время пандемии игроки рынка адаптировали съемочный процесс к условиям самоизоляции. Теперь можно создавать полноценные продуктовые видеоролики дешевле и полностью дистанционно.
Как образовательный контент помогает продавать и формирует добавленную ценность продукту.
Live форматы как тренд 2020.
Почему ugly content так любят пользователи, и как придумывать вирусные сюжеты.
Что смотрят миллениалы, поколение Z и Альфа.
Как коллаборировать с блогерами и инфлюэнсерами.
Зачем отправляться в экспедицию за контентом.
Как создавать трушную видеорекламу, которой будут доверять потребители.
Что такое Uber Video.
Спикеры митапа: основатели продакшн-студий, Head of Production со стороны агентств.
До встречи в Zoom!


about:cloud бессерверные технологии и IoT


  • 02 июля (четверг)
  • онлайн
  • бесплатно
  • 2 июля проведем about: cloud, во время которого:
    расскажем о новой функциональности Cloud-Native сервисов и планах развития направлений IoT и Serverless;
    представим новый сервис API Gateway;
    покажем примеры интеграции сервисов Yandex Message Queue и Yandex Monitoring;
    расскажем про алертинг в Yandex Monitoring;
    покажем Terraform-провайдер для Yandex Message Queue.

EdTech. Онлайн-образование: новые вызовы, новые перспективы


  • 02 июля (четверг)
  • онлайн
  • бесплатно
  • Многие университеты столкнулись с необходимостью быстрого изменения методов преподавания и формирования нового подхода к обучению, а образовательные онлайн-платформы, регулярно появляющиеся на рынке, пользуются сейчас небывалым спросом и приобретают все большую привлекательность в глазах инвесторов.
    Новая конференция Технопарка Сколково с участием топовых ВУЗов, ведущих корпоративных университетов, известных образовательных онлайн-школ, а также иностранных участников рынка будет посвящена вопросам онлайн-образования: новым глобальным вызовам, тенденциям и возможностям.
Подробнее..

Научные стажировки в Computer Science кто, что, зачем и почему?

29.06.2020 16:21:22 | Автор: admin
Об авторе. Антон Подкопаев является постдоком в MPI-SWS, руководителем группы слабых моделей памяти в лаборатории языковых инструментов JetBrains Research и преподавателем в Computer Science Center. За время аспирантуры он побывал на стажировках в IMDEA Software Institute (Мадрид, Испания) и в MPI-SWS (Кайзерслаутерн, Германия).

В этой статье я расскажу про научные стажировки и попробую ответить на базовые вопросы о них на основе своего опыта. Важно отметить, что эта публикация посвящена именно научным стажировкам, а не индустриальным. Последние имеют свою специфику, которая здесь не рассматривается. Более того, я никоим образом не претендую на полноту изложения: статья написана с точки зрения человека, занимающегося исследованиями в Computer Science (конкретнее формальными аспектами языков программирования) и имеющего опыт именно таких стажировок. Тем не менее многое, описанное здесь, будет верно и для других областей.



Содержание



Что такое научная стажировка?


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

А зачем вообще становиться стажером?


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

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

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

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

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

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

Как и куда подаваться на стажировку?


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


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

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

Способы вовлечения в научную жизнь и поиск научных групп


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

Конференции


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

Также последние годы на конференциях, посвященных языкам программирования и верификации (про другие области мне говорить сложно), проходят семинары для начинающих (mentoring workshops), как раз для погружения в научную жизнь: PLMW и VMW. На этих семинарах вводные доклады о различных научных задачах перемежаются с докладами о том, как писать хорошие научные статьи, как не сойти с ума в аспирантуре, как работать в научном коллективе и получать от этого удовольствие. Помимо того, что эти семинары крайне интересны, организаторы покрывают расходы участвующих студентов выделяют деньги на перелет, проживание и участие в конференции! Конечно, финансирование получают не все, но в данном случае научная неопытность даже на руку кандидатам, поскольку основная цель этих семинаров привлечь новых людей в науку.

Найти хорошую конференцию по интересующей теме можно с помощью рейтинга MSAR. Например, если вас интересует развитие языков программирования, стоит обратить внимание на конференции POPL (моя самая любимая), PLDI, OOPSLA, ICFP, а если машинное обучение, то на ICML и NeurIPS.

Студенческие школы


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

Студенческих школ очень много, их часто анонсируют в упомянутых рассылках. В частности, Computer Science Club поддерживает отличный список школ. Также, я не могу не отметить школы, которые каждый год проводит наша лаборатория языковых инструментов JetBrains Research (они стали источниками стажировок для многих наших магистров и аспирантов).

Финансовые условия стажировок


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

Личная история


Я попал на свою первую стажировку после школы по механизации доказательств в Coq, которую проводил Илья Сергей. Мне понравилась школа, и я захотел поработать под руководством Ильи. Стажировка проходила в IMDEA Software Institute в Мадриде, где он тогда работал. Мне было предложено заняться т.н. слабыми моделями памяти. Если очень кратко, то слабые модели памяти описывают реалистичное поведение многопоточных программ с учетом компиляторных и процессорных оптимизаций. На тот момент я не имел никакого представления об этой теме, но теперь это моя основная научная область, которой я занимаюсь уже пять лет.

Под меня тогда не получилось найти финансирование в IMDEA Software Institute (это скорее исключение из правил, но так тоже бывает), однако я смог получить грант от СПбГУ, где я на тот момент учился в аспирантуре, который покрыл мои билеты и жилье в Мадриде. Кстати, о жилье мне удалось снять комнату на последнем этаже дома через дорогу от королевского дворца, так что вид был очень неплох!

В Мадриде я провел прекрасные два месяца, которые были и полны впечатлений (спасибо, Илья, за показанные настолки ), и плодотворны в результате мы выполнили проект, по результатам которого я выступил со стендовым докладом на конференции POPL. На той же конференции я познакомился с Виктором Вафеядисом, ученым из MPI-SWS, чьи статьи я читал, только начиная изучать слабые модели памяти. В итоге Виктор пригласил меня на стажировку в его группу. Так, следующее лето я провел в Кайзерслаутерне, небольшом городке на юго-западе Германии. А потом приехал еще раз следующей зимой, и еще раз летом, и еще раз В общем, после пятой или шестой стажировке (как вы, наверное, уже догадались, мне там тоже очень понравилось настолок было даже больше) мне предложили остаться в институте в качестве постдока.

Научные стажировки это весело и полезно. Я очень рекомендую пройти через них всем студентам, аспирантам и тем, кто просто хотел бы попробовать себя в науке. Лично мне они дали очень многое: тесные научные и дружеские связи, область для исследований, возможность пожить в интересных местах.
Я хотел бы выразить благодарность Илье Сергею, Алексу Наневски, Марко Доко и Виктору Вафеядису, без которых были бы невозможны мои стажировки.
Подробнее..

7 июля международный форум btechday Биометрия против пандемии

30.06.2020 14:13:12 | Автор: admin
Привет!

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



И здесь есть где развернуться решениям, основанным на биометрии. Распознавание голоса, лица, сетчатки глаза, бесконтактный анализ отпечатков пальцев и рисунка вен, анализ особенностей походки всё это постепенно становится привычным настоящим, и в какой-то мере необходимой технологией. Сегмент бесконтактных биометрических технологий в 2019 уже оценен экспертами почти в 6,2 млрд долларов, а до 2027 прогнозируется рост на 20,3% ежегодно.

Наш форум #btechday соберет ведущих разработчиков биометрических технологий и мировых экспертов будут спикеры из ID R&D, VisionLabs, NtechLab, РТ Лабс, BIOSMART, BI Solutions, группы компаний ЦРТ, Русского биометрического общества и не только. Будет два блока пленарный, с обсуждениями актуальных вызовов рынка, и технологический, непосредственно про решения и их реализацию. Обсудим опыт разных стран и компаний, кейсы применения ML и компьютерного зрения.

Участие бесплатное, программа мероприятия под катом.

10:00-11:30 Вызовы рынка


Пленарный блок

  • Ускорение трендов бесконтактных биометрических технологий как ответ на вызовы рынка в период пандемии.
  • Единая биометрическая система: трансформация в новых условиях.
  • Биометрия в масштабе страны.


11:30-18:00 Бесконтактный мир


Технологический блок

  • Повышение точности ML-алгоритмов при минимальных входящих данных.
  • Термобиометрия в real-time.
  • Распознавание в масках.
  • Технологии 3D-распознавания для смарт-устройств.
  • Новинки технологий распознавания речи.
  • Технологии бесконтактных отпечатков пальцев.
  • Технологии аутентификации по сетчатке глаза.
  • Как сделать real-time биометрию cost-effective?
  • Уязвимости технологий и систем.
  • Риски и уязвимости биометрической идентификации.
  • Мультифакторная биометрия.


Участие бесплатное, зарегистрироваться можно вот на этой странице.

Если вам интересны биометрические технологии и вы хотите знать, как их в скором времени будут совершенствовать и применять присоединяйтесь к форуму. Зарегистрироваться можно до 6 июля, 18:00.
Подробнее..

Разговоры в пижамах смотри запись встречи с Виталием Фридманом

30.06.2020 16:15:52 | Автор: admin


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

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

Выпуск, как и весь проект Wrike Pyjama talks, на английском языке.

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

Подробнее..

Приглашаем на Mobile Meetup Innopolis

30.06.2020 18:10:31 | Автор: admin


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


Все ли вы знаете об Android Jetpack?



Кирилл Розов, Mobile Lead, Replika / Android Broadcast


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


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


Приглашаю послушать доклад практикующих Android-разработчиков. Вы узнаете, как сделать интеграцию Dagger 2 c Fragment (без Hilt) и какие API из KTX представляют опасность для использования.


Шаблоны проектирования Server Driven UI



Никита Русин, Platform lead, БюроБюро


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


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


Разберём:


  • Что такое Hypermedia API и Server Driven UI.
  • Каким образом при небольшой подготовке можно клепать 100500 информационных экранов в день, не меняя клиентский код.
  • Способы реализации SD UI на сервере и на клиенте вместе с простыми примерами на Python и Kotlin.
  • Как подготовиться к тому, чтобы на SD UI реализовывать целые пользовательские сценарии/новые разделы без изменений кода клиента.

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





Вместе со зрителями обсуждать доклады будут модераторы Юрий Новак, ведущий системный аналитик в компании РТ Лабс (Иннополис) и Александр Симоненко, технический директор Технократии (Казань).


Начинаем 2 июля в 17:00


Регистрация напомним о встрече за пару часов


Ссылка на трансляцию


Телеграм-чат митапа


До встречи!

Подробнее..

Продуктовый разворот от фигачечной к сознательной работе инженеров

02.07.2020 16:18:36 | Автор: admin
Весна 2020 показала, что благодаря DevOps-практикам многие бизнесы смогли быстро перестроить продукты и перейти в онлайн, сохранив работоспособность. Оказалось, что от зрелости практик DevOps зависят не только результаты бизнеса, но и само его выживание.

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

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



Основные измеряемые характеристики DevOps это стабильность работы приложений и производительность IT-команд, от идеи до выкладки фичи на продакшн. Поэтому мы много говорим о time to market и мониторинге и продолжаем технический трек.

А ещё IT-команды состоят из живых людей, которые не только могут выдавать хорошие KPI, а ещё и делают заведомо полезную работу. Ведь если DevOps-подход завоевал популярность в мире, то, наверное, это кому-то нужно. Для вас мы повстречались с Product Owners и бизнесменами, которые не всегда знают, что такое DevOps (как будто мы знаем :D) и расспросили их о том, что же им важно получить от технарей. В чём эта самая польза.

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

Вот какие гипотезы мы проверяли на встречах:

  • TTM важен для интересов Product Owner-а.
  • Стабильность работы приложения влияет на бизнесовые показатели.
  • Разработчики зачастую не согласны с мнением PO о том, что и как делать.
  • TTM помогает проводить CustDev. Речь не о технике интервью, а о поиске и подтверждении потребностей клиентов и построении компании.

Я беседую через с Zoom со своей давней знакомой, которая убеждена, что человеку, который ни разу в жизни не продавал, нечего делать в профессии Product Owner. Она часто появляется в передачах на радио и ТВ, проводит семинары по своей предметной области. Как только режим самоизоляции был облегчён, они с мужем и ребёнком арендовали дом на берегу великолепного озера и на всё лето переехали жить и работать туда. Её компания почти 20 лет на рынке онлайн-услуг. На первом месте по рейтингам в своей предметной области.

Скажи пожалуйста, проводишь ли ты специальную работу по сокращению цикла разработки и запуска фич в продакшн в своей команде?

Ты знаешь, уже нет. Если в 2014 году бутылочным горлышком была производительность айтишников, как разработки с тестированием, так и команды эксплуатации, то уже несколько лет я решаю другую задачу. Как успеть подготовить эксперименты, чтобы команде было, чем заняться (смеётся). Если говорить серьёзно, то сейчас я уверена, что фича будет запущена за срок от шести часов до недели...

Погоди, 6 часов?! Это...

От первой беседы с командой до пользователя. Т.е. уже на проде.

Зачем тебе такая скорость?

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

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

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

Внезапно я стал экспертом по удалёнке этой весной! (смеётся)

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

Когда мы с техдиром начали эту работу, ещё не были в ходу такие термины, как LTV, customer retention или unit economy. Просто мы представили, что пользователи не очень довольны падением приложения 20% времени...

Во, NPS!

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

Тебе именно это отношение важно?

Мне важен рост аудитории. Т.е. её лояльность и приверженность к моему продукту.

Что-то ещё? Как маркетинг связан с аптаймом?

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

Т.е. для тебя сейчас важно, чтобы приложение было доступно.

Сейчас я спокоен, потому что наш аптайм 4,5 девятки. В течение месяца приложение исправно отвечает на 99,995% запросов.

DevOps сделал своё дело, DevOps может...

DevOps ещё и не это может. В какой-то момент мы посчитали, что наш способ развития, через изменения в лаборатории и проверку на фокус-группах, дороже, чем проверка на малых долях аудитории. Вместо того, чтобы разработать прототип, собрать фокус группу и получить одобрение, а потом на живых пользователях увидеть их разочарование, я могу быстро-быстро проверить трипять вариантов на 0,1% пользователей и выбрать лучший.

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

Да, из палок и синей изоленты. (Игорь морщится, потому что я на громкой связи, а рядом дети)

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

Поэтому для нас важно управлять техдолгом. Можно сказать, что между бизнесом и IT есть контракт: в течение года не менее 30% времени разработки идёт на разгребание долга. Причём, эти проценты мы считаем совокупно за год. Например, весной 2020 мы перекрыли работу с техдолгом полностью, потому что нам была важна скорость изменения продукта. Нам пришлось искать новые модели использования наших сервисов.

Значит ли это, что за оставшиеся полгода ребята будут уже 40% времени заниматься рефакторингом, изменением архитектуры и выпиливанием костылей, а также работать с производительностью приложения?

Абсолютно.

Дальше Игорь рассказал, что у него появилась возможность работать на опережение. Значительная часть задач направлена на освоение новых технологий и интерфейсов. Первые результаты экспериментов уже доступны пользователям, например общение на естественном языке. При этом на сегодняшний день скорее можно говорить о Research части R&D. Компания осваивает технологии заранее, чтобы использовать момент зрелости технологий искусственного интеллекта для получения конкурентного преимущества.

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

  • Продуктовые. Product owner может включить или отключить фичу, а также раскатать её на заданный процент пользователей или даже конкретный список.
  • Настройки взаимодействия сервисов это зона ответственности разработчиков.
  • Админские, их крутит команда, которая занимается инфраструктурой.

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

Мы также созвонились с ребятами, которые ведут продукт в компаниях, где потенциал для развития DevOps намного больше. Они запускают стартапы или работают на крупного заказчика. Другими словами и больше через боль, они говорили о тех же ценностях для Product Owner-а, что и предыдущие собеседники.

Мы обнаружили, что находки нашего исследования подтверждают те выводы, которые есть в в отчете Google The 2019 Accelerate State of DevOps: Elite performance, productivity, and scaling (версия на русском).

Мы выделили четыре основные ценности для Product Owner-ов при использовании DevOps:

  • Предсказуемость времени реализации фичи и уверенность в качестве софта это необходимая база для активных экспериментов.
  • Надёжность работы прода = деньги. Когда трафик попадает на работающее приложение, то это не только позволяет рационально использовать бюджет на продвижение, но ещё и повышает лояльность пользователей, а значит и долю на рынке.
  • Скорость экспериментов определяет успех как для стартапа, так и для бизнеса со зрелым продуктом. Если стартапу важно быстро обнаружить предпочтения пользователей и удачные ответы на них, то зрелому продукту нужно удержание пользователей, стабильность массовой выручки и research работа на будущее технологий.
  • Доверие к разработчикам и взаимное доверие разработчиков к продакту. Партнёрские отношения между IT подразделением и бизнес юнитами, когда заключается контракт о способах взаимодействия и этот договор исполняют обе стороны. В терминах DevOps это управление техдолгом, поддержка кода в порядке и вовлечение команды в интерес своих пользователей.

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

Ребята, не беспокойтесь о том, будет ли на конференции по-прежнему много технических докладов. Потому что мы, члены программного комитета, любим системных администраторов и DevOps-инженеров, которых нет. И даже сами ими являемся.

Большинство активностей на конференции сделаем интерактивными, потому что говорящих голов достаточно в интернете. Ведь каждый сознательный инженер может не только найти видео докладов по нужной ему тематике, но и прочитать статьи (например, статьи по следам всех DevOpsConf в профиле Александра Титова).

Наша цель этой осенью дать каждой компании возможность высадить виртуальный десант из Product Owner-ов, техлидов и инженеров всех мастей. Так, чтобы IT-спецназ сориентировался на местности и вернулся в работу с разработанным планом захвата Вселенной!

В следующих статьях расскажем про CTO, разработчиков и безопасников зачем конференция им.
DevOps Live пройдет онлайн 29-30 сентября и 6-7 октября 2020. В онлайне будет всё, за что сообщество любит наши конференции, и при этом мы вместе исследуем новые возможности онлайна.

Пока до конференции есть немного времени подписывайтесь на рассылку: будем присылать письма с новостями о программе, анонсами докладов (и расшифровками с прошлых конференций), а также с разными сюрпризами. И подавайте заявки на доклады или мастер-классы, если хотите повлиять на развитие DevOps в России. А если вы продакт, которому весь этот DevOps только мешает, напишите в комментариях, как вам удается держаться на плаву.
Подробнее..

JetBrains Technology Day for Java

02.07.2020 20:17:59 | Автор: admin
В мае языку Java исполнилось 25 лет. Такое событие нельзя пропустить! Давайте праздновать вместе с JetBrains 10 июля на первом в мире виртуальном митапе для Java энтузиастов JetBrains Technology Day for Java.

image

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

Здесь вся программа.

Java и JetBrains


Те, кто давно работают с Java, знают, что этот язык вдохновение для команды JetBrains. Наша флагманская IDE IntelliJ IDEA была написана для и на Java. Она быстро заняла нишу среди ведущих сред разработки, завоевала множество наград и преданных фанатов по всему миру.

С 2000 года JetBrains выпустила несколько IDE на базе платформы IntelliJ для различных языков программирования. Многие наши инструменты, такие как Space (пространство для командной работы), YouTrack (инструмент для управления проектами и отслеживания ошибок), TeamCity (наш CI/CD-сервер) и другие, написаны на Java. Kotlin, популярный язык программирования, разработанный JetBrains, совместим с Java и также работает поверх JVM.

Чем займемся?


На протяжении всего дня с 11:00 до 21:00 по Москве лучшие Java-спикеры проведут 10 часовых инфосессий. Выбранные темы будут интересны и тем, кто давно работает с Java, и тем, кто только собирается с духом, чтобы шагнуть в этот увлекательный мир. Например, вы узнаете:

  • Как разрабатывать через тестирование (TDD)
  • Что такое ленивые вычисления (lazy evaluation)
  • Можно ли бесплатно выучить Java и написать код на первом уроке
  • Как создать новые и расширить существующие Java collections
  • Зачем нужны ZGC и Shenandoah GC
  • Почему визуальная валидация (visual validation testing) улучшает UX, локализацию и адаптивный дизайн

А вот и полный список тем:



Как участвовать?


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

Во время прямого эфира задавайте вопросы в чате. Спикеры ответят на них в конце сессий.

Сразу же после ивента запись видео появится на сайте, и чуть позже вы сможете посмотреть сессии на канале IntelliJ IDEA на YouTube.

Если JetBrains Technology Day for Java интересен вашей юзер-группе, посвященной Java, делитесь ссылкой и регистрируйте свой JUG. Присоединяйтесь к десяткам JUG, которые поддерживают наше мероприятие!

Регистрируйтесь сейчас, ведь количество мест ограничено, а любителей Java становится больше с каждой минутой.

Хочу на JetBrains Technology Day for Java

P.S. Не забывайте хэштеги #JBTechDayforJava и #JetBrainsLovesJava в Twitter, Facebook и LinkedIn. Мы тоже там будем, давайте общаться!

Ваша команда JetBrains
The Drive to Develop
Подробнее..

Digital-мероприятия в Москве c 6 по 12 июля

06.07.2020 10:05:56 | Автор: admin

Подборка мероприятий на неделю


image


Как использовать управляемую базу данных ClickHouse в Яндекс.Облаке


  • 07 июля (вторник)
  • онлайн
  • бесплатно
  • Из вебинара вы узнаете, как устроен сервис Yandex Managed Service for ClickHouse и как работать с кластерами ClickHouse в Облаке.
    Вот лишь несколько тем, которые мы затронем:
    -как устроен кластер;
    -как происходят репликация, резервное копирование и восстановление после аварии;
    -как подключиться к кластеру и что в нем можно менять;
    -как устроено шардирование;
    -как перейти от системы на базе одного узла к отказоустойчивой конфигурации, распределенной между несколькими ЦОД.
    Вебинар будет полезен всем, кто интересуется ClickHouse и хочет эффективно работать с этой БД в Облаке.

Digital Standup by SMIT.Studio


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

Callday.Finance


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

Хакатон Труда ТрудHack.Генерация


  • 08 июля (среда) 12 июля (воскресенье)
  • онлайн
  • бесплатно
  • Хакатон труда технологический молодежный турнир, призванный стимулировать появление новых идей по развитию эффективных цифровых инструментов и сервисов в сфере поддержки труда и занятости населения. Призовой фонд: 500 000 рублей

Митап Бьюти-индустрия 2020: новая нормальность


  • 09 июля (четверг)
  • онлайн
  • бесплатно
  • 9 июля в 17:00 коммуникационное агентство MIGEL AGENCY совместно с бизнес-школой RMA проведёт митап Бьюти-индустрия: новая нормальность для рекламодателей из бьюти, предпринимателей, бренд-менеджеров, маркетологов и digital-специалистов.
    Пандемия изменила рынок потребления продукции во всех сферах, в частности в бьюти-индустрии. Девушки стали чаще пользоваться службами доставки косметических средств, а акценты в покупках сместились в пользу уходовой косметики. Косметические бренды стали перестраивать свои стратегии в пользу Digital, Social Mediaиработыс инфлюенсерами.
    В период май-июнь 2020 агентство MIGEL AGENCY провело большое исследование Красота во время пандемии, опросив женщин из больших городов со всей России, чтобы выяснить: как изменились покупательские предпочтения в период пандемии.
    Какие тенденции в SMM-коммуникациях в бьюти будут актуальными после кризиса? Как изменится сотрудничество с блогерами в 2020 году? Какие площадки для продвижения косметических брендов станут наиболее релевантными? На эти и другие вопросы спикеры ответят в ходе мероприятия.
    Ждём вас!

QA EVENING (online): почему тестировщик должен построить CI/CD и как обеспечить качество на большом проекте


  • 09 июля (четверг)
  • онлайн
  • бесплатно
  • В этот раз Дмитрий Красильников из DINS расскажет, почему именно тестировщик должен построить CI/CD, и как это сделать. Дмитрий Борисов из Nexign поговорит об эволюции инструментов и подходов обеспечения качества на большом проекте.

it is hard. Онлайн-митап для компаний, разрабатывающих hardware продукты


  • 10 июля (пятница)
  • онлайн
  • бесплатно
  • На митапе от Университета Иннополис и компании Rozum Robotics вы узнаете, как заинтересовать инвесторов своим проектом, выстроить внутренние процессы и работу в команде, спланировать маркетинговую стратегию и найти клиентов. Об этом расскажут эксперты, которые прошли все этапы по созданию своего железного стартапа.
Подробнее..

Победители соревнований Dialogue Evaluation о задачах, языковых моделях, ML и о себе

06.07.2020 16:22:04 | Автор: admin
Недавно завершился Диалог 2020, международная научная конференция по компьютерной лингвистике и интеллектуальным технологиям. Традиционно одно из ключевых событий конференции это Dialogue Evaluation, соревнования между разработчиками автоматических систем лингвистического анализа текстов. Мы уже рассказывали на Хабре о задачах, которые участники состязаний решали в прошлом году, например, о генерации заголовков и поиске пропущенных слов в тексте. Сегодня мы поговорили с победителями двух дорожек Dialogue Evaluation этого года Владиславом Корзуном и Даниилом Анастасьевым о том, почему они решили участвовать в технологических соревнованиях, какие задачи и какими способами решали, чем ребята интересуются, где учились и чем планируют заниматься в будущем. Добро пожаловать под кат!

Владислав Корзун, победитель дорожки Dialogue Evaluation RuREBus-2020



Чем ты занимаешься?


Я разработчик в NLP Advanced Research Group в ABBYY. В данный момент мы решаем задачу one shot learning для извлечения сущностей. Т. е. имея небольшую обучающую выборку (5-10 документов), надо научиться извлекать специфические сущности из похожих документов. Для этого мы собираемся использовать выходы обученной на стандартных типах сущностей (Персоны, Локации, Организации) NER-модели в качестве признаков для решения этой задачи. Также мы планируем использовать специальную языковую модель, которая обучалась на документах, схожих по тематике с нашей задачей.

Какие задачи ты решал на Dialogue Evaluation?


На Диалоге я участвовал в соревновании RuREBus, посвященном извлечению сущностей и отношений из специфических документов корпуса Минэкономразвития. Данный корпус сильно отличался от корпусов, используемых, например, в соревновании Conll. Во-первых, сами типы сущностей были не стандартные (Персоны, Локации, Организации), среди них были даже неименованные и субстантивы действий. Во-вторых, сами тексты представляли собой не наборы выверенных предложений, а реальные документы, из-за чего в них попадались различные списки, заголовки и даже таблицы. В итоге основные трудности возникали именно с обработкой данных, а не с решением задачи, т.к. по сути это классические задачи Named Entity Recognition и Relation Extraction.

В самом соревновании было 3 дорожки: NER, RE с заданными сущностями и end-to-end RE. Я пытался решить первые две. В первой задаче я использовал классические подходы. Сперва я попробовал в качестве модели использовать рекуррентную сеть, а в качестве признаков словные эмбеддинги fasttext, шаблоны капитализации, символьные эмбеддинги и POS-тэги[1]. Затем я уже использовал различные предобученные BERT-ы [2], которые довольно сильно превзошли предыдущий мой подход. Однако этого не хватило, чтобы занять первое место в этой дорожке.


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

В качестве подходов к решению задачи классификации отношений я использовал две модели, основанные на BERT-e. В первой я просто конкатенировал выходы BERT с NER-эмбеддингами и затем усреднял признаки по каждому токену с помощью Self-attention[3]. В качестве второй модели была взята одна из лучших для решения SemEval 2010 Task 8 R-BERT[4]. Суть данного подхода в следующем: вставить специальные токены до и после каждой сущности, усреднить выходы BERT для токенов каждой сущности, объединить полученные вектора с выходом, соответствующим CLS-токену и классифицировать полученный вектор признаков. В итоге данная модель заняла первое место в дорожке. Результаты соревнования доступны здесь.


[4] Wu, S., He, Y. (2019, November). Enriching pre-trained language model with entity information for relation classification. In Proceedings of the 28th ACM International Conference on Information and Knowledge Management (pp. 2361-2364).

Что показалось тебе наиболее сложным в этих задачах?


Самым проблемным оказалась обработка корпуса. Сами задачи максимально классические, для их решения уже есть готовые фреймворки, например AllenNLP. Но ответ нужно выдавать с сохранением спанов токенов, поэтому я не мог просто использовать готовый пайплайн, не написав множество дополнительного кода. Поэтому я решил писать весь пайплайн на чистом PyTorch, чтобы ничего не упустить. Хотя некоторые модули из AllenNLP я все-таки использовал.

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

Ты раньше участвовал в Диалоге и дорожках?


В прошлом году выступал со своим магистерским дипломом на студенческой сессии.

А почему в этом году решил участвовать в соревнованиях?


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

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

А в других соревнованиях ты участвовал?


В это же время наша команда участвовала в SemEval. В основном задачей занимался Илья Димов, я лишь предложил пару идей. Там была задача классификации пропаганды: выделен спан текста и нужно его классифицировать. Я предложил использовать подход R-BERT, то есть выделять в токенах эту сущность, перед ней и после нее вставлять специальный токен и усреднять выходы. В итоге это дало небольшой прирост. Вот и научная ценность: для решения задачи мы использовали модель, предназначенную совсем для другого.

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

Какие самые интересные задачи ты решал на соревнованиях либо на работе?


Скоро будет соревнование по генерации жестов GENEA, и я собираюсь туда пойти. Мне кажется, это будет интересно. Это воркшоп на ACM International Conference on Intelligent Virtual Agents. В данном соревновании предлагается генерировать жесты для 3D-модели человека на основе голоса. Я выступал в этом году на Диалоге с похожей темой, делал небольшой обзор подходов для задачи автоматической генерации мимики и жестов по голосу. Нужно набираться опыта, ведь мне еще диссертацию защищать по схожей теме. Я хочу попробовать создать читающего виртуального агента, с мимикой, жестами, и конечно, голосом. Текущие подходы синтеза речи позволяют генерировать довольно реалистичную речь по тексту, а подходы генерации жестов жесты по голосу. Так почему бы не объединить эти подходы.

Кстати, где ты сейчас учишься?


Я учусь в аспирантуре кафедры компьютерной лингвистики ABBYY в МФТИ. Через два года буду защищать диссертацию.

Какие знания и навыки, полученные в вузе, тебе помогают сейчас?


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

Даниил Анастасьев, победитель дорожки Dialogue Evaluation GramEval-2020



Чем ты занимаешься?


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

Расскажи про задачу, которую ты решал в этом году на одном из треков Dialogue Evaluation.


Я занимался задачей, очень близкой тому, чем занимаются в ABBYY. Нужно было построить модель, которая проанализирует предложение, сделает морфологический и синтаксический разбор, определит леммы. Это очень похоже на то, что делают в школе. Построение модели заняло примерно 5 моих выходных дней.

image

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

А похоже ли это на то, чем ты занимаешься на работе?


Скорее, нет. Тут надо понимать, что эта задача сама по себе особого смысла не несет её решают как подзадачу в рамках решения некоторой важной для бизнеса задачи. Так, например, в компании ABBYY, где я работал когда-то, морфо-синтаксический разбор это начальный этап в рамках решения задачи извлечения информации. В рамках моих текущих задач у меня не возникает необходимости в таких разборах. Однако сам по себе дополнительный опыт работы с предобученными языковыми моделями типа BERT, по ощущениям, безусловно полезен для моей работы. В целом, это и было основной мотивацией для участия я хотел не выиграть, а попрактиковаться и получить какие-то полезные навыки. К тому же, мой диплом был частично связан с темой задачи.

Участвовал ли ты в Dialogue Evaluation до этого?


Участвовал в дорожке MorphoRuEval-2017 на 5 курсе и тоже тогда занял 1 место. Тогда нужно было определить только морфологию и леммы, без синтаксических отношений.

Реально ли применять твою модель для других задач уже сейчас?


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

А для чего ты участвуешь в Dialogue Evaluation и других подобных соревнованиях?


Хакатоны и такие соревнования напрямую не связаны с моей деятельностью, но это все равно полезный опыт. Например, когда я участвовал в хакатоне AI Journey в прошлом году, я научился каким-то вещам, которые потом использовал в работе. Задача была научиться проходить ЕГЭ по русскому языку, то есть решать тесты и писать сочинение. Понятно, что это всё слабо связано с работой. А вот умение быстро придумать и обучить модель, которая решает какую-то задачу очень даже полезно. Мы тогда с командой, кстати, заняли первое место.

Расскажи, какое образование ты получил и чем занимался после университета?


Окончил бакалавриат и магистратуру кафедры компьютерной лингвистики ABBYY в МФТИ, выпустился в 2018 году. Также учился в Школе анализа данных (ШАД). Когда пришло время выбирать базовую кафедру на 2 курсе, у нас большая часть группы пошла на кафедры ABBYY компьютерной лингвистики или распознавания изображений и обработки текста. В бакалавриате нас хорошо учили программировать были очень полезные курсы. Я с 4 курса работал в ABBYY на протяжении 2,5 лет. Сначала в группе морфологии, затем занимался задачами, связанными с языковыми моделями для улучшения распознавания текста в ABBYY FineReader. Я писал код, обучал модели, сейчас я занимаюсь тем же, но для совсем другого продукта.

А как проводишь свободное время?


Люблю читать книги. В завиcимости от времени года стараюсь бегать или ходить на лыжах. Увлекаюсь фотографией во время путешествий.

Есть ли у тебя планы или цели на ближайшие, допустим, 5 лет?


5 лет слишком далекий горизонт планирования. У меня ведь даже нет 5-летнего опыта работы. За последние 5 лет многое поменялось, сейчас явно другое ощущение от жизни. С трудом представляю, что еще может измениться, но есть мысли получить PhD за границей.

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


Лучше всего практиковаться, пробовать и участвовать в соревнованиях. Совсем начинающие могут пройти один из множества курсов: например, от ШАДа, DeepPavlov или даже мой собственный, который я когда-то провел в ABBYY.


Кстати, мы продолжаем набор в магистратуру на кафедры ABBYY в МФТИ: распознавания изображений и обработки текста (РИОТ) и компьютерной лингвистики (КЛ). До 15 июля включительно присылайте на brains@abbyy.com мотивационное письмо с указанием кафедры, на которую хотели бы поступить, и резюме с указанием среднего балла GPA по 5- или 10-балльной шкале.

Подробности о магистратуре можно посмотреть на видео, а о кафедрах ABBYY прочитать здесь.
Подробнее..

Анонс онлайн-митапа по тестированию три доклада про плохие процессы в команде, хотфиксы и первые шаги в автоматизации

07.07.2020 10:10:24 | Автор: admin

image


Наши тестировщики из Новосибирска соскучились по встречам с единомышленниками и приготовили онлайн-митап, который нельзя пропустить. Катя Синько порассуждает о том, как занять проактивную позицию и улучшить выстроенные процессы в команде. Инна Шундеева расскажет, как стать автоматизатором и не отступать перед трудностями. А Люда Малеева из Miro поделится советами, как организовать релизы без багов и что правильно делать, если на боевой их всё-таки нашли.


Когда: 9 июля в 16:00 (Мск)
Где: Ютуб-канал Контура


Менять процессы нельзя страдать Катя Синько, Контур


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


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


Качество релизов ответственность команды Люда Малеева, Miro


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


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


5 открытий: дневники автоматизатора Инна Шундеева, Контур


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


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


До встречи! Жмите колокольчик на Ютубе, готовьте прохладительные напитки, подключайтесь и смотрите онлайн-митап Kontur Tech Talks по тестированию.

Подробнее..

Категории

Последние комментарии

© 2006-2020, personeltest.ru