Да, вот такой гибридный, русско-английский заголовок получился… Поэтому давайте сразу кое-что проясним. Итак, если SEO широко известный (в узких кругах) термин, то AMP — ещё не столь. Accelerated Mobile Pages был анонсирован Google в 2015 г. (см. статью в Википедии), как инструмент, позволяющий быстро просматривать веб-страницы на мобильных телефонах. Со временем AMP превратился в фреймворк, позволяющий создавать страницы для любых сайтов (не только для мобильных устройств), и расширил свою «номенклатуру»: собственно сайты (AMP Websites), истории (AMP Stories; тема этой статьи), рекламные блоки (AMP Ads), и электронные письма (AMP email). За всем этим, как было сказано выше, стоит Google, и если вас интересует продвижение сайтов в этой поисковой машине — полезно будет отнестись к теме AMP с должным вниманием. Но давайте сначала посмотрим как выглядят эти самые AMP-истории (AMP stories), затем решим нужны ли они нам, и, если окажется, что нужны — рассмотрим как это сделать.

Пример AMP-истории

Кликните по QR-коду, чтобы посмотреть как выглядит AMP-история на реальном сайте с настольного компьютера или ноутбука, или сосканируйте его, чтобы просмотрите эту же страницу с мобильного устройства (смартфона и/или планшета):

На компьютере или ноутбуке вы должны увидеть такую «историю»:

А на планшете и смартфоне такую:

Кому это подходит

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

Как это влияет на поисковую оптимизацию (SEO)

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

• Скорость загрузки страниц
• Адаптация к мобильным устройствам
• Наличие структурированных данных
• Наличие обильного контента
• Долгая история сайта

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

Скорость загрузки страниц

Взгляните на этот скриншот из документации Google, и прочитайте подчёркнутое (или кликните на изображение, чтобы перейти к этому документу):

Технология AMP с самого начала была разработана именно для увеличение скорости загрузки страниц на мобильных устройствах. Для этих целей, на мобильные устройства Google загружает AMP-страницы не с вашего сервера, а из своего кеша (Google AMP Cache). То есть Google предварительно сохраняет вашу AMP-страницу (в данном случае AMP-историю) у себя, и затем быстро отдаёт её пользователям мобильных устройств с помощью своей мощной глобальной сети серверов, т.н. CDN — Content Delivery Network.

Правда, это справедливо лишь для страниц, открываемых на мобильных устройствах (страницы, открываемые с компьютера, по-прежнему будут грузиться с вашего сервера), но мы знаем, что адаптация к мобильным устройствам очень важна, поскольку сегодня пользователи заходят на сайты с мобильных устройств чаще, чем с традиционных компьютеров и ноутбуков. Итак, с помощью технологии AMP мы решаем проблему скорости загрузки страниц (по крайней мере на мобильных устройствах), которая удовлетворяет жёстким требованиям Google. И это уже не мало! Но в документации также сказано и про: "иллюстрированные статьи в результатах Google поиска", коими, очевидно, названы AMP-истории (взгляните на первое предложение на скриншоте, или кликните на изображение, чтобы перейти к этому документу):

Из данного контекста можно сделать вывод, что Google в своём поиске выделяет им (т.е. "иллюстрированным статьям") специальное место в поисковой выдаче! Так почему бы не занять это место и вашим историям? Но технология AMP-историй ещё достаточно новая, и Google не раз объявлял о поэтапном её внедрении в результаты поисковой выдачи — по регионам планеты и темам самих историй. Но, я знаю, что вы знаете, когда лучше всего готовить сани… Кроме того, наличие на вашем сайте в качестве контента AMP-историй со структурированными данными просто не может остаться незамеченным (если мы всё правильно сделаем; об этом читайте далее) алгоритмами Google, и, очень даже вероятно, что это благотворно повлияет на позиции всего сайта в его поисковой выдаче.

А пока давайте проверим на Валидаторе AMP страниц от Google можно ли считать нашу историю корректной AMP-страницей с точки зрения самого Google:

Да, всё ОК. Обратите внимание, что внизу на данном скриншоте сказано и о том что "На странице найдены действительные структурированные данные". К ним мы ещё вернёмся, но сначала давайте проверим, адаптирована ли наша AMP-история к мобильным устройствам.

Адаптация к мобильным устройствам

Для этой проверки есть ещё один инструмент от Google — Проверка оптимизации для мобильных устройств. Проверяем:

Всё ОК. И, честно сказать, я почему-то это знал заранее.

Наличие структурированных данных

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

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

Как видите — ничего сложного. В документации Google сказано, что предпочитаемый формат JSON-LD — хорошо, делаем type="application/ld+json".

Далее документация говорит, что предпочтительный стандарт http://schema.org — принимаем и это.

А дальше всё очевидно и интуитивно понятно. Поясню только что:
— пути к файлам здесь можно указывать как относительные так и абсолютные;
— datePublished и dateModified при первой публикации совпадают, а в случае изменении контента — меняем только значение поля dateModified;
— формат полей datePublished и dateModified именно такой как показано, причём +3 — это смещение времени в часах от Гринвича (GMT — Greenwich Mean Time), в данном случае имеется в виду московское время;
— в качестве image (здесь это файл poster.jpg) рекомендуется использовать изображение с соотношениями сторон (ширина/длина) 3:4, размером не менее 696 x 928 пикселей, рекомендуется: 960 x 1200 или 1200 x 1600;
— в качестве logo (здесь это файл thumb.png) рекомендуется постоянно использовать одно и то-же (для конкретного сайта или бренда) квадратное изображение, размером не менее 98 x 98 пикселей (думаю, что 200 x 200 или 256 x 256 будет ОК).

При проверки валидности AMP мы уже видели что: "На странице найдены действительные структурированные данные", но давайте проверим это с помощью специального инструмента от Google Проверка структурированных данных:

Как видим, в правом верхнем углу заглавными буквами написано: НЕТ ОШИБОК, НЕТ ПРЕДУПРЕЖДЕНИЙ — похоже, что Google довольный. Значит и мы тоже.

Дополнительно: данные для социальных сетей

