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

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

Как строиласьData-практикавEPAM

19.02.2021 12:19:30 | Автор: admin

Компания EPAM давно работает с данными, первые крупные заказчики с проектами поBigDataпоявилисьв далёком 2001 году.В то время известные аналитические компанииGartnerиForrester, а также крупные поставщикиOracle,Microsoftи IBM отмечали, что компании должны двигаться в сторонуBigData, поскольку эти технологии незаменимы во всех областях, связанных с обработкой больших объёмов данных.С того времени команда экспертовEPAMпостепенно росла, работая над всё более сложными проектами и предлагая проверенные решения и качественные продукты для работы с большими данными. Сегодня только в российскомEPAMболее 500 человек работают вData-практике. О том, как всё начиналось, какие проекты встречались, какие провалы случались,к чему должны готовитьсяData-специалисты и о том, какие вообще бываютData-специалисты,я поговорила с руководителемData-практики EPAM в России Ильей Герасимовым.

Карьера

Расскажи, как ты пришёл в направление Data

ВEPAMя пришёл в 2006 годукакjunior-разработчикна .NETиMSSQLServer, до этого работал в продуктовойкомпаниии занимал должность тимлида, разрабатывал ПО для автоматизациигостиници ресторанов.Но вEPAMяначалкарьерус нуля.К 2013 году я дорос дотимлидаиискал новыевозможностисвоегоразвитиявEPAM,и именно в это времяявстретилсянаSECeв Минскес руководителем центра компетенцийBigData, и мы договорились о том, что в России надо развивать это направление.

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

Почему так долго работаешь в компании?

Ещё до Data я подумывал пару раз уйти, но что-то не отпускало меня. Сейчас я могу сказать точно, что здесь меня держат люди, с которыми пройдено много всего. И здесь всегда появляется что-то новое новые проекты, заказчики.

Почему именно Data?

Потому чтовесь мир этоData, и мы в нейData.:)

Что сейчас представляет собой Data-практика?

ПостепеннопоявлялисьновыеData-компетенции:Data Science,Machine Learning,Business Intelligence, Enterprise Search, DevOps in Data, Data Quality, Business Data Analysis.Сегодняв нашей практике более 500 человек это оченьбольшое подразделение сглубокойэкспертизойв разных областях.

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

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

Более глубокое понимание качества данныхэто способ лучше понять бизнес клиента.

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

Проекты

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

Когда в 2013-2014 году мы начинали, у нас было буквально два-три проекта, мы работали с иностранной нефтегазовой компанией, с российским банком, потом появился проект с расшифровкой генома, а затем и первый проект с Data Science.

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

А самый большой провал и как справились с этим?

Первое время провалов было много. В основном они были связаны с нехваткой людей, потому что мы не могли найти готовых людей с улицы со знанием технологий. Мы набираем разработчиков со знанием Java, Python, DevOps-инжиниринг и потом доучиваем.

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

Помимо общего курса нашими специалистами разработано много внутренних курсов по разным направлениям Data Analytics, облачные решения, Data Engineering, Data Science и другие, доступных всем сотрудникам EPAM.

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

Про технологии

За чем сейчас будущее? На какие технологии появляется и сохраняется спрос?

Если я начну перечислять все технологии, то какие-то пропущу, какие-то не вспомню, на какие-то обращу больше внимания, чем они этого заслуживают. Технологий очень много, они быстро стареют и так же быстро появляются новые. Гнаться за суперсовременными технологиями не всегда получается, да и не всегда нужно. Зачастую новые решения появляются на рынке в довольно сыром состоянии. Однажды на одном проекте мы погнались за технологией Cadence, которая показалась заказчику приемлемой, но в итоге с ней постоянно возникало много проблем с производительностью, она не справлялась с тем объёмом данных, который был на проекте, и мы с трудом находили людей, которые могли бы быстро в ней разобраться.

Был ещё один кейс, на этот раз с технологией Reinforcement Learning. Один из наших заказчиков хотел внедрить систему с использованием этой технологии. Этому фреймворку на тот момент было около 2-х месяцев, он был довольно сырой. В целом было очень мало систем промышленного масштаба, где эта технология используется. В итоге ничего не получилось, и нам пришлось быстро откатить систему и создать решение, которое справлялось с задачей заказчика уже без использования Reinforcement Learning. Хотя технология очень перспективна, мы следим за её развитием и, возможно, даже уже в этом году мы сможем использовать её в проектах.

Но всё же существует некоторый золотой стандарт, который должны знать Data-специалисты. Причём этот стандарт тоже постоянно обновляется. На самом деле, в инкубаторе много проектов, которые завтра взлетят. Многие проекты, которые вошли в золотой стандарт это вчерашний инкубатор. Были, конечно, технологии, которые не взлетели. Так случилось, например, с технологией Theano, она появилась примерно в одно время с TensorFlow, но Theano куда-то исчезла.

  • УApacheесть целый набор инструментов, технологий, которые нужно знать среди нихSpark,Cassandra,Elasticsearchи другие.

  • Yarn, HDFS,MapReduce,Hive,Kafka,ZooKeeper этобазовые технологии, с которых всё начиналось.БазоваятехнологияHadoopникуда не делась,хотя онавыглядит немногоустаревшей, новсе принципы,которые в ней заложены,используются в современных технологиях.

  • Вразличных облачныхтехнологиях вAmazon,MicrosoftAzure,JCPесть свои аналогиHadoop, с которыми мы работаем.

  • Также актуальными являются инструменты защиты данных, такие какKerberos,Knox,Ranger.

  • Понятно, что различныеNoSQLиNewSQLбазы данных Cassandra, например(ужене новая),Snowflake,AmazonRedshift,HBase,MongoDB,Teradata.

  • DevOpsтехнологии Kubernetes, Docker, Jenkins.

  • Технологии визуализации данных:PowerBI,Tableau,QlikView.

  • ВDataScienceтоже множество различных фреймворков,напримерTensorFlowиGoogleBERT (который тоже ужевчерашний день, сегодняесть реализации лучше),PyTorch,Keras.

  • Отдельно стоит перечислить технологииStreaming.Streamingэто новый вызовмираData, поэтомуинструментыстоит знать Spark Streaming, KafkaStreams, ApacheFlink, Apache Storm.

Во многом набор знаний зависит от направления специалиста.

Для всех обязательно знание SQL (стандартного и аналитического), теории DWH (какие типы организации хранилищ данных бывают звезда, снежинка,DataVault, как организовать историчность хранения справочников ит.д.), нормализации данных (чем отличаются первая, втораяи третья нормальные формы, что это такое вообще, в каких случаях полезна денормализация), и понимать, чем отличается DWH,DataMart,DataLake.

Для всех обязательно понимание процесса промышленной разработки, знание систем контроля версий. В последние годы обязательным становиться опыт работы с облаками, хотя бы с одним из наиболее популярных AWS,Azure, GCP.

Для тех, кто занимается ETL (загрузка и преобразование данных перед их использованием) обязательно понимание разницы ETL и ELT, стадий загрузки, способов проверки и очистки данных, понятияslowlychangeddimension. Также обязательно знание как минимум одного языка программирования для написания ETL вручную (PL/SQL, T-SQL,pgSQL,Python,Spark), оркестраторов для запуска процессов (например,Airflow), специализированных программ, каккомерческих, так и бесплатных (Talend,InformaticaPowerCenter,Pentaho,etc.).

Для репортеров (DataAnalyticsandVisualization), помимо знания хотя бы 2-х репортинговых программ (PowerBI,Tableau, TIBCOSpotfire,MicroStrategy,Pentaho, ит.д.) необходимо знание различных подходов в создании отчётов идашбордов(например,Storytelling).

А вы сами участвуете в разработке каких-то технологий?

Наши сотрудникиконтрибьютятвApache Spark, NiFi, Elasticsearch и многие другие. Любой сотрудник может принять участие в проекте. Даже врамках нашего обучающего курса, о котором ярассказывал,одно из заданий доработать какую-то фичу или исправить решение в Open Source проекте.

Кроме того,мы разрабатываемисвоиOpenSourceпродукты, например, Open Data Analytics Hub (ODAHU) проект, предоставляющий компоненты для создания систем автоматизации полного жизненного цикла ML моделей.

Какие технологии используются у вас на проектах?

Мы немного по-другому смотрим на то, как долженстроитьсяподход к управлению проектами в Data он основанненавыборетехнологий,ана методологиях. У нас есть несколько шаблонов (blueprint) для решения тех или иных задач. Это решения задач,с которыми мы часто сталкивались на наших проектах, ужепроверенныевременем.Грубо говоря, у нас естьшаблон,который мынаполняемтехнологиямив зависимостиот задач заказчика, от его приоритетов, инфраструктуры.

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

Отличаются ли подходы к проектам в разных отраслях?

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

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

Что изменил 2020 год?

Четкое осознание, что данные нужно уже не только копить, но и заставлять их работать на бизнесу компанийпоявилосьвXXIвеке.И2020 год подтолкнул компании, так называемое позднее большинство (latemajority), которые до этого сомневались вценности использования данных,к изменениямвзглядов и походов.

The diffusion of innovations according to Rogers. (From Wikipedia)The diffusion of innovations according to Rogers. (From Wikipedia)

Про обучение

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

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

Чтобы начать учиться, необходимоиметьжелание,уверенность в будущемData, и умение программировать хотя бы на одном из языковJava,ScalaилиPython.

В тренинг-центре EPAM есть бесплатные курсы для начинающих специалистов, в том числе по направлениям Data Engineering, Data Science, BI, а также Python и другим языкам, которые помогут стартовать в профессии.

Что должен знать идеальный инженер, претендующий на место в команде Data в EPAM?

Выше подробно описан стек технологий. Если кратко, идеальныйDataгерой должен уметь программировать наJava,ScalaилиPython(вообще, большинство ребят полиглоты в терминах языков программирования),знатьSQL, понимать различные подходы к хранению и обработке данных, их плюсы и минусы, знать различные архитектуры построения гетерогенных систем, обязательно знатьDevOps-инструменты и методологии ведения проектов,умениеработать с облачными технологиямиипониманиеMachineLearningтакже приветствуются.

Подробнее..

Тупые и умные компоненты

21.09.2020 00:19:49 | Автор: admin

Меня зовут Илона, я Senior Experience Designer в EPAM. Работа для меня удачно совпадает с хобби в EPAM я проектирую интерфейсы для зарубежных заказчиков, читаю лекции для сотрудников и студентов лабы, менторю дизайнеров. В свободное время преподаю проектирование интерфейсов в магистратуре Университета ИТМО и веду Телеграм-канал о UX-дизайне.
В работе и преподавании я часто сталкиваюсь с проблемой: сложно организовать компоненты интерфейса так, чтобы было всегда понятно, какой компонент использовать, чтобы похожие компоненты не плодились и не путали дизайнеров и разработчиков.

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

Что вообще такое компоненты

Графический интерфейс (GUI), как правило, состоит из кнопок, полей, чекбоксов, текстовых блоков и пр. Именно это мы называемкомпоненты эдакая интерактивная (или нет) обёртка контента:кнопка Оформить заказ; чекбокс Я принимаю условия соглашения и т.д.

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

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

Посмотрим на простом примере

Дизайним карточку товара в интернет-магазине: картинка, информация, цена и кнопка Купить.

А ещё требуется карточка товара для корзины. Там нет кнопки Купить, зато есть кнопка Удалить и селектор количества товара. Звучит как новый компонент. Делаем!

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

И вот у нас уже 3 компонента Карточка.

Карточки во всем своем многообразииКарточки во всем своем многообразии

Теперь мы хотим показать информацию о заказе в личном кабинете. Неплохо смотрелась бы Карточка!
Какую же из трёх использовать? Ни одна толком не подходит. Проще уже сделать новую.


Проходит время, карточки разработаны и живут в разных местах системы.

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

Три группы правок в нескольких местах на макетах и в системеТри группы правок в нескольких местах на макетах и в системе

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

Зачем и как переиспользовать компоненты

Переиспользование компонентов помогает:

  1. облегчить жизнь себе и разработчикам;

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

Во имя переиспользования, по примеру разработчиков React.js, делим компоненты на два типа:тупыеиумные.

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

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

Шаблон карточки и примеры его примененияШаблон карточки и примеры его применения

Пример с карточками сделан в Figma. Тупая карточка Figma-component с применениемAuto Layout.Благодаря этому элементы карточки можно удалять и менять, а её размер подстроится под изменения. Умная карточка Figma-instance.

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

Скругление всех картинок одним движениемСкругление всех картинок одним движением

Тупой UI kit

Простая и понятная библиотека компонентов (UI kit), элементы которой легко переиспользовать и обновлять турбо-ускоритель дизайна и разработки. И состоит такая библиотека из тупых компонентов. Я называю её Тупой UI kit.
Если на вашем проекте уже есть UI kit, попробуйте сделать все компоненты в нём тупыми. Скорее всего, вы с удивлением обнаружите, что многие компоненты можно унифицировать: объединить похожие или удалить повторяющиеся. Отупить UI kit может быть непросто, понадобится время на ревизию системы и сильный дизайн-инструмент.Figmaотлично справляется, но иSketchне отстает.

Тупой UI kit облегчит работу над дизайном, избавив от необходимости плодить компоненты и изобретать велосипед. Разработчики тоже скажут вам спасибо за то, что они могут переиспользовать код компонента.
Тупой UI kit также может стать основой для созданияStorybookпроекта.

Выводы

Разделяя компоненты на умные и не очень, вы:

  1. создаете унифицированный интерфейс;

  2. оптимизируете дизайн и разработку, не выдумывая новые компоненты без необходимости;

  3. оставляете возможность легко вносить изменения в дизайн и код;

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


Больше о проектировании интерфейсов и UX можно почитать в моём телеграм-канале Поясни за UX.

Подробнее..

Эстимирование дизайна

12.01.2021 14:15:46 | Автор: admin

Меня зовут Илона, я Senior Experience Designer в EPAM. Работа для меня удачно совпадает с хоббив EPAM я проектирую интерфейсы для зарубежных заказчиков, читаю лекции для сотрудников и студентов лабы, менторю дизайнеров. В свободное время преподаю проектирование интерфейсов в магистратуре Университета ИТМО и ведуТелеграм-канал о UX-дизайне.

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

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

Проект и дизайн-команда

Проект, на котором мы работаем крупная e-commerce платформа с большой командой (80+ разработчиков, менеджеров, аналитиков, тестировщиков) и быстро меняющимися требованиями. На таком крупном проекте логично образовалась дизайн-команда из 4 ролей:

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

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

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

  • Team Lead, который налаживает процессы и решает оргвопросы, обеспечивает команде комфортные условия работы и также занимается UX-дизайном.

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

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

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

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

  • Каждую идею нужно проверить и утвердить с заказчиком. И не так просто понять, сколько времени это займёт и как результат обсуждения повлияет на работу дизайнера.

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

