Привет! Меня зовут Сергей Кривонос, я Solution Architect платформы WSO2 в Росбанке. Если вкратце, то WSO2 API Manager — это комплексная, интуитивно понятная и масштабируемая платформа, предназначенная для создания и управления API. Она примечательная тем, что является опенсорсной при сопоставимой с энтерпрайз-решениями функциональности. В статье я немного расскажу о самой платформе и поделюсь опытом Росбанка в работе с продуктами WSO2 — в целом, весьма позитивным.
Паттерн Компоновщик - так же известен как Дерево, Composite.
Суть паттерна
Компоновщик - это шаблон структурного проектирования, который позволяет объединять объекты в древовидные структуры, а затем работать с этими структурами, как если бы они были отдельными объектами.
Проблема
Использование шаблона Composite имеет смысл только тогда, когда базовая модель вашего приложения может быть представлена в виде дерева.
Например, представьте, что у вас есть два типа объектов: конфигурация награды и конфигурация сундука. Сундук может содержать несколько Наград, а также несколько Сундуков меньшего размера. Эти маленькие сундуки также могут содержать некоторые награды или даже сундуки меньшего размера и т. Д.
Допустим, вы решили создать систему выдачи наград, в которой используются эти классы. Конфигурация Награды может содержать простые награды без упаковки в сундук, а также сундуки с наградами ... и другие сундуки. Как бы вы рассчитали все награды основываясь на такой конфигурации?
Вы можете попробовать прямой подход: развернуть все сундуки, просмотреть все награды и затем рассчитать награды по их типам. Это было бы осуществимо в реальном мире; но в программе это не так просто, как запустить цикл. Вы должны заранее знать классы наград и сундуков, которые вы проходите, уровень вложенности сундуков и другие неприятные детали. Все это делает прямой подход либо слишком неудобным, либо даже невозможным.
Эта статья, скорее даже не статья, а заметка, и цель ее - подсветить саму идею полезности построения моделей, которые можно использовать в процессе принятия решений, при проектировании IT инфаструктур, да и в целом любых систем. Ну и, конечно, еще раз показать сам инструмент, и подход к мышлению, необходимый при использовании этого инструмента.
Я не трачу свое время на рассуждения о высоких концепциях; я трачу свое время на решение инженерных и производственных проблем".
- Илон Маск, главный инженер/конструктор SpaceX
Я дико люблю ковыряться в чужом коде. Это одна из моих любимых специализаций. То есть я просто беру чужой код, анализирую его, читаю. Как я читал его раньше: я переводил код в русский язык. Описывал, что происходит по флоу кода, и пытался понять, что там происходит. Эти записи я в дальнейшем использовал как для написания статей в Confluence, так и для общего понимания происходящего.
С одной стороны, решение работающее. С другой, буквально через неделю-две я уже начинал сомневаться, достаточно точно ли я «перевел» с кода на русский язык? И тогда вспомнил про UML-диаграммы. И вместо того, чтобы записывать текст, стал визуализировать его и исписал неимоверное количество тетрадей.
Но в какой-то момент подумал, что хорошо бы перевести все это в электронный вид, чтобы какой-то инкремент оставался. Не фоткать же, например, для документации, свою тетрадь с каракулями. Так я нашел инструмент PlantUML — opensource-решение, которое использует графическую библиотеку graphviz, превращающее код в наглядные схемы.
Давайте вспомним, что такое Unified Modeling Language. Чаще всего в университете UML используется для описания диаграммы классов.
Make legacy great again.
Когда я только начинал работать на IBM Integration Bus, руководств по построению приложений я толком найти не мог, тем более на русском, в том числе и на Хабре. Пора это исправлять. Наша цель - построить простой сервис, который на вход будет принимать JSON с одной цифрой и возвращать её инкремент. Данное руководство работает как в десятой версии интеграционной шины, так и в одиннадцатой.
Биржевая ИТ-инфраструктура исторически включает в себя несколько торговых платформ. Три года назад мы создали еще одну. Зачем было инициировать новую разработку при многообразии существующих систем? Рассказывают Александр Стриковский и Александра Кузнецова из Блока развития торгово-клиринговых систем.
Или как понять, когда остановиться
Как-то раз мой коллега, лид разработки, после затяжного спора о том, что должно быть в системной спецификации, подошел ко мне и спросил:
— Скажи, а зачем нам вообще нужны аналитики?
— И действительно, зачем? – подумал тогда я и написал заявление
Вопрос этот, как бы крамольно он ни звучал, очень правильный. Системный анализ, как фаза разработки приложения, присутствует всегда (даже если это системы класса «Hello, world»), а вот системный аналитик, как выделенная роль – нет. Выделение отдельной специальной роли работает точно так же, как и разделение труда в обычном производстве: для маленьких задач не целесообразно, для больших задач – оправданно. При таком разделении системный аналитик забирает на себя часть задач и функций некоего «универсального» исполнителя задачи. Однако, подобное разделение труда имеет свою цену: это потеря знаний при коммуникации, более сложное управление процессом и др. В этой статье я хочу поделиться своим опытом: описать минусы крайностей и дать рекомендации по распределению обязанностей между системными аналитиками и разработчиками.
Итак, нам нужен системный аналитик, который формирует требования и разработчик, который эти требования реализует в коде.
Если спросить у любого разработчика, каким главным свойством должны обладать системные требования, он, скорее всего, скажет: «чтобы было понятно, что делать». И это проблема.
Заключается эта проблема в том, что между сбором и систематизацией требований (прямая и понятная задача аналитика) и непосредственно кодированием (прямая и понятная задача разработчика) есть область проектирования решения; задачи из этой области могут и должны выполнять обе роли.
Привет!
Мы продолжаем проводить One Day Offer, в эту субботу на очереди системные аналитики.
Мы ждём тех, кто хотел бы заниматься этим делом в крупнейшем частном банке страны. Так как это ускоренная процедура, есть ряд ограничений — например, мы рассматриваем только специалистов уровней middle и senior.
От желающих получить оффер за сутки мы будем ждать вот этого набора навыков:
Цель данной статьи - рассказать о GraphQL и Hasura человеку, который вообще ничего не слышал об этих инструментах. И, например, его карьерный путь сложился так, что ему необходимо иметь общее представление об этих инструментах и даже с ними взаимодействовать, например, для проведения тестирования. Или же ситуация иная: человек постоянно развивается, изучая новые архитектурные подходы, следит за популярными и новыми инструментами и сейчас в своем обучении дошел до GraphQL и Hasura.
Я аналитик, который сам недавно оказался в ситуации первого типа (вообще не слышал ничего о GraphQL и Hasura, каюсь), поэтому статья не претендует на глубокое погружение в тему и нацелена скорее на аналитиков и тестировщиков, которые не работали с упомянутыми инструментами.
Теперь всё, переходим к контенту с чистой совестью.
Лето закончилось 😿, а значит наступает пора айтишного движа 😉
В новом выпуске «e-legion рекомендует» Анастасия Московкина, руководитель отдела анализа, рассказывает об интересных для аналитиков мероприятиях и не только. Приятного чтения!
В предыдущих хабрапостах мы поделились open source инструментом для сравнительного анализа метагеномных данных и рассказали об открытых проектах, которыми занимается наша лаборатория мультиагентных систем.
На этот раз представляем вашему вниманию Process Flow Optimization Tool от Национального центра когнитивных разработок Университета ИТМО.
Эта статья является переводом материала «When to Mock».
Использование моков в модульном тестировании является спорной темой. Автор оригинала заметил, что на протяжении всей своей карьеры в программировании он сначала перешел от «моков почти для каждой зависимости» к политике «без моков», а затем к «только моки для внешних зависимостей».
Ни одна из этих практик не является достаточно хорошей. В этой статье Владимир Хориков покажет, какие зависимости следует мокать, а какие использовать как есть в тестах.
Статья будет полезна Junior-специалистам, которые так или иначе работают с документацией на проекте. В статье рассматриваются как сами пользовательские истории, так и критерии, по которым можно написать хорошую историю. Из статьи читатель сможет подчеркнуть и как писать истории, и как правильно дополнить их деталями, и какие детали важны, и как не перегрузить историю.
Я занимаюсь разработкой электроники. Шесть лет назад я написал свою первую статью начинавшуюся этими-же словами и увидел неподдельное внимание. Все эти годы я продолжал оттачивать свое мастерство и на текущий момент я хочу перефразировать вступление:
Я занимаюсь разработкой электроники и мне этого мало.
Чтобы немного понять что я имею ввиду предлагаю заглянуть под кат.
Эта статья цикла, посвященного российским BIM-технологиям, рассказывает о продуманном процессе проектирования внутренних инженерных систем в программных комплексах Model Studio CS Отопление и вентиляция, Model Studio CS Водоснабжение и канализация и Model Studio CS Трубопроводы.
Единая биометрическая система (ЕБС) с 2018 года используется для идентификации человека по его биометрическим характеристикам: голосу и лицу.
Чтобы получать услуги по биометрии, пользователю необходимо зарегистрироваться в системе в одном из 13,1 тысяч отделений банков. Там операционист сделает его фотографию, запишет голос и отправит эти данные в систему. А для того чтобы компании могли оказывать по биометрии различные услуги, им необходимо провести интеграцию с ЕБС.
Оператором системы является «Ростелеком», а разработкой занимаемся мы – дочерняя компания РТЛабс .
Меня зовут Сергей Браун, я заместитель директора департамента цифровой идентичности в РТЛабс. Вместе с Артуром Душелюбовым, начальником отдела развития и разработки департамента цифровой идентичности, мы расскажем, как мы создавали платформу для любой биометрии, с какими проблемами встретились и как их решали.
