Месяц: Декабрь 2019

Специалисты ИТ-компании «ТехЛАБ» рассказывают о самых интересных инструментах, за развитием которых стоит наблюдать в 2020 году.

GraphQL

Павел Якупов, веб-разработчик:

До недавнего времени распространенным стилем программной архитектуры был монолит, в соответствии с которым система структурируется в виде одного исполняемого файла или развертываемого компонента. Примером такого подхода может служить Java-приложение уровня предприятия или, например, приложение с использованием популярных PHP-фреймворков (Laravel, Yii2, Symphony).

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

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

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

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

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

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

VUE NEXT

Дмитрий Федоров, веб-разработчик:

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

Попробовать возможности обновленного фреймворка можно уже сегодня: проект находится в статусе Pre-alpha.

Что же нас ожидает?

– Уже сегодня в репозитории можно увидеть то, что многие из нас так ждали. Процент TypeScript кода в репозитории – 96.1%!

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

– Новая кодовая база спроектирована с нуля как tree-shaking friendly. Такие функции, как встроенные компоненты (<transition>, <keep-alive>) и директивы-помощники (v-model), теперь импортируются по требованию. Размер новой runtime библиотеки <10kb в gzip. Также мы можем предлагать больше встроенных функций в будущем, не прибегая к утяжелению полезной нагрузки для пользователей, которые их не используют.

– Vue 3.0 будет поставляться с реализацией паттерна Observer на основе Proxy, которая обеспечивает отслеживание реактивности. Это даст следующие преимущества: открытый API для создания наблюдаемых объектов, ленивое наблюдение по умолчанию, что ограничит ресурсы на наблюдение за неиспользуемыми при рендеринге полями. Также запланировано улучшение возможностей отладки: появится возможность точно отслеживать, когда и почему происходит перерисовка компонента или запускаются новые обработчики.

– Фрагменты и порталы: несмотря на уменьшение размера, 3.0 поставляется со встроенной поддержкой фрагментов (компонент, возвращающий несколько корневых узлов) и порталов (рендеринг поддерева в другой части DOM, а не внутри компонента).

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

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

WebAssembly (wasm)

Дмитрий Конасов, ведущий веб-разработчик:

В последние годы код на фронтенде решает все более и более сложные задачи, переставая брать на себя исключительно отрисовку подготовленных данных. Форматы данных, которые приходится обрабатывать на клиенте, усложняются, на web-платформы портируются классические 3D-игры и пишутся новые. В общем, сайты уже давно перестали быть такими, какими мы их знали в конце нулевых-начале десятых. При этом язык Javascript, который, казалось бы, уже успел победить в вебе и Java, и Flash, и прочий ActiveX, не способен обеспечить тот уровень производительности, который необходим для решения упомянутых задач.

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

Есть несколько причин для того чтобы следить за WebAssembly в 2020 году и, возможно, даже использовать в своих проектах. Во-первых, wasm-модули начали стабильно и хорошо собираться из языков типа С, C++ и Rust. По-крайней мере, судя по тому же Яндексу, они уже вполне production-ready. Во-вторых, в ближайшее время должна появится прямая поддержка основных джаваскриптовых API (DOM, XmlHttpRequest и прочие), потоков, полноценный GC, что делает использование wasm еще проще, а саму технологию более востребованной. В-третьих, помимо С и Rust возможность писать под WebAssembly добавляется в огромное количество других языков. Эта поддержка пока не слишком развита, но тренд достаточно интересный и, возможно, в будущем он упростит портирование под web имеющихся приложений, написанных на разных языках. А еще появляются языки, которые созданы специально под wasm, например, AssemblyScript. Это почти Typescript, но у него есть несколько существенных отличий: он обладает только самыми простыми типами, в нем нет возможности использовать any (что дисциплинирует разработчиков), и в целом код на нем пишется в более «низкоуровневом» стиле.

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

Источник: VC.ru

Спасибо, что пришли

Когда мы начинаем внедрение нашего ИТ-решения в каком-то медицинском учреждении, то в первую очередь обращаем внимание на уровень подготовки врачей. Конечно, в 2019 году вряд ли можно столкнуться с тем, что специалист не умеет пользоваться браузером или программами Microsoft Office – между тем, лет 10-15 назад такое вполне было возможным. Сегодня у врача есть большой пользовательский опыт работы с компьютером, поэтому базовое обучение не требуется.

Однако почти в 100% случаев мы сталкиваемся с другой проблемой – нехватка времени. Какой бы продукт мы ни внедряли, чаще всего сначала работаем с заведующими отделениями. Обычно они с интересом относятся к ИТ-разработкам и понимают, как те помогут сотрудникам медучреждения и им самим. Однако каждый из этих специалистов – очень занятой человек: если он нашел 10 минут на инструктаж – отлично!

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

Что в такой ситуации делать разработчику? Как наладить диалог и процесс обучения?

Три фактора успеха

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

Начнем с диалога. Честно говоря, людям с техническим образованием общаться с врачами трудновато: можно сказать, что мы по-разному воспринимаем окружающий мир. Опыт «ТехЛАБ» показывает: о чем бы вы ни говорили с врачом – о новом предложении или текущем проекте – нужен «переводчик». Поэтому в нашей команде есть дипломированные врачи, которые сменили сферу деятельности на ИТ и стали менеджерами по медицинским данным. Они шутят, что программисты и доктора говорят на разных языках, в которых совпадают только предлоги. Менеджеры по медицинским данным выступают посредниками между нами и врачами, причем помогают не только в коммуникации, но и при разработке систем: благодаря медицинскому бэкграунду они знают о потребностях будущих пользователей и помогают правильно интерпретировать источники, которые нужно оцифровать.

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

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

Информационные технологии спешат на помощь

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

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

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

Источник: Evercare

Изображение: Evercare