Вот некоторые цитаты из ретроспектив, которые мы проводили внутри дизайн-команды:

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

Относительная оценка сложности

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

Согласно Scrum, для оценки задач используется абстрактная единица Story point. В одной команде ею могут измеряться часы, в другой дни, в третьей что-то ещё. Кому как удобно.

В нашей команде 1 Story point был равен 4 часам. И нам, по перечисленным ранее причинам, было крайне тяжело оценивать работу в таких Story points. Поэтому я решила наделить Story point другой мерой сложность.

Сложность (complexity) количество усилий, необходимых для выполнения задачи.

В нашем случае оценка сложности в Story points оказалась гораздо эффективнее, чем оценка часов, потому что:

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

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

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

  • Исключаются обсуждения в формате Я бы сделал эту работу быстрее.

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

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

Параметры сложности

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

  1. Зависимости от других людей

  2. Навыки дизайнера

  3. Количество коммуникации в рамках задачи

  4. Согласованность нового дизайн-решения с уже существующими

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

Для каждого параметра я подобрала шкалы от 1 до 4. Например, оценка параметра Зависимость (Dependency) выглядит так:

1 (нет сложности) никто кроме дизайнера не вовлечён в работу, нет зависимости от других людей;

2 (низкая сложность) 1 человек вовлечён и немного работы с стороны;

3 (средняя сложность) 2-3 человека и/или много работы со стороны;

4 (высокая сложность) более 3 человек и/или невозможно определить количество работы со стороны.

Подробные шкалы по всем четырём параметрам сложности можно найти в моём докладе для конференции Design Z Day:

Как понять, что сложно, а что нет

Всё познается в сравнении.

Если время можно определить конкретно (например, два часа), то с оценкой сложности возникают проблемы. Что значит сложно? Где грань между сложно и очень сложно?

Секрет относительная оценка. Задачи оцениваются не в вакууме, а относительно друг друга, в сравнении.

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

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

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

Как наша команда начала использовать относительную оценку сложности

Нам было сложно перестроиться с абсолютной оценки часов на относительную оценку сложности.

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

Из прошлого спринта, который мы оценивали в часах, взяли 3 задачи. Мы их уже выполнили, поэтому всё про них знали. Для каждой задачи мы последовательно прошлись по 4 параметрам сложности (зависимости, навыки, коммуникация, согласованность) и дали новые оценки в относительных Story Points. Это было непросто, мы долго обсуждали каждую оценку и приходили к единой цифре. Вот что у нас получилось:

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

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

Результаты перехода на относительную оценку сложности

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

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

Важные результаты для нашей дизайн-команды:

  • прозрачность задач;

  • более точные оценки с меньшими усилиями;

  • команда дизайнеров понимает, что мы должны знать перед выполнением задачи;

  • лучшая декомпозиция задач;

  • учитывается вся работа, включая согласования, генерацию идей и обсуждения;

  • мы постоянно сравниваем задачи и видим общую картину.

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


Больше о проектировании интерфейсов и UX можно почитать в моём телеграм-канале Поясни за UX.

Подробнее..

Визуализация данных в интерфейсе

09.04.2021 20:23:06 | Автор: admin

Меня зовут Илона, я Senior Experience Designer в EPAM. Я проектирую сложные интерфейсы для зарубежных заказчиков, выступаю с докладами, менторю дизайнеров. В свободное время преподаю проектирование интерфейсов в магистратуре Университета ИТМО и ведуТелеграм-канал о UX-дизайне.

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


Множественные данные, которые, в принципе, можно считать Big Data, представляют из себя набор информации (цифры, процентные соотношения, статусы, параметры, текст и пр.), на основании которой пользователь может делать определённые выводы.

Любимые дизайнерамидашбордырезультат визуализации таких данных.

Dashboard by Ghulam RasoolDashboard by Ghulam Rasool

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

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

В первую очередь вам понадобятся знания основ инфографики.

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

Инфографика зародилась в 18 веке с изобретением столбчатой, линейной и круговой диаграмм шотландским экономистом по имени Уильям Плейфей, которые он опубликовал в книгеCommercial and Political Atlas and Statistical Breviary.Его, по моему скромному мнению, гениальные наработки послужили базисом визуализации данных и до сих пор активно используются для отображения информации.

Первая столбчатая диаграмма за авторством Уильяма Плейфея, 1781Первая столбчатая диаграмма за авторством Уильяма Плейфея, 1781

Большое влияние на современную визуализацию данных оказал профессор Йельского университетаЭдвард Тафти, написавший несколько книг об отображении информации, в том числеThe Visual Display of Quantitative Information.Книга содержит множество примеров и я крайне рекоммендую её к прочтению, для расширения кругозора.

Книги Э. Тафти о данныхКниги Э. Тафти о данных

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

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

Косметическое украшение никогда не компенсирует ошибки отображения данных, зато может их исказить.
Э. Тафти

Иллюстрация из книги Э. ТафтиИллюстрация из книги Э. Тафти

Способы визуализации информации

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

  1. Точка индикатор положения данных. Может находиться на оси графика, точке окружности и т.д.

  2. Линия соединяет две точки и отображает тенденцию изменения данных.

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

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

На основе этих простых элементов можно построить множество визуализаций. Перечислю лишь основные и самые распространённые типы в зависимости от целей отображения.

Инструменты визуализации

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

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

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

  • Вертикальная (столбчатая), горизонтальная диаграмма/гистограмма сравнение значений. Могут быть сгруппированными и сегментированными. Горизонтальный вариант лучше в случае длинных заголовков.
    Примеры применения: сравнение количества продаж разных товаров по месяцам, сравнение количества сотрудников разного уровня в компании, сравнение количества посетителей на разных сайтах.

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

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

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

  • Временной график линейное отображение событий.
    Примеры применения: отображение опыта работы, план выполнения проекта.

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

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

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

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

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

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

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

  • Блок-схема, дорожки бассейна визуализация процесса.
    Примеры применения: сценарий работы устройств на конвейере, процесс взаимодействия разных департаментов во время работы над проектом.

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

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

Проектирование интерфейса

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

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

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

Анализ актуального состояния

Анализом актуального состояния занимаются, к примеру, сотрудники АЭС, производства, аэропорта, тот самый админ в серверной.

Дашборд для анализа актуального состояния нагрузки порта Хобокен, Нью-ДжерсиДашборд для анализа актуального состояния нагрузки порта Хобокен, Нью-Джерси

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

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

Приложение мониторинга на производстве от devvelaПриложение мониторинга на производстве от devvela

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

Анализ статистики

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

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

Дашборд состатистики продажДашборд состатистики продаж

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

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

  1. Начните проектирование с анализа потребностей пользователя. Определите цель пользователя и какую информацию он анализирует: актуальную или статистическую.

  2. Подберите способ визуализации данных исходя из того, что пользователь хочет оценить (сравнить объём данных, соотношение, увидеть иерархию и т.д.).

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

  4. Группируйте разные данные в отдельные блоки.

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

  6. Не перегружайте один экран множеством разнородных блоков данных. Человек не очень хорошо справляется с объемом более 57 блоков.

  7. Используйте понятные заголовкидля всехданных и графиков.

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

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

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

Не очень позитивный, но актуальный и информативный пример дашборда от Johns HopkinsНе очень позитивный, но актуальный и информативный пример дашборда от Johns Hopkins

Больше о проектировании интерфейсов и UX можно почитать в моём телеграм-канале Поясни за UX.

Подробнее..

Compose. Jetpack Compose

09.10.2020 12:10:51 | Автор: admin
image

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

Пожалуй, главным трендом мобильной разработки за последние несколько лет стал декларативный UI. Такое решение уже давно успешно применяется в веб и кроссплатформенных решениях и, наконец, добралось и до нативной разработки. На iOS существует SwiftUI (представленный на WWDC 2019), а на Android Jetpack Compose (представленный месяцем ранее на Google I/O 2019). И именно о последнем мы сегодня и поговорим.

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

Появление


Официальная история Jetpack Compose начинается с мая 2019, когда он был представлен публике на конференции Google I/O. Простой, реактивный и Kotlin-only новый декларативный фреймворк от Google выглядел как младший брат Flutter (который к тому моменту уже стремительно набирал популярность).

API design is building future regret

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

Преимущества


Итак, чем же хорош Jetpack Compose и, главное, чем он кардинально отличается от существующего на данный момент UI-фреймворка Android?

  • Unbundled toolkit: JC не зависит от конкретных релизов платформы, а значит, забудем уже про Support Library.
  • Kotlin-only: Больше не нужно переключаться между классами и xml-файлами вся работа с UI происходит в одном Kotlin-файле.
  • Композитный подход: Наследованию нет, композиции да. Каждый UI-компонент представляет собой обычную composable-функцию, отвечающую только за ограниченный функционал, т.е. без лишней логики. Никаких больше View.java на 30 тысяч строк кода.
  • Unidirectional Data Flow: Одна из основополагающих концепций Jetpack Compose, о которой будет рассказано подробнее чуть ниже.
  • Обратная совместимость: Для использования Compose не требуется начинать проект с нуля. Имеется возможность как его встраивания (с помощью ComposeView) в имеющуюся xml-вёрстку, так и наоборот.
  • Меньше кода: Тут, как говорится, лучше один раз увидеть, чем сто раз услышать. В качестве примера возьмём классическое сочетание компонентов два поля ввода и кнопка подтверждения:

В реализации текущего UI-фреймворка вёрстка этих компонентов выглядит так:

<?xml version="1.0" encoding="utf-8"?><LinearLayout xmlns:android="http://personeltest.ru/away/schemas.android.com/apk/res/android"    android:layout_width="match_parent"    android:layout_height="wrap_content"    xmlns:app="http://personeltest.ru/away/schemas.android.com/apk/res-auto"    android:orientation="vertical"    android:padding="@dimen/padding_16dp">    <com.google.android.material.textfield.TextInputLayout        android:id="@+id/til_login"        android:layout_width="match_parent"        android:layout_height="wrap_content"        style="@style/Widget.MaterialComponents.TextInputLayout.OutlinedBox"        android:hint="@string/sign_in_email"        android:layout_marginBottom="@dimen/margin_8dp">        <com.google.android.material.textfield.TextInputEditText            android:id="@+id/et_login"            android:layout_width="match_parent"            android:layout_height="wrap_content"            android:inputType="text"/>    </com.google.android.material.textfield.TextInputLayout>    <com.google.android.material.textfield.TextInputLayout        android:id="@+id/til_password"        android:layout_width="match_parent"        android:layout_height="wrap_content"        style="@style/Widget.MaterialComponents.TextInputLayout.OutlinedBox"        android:hint="@string/sign_in_password"        android:layout_marginVertical="@dimen/margin_8dp">        <com.google.android.material.textfield.TextInputEditText            android:id="@+id/et_password"            android:layout_width="match_parent"            android:layout_height="wrap_content"            android:inputType="textPassword"/>    </com.google.android.material.textfield.TextInputLayout>    <Button        android:id="@+id/btn_confirm"        android:layout_width="match_parent"        android:layout_height="wrap_content"        android:text="@string/sign_in_submit"        android:layout_marginTop="@dimen/margin_8dp"        android:padding="@dimen/padding_8dp"        android:background="@color/purple_700"/></LinearLayout>

В то же время, при использовании Jetpack Compose, решение будет выглядеть следующим образом:

@Preview@Composablefun LoginPage(){    var loginValue by remember { mutableStateOf(TextFieldValue("")) }    var passwordValue by remember { mutableStateOf(TextFieldValue("")) }    Surface(color = Color.White) {        Column(modifier = Modifier.padding(16.dp).fillMaxWidth()) {            Surface(color = Color.White, modifier = Modifier.padding( vertical = dimensionResource(id = R.dimen.padding_8dp))) {                OutlinedTextField(                        value = loginValue,                        onValueChange = { loginValue = it },                        label = { Text(text = stringResource(id = R.string.sign_in_email)) },                        placeholder = { Text(text = stringResource(id = R.string.sign_in_email)) },                        modifier = Modifier.fillMaxWidth()                )            }            Surface(color = Color.White, modifier = Modifier.padding( vertical = dimensionResource(id = R.dimen.padding_8dp))) {                OutlinedTextField(                        value = passwordValue,                        onValueChange = { passwordValue = it },                        label = { Text(text = stringResource(id = R.string.sign_in_password)) },                        placeholder = { Text(text = stringResource(id = R.string.sign_in_password)) },                        visualTransformation = PasswordVisualTransformation(),                        modifier = Modifier.fillMaxWidth()                )            }            Button(                    onClick = {},                    modifier = Modifier.padding( vertical = dimensionResource(id = R.dimen.padding_8dp)).fillMaxWidth(),                    backgroundColor = colorResource(R.color.purple_700)) {                Text(text = stringResource(id = R.string.sign_in_submit), modifier = Modifier.padding(8.dp))            }        }    }}

Ну и напоследок сравнительный результат:

image

Недостатки


  • Alpha-версия: Безусловно, более чем за год разработки фреймворк значительно преобразился и стал гораздо стабильнее. Однако это всё ещё альфа, а поэтому за пределами Pet-проектов использовать его не рекомендуется.

Декларативный стиль


Отдельное внимание стоит уделить главной особенности Jetpack Compose декларативному стилю создания UI. Суть подхода заключается в описании интерфейса как совокупности composable-функций (они же виджеты), которые не используют под капотом view, а напрямую занимаются отрисовкой на canvas. Для кого-то это минус, для других возможность попробовать что-то новое. Так или иначе, к концепции верстать UI кодом нативному разработчику, не работавшему ранее с аналогичными технологиями (к примеру, Flutter или React Native), придётся привыкать.

Что за Unidirectional Data Flow?


В современном android-приложении UI-состояние меняется в зависимости от приходящих событий (нажатие на кнопку, переворот экрана и т.д.). Мы нажимаем на компонент, тем самым формируя событие, а компонент меняет свой state и вызывает callback в ответ. Из-за довольно тесной связи UI-состояния с View это потенциально может привести к усложнению поддержки и тестирования такого кода. К примеру, возможна ситуация, когда помимо внутреннего state компонента, мы можем хранить его состояние в поле (например во viewmodel), что теоретически может привести к бесконечному циклу обновления этого самого state.

