Банковская карта — вещь такая же привычная, как смартфон: есть у большинства, и ей пользуются ежедневно миллионы людей. Впрочем, именно «карта» постепенно становится пережитком прошлого, уступая место тем же смартфонам в качестве платёжного средства. Но и пластиковыми кредитки были далеко не всегда. А какими были? Вернёмся в 1888-й — к самому началу.

В этой статье я дам краткую вводную, что такое Archi и ArchiMate. Расскажу о коллективной работе с Archi используя расширение coArchi, после чего предоставлю контейнер позволяющий автоматизировать работу по созданию HTML и PDF документов с ArchiMate моделями. Завершим же, созданием своего GitHub Action, настроим GitHub и GitLab пайплайн с последующей публикацией модели в GitHub/GitLab Pages.

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

Для начала скажу пару слов о себе.
Я работаю в области машинного обучения уже несколько лет, успев потрудиться за это время в нескольких компаниях на разных ролях, связанных с исследованиями и разработкой. Сейчас я работаю в R'n'D команде, где занимаюсь исследованиями в области NLP (Natural Language Processing) и подготовкой публикаций на конференции А*. Думаю, этой информации достаточно в качестве контекста, который поможет читателям лучше прочувствовать глубину моего культурного шока от контакта с феноменом под названием УИИ.

Данный проект рассматривается как pet-project. Любую критику и советы готов увидеть в комментариях.

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

Репозиторий с исходным кодом: https://github.com/theartofdevel/notes_system

Видео версия: https://www.youtube.com/watch?v=Txi95RQPRP0

Под катом текстовая расшифровка.

О сложных системах простыми словами.

В шпаргалке на высоком уровне рассматриваются такие вещи, как протоколы коммуникации, DevOps, CI/CD, архитектурные паттерны, базы данных, кэширование, микросервисы (и монолиты), платежные системы, Git, облачные сервисы etc. Особую ценность представляют диаграммы — рекомендую уделить им пристальное внимание. Полагаю, шпаргалка будет интересна всем, кто хоть как-то связан с разработкой программного обеспечения и, прежде всего, веб-приложений. Буду признателен за помощь в уточнении/исправлении понятий, терминологии, логики/алгоритмов работы систем (в рамках того, что по этому поводу содержится в оригинале), а также в обнаружении очепяток.

Выражаю благодарность Анне Неустроевой за помощь в редактировании материала.

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

System Design (сборник на английском языке).

Данная статья является продолжением первой части: "PostgreSQL 16. Организация данных. Часть 1".

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

PostgreSQL очень популярная СУБД. Её используют во многих проектах, как новички, так и профессионалы. Однако не все понимают, как именно работает данная система и какое у неё внутренне устройство.

Давайте разберемся вместе на основе книги «PostgreSQL 16 изнутри» и официальной документации!

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

Вместо введения

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

Микросервисы. С хайпом вокруг них, лучше быть разработчиком, архитектором, тестировщиком, проджект-менеджером, дизайнером. Хорошо быть кем угодно в микросервсиах, но только не аналитиком. Аналитик ведь всегда во всем виноват. Ни разу не слышал, чтобы в “факапе” и срыве сроков обвинили архитектора, ну или там разработку. Нет, господа, вина всегда лежала и будет лежать на плохой документации и нечетко поставленных задачах. Вот вся команда собралась и тычет в тебя пальцами. Дескать, это все он! Опытный архитектор спроектировал, хороший разработчик сделал, внимательный тестировщик протестировал, мотивированный проджект-менеджер обеспечил… а невнимательный аналитик все завалил. А меж тем, материалов по аналитике и как её вести на русском языке очень мало. И как “анализировать” эти самые микросервисы не совсем понятно. Более того, никто вам не скажет, чем “системный аналитик” теперь отличается от “солюшн архитектора”. Вот во всем этом я и захотел разобраться и поделиться. Поэтому, если вы не аналитик - не читайте. Вам не будет интересно. Ведь, нет в вас экзистенциального кризиса и вопросов “Кто я? и зачем я им нужен на проекте”.

Из этого поста вы узнаете, зачем добавлять в интеграционный слой бизнес-логику, что случается, когда «не летит» Service mesh, и почему иногда костыли — лучшее решение проблемы.

Привет Хабр, на связи Иван Большаков — архитектор интеграционных решений, эксперт департамента разработки ПО КРОК. Я расскажу, как мы делали интеграционный слой для CRM-системы группы контакт-центров торговой сети Пятерочка.

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

Всем привет.

С середины 2016 года мы проектируем и разрабатываем новое поколение платформы. Принципиальное отличие от первого поколения — поддержка API "тонкого" клиента. Если старая платформа предполагает, что на клиента при запуске загружается метаинформация о всем контенте, который доступен для абонента, то новая платформа должна отдавать срезы данных отфильтрованные и отсортированы для отображения на каждом экране/странице.

Высокоуровневая архитектура на уровне хранения данных внутри системы — постоянное хранение всех данных в централизованном реляционном SQL хранилище. Выбор пал на Postgres, тут никаких откровений. В качестве основного языка для разработки — выбрал golang.

У системы порядка 10м пользователей. Мы посчитали, что с учетом профиля теле-смотрения, 10М пользователей может дать сотни тысяч RPS на всю систему.

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

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

Большую часть своей рабочей биографии я занимаюсь различными финтех продуктами – Яндекс.Деньги, 1ЦУПИС и так далее. Последние два года я разрабатываю очередное платежное решение и хочу рассказать о некоторых задачах, с которыми мы встретились. Но мне интересно рассказать не только про появившиеся решения, но и, в первую очередь, про то, как вообще можно думать про архитектуру сложных систем.

Всем привет! Я Ирина Матевосян, системный аналитик в направлении продуктового и системного анализа в отделе Tinkoff Mobile Core. Мы разрабатываем общие библиотеки, которые используют все мобильные приложения экосистемы Тинькофф. 

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

САР использует слишком узкое определение

Введение

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

Событие, когда какая-то статья вызывает бурю эмоций, — крайне редкое. Первый раз такое возникло, когда я прочитал про chained replication. Меня пытались убедить, что это мощный подход и что это лучшее, что могло произойти с консистентной репликацией. Я сейчас не буду приводить доводы, почему это плохо работает, а просто приведу говорящую цитату из статьи Chain Replication metadata management:

Split brain management is a thorny problem. The method presented here is one based on pragmatics. If it doesn’t work, there isn’t a serious worry, because Machi’s first serious use case all require only AP Mode. If we end up falling back to “use Riak Ensemble” or “use ZooKeeper”, then perhaps that’s fine enough.

В моем вольном пересказе это означает примерно следующее: "У нас тут есть некий алгоритм. Мы не знаем, будет ли он работать правильно или нет. Да нам это и не важно". Хотя бы честно, сэкономило кучу времени, спасибо авторам.

И тут, значит, попадается на глаза статья: Spanner, TrueTime & The CAP Theorem. Её мы разберем по полочкам ближе к концу, вооружившись понятиями и знаниями. А перед этим разберем самые распространенные мифы, связанные с CAP теоремой.