Несмотря на то, что я считаю себя криптографом, меня не особенно привлекает слово "крипто". Не думаю, что я уже староват, но я гораздо чаще кликаю на мемы в духе "Интернет всё помнит" о том, как "крипто" раньше означало "криптография", чем на последние новости об NFT.

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

В архитектуре программного обеспечения существует один малоизвестный паттерн, заслуживающий большего внимания. Архитектура, ориентированная на данные, (data-oriented architecture, DOA) была впервые описана Радживом Джоши в отчете RTI 2007 года, а затем в 2017 году Кристианом Ворхемом и Эрихом Шикутой из Венского университета в статье iiWAS. DOA — это инверсия традиционной дихотомии между монолитным кодом и хранилищем данных (монолитная архитектура) с одной стороны, и небольшими распределенными независимыми компонентами с собственными хранилищами (микросервисы и сервис-ориентированная архитектура) с другой. В архитектуре, ориентированной на данные, монолитное хранилище данных является единственным источником состояния в системе, на которое воздействуют слабосвязанные микросервисы без состояния.

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

 - Кто в нашей компании отвечает за согласование доступа в выходные на объект N?
 - Александр Иванов.
 - А какой у него телефон?

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

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

Зрелый язык может использоваться немногими. Но он остаётся частью моей кодовой базы.

Как давнего пользователя (и активного сторонника) Scheme/Common Lisp/Racket, меня иногда спрашивают, почему я предпочитаю их. К счастью, я всегда возглавлял собственные инженерные организации, поэтому мне никогда не приходилось оправдывать это перед руководством. Но есть еще более важная аудитория - мои собственные коллеги-инженеры, которые никогда не имели удовольствия использовать эти языки. Хотя им не требуются оправдания, они все же спрашивают из интеллектуального любопытства, а иногда и из-за удивления, почему я не схожу с ума по поводу следующей крутой функции, которая будет в этом месяце добавлена в Python или Scala, или что бы там ни было в их вкусе.

BaseX является очень легковесной, высокопроизводительной и масштабируемой XML базой данных с XPath/XQuery 3.0 процессором, который имеет полную поддержку W3C Update и Full Text спецификаций. Интерактивный и дружественный графический интерфейс позволяет легко изучать ваши XML документы

Хочу представить публике фрагмент вот этой недавно вышедшей книги:

Онтологическое моделирование предприятий: методы и технологии [Текст]: монография / [С. В. Горшков, С. С. Кралин и др.; отв. ред. С. В. Горшков]. — Екатеринбург: Изд-во Уральского ун-та, 2019. — 234 с.: ил., табл.; 20 см. — Авт. указаны на обороте тит. с. — Библиогр. в конце гл. — ISBN 978-5-7996-2580-1: 200 экз.

Цель выкладки этого фрагмента на Хабре троякая:

• Собрать вопросы и замечания, чтобы учесть их при включении этого текста в переработанном виде в другие издания.
• Внести дополнения, не очень совместимые с форматом печатной монографии: злободневные примечания (ниже они под спойлерами) и гиперссылки; а также внести исправления (ниже они никак не выделены).
• Многие адепты Semantic Web и Linked Data до сих пор считают, что их круг столь узок в основном потому, что широкой публике все еще по-хорошему не объяснили, что же это такое — Semantic Web и Linked Data. Автор фрагмента, хоть к этому кругу и принадлежит, такого мнения не придерживается, но, тем не менее, считает себя обязанным сделать еще одну попытку.

Semantic Web и Linked Data подобны ближнему космосу: жизни там нет. Чтобы отправиться туда на более-менее длительный срок… ну, не знаю, что говорили вам в детстве в ответ на «хочу стать космонавтом». Но понаблюдать за происходящим можно и находясь на Земле; стать астрономом-любителем или даже профессионалом гораздо проще.

В статье речь пойдет о свежих, не старее нескольких месяцев, трендах из мира RDF-хранилищ. Метафора в первом абзаце была навеяна вот этой эпических размеров рекламной картинкой.

Перед вами история интегрирования БЭМ-методологии в React-вселенную. Материал, который вы прочитаете, построен на опыте разработчиков Яндекса, развивающих самый масштабный и нагруженный сервис в России — Яндекс.Поиск. Мы никогда раньше не рассказывали настолько подробно и глубоко о том, почему делали так, а не иначе, что нами двигало и чего мы действительно хотели. Внешнему человеку доставались сухие релизы и обзоры на конференциях. Лишь в кулуарах можно было услышать нечто подобное. Я как соавтор негодовал из-за скудности информации снаружи каждый раз, когда рассказывал о новых версиях библиотек. Но в этот раз мы поделимся всеми подробностями.

Все слышали о методологии БЭМ. CSS-селекторы с подчёркиваниями. Компонентный подход, о котором говорят, имея в виду способ написания CSS-селекторов. Но про CSS в статье не будет ни слова. Только JS, только хардкор!

Всем привет.

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

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

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

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

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

Несколько лет назад я разрабатывал для одного большого телекома новую информационную систему. Нам приходилось взаимодействовать со всё нарастающим количеством веб-сервисов, открываемых более старыми системами или бизнес-партнёрами. Как вы понимаете, мы получили добрую порцию SOAP-ада. Заумные WSDL, несовместимые библиотеки, странные баги… Где только возможно мы старались продвинуть — и использовать — простые RPC-протоколы: XMLRPC или JSONRPC.

Вступление

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

Для начала спросим себя, зачем нам вообще оформлять права?