Что же касается Jetpack Compose, то здесь все компоненты по умолчанию являются stateless. Благодаря принципу однонаправленности нам достаточно скормить модель данных, а любое изменение состояния фреймворк обработает за нас. Таким образом, логика компонента упрощается, а инкапсуляция состояния позволяет избежать ошибок, связанных с его частичным обновлением. В качестве примера возьмем уже рассмотренный ранее composable-код. Перед описание компонентов были определены две переменные:

    var loginValue by remember { mutableStateOf(TextFieldValue("")) }    var passwordValue by remember { mutableStateOf(TextFieldValue("")) }

Мы создаем два текстовых объекта, значения которых будем устанавливать полям ввода (логина и пароля) в качестве value. А благодаря связке remember { mutableStateOf() } любое изменение значений этих объектов (из других частей кода) уведомит об этом соответствующее поле ввода, которое перерисует только значение value, вместо полной рекомпозиции всего компонента.

Вывод


Какой же вывод можно сделать о Jetpack Compose? По моему мнению, у нового решения от Google имеется огромный потенциал. С момента анонса в 2019 году была проделана огромная работа, и не менее долгий путь до релиза у фреймворка ещё впереди. Однако теперь он публично доступен, и я считаю, что это прекрасная возможность познакомиться с ним поближе. Ну а за чем, по вашему мнению, будущее пишите в комментарии, будет интересно узнать ваше мнение. Любите android!
Подробнее..

Использование code-style плагинаktlintвKotlinпроекте. Краткая инструкция дляbackend-разработчика

02.03.2021 18:23:53 | Автор: admin

Я работаюJava/Kotlin-разработчиком в компании EPAM.

В первой статье ярассказывала про свой проект Brain-Up.

В этой статье хочу поделиться опытом настройки плагина ktlint для Kotlin проекта.

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

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

Потому решилаподелиться свои опытом,надеюсь кому-то будет полезнапошаговая инструкция подключения к проекту.Этотпример актуален для проекта наKotlin1.4,gradle6.0.

#1. Добавление зависимости в build.gradle на плагин

dependencies {        ktlint "com.pinterest:ktlint:0.38.0"}

#2. Добавление gradle таски `ktlintFormat`

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

task ktlintFormat(type: JavaExec, group: "formatting") {    description = "Fix Kotlin code style deviations."        classpath = configurations.ktlint        main = "com.pinterest.ktlint.Main"        args "-F", "src/*/.kt"}

#3. Конфигурирование gradle таски `ktlint` для вашего проекта

project.task("ktlint", type: JavaExec) {        group = "verification"        description = "Runs ktlint."        main = "com.pinterest.ktlint.Main"        classpath = project.configurations.ktlint        args = [                    "--reporter=plain",                    "--reporter=checkstyle,output=${project.buildDir}/reports/ktlint/ktlint-checkstyle-report.xml",                    "src/*/.kt"    ]}

#4. Встраивание таски `ktlint` в процесс сборки приложения

compileKotlin.dependsOn ktlint

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

Если возникаетошибкаформатирования, то мыувидим примерно такое сообщение, из которого понятно,что и где не так.

Правим форматирование.

#5. Настройка параметров Idea для правильного форматирования

Это можно настроить здесь File -> Settings -> Code Style -> Kotlin.

#6. Форматирование текущего класса

Первый способ.

Мне удобно при работе с классом сразу по окончании нажатьCtrl+Alt+L,и класс автоматически отформатируется согласно установленным вIdeaсвойствам форматирования. Если выделить мышкой папочку в проекте и нажать на ней данную комбинацию, то отформатируются все классы в этой папочке согласно настройкамIdea, которые мы задали выше.

Второй способ.

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

#7. Выключение правил

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

Например,мы в проекте отказались от правила необходимости импортов быть отсортированными в лексикографическом порядке. То есть правило может это и не плохое,оно, кстати,недавно в плагине появилось, только вотCtrl+Alt+Lимпорты не группирует и таска ихktlintFormatтоже, а делать это каждый раз руками надоедает.

[*.{kt,kts}]disabled_rules = import-ordering

Резюме

Таквыглядитвbuild.gradleдобавление плагина в итоге у нас на проекте. Работаем с ним 2-й год, всё стабильно пока.

Если у вас есть свои идеи,опыт, как улучшить / решить задачу единого code style на Kotlin проекте,пишите в комментариях, будет интересно узнать:какими вы пользуетесь плагинами, насколько они удобны, стабильны к обновлениям языка и быстро настраиваемы.

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

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

Всем удачи!

Подробнее..

Кому рецепты для электронной коммерции? Для SAP Commerce и не только

12.08.2020 08:15:24 | Автор: admin
Моё хобби автоматизация онлайн-ритейла. Уже много лет даже всвои выходные яневылажу изэтого болота. Да, наверное, это звучит дико идаже смешно. Как можно увлекаться таким скучным делом? скажут одни. Что там увлекаться, это просто какая-то частная тема для уважающего себя архитектора ПО! скажут другие.

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

Ивот с2016я веду техноблог, hybrismart.com. Такая хабра вминиатюре, только наанглийском исфокусом наблизкую мне тему разработку наSAP Commerce. Унас тут сформировалась небольшая компания изнескольких десятков тысяч авторов, нонаблог пока что пишут только часть изних. Ну, хорошо, пишут пока немногие. Десяток. Номыстараемся. Наблоге уже накопилось под две сотни статей, преимущественно больших иочень больших насамые разные темы, тем или иным боком относящиеся кecom. Всущественной части это все-таки персональный блог, поэтому отдуваюсь тутя, аненаша пиар-служба. Ноэто отдуши, правда.

Как легко догадаться изназвания, hybrismart про хайбрис. Ипочти все, кто его находит, знают охайбрисе непонаслышке. Нуинаоборот: наверное, каждый разработчик наhybris хотябы раз наблог заходил (Конечно, неподоброй воли, нам гугл помогает!). Теперь вот ивызашли. Ичтобы вытам непотерялись, хочу провести небольшую экскурсию. Задавайте, пожалуйста, вопросы всамом конце.



ЖАЖДА ПОИСКА



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

Пожалуй, это самый жирный топик намоем блоге. Вхайбрисе запоиск отвечает Apache Solr, один издвух крупных иповсеместно известных опенсорсных движков (вместе сElasticSearch). Нокак выпонимаете, специфики хайбриса встатьях про поиск минимум.

Rauf Aliev, Timofey Klyubin
The Challenges OfChinese And Japanese Searching
https://hybrismart.com/2019/08/18/the-challenges-of-chinese-and-japanese-searching/

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

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

Rauf Aliev
Facet Search: The Most Comprehensive Guide. Best Practices, Design Patterns, Hidden Caveats, And Workarounds.
https://hybrismart.com/2019/02/13/facet-search-the-most-comprehensible-guide-best-practices-design-patterns/

Аэта работа относится кфасетному поиску. Очень много букв, ноесть содержание сссылками. Былобы концептуально сделать фасетный поиск постатье пофасетному поиску, ноясебя остановил. Встатье предпринята попытка систематизировать знания иопыт вэтой области иорганизовать эти знания ввиде одной большой простыни сфактами, ссылками, иbest practices. Наверное, эта статья должна быть полезна тем, кто породу работы связан спользовательскими интерфейсами.

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



Rauf Aliev
Autocomplete, Live Search Suggestions, and Autocorrection: Best Practice Design Patterns
https://hybrismart.com/2019/01/08/autocomplete-live-search-suggestions-autocorrection-best-practice-design-patterns/

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

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



Rauf Aliev
Search Analytics
https://hybrismart.com/2017/10/06/part2-sap-hybris-thinking-outside-the-box-part-2-of-4-video-russian-english-search-analytics/

Некоторые материалы представлены наблоге неввиде статей, аввиде видеозаписей. Ксожалению, такой формат пока еще неприжился. Здесь ярассказываю про Search Analytics механизму сбора иобработки статистики, имеющей отношение кдействиям покупателей свовлечением поиска потоварам. Япридумал этот механизм для большого продуктового магазина вЕвропе, иперепроверил его еще раз для той самой байотек-компании изпредыдущего примера. Вкратце, идея сводится ктому, что действия покупателей могут много рассказать прото, как работает поиск, игде унего слабые места. Например, статистика показывает, что некоторые товары ищут часто, нокладут вкорзину редко (высокая цена? Устаревшие модели?), адругие кладут часто, нодовольно плохо ищут (подсказки?), азатретьими готовы прокликивать несколько страниц результатов поиска (какие-то нерелевантные товары вылезают вперед?). Вобщем, это такой Google Analytics, нодля поиска.

Rauf Aliev
Multi-line Search
https://hybrismart.com/2017/04/07/multi-line-product-search-for-bulk-orders/

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



Rauf Aliev
Product Image Visual Search
https://hybrismart.com/2018/08/26/product-image-visual-search-in-sap-commerce-cloud-hybris-commerce/