Хотя к поисковым технологиям это не имеет отношения, но поскольку мы хорошо осознаём роль социальных сетей, давайте сделаем кое-что полезное и для них (но мы-то знаем — в конечном итоге это всё обернётся в нашу пользу). Итак, в разделе head AMP-истории (впрочем, как и любой другой страницы сайта) также можно разместить разметку, сообщающую социальным сетям таким как Facebook, Twitter, Pinterest, ВКонтакте дополнительную информацию о нашей AMP-истории. Теперь если пользователь одной из соцсетей поделится ссылкой на нашу страницу — «подтянется» ещё изображение и заголовок (а иногда ещё и описание), как на примере с ВКонтакте на этом скриншоте:

А вот как эта разметка выглядит в коде страницы:

Здесь, думаю, тоже всё интуитивно понятно. Но поясню следующее.

Разметка пустыми строками разделена на три секции.

Facebook (использует пространство имён og — Open Graph), Twitter (использует пространство имён twitter), и ВКонтакте (использует пространство имён vk).

Надо сказать что Open Graph де-факто является стандартом для подобной разметки, и другие социальные сети также используют её. Более того, если вы не укажите отдельно для Twitter и ВКонтакте — они также будут пытаться использовать Open Graph. Но мы указали для более контролируемого результата.

Надо также отметить, что пути к ресурсам здесь надо прописывать абсолютные, за исключением ВКонтакте — здесь путь к изображению можно прописать как абсолютный, так и относительный (в примере выше — относительный: content="./hero_vk.jpg").

Кроме того, Facebook требует создать т.н. веб-приложение, и использовать его идентификатор (property="fb:app_id", см. первую строку), вероятно, чтобы контролировать распространение стороннего контента через свою сеть (и иметь возможность в любой момент прикрыть эту лавочку, если ему что-то не понравится).

Чтобы создать такое приложение перейдите на страницу приложений аккаунта разработчика (который надо создать, если ещё не создан) Facebook for Developers и нажмите плитку: "Добавьте новое приложение". Дайте своему приложению любое имя (своё я назвал «Визуальные Истории»), и сразу после создания вы увидите идентификатор вашего приложения, как показано на скриншоте ниже:

Дальнейшие настройки легки для понимания, и для наших целей — не обязательны.

Теперь давайте проверим валидность нашей разметки для социальных сетей.

Отладчик репостов Facebook:

Кажется с Facebook всё ОК.
Теперь Twitter Card validator:

И с ним, похоже всё хорошо.
На очереди Pinterest Rich Pins Validator:

И Pinterest вроде доволен. Даже написал: AMP Valid? True. И обратите также на значение полей Canonical URL и AMP URL — это важно, и мы через пару шагов заострим на этом внимание.

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

Как сделать

AMP-историю можно создать… вручную. Хотя у некоторых CMS есть расширения для создания AMP-страниц, но именно AMP-истории, насколько мне известно, ещё не поддерживаются. Есть также несколько онлайн сервисов для создания именно AMP-историй, например, MakeStories, но я их не тестировал, поскольку не люблю подобные зависимости от третьих лиц, в смысле чистоты кода, полноты функционала и своевременности обновлений. Поэтому, вот ссылка на шаблон в моём GitHub-репозитории, содержащий базовый функционал (изображения, видео, анимация — всё как в AMP-истории «Низкие звёзды лета»), которого вполне достаточно для большинства случаев, но и его можно легко расширить пользуясь официальным каталогом компонентов. Шаблон также можно склонировать:

git clone https://github.com/stmike/amp-story-template-ru.git
cd amp-story-template-ru

Но код будет работать некорректно, если его запускать непосредственно из файловой системы. Для целей разработки и тестирования сначала надо запустить локальный сервер. Если у вас нет своего проверенного, надёжного и привычного, и у вас браузер Chrome — могу порекомендовать Web Server for Chrome. Просто запустите, выберите папку с файлами (amp-story-template-ru) и откройте локальный адрес — всё как показано на скриншоте:

Поскольку мы уже говорим о браузере Chrome, могу порекомендовать ещё и расширение от разработчиков AMP — AMP Validator. Пользоваться им невероятно просто: если вы на валидной AMP-странице — на панели Chrome горит зелёный значок; если нет — красный, и при клике показывает номера строк с ошибками.

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

1. Поисковая система Google будет считать AMP-историю (как и любую AMP-страницу) валидной, только если для доступа к ней используется безопасный протокол HTTPS (не HTTP).

2. Если AMP-история (как и любая AMP-страница) имеет в качестве «компаньона» другую, «обычную» страницу сайта, в разделе head обоих страниц необходимо разместить теги link как показано на скриншотах:

Именно об этом нам также сообщил Pinterest-валидатор. Обратите внимание на значение атрибута rel. В первом случае rel="canonical", а во втором — rel="amphtml". Дело в том, что на данном сайте имеется «обычная» (canonical) страница о походе под названием «Низкие звёзды лета», и описываемая здесь (amphtml) AMP-история с таким же названием. Поэтому эти две страницы необходимо «связать» между собой, чтобы Google был в курсе дела.

Если же для AMP-страницы/истории нет канонической («обычной») страницы-компаньона, всё равно на AMP-странице/истории надо обязательно разместить тег link, но уже c атрибутом rel="canonical", и ссылкой на эту же страницу (т.е. на саму себя; атрибут href). Только так Google будет считать нашу AMP-историю валидной!

3. В GitHub-репозитории наряду с привычным index.html файлом вы найдёте и файл bookend.json. В AMP-историях он отвечает за изящное окончание истории: повторить, поделиться через соцсети, полезные ссылки. Всё, как показано на скриншоте:

Пути к сторонним ресурсы в файле bookend.json могут быть как абсолютными, так и относительными.

Заключение

На сегодня всё. Другие материалы следуют. Кому подобное читать интересно — подписывайтесь на уведомления о новых публикациях. Подписаться можно на этом сайте (кнопка Подписаться внизу), или на Telegram-канал IT Туториал Захар, или Twitter @mikezaharov.

Донаты

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

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

---

«Как организовать работу команды на удаленке» (вебинар)

Когда: 2 мая, 13:00
Условия участия: бесплатно
Организатор: GeekBrains

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

Темы для обсуждения:

• Основные принципы удаленной работы.
• Инструменты для совместной удаленной работы.
• Способы организовать себя и сотрудников.

Ведущий вебинара — Николай Белоусов, интернет-маркетолог с пятилетним опытом, основатель агентства Your Partner Digital.

