Веб-сервисы широко применяются для интеграции между компонентами одной системы или между различными системами. Популярность веб-сервисов как способа интеграции обусловлена их универсальностью, а также простотой реализации и отладки. Универсальность связана с передачей данных с помощью интернета и протокола HTTP. Веб-сервисы дают возможность относительно легко построить интеграции между компонентами, написанными на разных языках, запускаемыми на разных операционных системах и платформах. Простота реализации веб-сервисов достигается за счет встроенных во многие IDE средств и компонентов, позволяющих быстро разработать как сам веб-сервис (provider side), так и необходимый код для вызова сервиса на стороне клиента (client side). Отладку сервисов упрощает использование понятных человеку форматов обмена данными — XML и JSON. Кроме того, существует множество утилит для отладки и тестирования сервисов, в том числе нагрузочного.

В этой статье рассмотрим несколько способов создания веб-сервисов непосредственно из СУБД Oracle, то есть без использования сторонних средств.

Обычно фреймворк EF Core используют в сочетании с MS SQL — другим продуктом Microsoft. Однако это не догма. Например, мы в CUSTIS пишем бизнес-логику на C#, а для управления базами данных используем Oracle. В EF Core есть замечательный механизм миграций, но в нашем случае они не идемпотентны. Дело в том, что Oracle и ряд других БД, например MySQL, не поддерживают транзакционный DDL. Значит, если миграция упадет где-то посередине, ее не получится ни накатить, ни откатить. Как же реализовать идемпотентные миграции на EF Core без MS SQL?

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

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

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

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

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

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

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

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

Встречали ли вы в C# конструкцию типа using (var scope = new TransactionScope(TransactionScopeOption.Required))? Это значит, что код, выполняющийся в блоке using, заключается в транзакцию и после выхода из этого блока изменения будут зафиксированы или отменены. Звучит понятно, пока не начинаешь копать глубже. И чем глубже копаешь, тем «страньше и страньше» становится. Во всяком случае, у меня при более близком знакомстве с классом TransactionScope и вообще транзакциями .NET возникла целая уйма вопросов.

Что за класс TransactionScope? Как только мы используем конструкцию using (var scope = new TransactionScope()), все в нашей программе сразу становится транзакционным? Что такое «управляющий ресурсами» (Resource Manager) и «управляющий транзакциями» (Transaction Manager)? Можно ли написать свой управляющий ресурсами и как он «подключается» к созданному экземпляру TransactionScope? Что такое распределенная транзакция и правда ли, что распределенная транзакция в SQL Server или Oracle Database — это то же самое, что и распределенная транзакция .NET?

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

Приходя на новый проект, я регулярно сталкиваюсь с одной из следующих ситуаций:

1. Тестов нет совсем.
2. Тестов мало, их редко пишут и не запускают на постоянной основе.
3. Тесты присутствуют и включены в CI (Continuous Integration), но приносят больше вреда, чем пользы.

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

Что можно сделать, чтобы изменить сложившуюся ситуацию? Идея использования тестов не нова. При этом большинство туториалов напоминают знаменитую картинку про то, как нарисовать сову: подключаем JUnit, пишем первый тест, используем первый мок — и вперед! Такие статьи не отвечают на вопросы о том, какие тесты нужно писать, на что стоит обращать внимание и как со всем этим жить. Отсюда и родилась идея данной статьи. Я постарался кратко обобщить свой опыт внедрения тестов в разных проектах, чтобы облегчить этот путь для всех желающих.

Гравюра М. Эшера «Относительность», 1953

Введение

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

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

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

Приведенные в статье фрагменты кода — на языке C#. На GitHub можно найти примеры реализации механизмов интернационализации с использованием двух различных связок ORM и СУБД: NHibernate + Oracle Database и Entity Framework Core + SQL Server. Разработчикам, использующим упомянутые ORM, будет интересно узнать конкретные приемы и трудности работы с многоязычными данными, а также блокирующие дефекты фреймворков и перспективы их устранения. Изложенные ниже принципы и примеры работы с многоязычными данными легко перенести и на другие языки и технологии.