Вэтой статье яописываю поиск похожих товаров поцвету или форме. Это довольно классическая тема, нонапрактике, понепонятной мне причине, редко реализуемая. Ясделал прототип, иописал матчасть. Практически все статьи подобного характера сопровождаются видео, как работает прототип сSAP Commerce, иэта неисключение. Для интеграции сApache Solr яиспользовал Lire (http://personeltest.ru/aways/github.com/dermotte/lire).



Rauf Aliev
More Like This InSOLR
https://hybrismart.com/2017/02/05/more-like-this-in-hybris-solr-search/

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



Rauf Aliev
Concept Aware Search: Automatic Facet Discovery
hybrismart.com/2017/06/25/concept-aware-search-automatic-facet-discovery-in-hybris

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

Rauf Aliev
Enhanced Multi-Word Synonyms and Phrase Search
https://hybrismart.com/2017/08/09/enhanced-multi-word-synonyms-and-phrase-search/

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

Наблоге есть еще пара десятков статей натему поиска. Анаэтом прекрасном месте тема поиска уступает теме расчета акций искидок ипрочей лояльности.

АКЦИИ ПОПРАВИЛАМ



Купи два пуховика поцене трех иполучи один вподарок!. Что только маркетологи непридумают, чтобы программисты нескучали. Делаешь полгода совершенный движок акций, который умеет вообще всё иеще немножко, итут приходит менеджер сочередной идеей, из-за которой нужно переписывать половину! ВХайбрисе тоже было два поколения таких движков. Разработчики решили неизобретать велосипед ииспользовали JBoss Drools, довольно мощную систему управления бизнес-правилами, которая интегрирована вхайбрис для темы акционных механик, темы узкой, норазнообразной всвоей узости.



Если вдвух словах, тоDrools это среда выполнения бизнес-правил. Механизм обрабатывает так называемые факты входные данные, ивыдает результат врезультате обработки правил ифактов. ВХайбрисе для Drools сделали интерактивный редактор правил втерминах e-commerce, атакже представили API для расширения.

Rauf Aliev
Could Have Fired
https://hybrismart.com/2016/06/04/hybris-6-could-have-fired-messages-poc/

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



Rauf Aliev
Distributed promotion calculation inthe cluster. Promo asaservice
https://hybrismart.com/2016/07/05/distributed-promotion-calculation-cluster-promo-as-a-service/

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



Rauf Aliev
Using hybris rule engine for product recommendations
https://hybrismart.com/2016/08/09/using-hybris-rule-engine-for-product-recommendations/

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



Rauf Aliev
Complex Realtime Event Processing with Drools Fusion
https://hybrismart.com/2016/10/17/complex-realtime-event-processing-with-drools-fusion-integrating-with-hybris/

Нураз яуже построил этот кластер, янемог его недомучить ипостроить наего основе штуку, которая обрабатывалабы события налету, накладывая наних натомже лету правила. Мне удалось разобраться иподключить Drools Fusion + Drools Server последней версии кhybris. Эта штука правильно называется Complex Event Processing. Смысл втом, что если увас есть поток каких-либо данных для обработки вреальном времени, Drools Fusion позволяет делать это быстро игибко. Например, вслучае екоммерса таких данных много. Самые простые это клики ипереходы

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



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



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

Rauf Aliev
Reactive Rule-based Dynamic Forms
https://hybrismart.com/2018/01/04/reactive-rule-based-dynamic-forms-in-hybris-using-drools-7/

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



Чтобы плавно закончить тему сDrools иначать тему про всякое разное векоммерсе ихайбрисе, япредставлю еще подробный обзор акционных механик

Rauf Aliev
Promotion Mechanics and Their Implementation inHybris
https://hybrismart.com/2017/04/30/promotion-mechanics-and-their-implementation-in-hybris-6-x/

Замечаете, почти все темы несовсем ипро Хайбрис. Там везде онкаким-то боком есть, новцелом екоммерс это невещь всебе. Все связано совсем.

Конечно, насайте есть еще десятки материалов, которые довольно сложно понять тем, кто вообще неразбирался сХайбрисом.

Rauf Aliev
Merging Carts When ACustomer Logs In: Problems, Solutions, and Recommendations
https://hybrismart.com/2019/02/24/merging-carts-when-a-customer-logs-in-problems-solutions-and-recommendations/

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



Rauf Aliev
Hybris Impex Preprocessor
https://hybrismart.com/2018/05/27/hybris-impex-preprocessor-impex/

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

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

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

Rauf Aliev
Payments: Alook Inside the Black Box
https://hybrismart.com/2019/09/08/payments-a-look-inside-the-black-box/

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



Rauf Aliev
Server-side PDF document generation
https://hybrismart.com/2017/06/15/pdf-and-sap-hybris/

Аещё раньше, вовремена зачеток ипейджеров, яработал дизайнером иверстальщиком (впрочем, вколоменском педуниверситете ипейджинговой компании Мобилтелеком ятоже работал. Да, яуже старый). Нетем верстальщиком, который HTML, атем, который про книжки ижурналы, аиногда даже православные газеты, телепрограммы иноты. И, конечно, янемог обойти стороной тему Postscript иPDF, которые пугают очень многих из-за туманных иплохо документированных внутренностей. Встатье япоказываю, что нетак страшен черт, иделаю обзор инструментов под генерацию PDF.



Rauf Aliev
Authentication with Hardware Security Keys via Webauthn inSAP Commerce Cloud
https://hybrismart.com/2019/05/23/authentication-with-hardware-security-keys-via-webauthn-in-sap-commerce-cloud/

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



Rauf Aliev
Geofencing: Custom Shipping Zones
https://hybrismart.com/2016/10/19/geofencing-in-hybris-custom-shipping-zones/

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

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

Заодно разобрался сразработкой наGoogle AppEngine. Дело втом, что определение многоугольника (зоны), вкоторый входит точка накарте (где покупатель), для ситуации много зон сложной формы потенциально может быть довольно тяжелой вычислительной задачей. Иесли есть возможность, еелучше сразу делать накластере, который может легко масштабироваться, алучше еще исам. Ивот этот кейс отличный для Google AppEngine, где задействован Google DataStore для хранения параметров многоугольников, иGoogle Memcache для хранения кэша.

Rauf Aliev
Page Fragment Caching: Custom, with Varnish, Nginx, Memcached
https://hybrismart.com/2016/07/24/page-fragment-caching-for-hybris/
https://hybrismart.com/2016/07/27/varnish/
https://hybrismart.com/2016/07/30/hybris-page-fragment-caching-with-nginx-and-memcached/

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

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

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

Rauf Aliev
Best Practices: Migrating Content ToHybris
https://hybrismart.com/2017/01/10/best-practices-migrating-content-to-hybris/

Migrating Data with Pentaho ETL (Kettle)
https://hybrismart.com/2017/01/15/migrating-data-with-pentaho-etl-kettle/

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

Также наблоге есть довольно подробно разобранные темы счат-ботами (Facebook, Skype, кастом), вынесение хранения сессий запределы хайбриса вотдельный сервис, разбор всего, что касается аутентификации илогин-форм, разбор особенностей реализации тревел-сервисов (заказ билетов, отели) часть 1ичасть2, атакже собранные best practices поинтеграции поproduct availability свнешними системами, икакие сложности этот процесс имеет.

Какие еще темы выбы хотели видеть разобранными подобным образом? Поконцепции блога они должны иметь отношение кecommerce. Буду рад любым отзывам ипредложениям.
Подробнее..

Рекомендательные системы, основанные на графах

06.11.2020 14:12:14 | Автор: admin
Всем привет! Меня зовут Александра Зенченко, я Lead Software Engineer в ЕРАМ. Занимаюсь разработкой решений, которые помогают нашим клиентам повышать эффективность работы и, в основном, включают в себя часть машинного обучения. В последнем проекте я работала над построением рекомендательной системы в сфере логистики. Хочу поделиться своим опытом и рассказать, как при помощи алгоритмов помочь довезти груз из Мюнхена в Женеву.

image

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


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

Что нам дано?


Я работала на проекте для крупной мировой компании, которая предоставляет своим клиентам SaaS-решение обмена грузами или freight exchange платформу.

Звучит непонятно, а как происходит на деле: с одной стороны, на платформе зарегистрированы пользователи, у которых есть грузы и которым нужно их куда-то отправить. Они размещают заявку по типу Есть партия декоративной косметики, ее нужно отвезти завтра из Амстердама в Антверпен и ждут ответ. С другой стороны, у нас есть люди или компании с грузовиками грузоперевозчики. Допустим, они уже совершили свой стандартный еженедельный рейс, доставив йогурты из Парижа в Брюссель. Им нужно возвращаться и, чтобы не ехать с пустым грузовиком, найти какой-то груз для перевозки по дороге назад. Для этого грузоперевозчики заходят на платформу моего заказчика и выполняют серчи (от англ. search), указывая направление и, возможно, тип груза (или фрейта, от англ. freight), походящий грузовику. Система собирает заявки от грузоотправителей и показывает их грузоперевозчикам.

image

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

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

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

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

Как гадать будем?


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

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

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

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

image

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

Пробы алгоритмов


Как известно, стратегии создания рекомендательных систем, в основном, делят по фильтрации на основе содержания (сontent-based) и коллаборативной фильтрации (сollaborative filtering). На этой классификации я и стала строить варианты решений.

image
Картинку взяла с hub.forklog.com

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

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

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

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

Знакомьтесь, PageRank


Так я обратила внимание на алгоритм PageRank, созданный когда-то основателями Google Сергеем Брином и Ларри Пейджем, который по сей день используется этой поисковой системой для рекомендаций сайтов пользователям. PageRank представляет все интернет-пространство в виде графа, где каждая веб-страничка является его узлом. С его помощью можно рассчитать важность (или rank) для каждого узла. PageRank принципиально отличается от алгоритмов поиска, существовавших до него, так как основывается не на содержании страниц, а на ссылках, которые находятся внутри них. То есть rank каждой страницы зависит от количества и качества ссылок, указывающих на нее. Брин и Пейдж доказали сходимость этого алгоритма, а значит мы всегда можем рассчитать rank любого узла направленного графа и придем к значениям, которые не будут меняться.

Посмотрим на его формулу:

image

  • PR(P) rank конкретной страницы
  • N количество страниц
  • i остальные страницы
  • O количество исходящих ссылок
  • d понижающий фактор. Когда пользователь ищет что-то, в определенный момент он останавливается, перестает переходить по ссылкам со страницы на страницу и начинает поиск чего-то другого. Понижающий фактор говорит нам о том моменте, когда произойдет переход к новому поиску. 0 d 1 обычно d равен 0,85. В нашей модели я сохранила это значение.

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

image

Можно увидеть, что самым важным здесь стал узел А вопреки тому, что на него, как и на С, указывают всего лишь два узла. Но rank узлов, указывающих на А, больше, чем у узлов, ведущих к С.

Предположения и решение


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

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

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

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

Результат


image

Все реализовано на платформе Google. У нас есть OLTP-приложение, откуда идут данные о запросах и поступают в BigQuery, где формируются дополнительные представления и таблицы, содержащие уже обработанную информацию. Для ускорения и параллелизации обработки больших объемов данных использовалась библиотека DASK. В нашем решении все данные переносятся в Cloud Storage, потому что DASK работает только со ним и не взаимодействует с BigQuery. В Kubernetes были созданы две Job, одна из которых переносит данные из BigQuery в Cloud Storage, а вторая делает рекомендации. Это происходит так: Job берет данные о парах серчей из Cloud Storage, обрабатывает, формирует рекомендации на предстоящий день и отправляет их назад в BigQuery. Оттуда, уже в формате .json, мы можем передавать рекомендации на OLTP-приложение, где их будут видеть пользователи. Точность рекомендаций оценивается в Tableau, где сравниваются наши рекомендации и то, что потом реально искал пользователь, а еще его реакция (понравилось или нет).

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

image

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

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

image

Замечу, что у пользователя 2 графа с разными весами. В одном точность достигала 38%, а значит где-то 3 из 8 вариантов, рекомендованных нами, оказались релевантными. И, возможно, если мы найдем грузы на этих направлениях, то пользователь их и выберет.

Последний и самый простой пример. Человек каждый день делает примерно 2 поиска. У него очень устойчивые паттерны, не слишком много предпочтений и простой граф. Точность наших предсказаний в результате 100%.

image

Performance в фактах


  • Наши алгоритмы работают на 4 стандартных CPU и 10 GB памяти.
  • Объемы данных составляет до 1 миллиарда записей.
  • Создание рекомендаций для всех пользователей, которых около 20 000, занимает 18 минут.
  • Библиотека DASK используется для параллелизации, а библиотека NetworkX для алгоритма PageRank.

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

Перевод Документирование архитектуры введение

03.08.2020 14:12:05 | Автор: admin

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


Как вы рисуете диаграммы для вашего ПО? На какие вопросы они должны ответить? Зачем рисовать что-либо вообще? Давайте разберёмся.



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


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

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



Photo by ThisisEngineering RAEng / Unsplash


РАССМОТРИМ ПРИМЕР


Любое ПО довольно сложное. И первое, что можно сделать, чтобы задокументировать его попытаться нарисовать какую-то диаграмму, которая бы включала всё. Конечно, эта попытка сразу бы провалилась. Представьте, что мы хотим задокументировать какое-то относительно простое решение, скажем, мой блог. Он работает на Ghost CMS, данные хранятся в базе данных MySQL; в качестве веб-сервера используется Apache. Запросы обрабатываются веб-сервером, все запросы перенаправляются с http на https и отправляются в CMS. CMS проверяет токены и запрашивает содержимое базы данных, включая страницы, сообщения в блогах и плагины. Все три компонента работают в виртуальной машине в GCP в сети по умолчанию в отдельной организации. Система доступна читателям, контент-менеджерам, которые могут добавлять новый контент и редактировать текущий. Системные администраторы могут изменять систему через облачную консоль. Если включить всю эту информацию в одну диаграмму, вот что получится:



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


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

Я хотел поговорить о представлениях архитектуры (views) и точках зрения(viewpoints), как это описано в книге "Документировании архитектуры программного обеспечения" SEI, но это слишком академичный подход. Поэтому сокращу свою мысль до следующих утверждений:


  1. Вы не можете разместить всю информацию на одном изображении.
  2. Более того, вы не должны этого делать.
  3. Вместо этого вы предоставляете набор картинок, чтобы каждая из них идеально подходила для конкретного стейкхолдера, человека, заинтересованного в вашем проекте.
    Есть несколько подходов к этому (Модули-Компоненты и Разъёмы-Распределения, Подход C4 и т. д.), Неважно, что вы выберете. Главное, чтобы один человек одновременно получал максимум информации за минимальный период времени.

РАЗДЕЛИТЕ ПРОБЛЕМ


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


И у каждого свои запросы:



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


С кем взаимодействует система?



Эта диаграмма называется контекстной диаграммой (Context Diagram, по модели C4), которая показывает именно то, с какими агентами общается система. Здесь есть блок "Аналитика". Я забыл о ней, когда рисовал первую диаграмму, но, глядя на определённый уровень, можно сосредоточиться на определённых аспектах и ничего не пропустить.


Как и где система развернута?



Deployment Diagram


На этой диаграмме видно, что решение развернуто на облачной платформе Google, на одной виртуальной машине в одной сети в пределах одного региона, доступ защищен облачным IAM. В основном она отвечает на вопрос, сколько денег примерно стоит решение (20-30 долларов в месяц в зависимости от региона и размера виртуальной машины), видно, что оно плохо масштабируется и требует перепроектирования в случае резкого увеличения нагрузки. Кроме того, нет резервной копии БД.
Но эта диаграмма не показывает, какие компоненты развернуты на виртуальной машине, для этого нужна другая.
Таким образом, мы фокусируемся на определённых аспектах одновременно. Согласитесь, так гораздо легче понять информацию.


Какова функциональность системы?



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


РЕЗЮМЕ


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

Подробнее..

Выжать максимум Cloud Composer как fully-managed решение для Airflow

29.01.2021 14:10:10 | Автор: admin

Привет,Хабр! Меня зовут Сергей, яLeadSoftwareEngineer/SreamLeadв ЕРАМ,сертифицированныйGoogleCloudинженер и архитектор. Уже более 10лет занимаюсь коммерческой разработкой для различныхглобальныхкомпаний,в основном с фокусом набэкенд.А еще яочень люблю делиться своими знаниями.Сегодня хочу рассказать проApacheAirflow, который, на мой взгляд, является хорошиминструментом для построениявашихпайплайнов.

Какой план?

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

  • Посмотрим, что такоеGoogleCloudComposer, как он используетAirflowиупрощает разработкунареальных проектах.

  • Взглянем наdevelopmentиdeploymentпрактикив рамкахGoogleCloudComposer,а такжетрудностииограничения,с которыми можно столкнутьсяво времязапускаAirflowвCloudComposer.

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

Airflowв нескольких абзацах

Итак, этоинструментдля планирования, построения и мониторингапайплайнов, написанных наPython.Есть и другие готовые решения дляоркестровки процессов, напримерLuigi. Но сейчас поговорим о достоинствахAirflow:

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

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

  3. Веб-интерфейс: простой, хороший и удобный.

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

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

Разберемся состроительнымиблокамиAirflow.Первым идетDAG(DirectedAcyclicGraph)ацикличный направленныйграф,основаAirflow. В целом это коллекция задач, которые мы хотим запустить. Они организованы специальным образом,могутиметьмежду собой зависимости.

Tasksопределяют единицу работы DAG и выражены как его узлы.Если проще, то задачиобозначают,чтоконкретно нам нужносделать.АOperatorsв свою очередь описывают,какмы хотим это сделать, конкретизируют действияв рамках задачи.На картинкехорошовидно, что задачи это узлыDAG-а. Ониявляются сущностямиразных операторовDataLoadOperator,GoogleCloudStorageListOperatorиUpdateStatusOperatorкаждый из которыхописывает некую единицу логики, которую нужно будет сделать.Как видно, некоторые задачи, выстроенные вDAG-е, могутвыполняться параллельно. Всезависит оттипаисполнителязадачи количестваворкеров.

EщеестьDAGsRunиTasksInstances.DAGsRun это объект самогоDAGа,предназначенныйк запуску в конкретные логические время и дату.TasksInstance объект задачи,ассоциированныйс конкретнымDAGRun.А логические дата и время дляDAGRunи егоTasksInstances этоexecutiondate.

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

Плавно переходим ккомпонентам, которыеучаствуютв исполнениипайплайнавнутриAirflow:

  • Планировщик(Scheduler)мониторит всеDAG-и,задачи иотвечаетзаихсвоевременный запускиотправку на исполнение.

  • Исполнители(илиExecutor)сущность, котораяследитзаорганизациейисполнениязадач.Они бывают разные:SequentialExecutor,CeleryExecutorи др. А некоторыеиз исполнителей могут иметь дополнительные зависимости. Например,CeleryExecutorтребуетQueueBroker.

  • Воркеры(Workers)просто исполняют наши задачи(подобноворкерамCelery).

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

  • Всяинформацияпроисполнениезадачпишется вLogs.Логированиепроисходитво время исполнения задач из самого кода,а такжепишутсясистемныелогиAirflow.Местомхранения логовмогут быть просто файлы, база данных либо какое-нибудь решение отсloud-провайдера. Например,можно писать вStackdriverиливGCSbucket.

  • С помощьюAdminPanelмыактивируем/деактивируемизапускаемDAG-и,устанавливаемпеременные,смотримлоги,находимпричиныпроблем(например, почемупайплайныупали).

Как это всеработает вместе?

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

GoogleCloudComposerизнутри

GoogleCloudComposerилипростоComposer этоfullymanagedсервисоркестрации, который позволяет создавать, планировать и мониторитьвашипайплайн вcloud.

Сразунесколько примеров, почему это удобно и классно.Допустим,у насестьклиент, который хочет автоматизироватьежедневныйпереносданных изstorageA вstorageB.Для этого мы напишемAirflowDAG,задеплоимего вComposerибудемзапускатьнашпайплайнвконкретный интервал времени.Задачимогут исполняться синхронно,стартоватьв определенном порядкеили параллельно.Если вдруг что-то упадет, тоестьмеханизмretry, которыйподнимет задачу ипопробуетзановоее исполнить.В общем, весь процесс зависит от настроек задачи.Теперь представьте, что нам нужно было бы сделатьcronjobs, строя при этом 100 разныхпайплайнов,без помощиAirflowиComposerоперирование, запуск и отладка дались бы гораздо труднее.

И еще немного о плюсахComposer:

  • Во-первых,с нимлегко разрабатывать идеплоить.Composerпостроен поверхAirflowипредоставляетвнутриGoogleConsoleвесь необходимый UI из коробки, чтобыбылоудобно работать,создавать окруженияизагружать файлыDAG-овс легкостью. Тамужевсе есть, мы просто создаемфайлыDAG-ов,плагиновиоператоров, указываем дополнительныезависисмости, а после загружаем в заранее созданныйComposerbucketвGCS.Дальшефайлы из бакета будут исполняться вузлахворкеров.

  • Во-вторых,уComposerестьмеханизмдля управления окружениями, причемвсе делается через UI.То есть мы можем создаватьнужное количествоокруженийсо своими версиямииотдельнымиAirflow, которые никак не будут пересекаться.

  • В-третьих,Composerтесно интегрирован сsecurity-подходами и инструментами, которые есть вGoogleCloud. Например,PrivateIPs,Authorizationит. д.

  • В-четвертых,ComposerConsoleпредоставляетстраницу метрикзапущенныхокружений.

Давайтепосмотримна компонентыComposer.На возможноеЗачем, если этоfullymanagedсервис и в нем все можно накликать?сразу скажу,чтознаниемеханизмов, сильных и слабых сторонпомогаетсделать разработку решений более эффективной.Итак,компоненты:

Пройдемся по некоторым(держим в голове, чтоComposerвсе делает сам).Накартинке видимTenantProject это для того, чтобы унифицироватьIdentityAccessManagement. Просто реализован дополнительный уровень безопасности.AppEngineFlexibleиспользуетсядля веб-сервера,CloudSQLкак база данныхAirflow.УCloudSQLестьопределенные плюсы, например,он даетограниченный доступ для сервис-аккаунта, а еще каждый день автоматически делает бэкапы.ВнутриCloudStorageComposerсоздаетbucket, который становится единой точкой для того, чтобы автоматическизагружать/обновлятьDAG-и,плагины и зависимости к ним. Файлы избакетабудут использоваться всемиворкерами, поднятымивKubernetesкластере.Core-компоненты, такие какпланировщик,worker-нодыи, например,Redis, который используетсядляCeleryExecutor,поднимаются внутриGoogleKubernetesEngine.Все это тоже автоматизировано:вместе с окружениемсоздаютсяKubernetesкластер, необходимое количествонодов,отдельноподнимаютсяворкерыиRedis.Кстати,RedisобслуживаеточередьзадачвнутриAirflow, а также нуженкак персистентное хранилище между рестартами контейнеров внутриKubernetesEngine.Большой плюс, чтоComposerхорошо интегрирован соStackdriverдля мониторинга илоггинга можно вселогии метрикисобиратьв одном месте.Это очень удобно, особенно когда у нас 100 узлов в кластере, а то и больше.

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

Кстати, воткакпроисходитмасштабированиеокружения:

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

Deploymentиdevelopment, трудности и ограничения

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

Обратите внимание, что код разбит подиректориямвендоров либоподоменным областямпродукта. А ещеAirflowдобавляетпеременныеDAGS_FOLDERиPLUGINS_FOLDERвsys.pathи потом автоматическипроцесситфайлы, которые в них находятся.Тутпросто: вDAGS_FOLDERищемDAG-и, а вPLUGINS_FOLDERсущности плагинов дляAirflow.

Итак, мы разделяем все на папки вендоров, каждаяизкоторыхможет содержатьвнутриподпапку библиотекlibsилиutils. Все зависит от того,каквам будетудобнеедержатьвместе файлы.Подпапки внутриpluginsотносятся кAirflowPLUGINS,их структурасоответствует конвенции оформления плагинов вAirflow.Я имею в видуoperators,hooks,macrosвсе, чтоAirflowпредоставляет из коробки.

Теперь поговорим прозависимостивнутри проекта.Ярекомендуюиспользоватьpipиrequirements.txtфайлкак можно чаще.Еслиработаем вComposer,тоуказывать в настройках UI,какие пакеты и версиинеобходимоустановитьв каждом из контейнеров. Или,если вы управляете окружениями внутри ваших CI/CDпайплайнов, можно устанавливать зависимости используя утилитуgcloud.Установка зависимостей с помощьюpipхорошо описана в документацииComposer.

Так какAirflowдобавляетDAGS_FOLDERиPLUGINS_FOLDERвsys.path,необходимо,по возможности,держатьлокальные зависимости вDAGS_FOLDER, а не вPLUGINS_FOLDER.Все дело в том, как работаетAirflow,ивего механизмахпоиска, сканированияи исполненияэтихдиректорий.Например,вAirflowестьнастройка, которая позволяет указать, с какой периодичностьюресканироватьпапку сDAG-ами. АвPLUGINS_FOLDERвсегораздосложнее.Поэтому не стоитпомещать много исполняемого кодаилимодулей внутрьpluginsпри каждомресканеили запуске все файлы будут исполняться и загружаться.А это может нести за собой дополнительные накладные расходы.Вообще многие команды сталкиваются с тем, что перезагрузка окружения происходит так долго, что задачисильно подвисают ипросто не могут исполняться.

Стоитьсказатьпроограничения настроекAirflow:их не все можно переопределить.Composerоставляетза собойправопредоставлять некоторые настройки только в режимеread-only. Полный список защищенных настроек можно подсмотретьв документации.

Ябыещепосоветовал использовать.airflowignoreфайл. Он работает как.gitignoreфайл, который можно помещать в директории либо описывать в нем паттерны для того, чтобымеханизмамиAirflowисключать из сканирования эти директорииилитипы файлов внутри. Это достаточно удобно, когда у нас есть большая директория. Например, в PLUGINS_FOLDER очень много кода,анамнужно хранить зависимости рядом с оператором в той же директории.Благодаря.airflowignoreзависимостибудут доступны внутриPythonкода, носам сканер их проигнорирует.

Немного про плагины вAirflow.Я рекомендуюне использовать встроенныйвAirflowмеханизмплагинов, разве что толькодля UI-вещей, например для созданияView.А дляoperators,hooksилибольшой общей логики я бывзялпростые классы.За счет того, чтоAirflowавтоматически добавляетPLUGINS_FOLDER вsys.path, можнобез проблемприменятьобычный импорт, как например,fromvnd.operators.my_operator. Такмы небудемиспользоватьникакие сущности,динамическую загрузкуилинейминг, которые предоставляет намAirflow. Пример, как может быть организован импорт внутри модулей:

from vnd.operators.my_operator import MyOperatorfrom vnd.sensors.my_sensor import MySensor

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

Еще совет:избегать, на сколько это возможно,callable-кода внутри модулей, то есть использоватьlazyподход. Это в целом относится и к плагинам, и кDAG-ам. За счет того, чторесканидеткаждый раз c определенныминтервалом, код будет исполнятьсятоже каждый раз.Этоможетповлечьза собой определенные ошибки, задержкивмоментобновлениясамого окружения.Иногдавстречаются кейсы,когда внутри наглобальномуровне самого модуля разработчики написали такойкод,гдемы ходим в базу данных, достаем какие-то записи,процессими потом используем этизначения в качествепеременныхв другом месте. Эти запросы будутвыполнятьсякаждый раз:мы каждую секунду будемресканироватьнашу директорию сDAG-амииисполнять этот код.

CI/СD подходтут нет ничего сложного. Мы используем те же самые подходысlinters,isortsдляGitlabCI/CDпайплайнов.В целомможнобрать любой CI/СDинструментна ваше усмотрение, ведьвсе они работают примерно одинаково:Jenkins,Gitlabpipeline,Spinnaker.

Например,мыв своемпроектеиспользуемlinters,потомидет шагunitтестов,дальшеинтеграционных.Чтобы доставить это вComposer,вызываемgcloudrsync.

Так как весь код вComposerдеплоитсявбакет,то нам нужнопросто обновить файлы до последней версиипри помощиrsync,которые в последствии будут использованыворкерамиAirflow.Конечно, можновзять командуgcloudcomposer,сее помощью регистрировать новыеDAG-и,плагиныи из каких-то своих исходных файлов все будет автоматическидоставляться внужныйбакет. Но,намой взгляд, этовыглядиткак-то сложно. Поэтому хорошо бы иметь свойrsync, который будет складыватьлибообновленные файлы,либо все фалы проекта вбакетоднимобщим подходом/способом.

Инструменты

Как и любая полноценная популярная система,Airflowпоощряет и поддерживает разработкурасширений. Они легко интегрируются,пишутся,сегодняихестьдостаточное количество в плане операторов.Но, ксожалению,не так много инструментов относятся к самомуAirflow. Один из них я могу привести. Этоafctlутилита командной строкиилиCLI-инструмент, который позволяет управлятьAirflowпроектом из командной строки. У него естьсвоибойлерплейтыилишаблоны, на базе которых можно создавать модули,DAG-иидр. Причем структура, в которойafctlсоздает свои директории,очень похожана ту,что мы используем в своем проекте (ячуть вышеотмечалее как рекомендованную).

А ещеесть достаточно много готовых интеграций, рабочих и хороших,дляAirflow.Например,GoogleCloudPlatform,AWS,Azure, различныеконнекторы кбазамданных.Их можно найтив папкеprovidersвнутри самого пакетаAirflow.

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


Суммируем и резюмируем:

Все, что относится кAirflowи что можносделатьвself-service, запускаетсявCloudComposer.

CloudComposer, к сожалению, не масштабируется в ноль(scalingtozero). Тоесть,создавокружение, мы будем платить за него деньги. Но за счет этого можноуправлятьComposerинвайронментом:строитьновый,проводитьA/B-тесты, презентовать заказчику иудалить его. Естественно,еслинет окруженийиподнятогоGKE кластера, томы ни за что не платим.

Стоит разделять окружения внутриComposer, например,Prod/Dev/Staging.Иеще держать их обновленными.ВComposerиспользуется версияAirflow,адаптированная под работу с ним,акомандаGoogleтожеактивно обновляет свои версииAirflow.Поэтому время от времениComposerпредлагаетапдейтнутьокружение:появляется кнопка,автоматическисоздаетсяновыйimage, контейнеры и вашинвайронментпереводитсявновую версиюAirflow.

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

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

По возможности не используемAirflowPluginсущноститолько дляUI вещей, которыепредоставляетAirflow. Но для операторов я бы не рекомендовал.

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

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

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

ИспользуйтеKubernetesPodOperatorдля запуска зависимостей и утилит, написанных не наPython. Так как у нас все окружение загружается и исполняется вкластереKubernetes,Airflowбудет инициироватьисполнение задачив отдельномPod-е. Для этого будут использованы дополнительные ноды кластера, созданные Composer-ом.

Помните проограничениеComposer, а именно проread-onlyнастройкиAirflow.Полный список защищенных настроек можно подсмотретьв документации.

Уверен, что вы сможете оптимизировать свои пайпланы, а Airflow и Composer станут в этом отличными помощниками :)