→ Подробности и регистрация

---

«StayHomeClub Meetup №2 Spice IT & GeekBrains» (онлайн-митап)

Когда: 4 мая, 18:00
Условия участия: бесплатно
Организатор: Spice IT Recruitment и GeekBrains

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

Ведущий дискуссии — Станислав Антонов, Business Development Director в Spice IT.

→ Подробности и регистрация

---

«TechRec Webinar Week» (серия вебинаров)

Когда: начало 5 мая, 15:00
Условия участия: бесплатно
Организатор: GetIT

Серия вебинаров с экспертами IT-подбора в рамках онлайн-конференции TechRec 2020.

Расписание и темы вебинаров:

• 5 мая: «Стратегия подбора IT-специалистов в кризис» — Светлана Петровичева, GetIT;
• 6 мая: «Удаленный подбор: как повысить эффективность отдела рекрутмента» — Юлианна Васкевич, Soft Skills;
• 7 мая: «Эмоциональное выгорание IT-рекрутера: как его победить и не допустить в вашей команде» — Елена Феденкова, ex YouDo;
• 8 мая: «Бесплатные инструменты сорсинга» — Егор Яценко, Sourcing School.

→ Подробности и регистрация

---

«Миссия выполнима, или Как не дать команде сойти с ума?» (вебинар)

Когда: 6 мая, 18:00
Условия участия: бесплатно
Организатор: Хабр Карьера

Антон Здор, менеджер департамента разработки и дизайна медийных проектов Rambler Group, расскажет о том, как не дать команде сойти с ума на удалёнке. 

Поговорим про: 

• Объединение полезного и развлекательного — миф или реальность? 
• Как сделать так, чтобы ежедневные митинги не наскучили?
• Немного о неформальном: личное и персонализированное. 
• Как жонглировать темами, в том числе и негативными.

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

---

«Секреты нерабочих процессов Додо» (вебинар)

Когда: 8 мая, 18:00
Условия участия: бесплатно
Организатор: Хабр Карьера

Дарья Мамлыгина, HR менеджер компании Dodo Pizza, расскажет о том, как они живут на удалёнке. 

Будем говорить о:

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

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

---

«Инструменты мотивации, которые работают и на удалёнке» (вебинар)

Когда: 12 мая, 18:00
Условия участия: бесплатно
Организатор: Хабр Карьера

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

Спикер — Алексей Шаграев, руководитель службы разработки в Поисковом портале Яндекса, кандидат технических наук, доцент МФТИ, старший преподаватель МЭИ.

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

---

«Удалёнке — да, хайпу — нет! Опыт полностью удаленной компании» (вебинар)

Когда: 13 мая, 12:00
Условия участия: бесплатно
Организатор: CyberMarketing

Алексей Сорокин, руководитель биржи WorkHard.Online поделится опытом, как его команда безболезненно перешла на удалённую работу два года назад.

Темы для обсуждения:

• Как мы пришли к удаленке?
• Что самое главное при работе с удаленными сотрудниками?
• Кого нанимать?
• Как навести порядок подручными средствами?
• Как и сколько платить?
• Как наладить коммуникацию?
• Мир не станет прежним?

→ Подробности и регистрация

---

«Мотивация и самомотивация в период неопределенности» (вебинар)

Когда: 13 мая, 18:00
Условия участия: бесплатно
Организатор: Хабр Карьера

В период неопределенности и стресса навыки мотивации и самомотивации изменяются и становятся сложнее. В обычном состоянии организм работает в режиме «захотел-сделал», но иногда прокрастинация и недостаток энергии ставят палки в колёса. В стрессе в эту схему добавляется еще два блока, получается: успокоиться → захотеть → разблокировать возможность действия → делать. Что это за блоки? Как они устроены нейробиологически? Что нужно сделать, чтобы они заработали и не съедали тучу времени? Обсудим это на вебинаре.

Спикер вебинара — Обухова Анна, Agile Coach, партнер компании ScrumTrek.  

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

---

«Как выводить сотрудников на работу в удаленке?» (вебинар)

Когда: 14 мая, 10:00
Условия участия: бесплатно
Организатор: ВИЗАВИ Консалт

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

Темы вебинара:

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

→ Подробности и регистрация

---

«Профессия IT-рекрутёр» (онлайн-курс)

Когда: начало 15 мая
Условия участия: 75 000 рублей
Организатор: Skillbox

Программа курса состоит из блока о рекрутинге, блока о технологиях и дипломной работы.

Чему вы научитесь:

• Грамотно составлять вакансии;
• Разбираться в IT-технологиях;
• Находить кандидатов;
• Проводить собеседования;
• Составлять оффер;
• Сопровождать соискателей.

→ Подробности и регистрация

---

«Мотивация и самомотивация в период неопределенности» (вебинар)

Когда: 15 мая, 18:00
Условия участия: бесплатно
Организатор: Хабр Карьера

Последний вебинар в рамках марафона удаленки на Хабр Карьере. Выступает Антон Зубков, руководитель проектного офиса AdTech Rambler Group.

Поговорим про: 

• Программистов на удалёнке, какие они бывают?
• Как управлять людьми, когда они далеко?
• Как не возненавидеть конфколлы?

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

---

«TechRec 2020» (онлайн-конференция)

Когда: 29 мая, 10:00
Условия участия: 4990 рублей (тариф «Мастер-класс»), 6990 рублей (тариф «Стандарт»), 9990 рублей (тариф «Всё включено»)
Организатор: GetIT

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

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

Программа ещё формируется, сейчас своё участие подтвердили эксперты из Qlean, Miro, Viber, Skyeng, AmazingHiring, Wheely, Sourcing School и Эльдорадо.

→ Подробности и регистрация

---

Об организаторах мероприятий:

1. ВИЗАВИ Консалт — федеральная рекрутинговая сеть.
2. Хабр Карьера — сервис поиска работы и сотрудников в ИТ.
3. CyberMarketing — обучающий центр.
4. GeekBrains — образовательный портал, который помогает начать карьеру в digital с нуля.
5. GetIT — IT рекрутинговое агентство.
6. LABA — международная образовательная платформа.
7. Skillbox — онлайн-университет современных digital-профессий.
8. Spice IT Recruitment — IT специализированное кадровое агентство.

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

