В предыдущих статьях я рассказал об этапах выполнения запросов и о статистике.

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

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

Архитектор – это звучит… Звучит как-то не понятно. Наверное, поэтому всегда добавляют что-то. Ну типа «системный архитектор» или там «программный архитектор». Не то чтоб так стало понятно, что он делает, но точно кто-то важный. Я вообще пишу «архитектор информационных систем и программного обеспечения». Это ж как назовёшься -так и поплывешь! С архитекторами тут вообще такое дело – это как бы и не профессия. Ведь архитектором как стать? Либо тебя назовут таковым, либо сам назовёшься. Другого пути нет. Ни школы, ни спец. образования, никаких то там универсальных сертификатов нету. Только название и есть.

А раз оно есть – значит зачем-нибудь нужно! А нужно чтоб как-то указать на необходимость главного элемента мозаики – архитектуры. А раз нужен элемент, то за него, конечно, должен кто-то да отвечать. А раз должен, то вот и появляется такая должность.

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

Чтоб избежать проверенного классического сценария «много, дорого, бестолково» нужны ориентиры. Пунктир намеченного пути на карте требований и функционала. Это не красота и элегантность рисунков Леонардо, и не лабиринты цвета Поллока. Архитектура вообще не про искусство. Нет, все любят, когда красиво. Вот я бы строил дом, тоже бы хотел не бетонную коробку, а чтоб в вечность. Но у вечности, однако свои расценки. Так что даже Джи-мэн с кейсом полным золота хочет хайп и тренды, но строго в бюджет. Архитектура даёт парадигму.

Продолжение. К предыдущим постам и карте цикла.

Знаете, что случается, когда и архитектура вроде получилась и команда подобралась нормальная? Приходит ПОЦ. Пилотная версия. Проверка боем. Да, вы уложились в сроки и даже прошли всё внутренние проверки и тестирование на стороне клиента (UAT, SIT, PPT, ETC), так что теперь вас ждёт всё более худшее – то, что не нашли. Потому что там точно что-то спрятали. Может и не вы, но в конце точно прозвучит: «доктор, это вам!».

- Составь, пожалуйста, руководство по тому, как делать архитектуру.

С такой просьбой ко мне однажды обратились менеджеры по разработке софта в компании, где я работаю или работал (не хочу раскрывать время и место). И надо сказать, что сначала эта просьба меня здорово озадачила. На тему архитектуры софта написано много книг, и не самых тонких. Мне предлагается написать еще одну? Чем она будет отличаться от существующих? И зачем вообще им это?

Что касается "зачем", то здесь все было понятно. Цель у менеджеров была благая. Проектов в компании обычно больше, чем могут осилить штатные архитекторы. Идея была в том, чтобы архитектуру для небольших проектов делали либо сами менеджеры по разработке, либо старшие разработчики, а архитектор только проверял, направлял и помогал где нужно.

Цель хорошая, запрос хороший. Оставалось только понять, как оказать им конструктивную помощь, а не отправить читать книжки или не засесть писать свою.

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

Собственно, этот список я здесь и публикую.

Mac наступает со своим чипом M1. Новичков в этой экосистеме должно заметно прибавиться. Сам я многие годы с уважением смотрел на эти интерфейсы. Слушая какой же Mac удобный, плавный и интуитивный. Какой там великолепный Trackpad, что даже мышь не нужна и бла бла бла. И вот, после 15 лет работы CAD разработчиком, я решил поменять профиль и стать программистом. А чтобы не терять мотивацию в процессе обучения, выбрал для себя наиболее наглядное направление, как мне показалось — iOS разработка. Сказано — сделано. MacBook Pro 16” уже год мой основной компьютер.

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

Книга, опыт выпуска которой и послужил источником данного материала, в статье ранее https://habr.com/ru/post/512460/ набрала тысячи скачиваний и десятки благодарных отзывов. 

Для тех, кто хочет узнать, как работает книжное дело сейчас, выкладывать ли онлайн самому или сотрудничать с издательством, сколько получают авторы, как попасть на полки Буквоеда, Читай-города, в главные интернет-магазины, и все ли решают лайки — прошу:

Вышла 16-я версия платформы Java SE. В этот релиз попало около двух с половиной тысяч закрытых задач и 17 JEP'ов. Изменения API можно посмотреть здесь. Release notes здесь.

Уже сейчас доступны для скачивания дистрибутивы Oracle JDK и OpenJDK.

Хочу рассказать о том, как мы оптимизировали наш оркестратор микросервисов.

Потому что в случае с такого рода сервисами наш любимый подход "пихаем в базу - строим индексы" не работает. Как минимум потому что базы нет).

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

Забегая вперёд, могу сказать, что переход на неблокирующий веб-клиент для нашего оркестратора, в разы увеличил производительность, а ещё, если думаете использовать WebClient совместно с CompletableFuture, то лучше не надо имеет смысл кое-что проверить.

«Отличие enterprise [решения] от всего остального — он всегда идёт от запросов бизнеса и решает какую-то бизнес-задачу.» [src]

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

Возможно, ваша компания захочет перейти на архитектуру микросервисов и автоматизировать рабочие процессы (в этом посте блога я не вдаюсь в мотивацию, но вы, возможно, захотите прочитать о 5 Workflow Automation Use Cases You Might Not Have Considered или BizDevOps — the true value proposition of workflow engines). Это ставит вас в ряд со многими нашими клиентами. Как правило, у вас возникнут вопросы:

• Область применения и границы — какой рабочий процесс вы хотите автоматизировать и как он ложится на несколько микроуслуг, или разраниченный контекст в вашем ландшафте. Я ограничен объемом этого поста, поэтому я не затрону эту тему сегодня, но вы, возможно, захотите прочитать Avoiding the «BPM monolith» when using bounded contexts или Real-Life BPMN.
• Стек и инструменты — какой движок процессов я могу использовать?
• Архитектура — я запускаю движок процесса централизованно или децентрализованно?
• Управление — кто владельцы модели рабочего процесса и как ее развертывать?
• Операции — как мне сохранить контроль?

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

О чем речь 

1. как реагирует UI, когда пользователь использует фильтры;
2. алгоритм формирования значений фильтров; 
3. шаблоны запросов и структуры индекса ElasticSearch с пояснениями.

1. Быть декларативным — не императивным. Vuecket не диктует какие-то специальные требования к коду. Он может быть приложен достаточно быстро и легко к уже существующим Vue.JS или Apache Wicket проектам.
2. Следовать принципу Парето. Vuecket должен обеспечивать 80% нужного функционала из коробки, но для оставшихся 20% должны быть хорошие и удобные точки расширения.

Elasticsearch — поисковый движок с json rest api, использующий Lucene и написанный на Java. Описание всех преимуществ этого движка доступно на официальном сайте. Далее по тексту будем называть Elasticsearch как ES.

Подобные движки используются при сложном поиске по базе документов. Например, поиск с учетом морфологии языка или поиск по geo координатам.

В этой статье я расскажу про основы ES на примере индексации постов блога. Покажу как фильтровать, сортировать и искать документы.