Подробнее..

Как быть тимлидом и продолжать программировать

19.11.2020 20:15:16 | Автор: admin

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


Хочу сказать отдельное спасибо Алисе Мироненко за подготовку транскрипта. Видео версия доклада:

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

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

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

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

Потом человек с таким опытом приходит к нам на позицию разработчика.

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

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

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

Но расстояние между лидоми менеджером такое же, как междуджуномилидом.

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

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

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

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

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

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


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

Возможно, у вас есть время на разработку, если:

  1. Вы занимаетесьмикроменеджментом.

  2. Пишете много документации в стол.

  3. Вы единая точка коммуникациина проекте.

  4. Ваша команда только пишет код.

  5. У вас много тет-а-тет митингов.

  6. Вы инициатор большинстваэтих митингов.

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

В целом ясчитаю, что совмещениеролейуправленцаи инженера зависит от трех вещей:

1) Стадии развития вашей команды

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

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

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

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

2) Уровня квалификации и мотивации ваших сотрудников

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

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

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

Есть классическая табличка на эту тему:

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

3) Уровня коммуникации на проекте

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

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

Очевидно, что в таком случае у вас не будет времени на инженерную деятельность.

Как настроить коммуникацию?

Вариант:если я единая точка коммуникации,я возьму и самоустранюсь.

Главная проблема будет в том, что появится неформальный лидер. Понятие неформальный лидер неприятное, потому чточасто неформальные и формальные лидеры не одно лицо. Это становится проблемой для формального лидера.

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

Как перестать быть единой точкой коммуникации?

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

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

  • Познакомьте заказчика с командой через task manager.

  • Организуйте встречу с командой в привычном для заказчика месте и времени. Не приводите сразу всех.

  • Ведите первые митинги как обычно, тет-а-тет с заказчиком, но с командой на фоне.

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

  • Поднимайте на встречах вопросы, которые можно адресовать команде. Пусть на них отвечают, не ожидая вас.

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

  • Всегда будьте в копии и на связи с заказчиком.

  • Это было про коммуникацию, теперь прото,как делегировать.

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

Делегирование это отдельная тема, сейчас я остановлюсь только на нескольких моментах.

Не забывать, чтоваши функции не очевидны другим.

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

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

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

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

Давайтетеперь подумаем,как бороться с отвлечением и управлять вниманием

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

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

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

Для тимлидов отметим важный момент: пишем через 15 минут правильно.

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

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

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

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

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

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

На виртуальном столе, где у вас релиз в продакшен, Jenkins/TeamCity, Splunk/Kibana, чат с DevOps. То же самое с обсуждением требований: Skype/Teams, Jira, Confluence.

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

Пора программировать

Мы настроили время, коммуникацию, справились с отвлекающими факторами, налили чаёк Имы парализованы.

У насантипаттерн аналитики-паралитики.

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

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

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

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

Напоследок хотелось бы поговорить про выбор программерскойроли, когда вы тимлид

Давайте рассмотрим основные роли:

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

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

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

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

Еще одни руки еще один программист,которыйпросто еще что-то делает фикситбаги, например.

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

И мое любимое кодерскийбалласт. Человек, которого лучше бы не было.

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

Резюмируя: как быть тимлидом и продолжать программировать.

Когда?

  • Когда команда на стадиинормингаилиперформинга.

  • Когда люди квалифицированы и мотивированы.Когда настроена коммуникация.

Как?

  • Прямая коммуникация.

  • Делегирование.

Рекомендации

  • Управлять отвлекающими факторами.

  • Микродекомпозироватьзадачи.

  • Облегчить переключение фокуса внимания.

  • Трезво выбирать роль.

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

Подробнее..

Трудности роста. Почему вашей компании стоит задуматься оdata-drivenподходе и как мы применяем его в ЕРАМ

