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

Блог компании haulmont

Перевод Вы уверены, что вам нужен API?

16.04.2021 10:20:09 | Автор: admin


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


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


Ценность API в сокрытии информации


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


Почему это важно? Потому что чем объемнее API, тем дороже его поддерживать. Представьте себе крайний случай открытие каждой детали реализации. Каждое изменение в системе может сломать код, который используют ваши клиенты. Именно по этой причине мы стремимся разрабатывать компактные API. Я писал статью (перевод на хабре) по этой теме в контексте описания шаблона Регистрация событий.


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


API как продукт


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


Разделение клиента и сервера


Я готов спорить, что такие API как продукт редкость. Гораздо чаще существование развесистого API признак плохо выбранных границ вследствие нарушения принципа слабая связанность сильное сцепление.


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


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


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


Тяга к отрисовке на клиентской части


Ещё один двигатель страсть к реализации клиентской части с использованием современных JS фреймворков для разработки пользовательского интерфейса, таких как Angular, React или Vue.js. В противоположность отрисовке на сервере (SSR), эти фреймворки отрисовывают интерфейс на клиентской машине (CSR) в браузере и полагаются на сервисы (REST, GraphQL,...), предоставляемые сервером для получения данных и выполнения каких-то действий.


Самодостаточность и CSR не противоречат друг другу


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


Но использование такого фреймворка не означает обязательное наличие API! Подумайте о поставке приложения как о самодостаточной, единой системе, которая включает в себя и клиент, и сервер! Уверен, у вас есть разделение сред выполнения, так как серверный код выполняется на сервере, а клиентский в браузере пользователя. И это разделение требует использования REST или GraphQL, чтобы синхронизировать среды выполнения.


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


Заключение


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


Если вы решите двигаться по пути создания единой системы, то вам решать, что использовать SSR или CSR. И, хотя зачастую понятия CSR и SPA (одностраничное приложение) часто слепливают вместе, вы можете использовать CSR и разрабатывать модульную клиентскую часть.


Ссылки


У меня появилась идея написания этой статьи, когда я слушал подкаст SoftwareArchitekTOUR Episode 82 (German) с Stefan Tilkov и Eberhard Wolff. Спасибо за вдохновение!


Хорошие источники для более глубокого погружения в самодостаточным системам и микро-фронтам:
Self-Contained Systems
Micro Frontend

Подробнее..

JPA Buddy Умный помощник половина работы

17.03.2021 14:12:14 | Автор: admin

От переводчика: это статья моего коллеги @aleksey-stukalov, которую мы опубликовали в блоге JPA Buddy пару месяцев назад. С тех пор мы выпустили JPA Buddy 2.0, но все сказанное в этой статье актуальности не потеряло.

Ну что ж, Hello World... После почти года разработки наконец-то вышла первая версия JPA Buddy! Это инструмент, который должен стать вашим верным помощником по написанию кода для проектов с JPA и всем, что с этим связано: Hibernate, Spring Data, Liquibase и другим ПО из типичного стека разработки.

Чем он вам поможет? Если кратко, JPA Buddy упростит работу с JPA и тем самым сэкономит ваше время. В этой статье мы взглянем на основные фичи JPA Buddy, немного обсудим его историю и поговорим о его преимуществах. Надеюсь, он займет достойное место среди любимых инструментов Java-разработчиков, которые пользуютсяJPA, Spring, Liquibase и, конечно же, самой продвинутой Java IDE IntelliJ IDEA.

Откуда растут ноги

Мы создатели CUBA Platform (кстати, не так давно мы переименовали ее в Jmix :)) среды быстрой разработки приложений на Java. Платформа CUBA уникальный продукт. Он состоит из двух частей: фреймворка и инструмента разработки CUBA Studio. Одной из самых полюбившихся частей CUBA Studio стал Entity Designer. В сообществе CUBA более 20 000 разработчиков, и почти все они отмечают, насколько легко и быстро он дает создавать модель данных. Даже для тех, кто никогда не слышал о JPA, такие вещи как создание JPA-сущностей, ограничений модели данных и DDL-скриптов становятся легкой задачей.

В 2016 году CUBA стала open-source проектом. С того момента мы приняли участие в десятках конференций по всему миру, собрали много отзывов и лучше поняли, что именно нужно разработчикам. Они нас часто спрашивали: Можно ли использовать ваш конструктор сущностей без CUBA Platform?. Рады сообщить, что с появлением JPA Buddy мы теперь можем смело ответить да!.

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

Область применения

Перед тем, как написать первую строчку исходного кода JPA Buddy, мы провели опрос и собрали различные сценарии использования JPA и сопутствующих технологий. Результат оказался достаточно предсказуемым: среднестатистическое приложение в настоящее время это приложение на Spring Boot с Hibernate в качестве реализации ORM, Spring Data JPA в качестве механизма управления данными и Flyway или Liquibase для системы миграции базы данных. Ах да, чуть не забыли про Lombok... В общем, на этом стеке мы и сконцентрировались в первом релизе.

