GDPR вступил в силу уже четыре года назад, однако его понимание и практика применения до сих пор развиваются. Как показывают последние новости, далеко не все преуспели в борьбе за соответствие – в январе Google и Facebook получили серьёзные штрафы (на €150 млн и €60 млн соответственно) за нарушения законодательства в отношении cookies, причём для Google это уже второй штраф за них (предыдущий был на €100 млн). Именно тема cookies постепенно становится "горячей": ей занялись не только регуляторы, но и активисты. Правила, действующие в отношении cookies, основываются частью на GDPR, частью – на ePrivacy Directive. В этой статье собрано текущее понимание этих правил для практического применения.

Всем привет! В недавней статье мы рассказали, как мы шли к построению нашей Data Platform.

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

То есть, если возвращаться к финальной схеме из упомянутой выше статьи (специально дублирую ее ниже, чтобы уважаемым читателям было удобнее), то сегодня мы будем более углубленно говорить о реализации «правой части» схемы — той, что лежит после Apache NiFi.

История

iframe

Certificate verification: chain

При автоматизации бизнес-процессов предприятия часть задач всё равно должен выполнять человек: это согласование различной информации, обогащение данных из аналоговых источников и многое другое. В интеграционной шине InterSystems Ensemble для решения данного класса задач есть подсистема Ensemble Workflow, позволяющая людям участвовать в автоматизированных бизнес-процессах. В результате работы подсистемы Ensemble Workflow накапливается большой объём информации о том кто и сколько выполнял поставленные задачи. В этой статье с использованием BI-технологии InterSystems DeepSee, про которую я недавно уже писал на Хабре мы проанализируем и визуализируем эту информацию.

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

­­ 

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

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

На мой взгляд, написание библиотек на Go — довольно хорошо освещенная тема… а вот о написании приложений (команд) статей гораздо меньше. Когда дело до этого доходит, весь код на Go представляет собой команду. Так давайте об этом и поговорим! Этот пост будет первым в серии, т.к. у меня много информации, которой я еще не делился.

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

Пару недель назад, я решил взять простейший пример HTTP сервера на Go и измерить его производительность. Потом я смело взял Phoenix, прогнал на тех же тестах, и расстроился. Результаты были не в пользу Elixir/Erlang (45133 RPS у Go и всего 3065 RPS у Phoenix). Но Phoenix — это тяжело. Надо что-то хотя бы примерно равное по простоте и логике разработки тому, что есть на Go: когда есть путь — "/" и handler для него. Логичной аналогией мне показалось решение cowboy + plug, где у нас есть Router, который так же ловит "/" и отвечает на него. Результаты убили — Elixir/Erlang опять оказался медленнее:

Golang
sea@sea:~/go$ wrk -t10 -c100 -d10s http://127.0.0.1:4000/
...
  452793 requests in 10.03s, 58.30MB read
Requests/sec:  45133.28
Transfer/sec:      5.81MB

elixir cowboy plug
sea@sea:~/http_test$ wrk -t10 -c100 -d10s http://127.0.0.1:4000/
...
  184703 requests in 10.02s, 28.57MB read
Requests/sec:  18441.79
Transfer/sec:      2.85MB

Как жить дальше? Две недели я не спал и не ел (почти). Все, во что я верил все эти годы: совершенство vm erlang, ФП, зеленые процессы, было растоптано разорвано, сожжено и пущено по ветру. Немного отойдя от шока, успокоившись, и подтерев сопли я решил разобаться, в чем дело.