23.03.2021 14:22:27 | Автор: admin

Сегодня ЕРАМ это сообщество из более 40 000 экспертов по всему миру. В таких масштабах для качественной работы с большими объемами данных и правильной оценки ресурсов нужны нетривиальные подходы. Некоторыми такими подходами делится ЕвгенийМоспан, SeniorSolutionArchitectи руководитель Центра компетенцииJava.

Больше года назад Евгений с коллегами начали работать над технологическим радаром по своему стеку. Вскоре эксперты обнаружили, что стоит объединиться с коллегами из разных локаций и команд и вместе создавать более масштабный, глобальный продукт. Лучшими практиками и вынесенными уроками на пути внедрения data-driven подходов в управление Евгений делится в этом материале. Если ваша компания планирует активный рост будет полезно.

Почему это важно

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

Чтобы имплементироватьdata-drivenподход, потребуется определитьmasterdata наиболее важные характеристики, вокруг которых будут строиться различные бизнес-сценарии. Причем они могут касаться не толькостаффингапроектов, но, предположим, и обучения сотрудников (например, если анализ покажет, что за последний год вашим инженерам регулярно отказывали в позициях на проектах по причине слабого знанияSpring, то вы сможете запланировать программу для прокачки этих навыков). Вариантов масса.

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

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

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

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

Как мы это делаем

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

Мы использовалиграфовуюмодель для построения связей между навыками. Их надо было объединить по компетенциям, сгруппировать поподмножествам, чтобы сравнивать в дальнейшем сопоставимые технологии (ведь нельзя ставить в один ряд фреймворк для созданияweb-приложений сIoT-фреймворком). Для этогоиспользовали разработанный внутренний продуктEPAMна базеArangoDB, позволяющийвести мастер-данные.Этот продукт был интегрирован воперационные системы, которые потребляют эту информацию,в качестве источника мастер-данных,чтобы пользователь мог правильно заполнитьстаффинг-позицию или личные данные во внутренней системе.

Упрощенно говоря, наша работа состоит из четырех этапов:

  1. Формирование мастер-данных

  2. Использование этих данных

  3. Аналитика

  4. Построение математической модели дляMachineLearning.

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

Что еще делаетJavaCompetencyCenterв компании:освежаем память

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

  • ##

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

В2020в рамкахJavaCompetencyCenterмы стартовалинесколькорабочих групп по разным направлениям. Так мы изучалиприменимостьKotlinкак язык дляback-endразработкив проектахкомпании и привлекательность его с точки зрениябизнеса. Также ЕРАМ заключила партнерство сAzul компанией, которая делает поставкуOpenJDK, предоставляет продуктZuluEnterprise, который дешевле аналога отOracle, и другие сервисы. Нашиэксперты изучали возможности модернизациивиртуальных машин потенциальных клиентовAzulи особенности их миграции наJava8 и 11. Еще одно перспективное партнерство ЕРАМ сLightbend, компанией, которая развиваетScala-технологии наJava-стеке.На сегодняшний деньинженерам компании EPAMдоступны обучающие материалыLightbend, что позволяетимполучатьновые, актуальные на рынке навыки, а также проходить сертификацию.

Онлайн кофе-поинт. Наши мероприятия поJava

В ЕРАМ мы верим в силу сообществ, потому развиваем глобальную платформуCommunity-Z. На ней можно найти комьюнити по своей технологии. Конечно, есть и по направлениюJava. Эксперты из Центра компетенции выстраивают горизонтальные связи между разными городами и странами и привлекают к работе не только коллег, но и широкое сообщество.

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

Кстати, в скором времени мы собираемся провестиJavaZ-Day,на который приглашаем всех желающих.

Подробнее..

EPAMAnywhereкакэтоработает.Субъективный взглядизнутри

26.05.2021 18:20:11 | Автор: admin

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

Кто я и чем занимался ранее

В тестированиия уже более четырех лет. Карьеру начинал в e-commerceпроекте интернет-магазине, который специализировался на продаже компьютерных комплектующих. У нас был маленький, носильныйИТ-отдел, который состоялиз двух разработчиков, проектного менеджера, бизнес-аналитика и тест-инженера меня. Мы разрабатывали монолитную e-commerceсистему на .NET.Там с нуля построил процессы контроля качества начиная с документации, заканчиваявнедрением регрессионного тестирования, сбора метрик ит.д.

Спустя два года такой работы, когда теоретические знания получили развитие в виде практических навыков, я решил идти дальше за новым опытом.Так я попал в одну из крупнейших сервисных ИТ-компаний в Украине на позициюMiddle/JuniorTestEngineer, где вместе с командой работалв доменеAssetManagement, разрабатывая программное обеспечение, которое собирало данные сразличных станций возобновляемой энергии.Там я проработалпочти двагода,за это время вырос до позицииTestLead, курировал несколькопроектов, которыесоздавалисьраспределеннымикомандами.

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

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

Почему фриланс не мой вариант

Да, мои ожидания могла бы удовлетворить работа на фрилансе.Однако ранее я уже имелопыт с фриланс-площадками. Результатом, мягко говоря, остался разочарован. И вот почему:

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

  • Инструменты для контроля.Если заказчик оказался адекватным, тебя можетожидать еще один существенный нюанс контроль за ходом работыииспользованиесофта, который отслеживает твою рабочую активность. Нет, я не хочу сказать, чтоконтроль этоплохо. Клиент платит деньги и имеет полноеправонаблюдатьза ходом продвижения проекта.Однако иногда это стремление к контролю приводит к ряду недопониманий.Например, работа тест-инженера не связана с постоянным взаимодействиемс клавиатурой и мышью, на что заточен контролирующий софт, снимающий данные о количестве нажатий кнопок на этих манипуляторах.Так,50-60% работы тест-инженеразаключаются ванализеинформации, разработкетактики тестирования, выстраиваниигипотез, чточастоне связано с активным взаимодействием с ПК.Соответственно по итогу своей работы ты получаешь низкий рейтинг, хоть проект и был выполнен в полном объеме. Заказчику, конечно, все это невсегданравится, что негативно влияет на итоговыйрейт.

  • Сложности с выводом денег с платформ.К сожалению, в реалиях Украины это не всегда просто необходимо определиться с типом карты, способомконвертации иностранной валюты.

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

Внезапное появление альтернативы

Парадоксально,но об EPAMAnywhereя узнал благодаряновойфриланс-площадке6nomads, на которую меня пригласилзнакомый изLinkedIn.Чисто из любопытствая прошел довольно длительную процедуру регистрациина этой фриланс-платформе, добавил к профилю несколько видео с самопрезентацией,скрупулезнозаполнил информацию о своих навыках.

Спустянекоторое время черезпрофиль на 6nomadsсо мной связалась рекрутер EPAM и предложила рассмотреть интересную для меня позицию, но ужев рамкахEPAMAnywhere.

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

Интервью, знакомство с платформой и неочевидный нюанс

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

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

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

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

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

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

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

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

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

Как работать и взаимодействовать и работать с командой на полной удаленке

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

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

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

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

Вот пример подходов, которым мы следуем, чтобы работать сплоченно на полной удаленке:

  • ссамого начала договорились включать камеры во время всех встреч;

  • отдали предпочтение онлайн-встречамвместо переписок в почте и чатах;

  • каждый из нас вышел на системный график работы;

  • регулярно проводим звонки для неформальных посиделок и обсуждения самых разных вопросов.

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

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

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

Над чем я работаю сейчас

Сегодня мояосновная задача следить, чтобыqualitygateнашего проекта соответствовал заявленным требованиямзаказчикаиз сферы на стыке e-commerceиretail.Наша команда работает над тем, чтобы исследовать и внедрить в проектлучшиеaccessibility-практики продукт клиента должен быть доступен для людей с ограниченными возможностями.Проект интересен как с социальной точки зрения, так и с технической для работы над нимнеобходимо использовать новые для меня подходы итехнологии(AdobeExperienceManager, технологии, связанные собеспечениемaccessibility, новые библиотеки,связанныес ним).Конечно, какTestLeadя отвечаю за контроль и менеджмент команды, ее обучение и рост, отчетность перед заказчиком, взаимодействие с разработчиками, функциональное тестирование.

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

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

Самая интересная часть текста. Плюсы и минусы платформы от EPAM

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

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

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

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

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

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

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

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

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

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

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

Итоги и дальнейшие планы

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

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

Хотел бы я вернуться к офисной работе? Скажу однозначно и искренне нет.

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

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

Буду радобщению и вопросамв комментариях.

Подробнее..

Перевод Как я получил несколько сертификатов по облачным технологиям за 9 месяцев

10.02.2021 10:11:22 | Автор: admin

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

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

Простая мотивирующая история с полезными ссылками.

Почему облачные технологии?

Ты присоединился к EPAM Anywhere в качестве DevOps инженера. Почему ты решил развиваться в облачных технологиях?

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

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

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

Первые шаги в облаке

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

Часть сертификатов ты получил самостоятельно, а остальные через EPAM Global Certification, верно?

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

В результате я прошел сертификацию AWS Cloud Practitioner и AWS Developer (Associate) до работы в EPAM, потом, будучи в EPAM, успешно сдал экзамен на AWS DevOps Engineer (Professional).

Помимо программы сертификации AWS, я принял участие в программе сертификации Microsoft Azure для сотрудников EPAM и прошел четыре сертификации: Azure Fundamentals; Azure Developer (Associate) и после небольшого перерыва архитектор решений Azure (Azure Solutions Architect Expert). Недавно я сертифицировался на Azure Data Scientist Associate.

От сертификатов AWS и Microsoft Azure до Google Cloud

Почему ты решил получить сертификат Google Cloud?

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

Затем я прочитал историю успеха о нашем коллеге, который получил ряд профессиональных сертификатов GCP, благодаря чему попал на новый интересный проект. Думаю, это послужило толчком для меня, я подал заявку на ещё одну сертификацию GCP и получил сертификат GCP Cloud Engineer (Associate).

Но это еще не конец истории. Поскольку я был на волне самообразования, я также решил изучить Kubernetes и, наконец, сдал экзамен на Kubernetes Application Developer (CKAD).

Сколько сертификатов сейчас в твоём портфолио?

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

Что, по-твоему, является самой сложной частью процесса сертификации и как с ней справиться?

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

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

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

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

Секреты успеха: ключевые принципы, которые помогут получить желаемые сертификаты

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

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

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

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

  • Мотивация, основанная на понимании преимуществ, которые сертификация даст для профессионального роста.

  • Продуманный стратегический план развития вашей карьеры на предстоящий период: 5 лет, 3 года, 1 год или меньше.

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

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

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

Двигайтесь вперед и никогда не останавливайтесь на пути к своей мечте!

Подробнее..

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

14.12.2020 10:07:17 | Автор: admin

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

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

Как вежливопопроситького-тосделать что-то (Asking someone to do something)

Mind

Tomindв контекстепросьбозначает возражать/иметь что-то против. В устной форме эта фраза может использоватьсядля предъявления требования, а не просьбы, в зависимости от интонации иконтекста.Однако в письменной форме это обычно считаетсяпросьбой, например:

Wouldyoumindsendingthatbeforetheendoftheday?

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

Would you mindto send<>?

Чтобы сделатьэту просьбу ещёболее вежливой,можнопоставитьподходящеенаречие после словаmind:

Would you mindterriblysending that before the end of the day?

Также следует помнить, чтоположительныйответна этот вопрос, если вы готовы выполнить просьбу,будетno, а неyesопять же, этокасается устной речи:

No,Idontminddoing that at all.

Favour

Ещёодин способ сделать запрос:

Could you do me a (big)favour?Can you send me that before the end of the day?

Обратите внимание, чтов этом выражении используется глаголdo, а неmake. (Такжепри общении с американскими партнерами или коллегамиимейте в виду, что в США словоfavourпишется безufavor).

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

Wonder

Этомойличный фаворит:

I was wondering if you couldsend me that before the end of the day.

Здесь следует обратить внимание на то, что мы используем прошедшее времяwaswonderingи could.Можно вообщесделать комбоиобъединить mind, favourиwonder, если хотитебытьсупервежливымииувеличитьшансы на получениежелаемого результата:

Iwaswonderingifyouwouldminddoingmeahugefavour.

Appreciate

Ещёодин очень распространенный способ вежливообратитьсяс просьбой:

I would really appreciateitif you could send it to me before the end of the day.

Многиеделаютошибку, опускаяit. Ноглаголуappreciateвсегданужен объект!Что-тонужно ценить.

Иногданекоторыезаменяют reallyнаvery.Но это тоже ошибка, потому что мы не можем использовать слово veryс глаголами(прим. ред.честно говоря, можем, но только если вместе сmuch:Iwouldverymuchappreciateit).

Также имейте в виду, что если вы опускаете словоreally,тоэтоуже будетбольше похоже на требование, а не просьбу:

I would appreciate it if you could send it to me before the end of the day.

Grateful

Gratefulоченьпохоженаappreciate.Только в отличие отвторого,grateful это прилагательное, поэтому здесь объект не нужен(noit!):

Idbereally gratefulif you couldsend it to me before the end of the day.

Потойжепричине(gratefulприлагательное),здесьмы можемзаменитьreallyнаvery.

Ивотличиеот предложений сappreciate,мы легко можем вовсе отброситьreally/very предложение всё равно останется вежливым.

Kind

Я заметил, что фраза Wouldyoubesokind<>очень популярна среди моих коллег, сотрудников EPAM. Однако часто эту фразу употребляютбез одного маленького, но очень важного слова. Правильно предложение будет звучатьследующимобразом:

Would you be so kindASto send that to me before the end of the day?

Да,здесь необходимо использоватьсловоas,так какмы проводим сравнение с помощью конструкции "so...as...".

Возможно, некоторые из вас читали Ромео и Джульетту Шекспира(в оригинале).Так вот,одна строчка из этой пьесызапомнилась мнесошколы,вероятно, потому чтомне нравится некая иронияи нарочитое преуменьшение значения высказывания. Это говорит второстепенный персонаж Меркуцио, который только что был смертельно ранен;вот как онговорит оразмересвоей раны:

No, 'tis notsodeepasa well, norsowideasa church door, but 'tis enough.

В21 векемы побольшей части заменилиsoвторым (или, если хотите, первым)as. ЕслибыШекспирписалсегодня,онмогбынаписать:

No, its notasdeepasa well, noraswideasa church door, but its enough.

Ещёодно замечание по поводу фразыWouldyoubesokindasto<>она очень формальная.Американцы, в отличие от британцев,редко его используют.Поэтому, есливы общаетесь с кем-тоиз Лос-Анджелеса или Торонто (илилюбого другого городаСША илиКанады), я бырекомендовалвыбратьменееформальнуюфразу.

