Откровенно говоря, давно я хотел написать эту статью. Но, постоянно отвлекали «очень важные» дела. Каждый раз я думал — вот к следующему дню матери точно напишу. Но, время шло, а «важные дела» не кончались.

Сегодня я это все же сделаю!

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

Сегодня в сообществе ИТ архитекторов, поддерживающих подход “Архитектура как код”, все чаще появляются упоминания о его перспективах выйти на уровень нового индустриального стандарта. Можно было бы сказать, что любое общество должно быть амбициозным и видеть себя в “Центре Вселенной”. Поэтому, не стоит об этом раньше времени статьи написывать. Но важно заметить, что архитекторы облечены ролью и должностью существенно влиять на решения о выборе стека и подходов в крупных компаниях. Поэтому, кажется, важно уже сегодня рассказать, что лежит в основе таких предположений.

Более года развивается инструмент управления архитектурой DocHub. За это время он “повзрослел”. Изначальная, ключевая идея “Архитектура как код”, значительно обогатилась новой - “Архитектура как данные”. 

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

Давненько я не публиковал новостей по развитию инструмента описания архитектуры кодом. А похвастаться есть чем. Сегодня я исправлю свою досадную оплошность.

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

Знаете что я больше всего ненавижу? Я люто ненавижу рамки. Ограничения, которые не дают развить мою идею. Вам знакомы эти чувства? Если да, то приглашаю в подкат поговорить.

- Саш, админы говорят, что у нас 400 полетели адово. Глянь, в чем проблема.
- Странно… все же было хорошо.

Пару часов спустя...

- Коллеги, и в очередной раз у нас изменены контракты без согласования и оповещения! Это уже не первый случай!

Сразу хочу успокоить. Сегодня SCRUM это уже не так страшно как десять лет назад. Современная медицина достигла невероятных высот. Люди со SCRUM живут полноценной жизнью. Остаются активными членами общества. Главное -  своевременно подобрать правильный режим лечения.

Всем привет, меня зовут Роман. Мне 40 лет. Из них примерно 25 лет я в ИТ. Первая моя должность - техник программист. Получил я ее в 17 лет. Без образования. В небольшом городке в глубинке России.

К тридцати годам я достиг “пика” карьеры ИТшника. Я стал ИТ директором в крупной, международной компании. Внезапно у меня возникала проблема. Проблема диалога с бизнесом.

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

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

Почти год назад я представил свой pet-проект — IoT платформу ThingJS. Честно сказать, я не достиг всех целей, которые ставил перед собой публикуя ту статью. Но работа окупилась. Удалось получить нечто иное — полезную критику.

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

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

Сижу я вчера спокойно, как водится никого особо не трогаю. Тут с двух разных контактов, почти одновременно присылают ссылку на небезызвестный твит про JSON из SQL. Одно из сообщений выглядело так:

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

Уверен, что заголовок вызвал здоровую реакцию — “ну опять началось…” Но позвольте завладеть вашим вниманием на 5-10 минут, и я постараюсь не обмануть ожидания.

Структура статьи будет такова: берется стереотипное утверждение и раскрывается “природа” возникновения этого стереотипа. Надеюсь, это позволит взглянуть на выбор парадигмы обмена данными в ваших проектах под новым углом.

Для того, чтобы была ясность в том, что такое RPC, предлагаю рассматривать стандарт JSON-RPC 2.0. C REST ясности нет. И не должно быть. Все, что нужно знать о REST — он неотличим от HTTP.

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

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

Статья будет интересна людям, которым близка тема IoT и они уже что-то делали в этой сфере. Важным замечанием будет то, что платформа должна заинтересовать (внезапно) JavaScript разработчиков, т.к. именно этот язык выбран как основа платформы. Конечно, и С/С++ разработчикам тоже будет что почитать.

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