Экс-руководитель отдела разработки пользовательских рекламных кампаний и развития аналитики в компании Appodeal Константин Грабарь рассказал о плюсах и минусах удаленного, офисного и смешанного формата работы.

Обратите внимание: статья по докладу 2018 года на конференции ProductSense. Некоторые процессы в компании успели поменяться, а почти всех сотрудников перевезли в Минск.

Appodeal существует на рынке с 2015 года. Офисы компании находятся в Сан-Франциско, Барселоне, Москве, Барнауле, Луцке и Минске. Это крупные локальные центры, где сосредоточены IT-специалисты. При этом большая часть людей все равно работает удаленно, потому что живет в других городах.

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

Как разрабатывают продукты в Appodeal

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

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

Период интеграции для крупных клиентов может длиться несколько месяцев. Это происходит из-за тех самых А/Б тестов и жестких прямых сравнений с конкурентами, о которых я говорил.

Требования к продуктам мы формируем несколькими способами:

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

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

Четыре проблемы удаленной разработки

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

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

Мы пробовали экспериментировать: привозили разработчиков и менеджеров в офис в Барселоне и замечали, что при командной работе за одну-две недели удается решить те задачи, которые не получается качественно выполнять на удаленке. Но собирать вместе 120 человек — это не очень гибко, удобно и дешево.

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

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

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

Третья проблема — гибкость. В отличие от предприятий стартапы — гибкие компании. Мы начинали как маленькая команда из 10−20 человек без продакт-менеджеров, и это не мешало нам работать. Но с появлением большего количества людей мы стали терять гибкость. Сильнее всего пострадала обратная связь. Она очень важна для компании, где постоянно проверяют множество гипотез, подстраиваются под меняющийся рынок и адаптируются к новым клиентам с особыми требованиями. И если нужно срочно решать задачу, а сотрудник в другом часовом поясе спит, приходится что-то менять. Как минимум, переводить сотрудника в тот же часовой пояс.

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

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

Когда в одном городе набирается более трех человек, идея создать офис возникает сама по себе. То есть люди сами съезжаются в коворкинги, чтобы поработать вместе. Хороший пример — офис в Барнауле, где у нас сконцентрирована команда технической поддержки. Там работает около 30 человек. Получается, что нам удалось создать эффективно работающую команду с низкой текучкой и с хорошим микроклиматом в небольшом городе.

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

Как мы перевезли ключевых сотрудников

Выбирая город для перемещения команды, нужно учитывать множество факторов, в том числе экономические и юридические. Мы предпочли Минск — один из самых комфортных городов-миллионников, по крайней мере, в странах СНГ. Офис стоит недешево, но по всему миру существуют особые экономические зоны, в том числе в России и в Белоруссии. Например, Парк высоких технологий в Минске. Такие зоны дают резидентам пониженную налоговую ставку и упрощают юридические формальности. Они помогают снижать градус боли при перемещении нескольких десятков человек в офис.

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

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

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

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

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

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

Что произошло за 1,5 года после переезда

Я выступал на конференции ProductSense с этим докладом в 2018 году. За прошедшее время мы сделали еще несколько дополнительных выводов.

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

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

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

Компания Appodeal не зациклилась исключительно на офисной работе. Хотя большинство теперь работает в Минске, остались офисы в США и Барселоне. Если возникает необходимость, любой сотрудник может поработать вне офиса. Главное — чтобы процессы были налажены, и другие специалисты из-за этого не страдали.

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

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

Выводы

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

Благодарим за подготовку статьи редактора Елену Егину.

Привет! На связи Музей Яндекса.

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

Знакомьтесь, «Феликс» — арифмометр, один из самых популярных экспонатов нашего музея. Мало кому удаётся пройти мимо и не попытаться разобраться, как он работает. А я — Александр Шмелёв, сотрудник Музея. Под катом покажу как устроен наш «Феликс», немного первых арифмометров и много видео!

Немного истории

Арифмометр — настольная (или портативная) механическая вычислительная машина, предназначенная для выполнения точных умножения и деления, а также сложения и вычитания. Первые механические счётные машины появились ещё в XVII веке:

— «считающие часы» Вильгельма Шиккарда, 1623 год

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

Реплика арифмометра Шиккарда

— суммирующая машина Блеза Паскаля («Паскалина»), 1642 год

Внешне — ящик с большим количеством шестерёнок. Хотя конструкция позволяла производить все 4 операции, удобно работать было только со сложением. Широкого распространения она не получила, но принцип работы (связанные шестерёнки) стал самым популярным для счётных машин ближайших трёх столетий.

«Паскалина» в Музее искусств и ремёсел в Париже

— арифмометр Готфрида Вильгельма Лейбница, 1673 год

Лейбниц придумал использовать шаговый барабан — колесо Лейбница. Позднее оно вошло в конструкцию популярного карманного арифмометра Curta («математическая граната»), выпускавшегося с 1948 по 1970 год. Как это выглядело:

Реплика арифмометра Лейбница

И как работало:

Модель колеса Лейбница

Прямым предком «Феликса» можно считать арифмометр, придуманный Вильгодтом Теофилом Однером, шведско-русским механиком и изобретателем. Он выпускался промышленно в Санкт-Петербурге с 1890 по 1918 год и известен под фамилией автора.

Арифмометр Однера

Самым важным новшеством в конструкции стало колесо Однера — подвижный диск с рычажками и штырьками. При перемещении рычажков штырьки выходят из своих гнезд, причём количество выдвинутых штырьков определяется положением рычажка. Арифмометр позволял выполнять 4 операции: сложение, вычитание, умножение и деление.

Колесо Однера

После Октябрьской революции 1917 года, наследники Однера вернулись в Швецию и стали производить вычислитель под маркой «Original-Odhner». В 1924 году петербургский завод был перевезён в Москву, и арифмометр стал «Феликсом».

Принцип работы на видео (осторожно, английский!):

«Феликс» — в честь Феликса Дзержинского

Под этим именем с 1929 по 1978 год было выпущено несколько миллионов экземпляров. Производством «Феликсов» занимались заводы счётных машин в Курске («Счётмаш»), Пензе (Пензенский завод вычислительной техники) и Москве (Завод счётно-аналитических машин имени В. Д. Калмыкова (САМ)). Кстати, «САМ» также занимался производством электронных вычислительных машин, таких как Урал-1, Стрела и БЭСМ-6.