Как вежливо дать указания сделать что-то (Telling someone to do something)

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

Could you pleasesend that to me before the end of the day?

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

Такие просьбыиногдамогутбытьсформулированынемного иначе,безplease, носдобавлениемask:

Could I ask you tosend that to me before the end of the day?


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

Оставайтесь вежливыми,иваши запросы будут выполнены!

И последний совет от Ромео и Джульетты:

Go wisely and slowly. Those who rush stumble and fall.Т.е.Ступайтес умом и медленно. Те, кто торопятся, спотыкаются и падают. Или, как у нас ещё говорят:Тише едешьдальше будешь.

Подробнее..

PhysicalTechnologyи розовыйхакатонистория нашего проекта

01.04.2021 10:10:31 | Автор: admin

Всем привет! Меня зовут АлександрБобко, я работаю менеджером проектов в инновационной лаборатории EPAM MadeRealLab. Это подразделение, которое занимается созданием быстрых прототипов иконцептовдля клиентов компании из самых разных отраслей. А еще команды лаборатории часто работают над разными социальными инициативами и проектами.

В своем первом посте наHabrя решил рассказать, как мы с коллегами приняли участие ввиртуальном хакатоне "Hack for Pink"и поделиться решением, за которое взялиГран-при. Речь о зеркале-домашнем помощнике при диагностикерака груди.

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

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

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

Команда

Основу составили ребята изPhysicalTechnology практики, которая занимается разработкой физических продуктов и устройств. Нетипичная для IT-компании гибридная командав Минскепоявилась около полутора лет назад и объединила инженеров и консультантов в областях электроники, медицинских, космических и других технологийиз6стран. А еще к нам присоединились коллеги из подразделенияInnovationconsulting,

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

Творческий процесс

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

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

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

C-Truemirror

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

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

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

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

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

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

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

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

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

ВперспективеC-TrueMirrorмог бы распознаватькаждого члена семьи (по аналогии стехнологией распознавания лиц в смартфонах) и запоминать данные по отдельности.Да и при помощи такого зеркала можно было бы проводить онлайн-тренировки или использовать для телемедицины.

В результате всенашипредположения подтвердились и получилихороший отклик от фокус-групп.

Воплощение идеи и презентация

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

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

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

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

Перспективы и новые направления развития

Важно отметить, чтоC-TrueMirrorзадумывался какумный домашний помощник,а не инструмент для полноценной медицинской диагностики.Послехакатонамы много общались с онкологами и собирали от них обратную связь. Врачи подтвердили, что наше решение будет действительно полезным для пользователей в качестве инструмента популяризации регулярной самодиагностики. Да и компьютер может быстрее обратить внимание пользователя на неочевидные внешние изменения. А дальше уже идет территория медиков, потому что онкологию в принципе сложно диагностировать (тем более в домашних условиях): нужно проводить спектральный анализ, УЗИ, обследования, измерять температуру на глубине 3-4 сантиметров, использовать специальную технику и руками доктора делать пальпации.

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

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

БлагодарюколлегМихаилаИргера, Марину Дайнеко, РоманаАлиевича,АрамаМанукяна, Яна Федорова, Максима Цвика, Ольгу Полещук и Артема Панасенко заидеи, классную работу и вклад в создание этого проекта!

Подробнее..

Почему я преподаю и вам тоже стоит начать это делать

29.07.2020 10:12:50 | Автор: admin
Это история о бывшем вузовском преподавателе, который нашел свое призвание в ИТ, но не перестал обучать молодых специалистов. Знакомьтесь Андрей Трубицын, Solution Architect, уже практически 5 лет сотрудничает с EРАМ. За его плечами 8 лет преподавания в ВУЗе и сейчас он задействован сразу в нескольких образовательных проектах компании. Андрей не стремился к преподаванию, но жизнь раcпорядилась иначе. Итак, далее рассказ от первого лица.



С чего все началось


В детстве увлекался произведениями фантастов Азимова, Лема, Стругацких, мечтал создавать роботов. С момента, когда в доме появился 8-разрядный ZX Spectrum, все мои мысли были только о программировании. В лицее я впервые познакомился с компьютерами из Европы, первые 286-е машины. Именно там в 11 классе у меня случился первый опыт преподавания. Я рассказывал пятиклассникам о Norton Commander, как копировать файлы, запускать игры, считывать информацию с дискеты. Изучая математику в вузе (механико-математический факультет в Харьковском национальном университете им. В.Н.Каразина), как и многие студенты, я постоянно подрабатывал решал лабораторные по программированию. Параллельно поступил в аспирантуту. Оказалось, преподавателей математики много, а информатики нет. Поэтому в 22 года я начал читать лекции по программированию. Читал курс по языкам программирования С++, Java, базы данных, спецкурсы по шаблонам проектирования, криптографии. Вначале было страшно в аудитории мои вчерашние приятели. Сложно воспринимать себя в новой роли, но это как раз был отличный период развития soft skills.



К программированию на мехмате относились как к гуманитарному предмету, единицы по-настоящему хотели учиться. Я работал только с теми студентами, кто интересовался, от других требовал минимум знаний. Сейчас по-другому, когда я преподаю, вижу отдачу. Люди понимают, что программисты зарабатывают выше по рынку, и это мотивирует. Иногда я встречаю своих бывших студентов среди тестировщиков, программистов, хотя в свое время они обещали никогда не заниматься программированием. За обещание я ставил им тройки.
По окончанию вуза я работал в Институте комплексной автоматизации, который разрабатывал программы для атомных станций. Кстати, парочка моих программ до сих пор вертится на Хмельницкой, Ивано-Франковской АЭС. Пока я писал кандидатскую и преподавал, другой институт попросил построить систему учета мониторинга роста и изготовления кристаллов. На тот момент таких специалистов было мало либо уехали за рубеж, либо ушли в коммерцию. Мне, молодому 24-летнему парню, выпала крутая возможность создавать продукт для крупного института, который зарабатывал миллионы на экспорте кристаллов. Благодаря этому сотрудничеству, институт прошел сертификацию на ISO, а я занялся фрилансом на различных платформах. Когда появилась семья, родилась дочь, стало ясно: надо что-то менять. Так в моей жизни появилась аутстафинговая компания Muranosoft и потом ЕРАМ. Началась моя карьера программиста и на пять лет приостановилась карьера преподавателя.

Как построить карьеру преподавателя в бизнесе


EPAM быстро растет, постоянно присоединяются новые ребята, которых нужно обучать. И вот я, уже архитектор, снова преподаю. Хотя я бы не сказал, что это совмещение карьер: обучение других это часть моей работы инженера. Я начинаю новые проекты и хочу, чтобы ко мне приходили те, кто понимает архитектуру, умеет читать диаграммы, может брать ответственность за часть работы, помогая мне добиваться целей. С 2016 года в компании существует Solution Architecture School (SAS), где я обучаю. Цель программы за 5 месяцев дать фундаментальные знания по этой дисциплине и помочь ребятам перейти на новый карьерный уровень в компании. Но профессия архитектора это, откровенно говоря, сложно. А 180 часов обучения немало, поэтому до конца доходят не все. Те, кто смогли, стали лучше выстраивать процессы и делать дизайн некоторых частей решения, анализировать требования на проектах и документировать решение. Чтобы я сам мог перейти на более высокий уровень Senior Architect, директор по технологиям или Lead Architect мне нужно подготовить смену, чем я и занимаюсь.

С прошлого года работаю также над внешней образовательной программой Masters degree Program, которая создана ЕРАМ в партнерстве с одним из престижных ВУЗов Украины Киево-Могилянской Академией. Это магистерская программа подготовлена специально для опытных разработчиков, которые мечтают о развитии карьеры в IT и она доступна абсолютно всем вне зависимости от проживания и места работы. Вместе с коллегами я разрабатывал модуль по Solution Architecture на основе опыта в SAS. Но, если в школе архитекторов больше внимания уделялось оффлайновым встречам, то в MsDP упор на онлайн формат и воркшопы. Новый формат требует адаптации учебной программы сделать опросники, квизы, задачи для отбора, разработка домашних заданий и т.д. Сейчас, когда половина обучения прошла, признаюсь, группа подобралась отличная. Ребята разные есть разработчики, менеджеры, директора. Есть руководитель IT-отделения банка, которому важно не стать архитектором, но понять внутренние процессы своего IT-отдела. Интересно, что пара ребят приехали из Белоруси, самостоятельно оплачивая программу и дорогу. Я был поражен их целеустремленностью. Невзирая на то, что программа насыщенная только один модуль длиться более 400 часов участники крайне мотивированы. Возможно, потому что обучение платное и отношение другое. Ситуаций, когда кто-то не сделал домашку не бывает. Как не бывает и сессий без вопросов. Студенты требуют ответов, погружаются в глубину темы, им нужны детали. Когда отдаешь знания и кому-то они нужны преподаватель счастлив. Кстати, в преподавательском составе MsDP специалисты очень высокого уровня. В Киев приезжали выступать IT-звезды несколько СТО, топы ЕРАМ, а также приглашенные преподаватели, среди которых Бертран Мейер, выпускник Стэндфорда, создатель языка программирования Eiffel. Это люди, которые много добились, у них огромный опыт, широкий взгляд на происходящее. Эти встречи очень популярны.



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

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



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

Кто он хороший преподователь?


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

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

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

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

Бесконечность не предел. История Advanced Software Engineer

19.08.2020 20:12:15 | Автор: admin
Если представить себе типичный карьерный путь разработчика, какой он? Наверное, специалист пройдёт все ступени от Junior до Lead или Chief. А что потом? Мы уже много рассказывали в нашем блоге, что в EPAM у инженера есть условно два пути пойти в Solution Architect (SA) или стать менеджером (Delivery, Resource, Project). Но некоторых ни один из них не устраивал. В итоге получалось, что талантливые разработчики застревали на одной позиции, и как бы они дальше ни развивались и ни углублялись в технологию, их талант оставался незамеченным. В прошлом году компания открыла новую тропинку на карте карьерных путей Advanced Software Engineer (ASE).

Конечно, роль ASE это не новое слово в ИТ. В некоторых компаниях, в том числе продуктовых, где используется система грейдов, можно встретить такую роль (обычно она называется Principal Developer). Чтобы лучше понять, кто такой ASE, что они делают и зачем они нужны компании, я расспросила продвинутых инженеров первой волны, что значит быть ASE. Рассказываю обо всём по порядку.

Кто такой ASE?


В первую очередь это инженер, который обладает какой-то глубокой уникальной экспертизой, при этом может довольно быстро войти в проект с любой технологией, можно сказать, что это Multi-skill или Cross-stack инженер. Сейчас это модно называть T-shape моделью, подход, когда у инженера есть какая-то глубинная область, но ничто не мешает ему разобраться и помочь команде пофиксить небольшой баг на фронтенде, например.

Константин Периков работает в EPAM 3 года, занимается разработкой information retrieval systems построением различных поисковых систем, работает с Open Source движками: Lucene, Solr, ElasticSearch. Он был в числе первых, получивших статус Advanced инженера по направлению Enterprise Search.
image
Когда я пришёл в компанию в качестве Chief инженера, я думал, что вот он потолок. Я должен был выбирать идти в SA, или в менеджеры. Когда в конце 2019 года мне рассказали об ASE, я понял, что это именно то, что мне нравится, и это то, что меня несколько лет останавливало записаться на ассессмент (своего рода аттестация) на SA. Я люблю программировать, это то, что я делаю каждый день, не только на работе, но и на каких-то домашних или Open Source проектах.
Основная идея ASE и отличие от SA и менеджеров это то, что человек должен писать код. Ежедневно, по несколько часов. Это и воодушевило меня пойти и попробовать новую роль.

imageДмитрий Таболич, Senior Solution Architect, более 8 лет работает в EPAM, стоял у истоков и был одним из авторов этого трека внутри компании.
Тема Software Engineering мне довольна близка, а проблема карьерного роста для инженеров достаточно понятна, поскольку какое-то время в компании я отвечал за процесс аттестации (ассессмента) Software Engineer в Solution Architect, где часто люди выбирали этот вектор развития как единственный не менеджерский. Так возникла инициатива по пересмотру всей линейки Software Engineer (от Junior to Distinguished) с учётом возможности развития без трудности выбора и перепрофилирования. Мы долго думали над концептом и способом идентификация таких специалистов, и однажды Павел Веллер, один из CTO компании EPAM и идеолог концепции ASE, предложил интересную неформальную метрику определения таких специалистов: known to others (пер. известный). Это сложно измерить, но легко понять, что имеется в виду. Скажем, есть Java-разработчик, к которому все обращаются за советом в рамках командной работы, или даже из других команд или проектов, а потом практик. Если кто-то известен в свой практике, это хорошо; если его знают во всей компании это ещё лучше.
Advanced Engineer не обязан быть спикером на каждой конференции, он просто знает больше остальных и делает вещи, которые никто больше не умеет.

Зачем нужны ASE?


Главным образом для того, чтобы решать сложные инженерные задачи. Рынок меняется, меняются решения, они становятся сложнее. Помимо глубоких технических навыков, ASE имеет развитые способности решать проблемы. Более того, ASE способен не просто решить проблему, а предугадать и не допустить её возникновение. Этакий технический гуру-предсказатель.

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

Дмитрий Таболич: Иногда на проект нужен один инженер, но очень сильный, такой классический техлид. Мы знаем, что в EPAM такие инженеры есть, но как их идентифицировать среди десятков тысяч специалистов, если максимальный грейд Chief? Конечно, мы можно взять архитектора с опытом разработки, но порой требуется кто-то, кто может сосредоточиться именно на написании кода и внедрении инженерных практик.

Какими качествами должен обладать ASE?


Внутри EPAM разработана матрица компетенций, в которой прописано, какие требования предъявляются к инженерам на каждом уровне.
В первую очередь, к ASE предъявляются высокие технические требования. ASE это технический эксперт с глубокими практическими и теоретическими знаниями в нескольких областях и разнообразным опытом работы с различными языками программирования и средами и в разных сферах бизнеса. Это то, с чем он сталкивается каждый день пишет код и делает это исключительно чисто, с использованием EngX (Engineering Excellence) или, другими словами, лучших инженерных практик и подходов к написанию кода, тестированию и т.д. При этом он способен проверить архитектуру или просто выступить в роли технического консультанта на проекте. Ключевым является фокус на построении конечного продукта или системы и понимании аспектов жизненного цикла их эксплуатации (производительность, безопасность, расширяемость и прочее).

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

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