Ранним утром 20 мая мы, команда организаторов первого в истории CUSTIS хакатона, радовались разгоравшемуся теплому дню (что для весны 2017 — эксклюзив). Каждый думал о своем: админы изучали графики нагруженности Wi-Fi-диапазона, девушки из PR- и HR-отделов сверлили взглядом списки участников, кураторы из департамента разработки почему-то вспоминали Макаренко и лучшие навыки управления распределенными командами. Антикафе во «Флаконе», где мы должны проводить хакатон, еще закрыто, узкие проезды между лофтами еще не наполнились густым туманом от вейпов и гулом гироскутеров. Мы были уверены в том, что все готово, но легкое волнение нас не покидало.

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

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

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

Гравюра М. Эшера «Вавилонская башня», 1928

Введение

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

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

Во-первых, сборная солянка — абстракция локали (locale). Локаль включает не только язык, но еще и письменность, календарь, правила форматирования чисел, денежных единиц, дат и пр.

Во-вторых, Юникод. Юникод — это не просто таблица кодирования символов. Это еще и различные формы одних и тех же букв, диакритические знаки, порядок сортировки символов, правила изменения регистра, алгоритмы нормализации строк, семейство кодировок UTF и многое другое.

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

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

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

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

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

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

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

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

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

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

Проблему разделения бизнес-логики и работы с данными на уровне отдельного приложения решает широко известный и не раз описанный на «Хабрахабре» архитектурный шаблон Data Access Layer (DAL). Для того, чтобы этот шаблон можно было масштабировать до уровня всего предприятия, необходимо дополнить его рядом архитектурных принципов, которые рассматриваются в данной статье. Следование этим принципам позволит предприятию осуществлять контролируемую (управляемую) замену или добавлять технологии хранения данных в свою архитектуру ИТ.

«Ландшафт» СУБД в проектах нашей компании до недавнего времени выглядел так: большую часть составляла Oracle, существенно меньшие — MS SQL и MySQL.

Но, как известно, нет ничего вечного, и недавно к нам поступил запрос о применимости Postgres в одном из наших проектов. К этой СУБД мы присматривались в последние пару лет очень пристально — посещали конференции, meetup’ы, но вот попробовать ее в «боевых» условиях до недавнего времени не доводилось.

В предыдущей статье мы рассказывали о том, что такое Attribute-Based Access Control и в чем его преимущества по сравнению с наиболее распространенным на сегодняшний день Role-Based Access Control. Пришло время рассмотреть ABAC более детально, через существующий стандарт под названием XACML.

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

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

В этой теме хотелось бы познакомить читателей с относительно новым подходом к контролю доступа под названием Attribute-based access control. Знакомство будет происходить на примере сравнения с популярным нынче Role-based access control.

Введение

До определенного момента своей жизни я ни о какой самоорганизации не задумывался. Все небольшое количество студенческих (аспирантских, junior-developer'ских) дел помещалось в голове, в нужный момент вспоминалось, а что не вспоминалось — тому не повезло. Женитьба, ремонт в квартире, рождение первенца, смена трех мест работы — все это удавалось худо-бедно удерживать в памяти. Но, как говорится, чем дальше в магазин, тем выше ставка по  кредиту. В какой-то момент у меня появилось ощущение, что я  постоянно занимаюсь «тушением пожаров» на работе, дома, в аспирантуре: провалил срок по рабочей задаче, не вспомнил о поездке к врачу с ребенком, дотянул до последнего с заказом билетов-отелей на летний отдых… О каких-нибудь хобби и получении удовольствия от жизни речи и вовсе не шло.

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

Когда долго и серьезно используешь какой-либо инструмент, неминуемо возникают претензии к нему — неудобства, с которыми сперва миришься, но в какой-то момент понимаешь, что проще один раз исправить, чем все время страдать. Хорош тот инструмент, который позволяет «допилить» сам себя.

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