Говоря о предназначении JPA Buddy, мы поставили перед собой следующие цели:

  • Сократить написание шаблонного кода вручную: инструмент должен генерировать код быстрее ручного ввода

  • Не заставлять тратить время на чтение документации: инструмент должен предоставлять интуитивно понятные визуальные конструкторы

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

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

  • Обеспечить обзор проекта с точки зрения данных и удобную навигацию между связанными сущностями

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

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

  • Аннотации Hibernate: @Where, @NaturalId, @Formula, поисковые аннотации и т. п.

  • Визуальный конструктор запросов

  • Аудит с использованием Envers и Spring Data JPA

  • Генерация модели по существующей схеме базы данных

  • Поддержка Kotlin

В дальнейшем мы учтем и другие функции: поддержка Quarkus и Micronaut, REST API и генерация пользовательского интерфейса для CRUD-операций.

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

Общий обзор

Давайте посмотрим, как выглядит JPA Buddy. После его установки у вас появятся 3 новые панели инструментов: JPA Structure, JPA Palette и JPA Inspector.

JPA Structure

Панель JPA Structure расположена в левом нижнем углу. Она позволяет посмотреть на проект с точки зрения модели данных. С ее помощью можно:

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

  2. Создавать объекты, связанные с данными: сущности, JPA-конвертеры/Hibernate-типы, Spring Data репозитории и Liquibase-скрипты.

  3. Увидеть, для каких сущностей созданы какие репозитории.

  4. Просматривать скрипты Liquibase и их внутреннюю структуру.

  5. Настраивать параметры плагина, такие как соединение с БД, Persistence Units и некоторые другие, которые плагин не обнаружил автоматически.

JPA Palette и JPA Inspector

Панель JPA Palette находится справа вверху, и ее содержимое зависит от контекста. Она доступна только тогда, когда Buddy готов предложить чтото для быстрой генерации кода. Сейчас панель появляется при редактировании следующих объектов: JPA Entity, Spring Data репозиториев и Liquibase-скриптов. Для генерации какого-либо элемента просто выберите нужный вариант в списке и кликните по нему дважды.

JPA Inspector размещается справа внизу, под JPA Palette, и открывается вместе с ним. С помощью JPAPalette можно генерировать новый код, а с помощью JPAInspector редактировать уже существующий. В нем видно, как можно сконфигурировать выбранную часть кода, будь то поле сущности или выражение изLiquibase-скрипта.

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

Интеграция с Liquibase

Хорошие новости для тех, кто использует Liquibase для управления версиями схемы базы данных: JPA Buddy тесно с ним интегрирован, он позволяет удобно редактировать и создавать Liquibase-скрипты, а также гибко управлять типами атрибутов. Давайте посмотрим, как именно JPA Buddy поможет вам работать с Liquibase.

Во-первых, в JPA Buddy есть визуальный конструктор для редактирования Liquibase-скриптов. Он показывает различные доступные команды плагина в JPAPalette, а панель инструментов JPAInspector дает увидеть настройки, которые можно применить к выбранному выражению.

Во-вторых, JPA Buddy дает определить свои собственные маппинги для сопоставления Java-типов (Конвертеров/Hibernateтипов) и типов, которые должны использоваться для каждой конкретной СУБД. Приведем несколько примеров, когда эта функция будет полезна:

  • Допустим, у вас в сущности есть поле типа byte[]. Что генератор схемы Hibernate, что Liquibase сопоставят ваш массив с довольно экзотическим типом OID. Думаю, многие разработчики предпочли бы использовать bytea вместо предлагаемого по умолчанию типа. Это можно легко сделать, создав маппинг с Java-типа byte[] на БД-тип bytea в настройках проекта в JPA Buddy.

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

  • Поля типа String по-умолчанию хранятся как varchar, то есть не поддерживают Юникод. С помощью JPA Buddy легко изменить этот тип на nvarchar, с которым этой проблемы нет.

Все эти случаи обычно решаются с помощью атрибута columnDefinition, однако это решение не будет работать для проектов, где одновременно используется несколько СУБД. JPA Buddy позволяет указать, какой именно маппинг использовать для конкретной СУБД.

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

  • Написание вручную

  • Создание скриптов путем сравнения двух баз данных: исходной (представляющей фактическое состояние модели) и целевой (с предыдущим состоянием модели)

Для тех, кто предпочитает первый вариант, JPA Buddy включает уже упомянутый ранее конструктор Liquibase-скриптов.

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

Начнем с небольшой проблемы: может случиться так, что база данных, используемая для разработки на ноутбуке разработчика, не того же типа, что и база данных на продакшене. Это можно исправить, например, запустив MS SQL в Docker на Mac.

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

ВJPA Buddy есть замечательная функция генерации Liquibase-скриптов напрямую, путем сравнения ваших объектов JPA сцелевой базой данных (или snapshotом целевой базы данных). Выможете использовать H2в целях разработки ипо-прежнему генерировать правильные журналы изменений для Oracle, MSSQL или того, что выиспользуете впродакшене. Подобный подход гарантирует, что если увас есть мусор вжурналах изменений, это именно тот мусор, который есть увас висходном коде. Все, что вам нужно, это содержать модель данных вчистоте, итогда миграция неприведет кнежелательным артефактам вбазе данных продакшена.

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

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

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

  • содержащие операторы, которые вызовут потерю данных, например, удаление таблицы или столбца

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