Константин Периков: Что часто дополнительно отличает ASE, так это общественное влияние (Public influence). ASE это человек, который имеет вес в профессиональном сообществе (на первых порах на уровне компании), является амбассадором и может помочь в сложной ситуации на совсем незнакомом проекте. Нельзя просто делать свою работу в стол и ожидать, что тебя пригласят в комитет по стандарту, например. Не обязательно быть искусным спикером, можно делать публикации или быть ментором.
Человек должен быть способен делиться своим уникальным опытом это то, что делает его по-настоящему ценным ресурсом.
Но нельзя стать просто докладчиком или ментором. Нужно в первую очередь обладать глубокими знаниями в предметной области.

Как стать ASE?


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

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

Все эти требования относятся и к внешним кандидатам.

Куда дальше развиваться ASE?


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


Денис Чичмарёв: Среди ASE абсолютно разные люди. У нас есть инженер, который настолько хорошо знает С ++, что участвует в определении мировых стандартов для него. Другие, наоборот, исследуют новые технологии и стеки. Следят за тем, что происходит в мире программного инжиниринга. Им не нужен менеджер, чтобы говорить, что делать, что читать, куда расти.
Единственное, что объединяет ASE, это то, что они ищут знания самостоятельно и так рьяно, будто они без этого жить не могут.

Выводы


  • Advanced Software Engineer это продвинутый инженер во всех смысл слова. Он знает то, чего не знает большинство, решает вопросы, которые нельзя загуглить, использует для решения задач лучшие практики и создает свои инновационные.
  • Advanced Software Engineer это технический гуру, он кодит каждый день, как минимум по несколько часов, не отвлекаясь на задачи управления проектом, распределения ресурсов в команде. Hands-on experience превыше всего!
  • Advanced Software Engineer это ментор, наставник. Его главная ценность не в хранении всей накопленной за годы практики информации, а в том, как он этой информацией распоряжается делится в блоге, рассказывает на конференциях или просто своей команде.
Подробнее..

Что нужно знать начинающим специалистам о процессе найма перед собеседованием? 12 вопросов рекрутерам

01.11.2020 16:04:58 | Автор: admin

Нас часто спрашивают, берём ли мыjunior-специалистов в командуEPAM, какими знаниями нужно для этого обладать, как проходит отбор и многое другое.Не секрет, что наша компания проводит бесплатное обучение специалистов в тренинг-центре, лучшим студентам по итогам тренинга предлагается пройти собеседование на проект.Сейчас в компании проводится подготовка по 14 программамв 11 городах, каждый год тренинг-центр обучает более 600 студентов,и 60%студентов трудоустраиваются в компанию по итогам тренингов.Мы собрали ответы рекрутеров на вопросы, которые помогут лучше понять процесс отбора и наймаjunior-специалистов.

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

1.Как вы оцениваете уровень кандидатов на первом этапе (тестовые задания, собеседования)? По каким критериям вы отбираете релевантных кандидатов?

НинаСказобова,LeadResourceDevelopmentLabHeadНинаСказобова,LeadResourceDevelopmentLabHead

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

2. Джуновотбирают опытные разработчики или рекрутеры?

Мария Выгузова, Resource Development AdministratorМария Выгузова, Resource Development Administrator

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

НинаСказобова, Lead Resource Development Lab Head:

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

3. Какими минимальными знаниями должны обладать джуны?

МарияВыгузова, Resource Development Administrator:

Всё зависит от направления и языка программирования. Еслибрать общие требования, тоджуниорыдолжны знать как минимум принципы ООП, один из языковпрограммированияна уровнеAdvanced, один из фреймворков, уровень английского должен быть не ниже A2+.

4. Что вы можете сказать о среднем уровнеджуниоров, которые приходят на собеседования?

НинаСказобова, Lead Resource Development Lab Head:

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

АлександраЗайцева,Front-endDeveloperАлександраЗайцева,Front-endDeveloper

Я прошла весь путь: от внешнего тренинга поFront-endдо обучения во внутренней лаборатории. <>. Во внутренней лаборатории нас погрузили в реальную жизнь. Здесь уже была немного другая атмосфера, более серьезная, мы начали изучение новых инструментов и фреймворков. Работали со сборщиками иtask-runner, учились писать юнит-тесты ипростенькиесервера на Node.js. После этого мы начали погружаться в изучение фреймворков:Angular,React,ReactNative. <>

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

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

Через 2-3 месяца я уже спокойно брала задачи на самостоятельную разработку с интеграцией с API, написание юнит-тестов и всё, что включало в себя полный цикл разработки.<>

Полное интервьючитайтенапортале Тренинг-центра.

5. Насколько большой может быть разница по скиллам между несколькимикандидатами, которые претендуют на одну позицию?

НинаСказобова, Lead Resource Development Lab Head:

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

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

МарияВыгузова, Resource Development Administrator:

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

ГригорийСилкин, Software Testing Team LeaderГригорийСилкин, Software Testing Team Leader

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

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

МарияВыгузова, Resource Development Administrator:

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

АртёмЦибенков,JavaDeveloperАртёмЦибенков,JavaDeveloper

Чтобы яснее представить, стоит ли мне идти в IT-сферу, начал изучать рынок труда в нашем городе, направления и специализации. Я понял: чтобы стать разработчиком не обязательно тратить время на получение высшего профильного образования, это плюс. Выбрал для изученияJava, как наиболее востребованный на рынке язык.<>

Записался на бесплатное онлайн-обучение. Прошёл, убедился, что разработка мне интересна.Решил пройти платный полугодовой онлайн-курс поJavaот одной известной компании.Пока проходил онлайн-курсы, в параллели узнавал, какие IT-компании есть в городе, какие у них требования дляcтажрови на вакансииjunior-специалистов.<>

Узнал, чтов офисеEPAMпланируется запуск обучения для начинающих специалистов и одно из направлений разработка наJava. И что новички после окончания получают возможность трудоустройства в EPAM, если пройти техническоесобеседование.<>

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

Понял, что есть немалыйобъминформации и его надо усвоить за 2 месяца. Составил план, получилось, что ежедневно надо заниматься по 8-9 часов. В итоге, после интервью, по окончании обучения меня взяли на позициюJuniorDeveloper.

Полное интервью на сайтеТренинг-центра.

7. Компании борются за сильных специалистов. Борются ли они заджунов?

НинаСказобова, Lead Resource Development Lab Head:

Да, сджуниорамиработа начинается ещёв вузе (со2-го, 3-гокурса) компании проводят мероприятия для студентов, приглашают на практику, выстраивают долгосрочные отношения ещё на этапе обучения кандидата.

8. Как вы считаете, компания должна продавать свои вакансииджунамилиджуныдолжны убеждать компании, что они ей нужны?

НинаСказобова, Lead Resource Development Lab Head:

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

9. Что эффективнее и выгоднее стажировки или поискджуновна рынке?

МарияВыгузова, Resource Development Administrator:

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

10. Что происходит послеоффераджуниор-разработчику: процесс обучения,онбординг, менторство? Как скоро он получит боевые задачи?

МарияВыгузова,ResourceDevelopmentAdministrator:

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

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

11. Как вы относитесь кджунам, которым за тридцать или за сорок кандидатам, которые резко решили сменить карьеру и пришли из других сфер?

МарияВыгузова, Resource Development Administrator:

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

ГригорийСилкин,SoftwareTestingTeamLeader:

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

Владимир Малюгин, Front-End разработчик Владимир Малюгин, Front-End разработчик

<> Когда несколько лет назад я решил выбрать новое направление развития, по совету знакомого преподавателя, обратил внимание на образовательные программы ЕРАМ. Но поступить на внешние курсы поFront-endмне удалось только с третьего раза. Слабым местом был уровень владения английским.

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

<>Я решил повторить путь своего старшего сына, но в отличие от меня, покаджуниора, он ужеteamlead.

Если есть желание и мотивация, то сменить сферу деятельности или научиться чему-то новому не проблема в любом возрасте<>.

Подробнее насайте Тренинга-центра.

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

НинаСказобова, Lead Resource Development Lab Head, EPAM:

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

МарияВыгузова, Resource Development Administrator, EPAM:

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


Подкидывайте идеи, о чём вам ещё было бы интересно почитать. Задавайте свои вопросы в диалогах.

Подробнее..

Перевод 5 диаграмм, необходимых для документирования архитектуры решений

20.01.2021 10:13:24 | Автор: admin

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

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

Контекстная диаграмма

Веб-сайт, посвященный модели С4 (Context, Container, Component and Code), довольно хорошо объясняет свои диаграммы, я же поделюсь своим представлением, как эта модель работает.

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

Пример

Context diagramContext diagram

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

Как рисовать

  • Определите пользователей.

  • Определите внешние системы.

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

  • Добавьте связи между системой, пользователями и внешними системами.

  • Напишите содержательные комментарии по каждому компоненту.

Инструменты

Существуют различные инструменты, которые можно использовать для создания контекстной диаграммы. Существуют трафареты C4 для OmniGraffle, примеры C4 для LucidChart, шаблоны есть также в draw.io. Чтобы использовать диаграммы как код, попробуйте PlantUML.

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

@startuml!includeurl https://raw.githubusercontent.com/RicardoNiepel/C4-PlantUML/master/C4_Context.puml' uncomment the following line and comment the first to use locally' !include C4_Context.pumlPerson(customer, "Customer", "A bank client")System(abc_system, "Digital Platform", "Allows freelancers and business owners see their transactions.")System_Ext(idnow, "IDNow", "System for KYC and Qualified Eletronic Signatures")System_Ext(pay, "Google Pay/Apple Pay", "Google Pay and Apple Pay systems")System_Ext(dms, "DMS", "Document Management System")System_Ext(crm, "CRM", "CRM")System_Ext(current, "Existing Banking System", "Banking Backoffice")Rel(abc_system, pay, "uses")Rel(customer, abc_system, "Uses")Rel_L(abc_system, idnow, "integrates")Rel_Neighbor(abc_system, dms, "uploads files")Rel_D(abc_system, crm, "integrates")Rel_U(abc_system, current, "uses")@enduml

Мы определяем человека, систему, внешние системы и отношения между ними. Предикаты Person, System и System_ext имеют 3 параметра: ключ, заголовок и описание. Предикат Rel также имеет 3 параметра, но они разные: ключ одной сущности, ключ другой и тип отношений между сущностями.

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

Важно

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

Я боролся с контекстной диаграммой для одной банковской системы. Она должна была включать только недавно созданную систему и одного клиента, который не принесет никакой ценности. После согласования я добавил API Gateway и существующий Auth Provider, который мы собирались использовать. Таким образом, контекстная диаграмма стала обретать смысл и позволяла опустить эти элементы из диаграмм нижнего уровня.

Алексей, архитектор решений

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

Джон, архитектор решений.

Резюме

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

Диаграмма контейнеров

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

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

Пример

Container diagramContainer diagram

Как рисовать

  • Определите список сущностей: микросервисы, хранилища, внешние сервисы.

  • Поместите их на диаграмму.

  • Добавьте комментарии о назначении каждого компонента и технологии, которую он реализует.

  • Добавьте соединения со стрелками.

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

  • Подберите цвет схемы.

  • Создайте легенду.

Инструменты

То же, что и для контекстной диаграммы: Draw.io, OmniGraffle, LucidChart и другие.

Важно

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

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

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

  • Очень распространенный вопрос, когда используешь облака, включать ли вы управляемые сервисы, такие как очереди сообщений? Я обычно отвечаю: Нет. Это усложняет диаграмму, делает её нечитабельной. Если некоторые сервисы обмениваются данными через очередь сообщений, отобразите её с помощью стрелки отдельного типа.

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

Илья, архитектор предприятия.

Резюме

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

Диаграмма последовательностей

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

Пример

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

Как рисовать

  • Выберите функцию (вход, покупка и т. д.).

  • Определите сущности, участвующие в этом процессе.

  • Поместите их на диаграмму.

  • Добавьте взаимодействие (стрелки).

  • Добавьте ценные комментарии к каждой стрелке.

Инструменты

К сожалению, OmniGraffle не подходит для диаграмм последовательности. Поэтому для создания этой диаграммы я использую draw.io и LucidChart. Последний вариант является хорош тем, что вы можете рисовать диаграмму вручную или использовать диаграмму последовательности UML.

Важно

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

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

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

Владимир, Архитектор решений

Резюме

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

Диаграмма развертывания

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

Есть несколько разных вещей, которые необходимо отобразить.

  • Вычислительные ресурсы. Это могут быть виртуальные машины, докеры, кластеры Kubernetes и облачные функции. Мобильные устройства и настольные компьютеры также можно рассматривать как вычислительные ресурсы.

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

  • Ресурсы обмена сообщениями. Установки Kafka / RabbitMQ, Google Cloud pub / sub, AWS SQS и другие.

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

  • Зоны доступности. Вы можете думать о них как о центрах обработки данных.

  • Узлы инфраструктуры. DNS-серверы, балансировщики нагрузки, брандмауэры, сети CDN

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

Как нарисовать

  • Разместите основные блоки: браузеры, мобильные устройства, общедоступное облако, центры обработки данных.

  • Разместите вычислительные ресурсы и ресурсы хранения.

  • Добавьте узлы инфраструктуры.

  • Добавьте сети.

  • Добавьте сетевые вызовы между узлами.

  • Добавьте ресурсы мониторинга.

Пример

В C4 нотации есть дополнительная диаграмма развертывания:

Обратите внимание на имена вычислительных ресурсов, их типы и номера узлов.

Другой пример для облака AWS:

Distributed Load Testing by AWSDistributed Load Testing by AWS

Инструменты

Существует множество инструментов для создания схемы развертывания. OmniGraffle, LucidChart, Draw.io и другие прекрасно справляются с этой задачей, если установлены соответствующие шаблоны.

Важно

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

Резюме

Диаграмма развертывания дополняет понимание системы с точки зрения внешнего вида.

Диаграмма вариантов использования

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

Как рисовать

  • Нарисуйте прямоугольник. Это будет граница системы.

  • Определите, кто будет работать с системой.

  • Добавьте варианты использования внутри системы с помощью овалов.

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

Примеры

Инструменты

Архитектор может нарисовать диаграмму с помощью любого графического редактора и того же набора инструментов, что и для других диаграмм. Omnigraffle, LucidChart, Draw.io работают хорошо. Помните, что эта диаграмма является структурированной, поэтому вы можете использовать UML для её создания. В этом помогает PlantUml или LucidChart.

Резюме

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

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

  • Масштабируйте внутренние компоненты системы с помощью контейнеров и диаграмм развертывания.

  • Документируйте конкретные бизнес-кейсы с помощью диаграмм последовательности.

Подробнее..

Категории

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

  • Имя: Макс
    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