В 70-ые годы «Феликс» стоил примерно 10–15 рублей, и за счёт достаточно низкой цены пользовался определённой популярностью: электрические калькуляторы в это же время стоили в несколько раз дороже. Арифмометрами учили пользоваться даже в школах. Почувствовать себя в роли оператора арифмометра можно тут: ссылка ведёт на инструкцию по эксплуатации.

«Феликс» на YaTalks 2019

На фото — экземпляр из коллекции Виктора Боева на YaTalks 2019. Если вы были в нашем музее до февраля текущего года, то видели именно этот арифмометр. Всем хотелось его потрогать (думаем, всё дело в его нечеловеческом обаянии), и мы решили обзавестись своим:

Органы управления арифмометром:

1 — барашек сброса счётчика оборотов ручки;
2 — счетчик оборотов основной рукоятки 10;
3 — рукоятка сдвига каретки;
4 и 7 — стрелки-запятые, не связаны с механизмом арифмометра;
5 — задвижка для сброса в 0 положений рычажков 8;
6 — счетчик результата;
8 — рычажки барабана, с помощью которых выставляется значение операнда;
9 — барашек сброса счётчика результата;
10 — основная рукоятка. На корпусе справа от рычажков 8 есть подсказка по нужному направлению вращения основной рукоятки 10 при разных арифметических операциях.

Что внутри?

Наш «Феликс» серого цвета выпущен заводом Счётмаш в городе Курск — на корпусе выбит соответствующий логотип — заглавная «С» в рамке. Сделан в 70-ые, последние годы выпуска — указан ГОСТ 16346-70. Габариты: 320х155х135 мм. Масса: 3,5 кг.

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

Для обслуживания арифмометра я приготовил:

— набор шлицевых отверток;
— бумажные салфетки;
— салфетки из нетканого материала;
— машинное масло;
— ватные палочки;
— баллон со сжатым воздухом;
— бензин «Калоша».

Чтобы снять заднюю крышку, откручиваем 4 винта:

Снимаем крышки каретки:

Переворачиваем арифмометр и откручиваем ещё 6 винтов:

Отсоединяем часть с колесами Однера и основной рукояткой:

1 — система зубчатых колес Однера; 2 — счётчик результата; 3 — счётчик оборотов основной рукоятки; 4 — звонок переполнения или отрицательного числа в счётчике результата.

Откручиваем фиксаторы каретки и отсоединяем её:

На этом этапе будет много пыли и других возможностей запачкаться — не забудьте подготовиться! Продуваем и протираем внутренности. Смазываем машинным маслом трущиеся поверхности каретки и можно собирать всё в обратной последовательности.

«Феликс» позволяет работать с числами до 9 знаков. Есть и другие технические ограничения: результаты сложения, вычитания и умножения не должны превышать 13 знаков, деления — 8. При переполнении счётчика результата или получении отрицательного числа звучит звонок: требуется отменить предыдущую операцию.

Для подготовки к работе:

1. С помощью рукоятки 3 передвинуть каретку в крайнее левое положение.
2. Барашками 1 и 9 сбросить показания счетчиков оборотов и результата.
3. Задвижкой 5 и поворотом основной рукоятки 10 по часовой стрелке до упора сбросить положение рычажков 8 в нулевое.

Чтобы сложить и вычесть числа:

1. Подготовить арифмометр к работе.
2. Выставить первый операнд рычажками 8.
3. Одним поворотом основной рукоятки 10 по часовой стрелке прибавить первый операнд к нулевому значению счётчика результата 6.
4. Выставить второй операнд рычажками 8.
5. Для сложения нужно повернуть основную рукоятку по часовой стрелке на один оборот. Для вычитания — против часовой стрелки на один оборот.
6. Ура! Результат сложения или вычитания в счётчике результата. Напоминаем: если в конце поворота основной рукоятки раздался звонок, произошло переполнение или получилось отрицательное число. В любом случае основную рукоятку требуется повернуть в обратную сторону.
Умножение и деление можно заменить на сложение и вычитание. Подробнее — в инструкции по эксплуатации, если не боитесь, или вот:

Так работает колесо Однера нашего «Феликса»:

и счётчик результата:

«Феликс» не только обаятельный, но и надёжный. И я не только о том, что арифмометр сохранил работоспособность несмотря на почтенный возраст. Большая часть нашей экспозиции — функционирующая ретро-техника. Как-то раз в музее отключили электричество. Но мы не растерялись: «Феликс» и конторские счёты не подвели!

После окончания пандемии будем рады видеть вас в музее! Научим пользоваться «Феликсом», разберём и покажем что у него внутри. Заодно на 0 поделить попробуете. А пока с удовольствием отвечу на ваши вопросы в комментариях.

Привет всем в этом блоге, и с вами четвертый пост из серии про Quarkus!

Предыдущий пост был о том, как Quarkus объединяет MicroProfile и Spring. Напомним, что Quarkus позиционируется как «сверхбыстрая субатомная Java», он же «Kubernetes-ориентированный Java-стек, заточенный под GraalVM и OpenJDK HotSpot и собранный из лучших библиотек и стандартов». Сегодня мы покажем, как модернизировать уже имеющиеся Java-приложения, задействуя возможности Quarkus, на примере приложения helloworld из репозитория Red Hat JBoss Enterprise Application Platform (JBoss EAP) Quickstart, в котором используются поддерживаемые в Quarkus технологии CDI и Servlet 3.

Здесь важно отметить, что и Quarkus, и JBoss EAP делают упор на том, чтобы использовать инструменты, максимально построенные на базе стандартов. У вас нет приложения, работающего на JBoss EAP? Не проблема, его можно легко перенести с текущего сервера приложений на JBoss EAP с помощью Red Hat Application Migration Toolkit. После чего финальная и рабочая версия модернизированного кода будет доступна в репозитории github.com/mrizzi/jboss-eap-quickstarts/tree/quarkus, в модуле helloworld.

При написании этого поста использовались руководства по Quarkus, в основном Creating Your First Application и Building a Native Executable.

Обзаводимся кодом

Первым делом создадим локальный клон репозитория JBoss EAP quickstarts:

$ git clone https://github.com/jboss-developer/jboss-eap-quickstarts.git Cloning into 'jboss-eap-quickstarts'... remote: Enumerating objects: 148133, done. remote: Total 148133 (delta 0), reused 0 (delta 0), pack-reused 148133 Receiving objects: 100% (148133/148133), 59.90 MiB | 7.62 MiB/s, done. Resolving deltas: 100% (66476/66476), done. $ cd jboss-eap-quickstarts/helloworld/ 

Смотрим, как работает исходный helloworld

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

Разворачиваем helloworld

1. Открываем терминал и переходим в корень папки JBoss EAP (его можно загрузить здесь), то есть в папку EAP_HOME.

2. Запускаем сервер JBoss EAP с дефолтным профилем:

$ EAP_HOME/bin/standalone.sh 

Примечание: на Windows для запуска используется сценарий EAP_HOME\bin\standalone.bat.

Через пару секунд в логе должно появится примерно следующее:

[org.jboss.as] (Controller Boot Thread) WFLYSRV0025: JBoss EAP 7.2.0.GA (WildFly Core 6.0.11.Final-redhat-00001) started in 3315ms - Started 306 of 527 services (321 services are lazy, passive or on-demand) 

3. Открываем в браузере 127.0.0.1:8080 и видим вот это:

Рис. 1. Домашняя страница JBoss EAP.

4. Следуем инструкциям в руководстве Build and Deploy the Quickstart: разворачиваем helloworld и выполняем (из корневой папки проекта) следующую команду:

$ mvn clean install wildfly:deploy 

После успешного выполнения этой команды в логе увидим примерно следующее:

[INFO] ------------------------------------------------------------------------  [INFO] BUILD SUCCESS  [INFO] ------------------------------------------------------------------------  [INFO] Total time: 8.224 s 

Итак, первое развертывание приложения helloworld на JBoss EAP заняло чуть больше 8 секунд.

Тестируем helloworld

Действуя строго по руководству Access the Application, открываем в браузере 127.0.0.1:8080/helloworld и видим вот что:

Рис. 2. Исходный Hello World из JBoss EAP.

Вносим изменения

Меняем входной параметр createHelloMessage(String name) c World на Marco:

writer.println("<h1>" + helloService.createHelloMessage("Marco") + "</h1>"); 

Опять выполняем следующую команду:

$ mvn clean install wildfly:deploy 

Затем обновляем страницу в браузере и видим, что текст изменился:

Рис. 3. Hello Marco в JBoss EAP.

Откатываем развертывание helloworld и завершаем работу JBoss EAP

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

$ mvn clean install wildfly:undeploy 

Чтобы завершить работу экземпляра JBoss EAP, просто нажмите Ctrl+C в окне терминала.

Модернизируем helloworld

Теперь займемся модернизацией исходного приложения helloworld.

Создаем новую ветку

Создаем новую рабочую ветку после того, как закончится выполнение проекта quickstart:

$ git checkout -b quarkus 7.2.0.GA 

Меняем файл pom.xml

Приложение мы начнем менять с файла pom.xml. Чтобы Quarkus мог вставлять в него XML-блоки, выполним следующую команду в папке helloworld:

$ mvn io.quarkus:quarkus-maven-plugin:0.23.2:create 

При написании этой статьи использовалась версия 0.23.2. У Quarkus часто выходят новые версии, узнать, какая версия является самой последней, можно на сайте github.com/quarkusio/quarkus/releases/latest.

Приведенная выше команда вставит в pom.xml следующие элементы:

• Свойство <quarkus.version>, задающее используемую версию Quarkus.
• Блок <dependencyManagement> для импорта Quarkus BOM (bill of materials), чтобы не добавлять версию для каждой зависимости Quarkus.
• Плагин quarkus-maven-plugin, отвечающий за упаковку приложения и предоставляющий режим development mode.
• Профиль native для создания исполняемых файлов приложения.

Кроме того, в pom.xml мы вручную вносим следующие изменения:

1. Вытаскиваем тег <groupId> из блока <parent> и размещаем его выше тега <artifactId>. Поскольку на следующем шаге мы удалим блок <parent>, то надо сохранить <groupId>.
2. Удаляем блок <parent>, поскольку при работе с Quarkus этому приложению больше не понадобится родительский pom от JBoss.
3. Добавляем тег <version> и размещаем его под тегом <artifactId>. Номер версии можно указать какой хотите.
4. Удаляем тег <packaging>, поскольку это приложение больше не WAR, а обычный JAR.
5. Модифицируем следующие зависимости:
   
   1. Меняем зависимость javax.enterprise:cdi-api на io.quarkus:quarkus-arc, удаляя <scope>provided</scope>, поскольку (согласно докам) это Quarkus-расширение обеспечивает injection зависимости CDI.
   2. Меняем зависимость org.jboss.spec.javax.servlet:jboss-servlet-api_4.0_spec на io.quarkus:quarkus-undertow, удаляя <scope>provided</scope>, поскольку (согласно докам) это Quarkus-расширение обеспечивает поддержку servlet’ов.
   3. Удаляем зависимость org.jboss.spec.javax.annotation:jboss-annotations-api_1.3_spec, поскольку они идет в комплекте с зависимостями, которые мы только что изменили.

Версия файла pom.xml со всеми изменениями лежит по адресу github.com/mrizzi/jboss-eap-quickstarts/blob/quarkus/helloworld/pom.xml.

Обратите внимание, что приведенная выше команда mvn io.quarkus:quarkus-maven-plugin:0.23.2:create не только меняет файл pom.xml, но и добавляет в проект ряд компонентов, а именно, следующие файлы и папки:

• Файл mvnw and mvnw.cmd и папку .mvn: Maven Wrapper позволяет запускать проекты Maven заданной версии Maven без установки этой самой версии.
• Папка docker (в каталоге src/main/): здесь лежат примеры файлов Dockerfile для режимов native и jvm (вместе с файлом .dockerignore).
• Папка resources (в каталоге src/main/): здесь лежит пустой файл application.properties и образец стартовой страницы Quarkus index.html (подробнее см. Run the modernized helloworld ).

Запускаем helloworld
Чтобы протестировать приложение, используем quarkus:dev, который запускает Quarkus в режиме development mode (подробнее см. вот этот раздел в руководстве по Development Mode).

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

Теперь запускаем команду, чтобы проверить, как это сработает:

$ ./mvnw compile quarkus:dev [INFO] Scanning for projects... [INFO] [INFO] ----------------< org.jboss.eap.quickstarts:helloworld >---------------- [INFO] Building Quickstart: helloworld quarkus [INFO] --------------------------------[ war ]--------------------------------- [INFO] [INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ helloworld --- [INFO] Using 'UTF-8' encoding to copy filtered resources. [INFO] Copying 2 resources [INFO] [INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @ helloworld --- [INFO] Nothing to compile - all classes are up to date [INFO] [INFO] --- quarkus-maven-plugin:0.23.2:dev (default-cli) @ helloworld --- Listening for transport dt_socket at address: 5005 INFO  [io.qua.dep.QuarkusAugmentor] Beginning quarkus augmentation INFO  [org.jbo.threads] JBoss Threads version 3.0.0.Final ERROR [io.qua.dev.DevModeMain] Failed to start quarkus: java.lang.RuntimeException: io.quarkus.builder.BuildException: Build failure: Build failed due to errors 	[error]: Build step io.quarkus.arc.deployment.ArcProcessor#validate threw an exception: javax.enterprise.inject.spi.DeploymentException: javax.enterprise.inject.UnsatisfiedResolutionException: Unsatisfied dependency for type org.jboss.as.quickstarts.helloworld.HelloService and qualifiers [@Default] 	- java member: org.jboss.as.quickstarts.helloworld.HelloWorldServlet#helloService 	- declared on CLASS bean [types=[javax.servlet.ServletConfig, java.io.Serializable, org.jboss.as.quickstarts.helloworld.HelloWorldServlet, javax.servlet.GenericServlet, javax.servlet.Servlet, java.lang.Object, javax.servlet.http.HttpServlet], qualifiers=[@Default, @Any], target=org.jboss.as.quickstarts.helloworld.HelloWorldServlet] 	at io.quarkus.arc.processor.BeanDeployment.processErrors(BeanDeployment.java:841) 	at io.quarkus.arc.processor.BeanDeployment.init(BeanDeployment.java:214) 	at io.quarkus.arc.processor.BeanProcessor.initialize(BeanProcessor.java:106) 	at io.quarkus.arc.deployment.ArcProcessor.validate(ArcProcessor.java:249) 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) 	at java.lang.reflect.Method.invoke(Method.java:498) 	at io.quarkus.deployment.ExtensionLoader$1.execute(ExtensionLoader.java:780) 	at io.quarkus.builder.BuildContext.run(BuildContext.java:415) 	at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35) 	at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:2011) 	at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1535) 	at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1426) 	at java.lang.Thread.run(Thread.java:748) 	at org.jboss.threads.JBossThread.run(JBossThread.java:479) Caused by: javax.enterprise.inject.UnsatisfiedResolutionException: Unsatisfied dependency for type org.jboss.as.quickstarts.helloworld.HelloService and qualifiers [@Default] 	- java member: org.jboss.as.quickstarts.helloworld.HelloWorldServlet#helloService 	- declared on CLASS bean [types=[javax.servlet.ServletConfig, java.io.Serializable, org.jboss.as.quickstarts.helloworld.HelloWorldServlet, javax.servlet.GenericServlet, javax.servlet.Servlet, java.lang.Object, javax.servlet.http.HttpServlet], qualifiers=[@Default, @Any], target=org.jboss.as.quickstarts.helloworld.HelloWorldServlet] 	at io.quarkus.arc.processor.Beans.resolveInjectionPoint(Beans.java:428) 	at io.quarkus.arc.processor.BeanInfo.init(BeanInfo.java:371) 	at io.quarkus.arc.processor.BeanDeployment.init(BeanDeployment.java:206) 	... 14 more 

Так, не работает… А почему?

Исключение UnsatisfiedResolutionException указывает на класс HelloService, который является членом класса HelloWorldServlet (java member: org.jboss.as.quickstarts.helloworld.HelloWorldServlet#helloService). Проблема в том, что HelloWorldServlet нужен инжектированный экземпляр HelloService, а его не получается найти (хотя оба этих класса и находятся в одном и том же пакете).

Самое время вернуться к документации и почитать, как в Quarkus работает Inject, а следовательно, и Contexts and Dependency Injection (CDI). Поэтому открываем руководство Contexts and Dependency Injection и в разделе Bean Discovery читаем: «Bean-класс, у которого нет определяющей bean аннотации, не ищется».

Смотрим класс HelloService – в нем действительно нет такой аннотации. Поэтому ее надо добавить, чтобы Quarkus мог искать и находить bean. И поскольку это stateless-объект, мы вполне можем добавить аннотацию @ApplicationScoped следующим образом:

@ApplicationScoped public class HelloService { 

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

import javax.enterprise.context.ApplicationScoped; 

Если сомневаетесь, какую область scope надо использовать в том случае, когда для исходного bean’а она не задана вообще, проштудируйте документацию JSR 365: Contexts and Dependency Injection for Java 2.0—Default scope.

Теперь опять пробуем запустить приложение командой ./mvnw compile quarkus:dev:

$ ./mvnw compile quarkus:dev [INFO] Scanning for projects... [INFO] [INFO] ----------------< org.jboss.eap.quickstarts:helloworld >---------------- [INFO] Building Quickstart: helloworld quarkus [INFO] --------------------------------[ war ]--------------------------------- [INFO] [INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ helloworld --- [INFO] Using 'UTF-8' encoding to copy filtered resources. [INFO] Copying 2 resources [INFO] [INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @ helloworld --- [INFO] Changes detected - recompiling the module! [INFO] Compiling 2 source files to /home/mrizzi/git/forked/jboss-eap-quickstarts/helloworld/target/classes [INFO] [INFO] --- quarkus-maven-plugin:0.23.2:dev (default-cli) @ helloworld --- Listening for transport dt_socket at address: 5005 INFO  [io.qua.dep.QuarkusAugmentor] (main) Beginning quarkus augmentation INFO  [io.qua.dep.QuarkusAugmentor] (main) Quarkus augmentation completed in 576ms INFO  [io.quarkus] (main) Quarkus 0.23.2 started in 1.083s. Listening on: http://0.0.0.0:8080 INFO  [io.quarkus] (main) Profile dev activated. Live Coding activated. INFO  [io.quarkus] (main) Installed features: [cdi] 

Теперь все проходит без ошибок.

Запускаем модернизированный helloworld
Как и написано в логе, открываем в браузере 0.0.0.0:8080 (стартовая страница Quarkus по умолчанию) и видим вот что:

Рис. 4. Стартовая страница Quarkus dev.

В аннотации WebServlet у этого приложения прописано следующее определение контекста:

@WebServlet("/HelloWorld") public class HelloWorldServlet extends HttpServlet { 

Поэтому идем в браузере на 0.0.0.0:8080/HelloWorldto и видим следующее:

Рис. 5: Страница The Quarkus dev для приложения Hello World.

Ну вот, всё работает.

А теперь вносим изменения в код. Обратите внимание, что команда ./mvnw compile quarkus:dev все еще работает, и мы не собираемся ее останавливать. Теперь попробуем применить те же самые – тривиальнейшие – изменения к самому коду и посмотрим, как Quarkus облегчает жизнь разработчику:

writer.println("<h1>" + helloService.createHelloMessage("Marco") + "</h1>"); 

Сохраняем файл и затем обновляем веб-страницу, чтобы увидеть надпись Hello Marco, как показано на скрине ниже:

Рис. 6. Страница Hello Marco в Quarkus dev.

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

INFO  [io.qua.dev] (vert.x-worker-thread-3) Changed source files detected, recompiling [/home/mrizzi/git/forked/jboss-eap-quickstarts/helloworld/src/main/java/org/jboss/as/quickstarts/helloworld/HelloWorldServlet.java] INFO  [io.quarkus] (vert.x-worker-thread-3) Quarkus stopped in 0.003s INFO  [io.qua.dep.QuarkusAugmentor] (vert.x-worker-thread-3) Beginning quarkus augmentation INFO  [io.qua.dep.QuarkusAugmentor] (vert.x-worker-thread-3) Quarkus augmentation completed in 232ms INFO  [io.quarkus] (vert.x-worker-thread-3) Quarkus 0.23.2 started in 0.257s. Listening on: http://0.0.0.0:8080 INFO  [io.quarkus] (vert.x-worker-thread-3) Profile dev activated. Live Coding activated. INFO  [io.quarkus] (vert.x-worker-thread-3) Installed features: [cdi] INFO  [io.qua.dev] (vert.x-worker-thread-3) Hot replace total time: 0.371s 

Обновление страницы триггернуло детектирование изменений в исходном коде, и Quarkus автоматически выполнил процедуру «стоп-старт». И все это выполнилось всего за 0.371 секунды (вот она, та самая «сверхбыстрая субатомная Java»).

Выполняем сборку helloworld в пакет JAR
Теперь, когда код работает как надо, упакуем его следующей командой:

$ ./mvnw clean package 

Эта команда создает два JAR-файла в папке /target: файл helloworld-.jar, который представляет собой стандартный артефакт, собранный Maven-командой вместе классами и ресурсами проекта. И файл helloworld—runner.jar, представляющий собой исполняемый JAR.

Обратите внимание, что это не убер-jar, поскольку все зависимости просто скопированы в папку /target/lib (а не упакованы в файл JAR). Поэтому, чтобы запустить это JAR из другой папки или на другом хосте, туда надо скопировать как сам JAR-файл, так и папку /lib, учитывая что элемент Class-Path в файле MANIFEST.MF в пакете JAR содержит явное перечисление JAR’ов из папки lib.
Чтобы узнать, как создавать приложения убер-jar, обратитесь к руководству Uber-Jar Creation.

Запускаем helloworld, упакованный в JAR

Теперь можно запускать наш JAR с помощью стандартной команды java:

$ java -jar ./target/helloworld-<version>-runner.jar INFO  [io.quarkus] (main) Quarkus 0.23.2 started in 0.673s. Listening on: http://0.0.0.0:8080 INFO  [io.quarkus] (main) Profile prod activated. INFO  [io.quarkus] (main) Installed features: [cdi] 

После того, как все это выполнится, зайдите в браузере на 0.0.0.0:8080 и проверьте, что все работает как надо.

Собираем helloworld в нативный исполняемый файл

Итак, наш helloworld работает как standalone-приложение Java, используя зависимости Quarkus. Но можно пойти дальше и превратить его в нативный исполняемый файл.

Устанавливаем GraalVM
Прежде всего, для этого надо установить необходимые инструменты:

1. Скачиваем GraalVM 19.2.0.1 с github.com/oracle/graal/releases/tag/vm-19.2.0.1.

2. Разворачиваем загруженный архив:

$ tar xvzf graalvm-ce-linux-amd64-19.2.0.1.tar.gz 

3. Идем в папку untar.

4. Запускаем приведенную ниже команду, чтобы скачать и добавить нативный образ:

$ ./bin/gu install native-image 

5. Прописываем папку, созданную на шаге 2, в переменную среды GRAALVM_HOME:

$ export GRAALVM_HOME={untar-folder}/graalvm-ce-19.2.0.1) 

Дополнительные сведения и инструкции по установке на других ОС можно найти в руководстве Building a Native Executable—Prerequisites.

Выполняем сборку helloworld в нативный исполняемый файл
Читаем руководство Building a Native Executable—Producing a native executable: «А теперь создадим нативный исполняемый файл для нашего приложения, чтобы сократить время его запуска и размер на диске. Исполняемый файл будет иметь все необходимое для запуска приложения, включая JVM-машину (вернее, ее усеченную версию, содержащую лишь то, что требуется для выполнения приложения) и само наше приложение».

Чтобы создать нативный исполняемый файл, надо включить native-профиль Maven:

$ ./mvnw package -Pnative 

У нас сборка заняла одну минуту и 10 секунд, а итоговый файл helloworld—runner f был создан в папке /target.

Запускаем нативный исполняемый файл helloworld

На предыдущем шаге мы получили исполняемый файл /target/helloworld—runner. Теперь запустим его:

$ ./target/helloworld-<version>-runner INFO  [io.quarkus] (main) Quarkus 0.23.2 started in 0.006s. Listening on: http://0.0.0.0:8080 INFO  [io.quarkus] (main) Profile prod activated. INFO  [io.quarkus] (main) Installed features: [cdi] 

Опять открываем в браузере 0.0.0.0:8080 и проверяем, что все работает как надо.

Продолжение следует!

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