Заключение

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

Говоря прямо, мы хотели бы вдохновить вас стать первыми пользователями JPA Buddy и сформировать сообщество энтузиастов. Установите JPA Buddy, попользуйтесь им и поделитесь своими отзывами с нашей командой разработчиков: это очень поможетнам выбрать правильное направление развития продукта. Также подпишитесь на наш Twitter: там мы показываем, какие еще фичи есть у JPA Buddy и как ими пользоваться. Думаю, вы найдете что-то полезное именно для вас.

Подробнее..

Hibernate и Spring Boot кто отвечает за имена таблиц?

28.04.2021 16:12:49 | Автор: admin

Когда мы добавляем зависимость в проект, мы подписываем контракт. Зачастую, многие условия в нем написаны мелким шрифтом. В этой статье мы рассмотрим кое-что, что легко пропустить при подписании трехстороннего контракта между вами, Hibernate и Spring Boot. Речь пойдет о стратегиях именования.

Значения по умолчанию в JPA

Главное правило для значений по умолчанию: они должны быть интуитивно понятными. Давайте проверим, следует ли этому правилу обычное приложение на Spring Boot с конфигурацией по умолчанию, Hibernate в качестве реализации JPA и PostgreSQL в качестве БД. Допустим, у нас есть сущность PetType. Давайте угадаем, как будет называться ее таблица в базе данных.

Первый пример:

@Entitypublic class PetType {    // fields omitted}

Я бы предположил, что именем таблицы станет имя класса, то есть PetType. Однако, после запуска приложения оказалось, что имя таблицы на самом деле pet_type.

Явно зададим имя с помощью @Table:

@Entity@Table(name = "PetType")public class PetType {    // fields omitted}

В этот раз имя точно должно быть PetType. Запустим приложение Таблица снова называется pet_type!

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

@Entity@Table(name = "\"PetType\"")public class PetType {  // fields omitted}

И опять наши ожидания не оправдались, имя снова "pet_type", но теперь в кавычках!

Стратегии именования Hibernate

На запрос имя таблицы поумолчанию для JPA-сущностей Google выдает следующий результат (англ.):

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

Именно это мы ожидали увидеть в первом примере, не так ли? Очевидно, что-то нарушает стандарт.

Углубимся в Hibernate. Согласно документации (англ.), в Hibernate есть два интерфейса, отвечающих за именование таблиц, столбцов и пр.: ImplicitNamingStrategy и PhysicalNamingStrategy.

ImplicitNamingStrategy отвечает за генерацию имен для всех объектов, которые не были явно названы разработчиком: имя сущности, имя таблицы, имя столбца, индекса, внешнего ключа и т.д.. Получившееся имя называется логическим, оно используется внутри Hibernate для идентификации объекта. Это не то имя, которое будет использовано в базе данных.

PhysicalNamingStrategy создает подлинное физическое имя на основе логического имени объекта JPA. Именно физическое имя используется в базе данных. Фактически, это означает, что с помощью Hibernate нельзя напрямую указать физическое имя объекта в БД, можно указать только логическое. Чтобы лучше понять, как это все работает, посмотрите на схему ниже.

По умолчанию, в Hibernate используются следующие реализации этих интерфейсов: ImplicitNamingStrategyJpaCompliantImpl и PhysicalNamingStrategyStandardImpl. Первый генерирует логические имена в соответствии со спецификацией JPA, а второй использует их как физические имена без каких-либо изменений. Лучше всего это описано в документации:

JPA определяет четкие правила автоматического именования. Если вам важна независимость от конкретной реализации JPA, или если вы хотите придерживаться определенных в JPA правил именования, используйте ImplicitNamingStrategyJpaCompliantImpl (стратегия по умолчанию). Кроме того, в JPA нет разделения между логическим и физическим именем. Согласно спецификации JPA, логическое имя это и есть физическое имя. Если вам важна независимость от реализации JPA, не переопределяйте PhysicalNamingStrategy.

Однако наше приложение ведет себя по-другому. И вот почему. Spring Boot переопределяет реализации Hibernate по умолчанию для обоих интерфейсов и вместо них использует SpringImplicitNamingStrategy и SpringPhysicalNamingStrategy.

SpringImplicitNamingStrategy фактически копирует поведение ImplicitNamingStrategyJpaCompliantImpl, есть только незначительное различие в именовании join таблиц. Значит, дело в SpringPhysicalNamingStrategy. В документации (англ.) указано следующее:

По умолчанию, в Spring Boot используется SpringPhysicalNamingStrategy в качестве физической стратегии именования. Эта реализация использует те же правила именования, что и Hibernate 4:
1. Все точки заменяются символами подчеркивания.
2. Заглавные буквы CamelCase приводятся к нижнему регистру, и между ними добавляются символы подчеркивания. Кроме того, все имена таблиц генерируются в нижнем регистре. Например, сущности TelephoneNumber соответствует таблица с именем telephone_number.

По сути, Spring Boot всегда преобразовывает camelCase и PascalCase в snake_case. Более того, использование чего-либо помимо snake_case вообще невозможно. Я бы не стал использовать camelCase или PascalCase для именования объектов базы данных, но иногда у нас нет выбора. Если ваше приложение на Spring Boot работает со сторонней базой данных, где используется PascalCase или camelCase, конфигурация Spring Boot по умолчанию для вас не подойдет. Обязательно убедитесь, что используемая PhysicalNamingStrategy совместима с именами в базе данных.

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

  • Конечное поведение всегда определяется конкретной реализацией и может отличаться от спецификации.

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

  • Поведение по умолчанию может измениться с обновлением версии библиотеки, что может привести к непредсказуемым побочным эффектам;

Заключение

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

  1. Всегда называйте свои объекты JPA явно, чтобы никакая автоматическая стратегия именования не повлияла на ваш код.

  2. Используйте snake_case для имен столбцов, таблиц, индексов и других объектов JPA, чтобы все реализации PhysicalNamingStrategy никак их не преобразовывали.

  3. Если нельзя использовать snake_case (например, при использовании сторонней базы данных), используйте PhysicalNamingStrategyStandardImpl в качестве PhysicalNamingStrategy.

Еще один плюс явного именования объектов JPA вы никогда случайно не переименуете таблицу или атрибут в самой базе при рефакторинге Java-модели. Для этого придется менять имя в @Table или @Column.

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

Если вы пользуетесь IntelliJ IDEA, попробуйте JPA Buddy плагин, который упрощает работу с JPA, Hibernate, Spring Data JPA, Liquibase и подобными технологиями. В настройках JPA Buddy есть специальная секция, в которой можно установить шаблоны для имен сущностей, атрибутов и пр.. Эти шаблоны применяются каждый раз, когда разработчики создают сущность или атрибут:

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

Подробнее..

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

05.05.2021 16:05:29 | Автор: admin


От переводчика: профессия девелопер адвоката появилась не так давно и почти у каждого крупного продукта или технологии есть свой адвокат, технологические компании понимают важность этого канала общения с миром. Есть такая должность и в Haulmont. Когда мы формулировали требования к вакансии, нам самим пришлось отвечать на вопрос "А что же должен делать девелопер адвокат?" И эта статья простым языком и очень исчерпывающе на этот вопрос отвечает.


Несколько лет назад я написал статью Кто такой вообще этот девелопер адвокат?, в которой постарался помочь людям в технической индустрии понять, что входит в эту роль. И до сих пор я получаю тонны вопросов про это в Твиттере.


В этой статье я собираюсь пролить свет на роль Developer Advocate и в этот раз приведу конкретные примеры задач и обязанностей, которые я выполняю в своей ежедневной работе в качестве Senior Developer Advocate в Microsoft, а также в качестве человека, который занимается этим с 2015 года.


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


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


Девелопер адвокат и технологический евангелист


Существует некоторая путаница в понимании терминов Дев. адвокатство и Технологический евангелизм. Давайте взглянем на их определения.


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


И это прямо противоположно тому, что делает адвокат!


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


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


Именно поэтому эти два звания должны применяться осмысленно.


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


Девелопер адвокат и маркетолог


Спроси любого адвоката о его роли всегда получишь разный ответ, и это немного путает. Причем это обычный случай. А вы когда-нибудь задумывались, почему так? Основная причина в том, что множество компаний нанимают дев. адвоката для выполнения разных задач, от продаж и коммуникаций до (в основном) маркетинга. Почему маркетинг? Потому что компании обычно тратят от 5 до 12 процентов своего дохода на маркетинг, и, когда нужно достучаться до большего количества разработчиков, они обычно нанимают кого-то в качестве адвоката (или чего-то похожего), кто отчитывается отделу маркетинга и должен выполнять KPI по маркетингу и продажам. Ещё важнее в этой ситуации то, что эта роль существует вне команды разработки продукта, что может стать проблемой (поговорим об этом далее).


Не поймите меня неправильно, нет ничего плохого в компаниях, которые используют маркетинг и продажи для привлечения большего количества разработчиков, но делать это, используя зонтичный бренд дев. адвокат, это оказание медвежьей услуги буквально всем. В целом, это обычно оказывается неудачным шагом, потому что не все разработчики хорошо умеют продавать (и заниматься продвижением продукта) и обычно делают это плохо. Разработчики изобретательны и креативны, но немногие обладают базовыми навыками продвижения бизнеса. Почему, вы думаете, большинство стартапов основаны как минимум двумя людьми? Если бы я был хорош в продажах и маркетинге, я бы гораздо лучше продвигал свои собственные open-source проекты, а вы наверняка даже не слышали про xlayers.dev. Так ведь?



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


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


Девелопер адвокат и деврел (Developer Relations)


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


Таким образом, дев. адвокатство крохотное подмножество деврел.



Какая у меня роль в Microsoft?


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


Наша роль работать мостиком между внутренней командой разработки и сообществом разработчиков. Мы также защищаем мнение сообщества внутри команды.


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


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


Вы, возможно, видите, что Microsoft постоянно поднимает планку качества для своих продуктов, и, чтобы этого достичь, компания инвестирует в разработчиков и открытый код. Поэтому миссия нашей деврел команды помогать разработчикам достигать большего. Наша большая дев. адвокатская команда (или облачная дев. адвокатская команда, как мы ее внутри называем, поскольку помогаем команде девопс) состоит из нескольких подкоманд, которые сфокусированы на различных сообществах разработчиков, таких как Rust, Java, Python и т.д., а также на таких аудиториях, как студенты, научные работники и стартапы.


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



Как выглядит мой типичный день дев адвоката?


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


Создание контента


Я участвую в написании документации и остального контента в различных форматах, используемых инженерами по всему миру. Это может быть просто обновление существующей документации, а может быть создание полной документации, как, например, документация по Azure Static Web Apps, над которой работала моя команда совместно с командой документации Microsoft.


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


Вот пара примеров из недавнего:



и вот:



Публичные выступления


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


Создание инструментария в открытую


Кроме работы, которую я делаю для своей компании, я также активный участник сообщества разработчиков софта с открытым кодом, и большая часть проектов, которые я делаю для своего нанимателя это тоже софт с открытым кодом. Это значит, что моя работа ещё и помогать разработчикам успешно осваивать инструменты, которые помогают им использовать и интегрировать Azure в свои продукты и приложения. Последние инструменты, которые я делал https://www.hexa.run, библиотеки Nest.JS для Azure CosmosDB, и Azure Storage. Можете посмотреть на все мои проекты с открытым кодом на wassim.dev.


Донесение обратной связи о продукте


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


Это как раз тот случай, когда в качестве дев. адвоката я могу выступать от имени JavaScript разработчиков, быть их голосом внутри команды. Недавний пример продукт Azure Static Web Apps, где я провел последние полтора года, участвуя в разработке продукта и помогая команде инженеров создать часть сервиса, обеспечивая важную обратную связь, пробуя новую функциональность и разрабатывая CLI инструмент для разработчиков.


Создание и выпуск продукта


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


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


Быть нулевым пользователем


Приличная часть моего времени уходит на улучшение продуктов и сервисов Azure, на работу с командами разработчиков Azure во всей компании для того, чтобы попробовать новую функциональность и дать обратную связь от JavaScript разработчиков об их ожиданиях. Продукты, с которыми я успел поработать за последние два года: Azure Functions, Azure Storage, Azure Cosmos DB, Azure IoT, Azure Static Web Apps, GitHub Codespaces и npm. Быть нулевым клиентом отличный способ кардинально повлиять на продукт до его релиза. Один из примеров здесь Azure Static Web Apps: моя команда и я тесно сотрудничали с командой разработки, чтобы помочь обеспечить лучший опыт использования сервисов для всех web разработчиков, которые будут им пользоваться.


Постоянное обучение


Поскольку JavaScript широко используется в множестве различных областей, стек технологий, на котором я обычно сосредоточен, это: Node.js, TypeScript, Serverless, архитектура IoT, базы данных и хостинг. Я также буду честным: я был восхищен языком Rust и планирую изучать его в ближайшем будущем! К счастью, мои коллеги из команды дев. адвокатов языка Rust сделали учебник 5 hours free guide about Rust for beginners. Похоже, для меня это отличное начало!


Создание и улучшение официальной документации


Как дев. адвокат я также трачу какое-то время на создание подробных технических наставлений для многих сервисов Microsoft Cloud. Одно из последних, над которой моя команда и я работали четыре месяца, the Node.js Learn Path. Что хорошо в нашей официальной документации это то, что она открыта и любой может помочь с улучшением. Мы также регулярно принимаем в этом участие и делаем пулл реквесты на улучшение и обновление документации на http://docs.microsoft.com.


Помогать другим расти


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


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


Бизнес, цели и ключевые результаты


Давайте внесем ясность: цель каждой компании делать бизнес. Компания не просто платит тебе за то, что ты работаешь над проектами с открытым кодом, путешествуешь и выступаешь. Компания инвестирует в тебя и ожидает ROI (возврата инвестиций). Но мы все знаем, что ROI сообществ и построения отношений не так просто определить и измерить.


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


Заключительные идеи


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


Дев. адвокаты инженеры, которым нравится учиться открыто.


Это моя история. Если вам нравится то, что вы прочитали, и вы согласны с этим, обратите внимание, что наша команда ищет новые кадры. Загляните на нашу страницу https://aka.ms/awesomejobs.


Бонус: айсберг дев. адвокатства.



Пишите мне в твиттер @manekinekko, если у вас ещё есть вопросы про дев. адвокатство. Вы также можете наблюдать за моими работами на wassim.dev.

Подробнее..

Нельзя просто взять и сделать продукт из внутреннего фреймворка или как прошел День открытых дверей Jmix

19.04.2021 16:09:25 | Автор: admin

В начале апреля мы в Haulmont анонсировали наше первое крупное онлайн-мероприятие для Java и React разработчиков в 2021 году День открытых дверей open source платформы Jmix.

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

История Jmix: от внутреннего фреймворка до внешнего продукта

Рассказываем, что такое Jmix, из чего он состоит и для кого подходит, почему мы решили создать новый продукт, спустя более 10 лет работы CUBA Platform, и зачем нас понесло в Low code.

01:41

Продукт для разработчиков

Говорим, чем разработка фреймворка с открытым кодом отличается от продуктовой и заказной разработки, обсуждаем Open Source, за который не стыдно, код, за который не страшно, требования для публичного API/SDK, а также выбор технологий и библиотек.

31:22

DevRel: уникальному рынку уникальный маркетинг

Рассказываем, кто такие DevRel-специалисты, чем они занимаются, и как эта деятельность помогает развивать фреймворк.

48:58

Технологии, направления и задачи Jmix

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

56:13

JPA Buddy: инструмент для разработчиков

Обсуждаем, в чем проблемы фреймворков, почему мы выделили JPA Buddy в отдельный проект, и что он умеет.

1:13:38

Вакансии Haulmont

Без лишних слов: если вы Java или React-разработчик, будем рады видеть вас в команде Jmix.

01:20:39

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

Подробнее..

Haulmont и тайные комнаты или почему мы не закрыли офисы разработки за год пандемии

18.03.2021 10:09:11 | Автор: admin

За 12 лет Haulmont вырос из группы амбициозных разработчиков в международную компанию, которая развивает несколько направлений: от open source фреймворка Jmix до системы электронного документооборота ТЕЗИС (с ними вы точно знакомы, если давно читаете нас), от решений для служб такси Sherlock и Shamrock до облачной CRM-системы детских, учебных и спортивных центров Параплан, от разработки на заказ до аутсорсинга офисной печати.

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

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

Мастер и Удаленка

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

Владимир, Frontend разработчик:

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

Дарья, специалист отдела маркетинга:

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

Алистер, директор по работе с ключевыми клиентами:

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

Михаил, разработчик:

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

Офисы сокровищ

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

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

Самара

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

Рабочие места оборудованы всей необходимой техникой и ПО, а еще игрушками, конструкторами и прочими украшениями но это, как вы понимаете, сокровища наших коллег.

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

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

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

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

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

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

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

Кстати, здесь спрятан еще один клад корпоративный спортзал с раздевалкой и душем.

Офис команды системы документооборота

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

Важная особенность этого офиса переговорки. Каждая из них названа в честь разных достопримечательностей и памятных мест Самары. Так что у нас есть своя Наба, Цирк, Драма, Ракета, Бункер и Звезда. Названия мы выбирали все вместе общим голосованием.

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

Тольятти

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

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

Здесь у каждой команды есть свой кабинет. А в общих переговорках HR-отдел часто проводит Soft Skills бранчи.

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

Саратов

Офису в Саратове почти 4 года. Это тоже довольно светлый open space с панорамными окнами. Здесь у каждого направления есть уютное рабочее пространство и достаточно свободных мест, чтобы в скором времени расширить команду.

Особенность этого офиса яркие плакаты и много-много граффити на стенах.

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

Воронеж

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

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

Что мы поняли за 2020 год

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

А что думаете вы: офис или удаленка? Хотели бы иногда возвращаться за рабочее место или уже не откажетесь от работы из дома?

Подробнее..

Вспомнить все или как мы вернулись изудаленки в 2021 году

18.06.2021 12:04:53 | Автор: admin

На самом деле2020-йгодбыл не так уж плох: мы заключилинесколькокрупных контрактов,выпустиликрупнейшееобновление платформыJmix, открыли новыеофисывдвух городахиорганизовали новогодний корпоратив на 500 человек вформате популярного вечернего ТВ-шоу.Вот только удаленкасильно нарушила командные связи. И тогдавозвращение в офис превратилось в операцию Вспомнить всес агентами Вакцинация, Пиццаи Буги-Вуги. Рассказываем, что происходило у нас весной 2021 года. Мы понимаем, что сейчас ситуация с коронавирусом и ограничительными мерами стремительно меняется. Пока в регионах, где расположены подразделения Haulmont, все спокойно, поэтому мы работаем в офисах пока есть возможность. Но внимательно следим за новостями и готовы реагировать по ситуации.

Люди в офисе: Дни минувшего прошлого

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

Наш двенадцатый день рождения впервые прошел за онлайн-чаепитием. Для сравнения, фото 2018 и 2020 года.

2018201820202020

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

Вдобавок,именнов 2020-м годуHaulmontвпервые стал наниматьсотрудниковна удаленкусо всейстраны. И, что говорить,новичкам проникнуться нашей атмосферой было тяжело.

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

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

V значит вакцина

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

Новый порядок

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

Назадв офисы

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

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

Конкурсы, еда и Буги-Вуги

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

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

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

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

  • За треки 2000-ых моеуважение.

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

  • Неплохой баланс свободного и не свободного времени.

Удаленка все. А что дальше?

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

А что вы цените в работе, кромесамойработы?Расскажите нам в комментариях.

Подробнее..

Организация разработки в изолированной сети как управлять зависимостями?

30.07.2020 10:07:11 | Автор: admin

Всем привет,


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


image


Конкретно мы поговорим про тот случай, когда в компании лимитирован доступ к всемирной паутине настолько, что вы не можете пользоваться публичными репозиториями артефактов, например таким, как maven central. Представьте себе, что мы (или вы) поставляем наш фреймворк в такой закрытый контур. Как же нам предоставить все необходимые артефакты, от которых мы зависим, включая транзитивные зависимости? Как потом их обновлять вместе с версиями фреймворка?


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


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


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


Но что делать в случае, если публичные репозитории недоступны из внутренней сети?


Возможные варианты решения проблемы


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


Что же нам остается?


  • Вариант 0. Упрашивание безопасников.
  • Вариант 1. Шлюз.
  • Вариант 2. Ручное управление зависимостями.

Вариант 0 рассматривать не будем, рассмотрим вариант 1 и 2.


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


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


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


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


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

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


Как мы предлагаем решать эти проблемы?


CUBA SDK


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


В чем отличие CUBA SDK от оффлайн плагинов для Gradle или Maven?
Главное отличие CUBA SDK не кэширует зависимости конкретного проекта, а позволяет синхронизировать артефакты между внешними и внутренними репозиториями, чтобы разработчикам было комфортно создавать и разрабатывать приложения в закрытой сети.
CUBA SDK не требует проекта и позволяет создать необходимый оффлайн стек фреймворков, аддонов и библиотек со всеми зависимостями.


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


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


image


CUBA SDK позволяет с помощью нескольких консольных команд определять все зависимости для артефактов и заливать их в нужные репозитории. Для полностью закрытых сетей можно использовать команды импорта и экспорта или установить CUBA SDK на шлюз.


Преимущества использования CUBA SDK:


  • автоматически собирает все зависимости с исходным кодом для загружаемых библиотек
  • определяет зависимости для платформы и аддонов CUBA Platform
  • проверяет и устанавливает новые версии библиотек
  • может работать одновременно с несколькими репозиториями для поиска артефактов, включая локальные maven репозитории
  • имеет встроенный Nexus OSS репозиторий артефактов
  • даёт возможность загрузки артефактов одновременно в несколько репозиториев, включая локальные maven
  • производит импорт и экспорт артефактов со всеми зависимостями
  • предоставляет интерактивный режим с подсказками для установки платформы и аддонов CUBA Platform
  • использует механизмы Gradle для определения зависимостей
  • не зависит от IDE
  • может быть установлен на CI сервере

Команды SDK


Полный список доступных команд можно посмотреть на странице GitHub.


CUBA SDK изначально поддерживает три типа компонентов: CUBA Framework, CUBA addon и библиотека, которая может быть загружена через maven координаты. Этот список может быть расширен для других типов компонентов через плагины для CUBA SDK.


Установка компонента в удаленный репозиторий может быть выполнена через команду install. При создании SDK мы предусмотрели вариант, когда SDK может быть установлен на шлюзовом компьютере или на переносном носителе, в этом случае установку компонентов можно сделать через команды resolve и push.


resolve просто определяет и скачивает все зависимости в локальный кэш SDK
push заливает уже скачанные артефакты с зависимостями в настроенные target репозитории


Для работы с репозиториями в SDK есть встроенный менеджер репозиториев.
Менеджер репозиториев поддерживает локальные и удаленные репозитории, которые в SDK разделены на две группы:


  • source это репозитории, которые будут использоваться для поиска артефактов
  • target репозитории, в которые нужно будет залить эти артефакты

SDK сам может использоваться как репозиторий, для этого с помощью команды setup-nexus SDK скачивает, устанавливает и настраивает репозиторий Nexus OSS. Для запуска и остановки репозитория используются команды start и stop.


Для проверки и установки обновлений достаточно выполнить команду check-updates.


Определение зависимостей


Самая главная проблема, которую должен был решать SDK это корректное определение и сбор зависимостей для компонентов. При разработке мы попробовали несколько подходов для определения транзитивных зависимостей компонентов. Изначально возникла идея, что можно просто распарсить .pom файлы и составить дерево зависимостей. Но идея парсить файлы вручную оказалась не очень хорошей, тем более что Apache Maven все это уже умеет делать из коробки.


Maven как менеджер зависимостей


Поэтому мы решили использовать Apache Maven для определения транзитивных зависимостей компонентов.


Для этого в CUBA SDK скачивается дистрибутив maven в домашнюю папку SDK и через Java Runtime запускаются команды.


Например, с помощью команды


dependency:resolve -Dtransitive=true -DincludeParents=true -DoverWriteSnapshots=true -Dclassifier=<classifier> -f pom.xml

мы определяли все зависимости для компонентов, которые описаны в pom.xml, и эти компоненты автоматически скачивались в локальный кэш maven, после чего с помощью команды


org.apache.maven.plugins:maven-deploy-plugin:3.0.0-M1:deploy-file -Durl=<repository URL>

артефакты заливались в нужный репозиторий.


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


org.apache.maven.plugins:maven-dependency-plugin:3.1.1:get -Dartifact=<maven coordinates>

Для выполнения команд Maven в приложении CUBA SDK сгенерировался settings.xml файл. Он содержал список всех репозиториев, которые должны были использоваться для загрузки и выгрузки артефактов.


Gradle как менеджер зависимостей


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


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


Для вызова задач Gradle используется Gradle Tooling API.


Для определения пути к зависимостями через Gradle мы используем artifact resolution query API. Следующий код позволяет получить путь к исходникам библиотеки:


 def component = project.dependencies.createArtifactResolutionQuery()            .forComponents(artifact.id.componentIdentifier)            .withArtifacts(JvmLibrary, SourcesArtifact)            .execute()            .resolvedComponents[0] def sourceFile = component?.getArtifacts(SourcesArtifact)[0]?.file

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


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


project.ext.properties["toResolve"].tokenize(';').each {            dependencies.add 'extraLibs', it        }        def resolved = [:]        configurations.all.collect {            if (it.canBeResolved) {                it.resolvedConfiguration.lenientConfiguration.artifacts.each { art ->                    try {                        ...                    } catch (e) {                        logger.error("Error: " + e.getMessage(), e)                        logger.error("could not find pom for {}", art.file)                    }                }            }        }

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


Для загрузки артефактов в репозитории SDK использует PublishToMavenRepository задачу Gradle.


task publishArtifact(type: PublishToMavenRepository) {    doLast {        if (project.ext.hasProperty("toUpload")) {            def toUpload = new JsonSlurper().parseText(project.ext.properties["toUpload"])            def descriptors = new JsonSlurper().parseText(project.ext.properties["descriptors"])            artifactId toUpload.artifactId            groupId toUpload.groupId            version toUpload.version            descriptors.each { descriptor ->                artifact(descriptor.filePath) {                    classifier descriptor.classifier.type                    extension descriptor.classifier.extenstion                }            }        }    }}

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


Сборка проекта


Для сборки CUBA SDK мы использовали тот же подход, что и для CUBA CLI. Мы с помощью инструмента jlink собирали все необходимые модули в кастомную JRE, которая поставляется вместе с приложением. Это позволило сделать SDK независимым от установленной на компьютерах пользователей Java. Пример такой сборки можно посмотреть в CLI Core Sample проекте.


Поддержка сторонних плагинов


Так как CUBA SDK построен на основе библиотеки CLI Core, CUBA SDK поддерживает сторонние плагины. С помощью системы плагинов сейчас в SDK реализованы maven и gradle менеджеры зависимостей компонентов и провайдеры для CUBA компонентов.


Рассмотрим пример, как мы можем расширить функционал SDK с помощью плагина. В данном примере мы напишем провайдер для стартеров Spring Boot из хорошо известного Spring Initializr.


Для начала создадим новый проект, для примера возьмем плагин для CUBA CLI, как описано здесь, и добавим зависимости:


implementation "com.haulmont.cli.core:cli-core:1.0.0"implementation "com.haulmont.cli.sdk:cuba-sdk:1.0.1"

Создадим новый провайдер для стартеров spring boot SpringBootProvider, который наследуем от BintraySearchComponentProvider. BintraySearchComponentProvider позволяет автоматически находить доступные версии компонентов, используя Bintray API.


class SpringBootProvider : BintraySearchComponentProvider() {   var springComponentsInfo: SpringComponentsInfo? = null   override fun getType() = "boot-starter"   override fun getName() = "Spring boot starter" ...   override fun load() {       springComponentsInfo = Gson().fromJson(readSpringFile(), SpringComponentsInfo::class.java)   }   private fun readSpringFile(): String {       return SpringComponentsPlugin::class.java.getResourceAsStream("spring-components.json")           .bufferedReader()           .use { it.readText() }   }

Этот провайдер будет искать доступные компоненты из файла spring-components.json, который является json версией yml файла приложения Spring Initializr.


Для маппинга из json в объекты создадим простые data классы:


data class SpringComponent(   val name: String,   val id: String,   val groupId: String?,   val artifactId: String?,   val description: String?,   val starter: Boolean? = true)data class SpringComponentCategory(   val name: String,   val content: List<SpringComponent>)data class SpringInitializr(   val dependencies: List<SpringComponentCategory>)data class SpringComponentsInfo(   val initializr: SpringInitializr)

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


class SpringBootComponentsPlugin : CliPlugin {   private val componentRegistry: ComponentRegistry by sdkKodein.instance<ComponentRegistry>()   @Subscribe   fun onInit(event: InitPluginEvent) {       val bootProvider = SpringBootProvider()       componentRegistry.addProviders(bootProvider)       bootProvider.load()   }}

Все готово. Теперь, чтобы установить наш плагин в терминале или через IDE, нужно выполнить команду gradle installPlugin.


Запустим SDK
image


Видим, что наш плагин успешно загрузился. Теперь проверим, что вся наша логика работает с помощью команды resolve boot-starter:


image


image


Как видим, подсказки для компонентов и их версий успешно заработали.


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


Исходный код тестового плагина можно найти на странице GitHub.


Заключение


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


Если вы самоизолировались в глухой деревне или летите 8 часов в самолете и не готовы платить по 300 евро за 10 мегабайт трафика, то CUBA SDK отличное решение, которое позволит собрать актуальный стек используемых библиотек и фреймворков локально у вас на компьютере.

Подробнее..

Категории

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

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru