Зрелость архитектурных идей можно отследить по наличию сформированных паттернов, направленных на решение практических проблем. У микросервисов такая зрелость наступает только сейчас, появляется много статей, которые рассказывают о подходах и шаблонах в микросервисных архитектурах.
Например, эта статья мне понравилась https://mcs.mail.ru/blog/26-osnovnyh-patternov-mikroservisnoj-razrabotki

#ссылки #архитектура

Если вы хотите завести свой АйТи бизнес в России, то скорее всего это будет очень похоже на то, о чем говорит Максим Кульгин. И с одной стороны это будет бизнес, который вполне может приносить деньги, которых хватит на оплату труда сотрудников и чуток еще останется. Но с позиции перспективы это будет довольно "тухло". Не в обиду Максиму, которого я очень уважаю, но я видел много таких стартапов, которые двигаясь ровно по той же линии, года через три упирались в то, что они не могли получить дополнительных денег из той же ниши рынка, а вместо этого искали соседние, похожие ниши.

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

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

Интересно узнать есть ли у вас желание завести что-то свое, даже понимая, что технологическим гигантом вряд ли получится стать?

https://www.youtube.com/watch?v=BnMWMYiiRIg

Прочитал тут коммент на ютубе "Архитектор должен разрабатывать архитектуру, а не разработчик". У меня для вас плохая новость, так было лет 10 назад, сегодня программист в небольшой компании (если это синьер) должен разбираться в архитектуре на уровне приложения, уметь проводить архитектурные границы и использовать хотя бы базовые архитектурные шаблоны (как минимум чистая архитектура).

Требования росли, растут, и будут расти. Ну либо пишите на WordPress )))

Про производительность Java. Я с 2006 года по 2014 год плотно работал с решениями написанными на Java для Enterprise задач. Все эти годы я сталкивался с проблемами производительности и потребления ресурсов на JAVA. Мы постоянно получали жалобы от пользователей, что все безумно медленно. И все эти годы я постоянно слышал, что JVM на самом деле очень быстрая, и это просто я не умею ее "готовить".

По поводу производительности я написал тонны писем в HP (как к разработчикам софта) и Oracle, к нам приезжали спецы разных уровней, начиная от местных, заканчивая зарубежными. Настраивали, оптимизировали, патчили... Но JVM по-прежнему жрала кучу ресурсов и тормозила.

В итоге я сдался и признал, что не могу решить эту проблему. И вот идет 2022 год и я по-прежнему слышу, что на самом деле JVM сейчас оптимизирована и по скорости сопоставима с компилируемыми языками.

Что могу сказать? Верю! Но проверять не буду. )

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

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

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

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

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

По обсуждению в предыдущем посте понял, что надо пояснить важную вещь: возможно ли из сеньера подняться в архитекторы?
Ответ - да.
Но надо понимать несколько важных вещей:
1. Я под "архитектором" в первую очередь понимаю "архитектора решения", есть еще "архитектор предприятия", "Архитектор ПО" и т.д. Самый близкий к программисту "Архитектор ПО".
2. Любой программист может влиять на свое развитие и только он определяет где работать, над какими проектами, на чем фокусироваться. Если программист хочет быть архитектором, то и фокусироваться надо на архитектуре, если тимлидом, то на управлении, если просто хочет писать код, то соответственно качать скилы разработчика;
3. Если вы решили, что код вам не интересен, а хочется в архитектуру, то вам все равно придется изучать программирование и расти как программист, потому что вам нужно будет найти работу где есть архитектор и архитектурные процессы. Сразу на архитектора "по курсам" не получится или это будет условный "архитектор ПО", которые так же пишет код как и все. но просто вот так называется.
4. Для архитектора важно качать не только программирование, но и знание инфраструктурных решений, понимать работу девопсов, уметь собирать требования и анализировать. В целом хорошо уметь в "абстракции". Архитектор должен уметь выражать мысли в понятиях отличных от кода. Соответственно надо смотреть не только на свою область, но и понимать как работают ваши коллеги. Не погружаясь глубоко, но в то же время понимая что и для чего использует ваша компания.
5. Если вы уже сеньер, в вашй компании есть архитектор решения и есть архитектурные процессы, то надо подключаться к ним. В каждом конкретном случае это может быть разные действия. У меня, например, входом послужило участие в "архитектурном комитете", я там изначально просто консультировал по техническим вопросам. А потом начал готовить требования, визировать решения по архитектуре в технической части.
6. Самое главное понимать, куда вы движетесь. Если вы просто ходите на работу, делаете задачи которые вам поручают, и просто стараетесь хорошо выполнять свою работу. То вряд-ли это приведет к тому, что вам начнут предлагать должности из тругих секций (неважно, тимлид или архитектор или еще что-то).

Выпустил три новых аудиоответа на soer.pro
Речь шла о разработке технических решений, новых идеях в программировании, и эффективном развитии в профессии.
Если интересно войдите на платформу - Развитие / Вопрос-ответ / Все вопросы

Минцифры запустило маркетплейс https://russoft.ru/ туда входит сотф, зарегистрированный в Едином реестре российского ПО.
Сейчас в маркетплейсе (блин, нельзя было нормальное название сделать?) содержится 1017 единиц отечественного ПО.
Если честно, пока выглядит очень скромно. Но движение есть, а это уже хоть что-то.

Посматриваю на JetBrains Fleet - https://www.jetbrains.com/ru-ru/fleet/
Что-то IDE следующего поколения явно пробуксовывает. Даже не пет-проектах скорости работы в интеллектуальном режиме не хватает, и это на стационарном ПК с кучей памяти и мощным процессором. Обещали гибкую распределенную систему, но пока не могут вылезти из стадии бета-тестирования.
Будем подождать, и посмотреть снова...

Запустил проект "S0ER.MEDIA" - https://s0er.ru
Это информационный сайт, где буду публиковать статьи, конспекты по архитектуре и не только, а так же тесты на проверку знаний (по версии меня, естественно). Первый тест по общим представлениям об архитектуре уже сегодня.

10 правил, которые позволят писать более качественный код - https://web.eecs.umich.edu/~imarkov/10rules.pdf

Ребята, спасибо за отклик на мой предыдущий пост. Пришло уже более 50 заявок. Поэтому пока набор остановлен.
В связи с такой активностью, на первом этапе решил отобрать чуть больше 7 человек, с учётом что часть наверняка отсеится.
В любом случае отвечу всем кто прислал письмо.

С развитием методов ИИ все больше проявляется интерес к программированию без программиста. Причем на всех этапах, начиная с момента проектирования, заканчивая моментом реализации. Прочитал статью "Towards Automatically Extracting UML Class Diagrams from
Natural Language Specifications" https://arxiv.org/pdf/2210.14441.pdf Понятно, что результаты далеки от желаемых, но интересен сам факт исследований. Исходя из статьи основные методы - это ML (в части анализа естественных языков) и генерация по шаблонам. Причем, в генерации диаграмм по шаблону я вижу наибольшую проблему. Понятно, что мы можем соотнести требования заказчика с имеющимися готовыми решениями и попробовать собрать "пазл" из того что есть, для некоторых классов повторяющихся задач это может выглядеть вполне неплохо. Но все же шаблоны по-прежнему должен создать и осмыслить человек. А хотелось бы ИИ, который может выдать неожиданный результат, найдя закономерности и решения, которые ускользают от человека.

На soer.pro выпустил 28-ый архитектурный стрим по "Чистой архитектуре". Это первая из 4-х частей.

Выпустил новую заметку на SOER MEDIA - https://s0er.ru/documents/article/3569

Существует три популярных варианта трудоустройства: работа в офисе, фриланс и удаленная работа. В этой статье я хочу поговорить о достоинствах и недостатках каждого из них.
https://s0er.ru/documents/article/3588

У меня на руках билеты в Питер на 9-ое число. Должна была быть большая конфа, но не случилось. Билеты остались, ехать или нет - вот в чем вопрос? Можно просто сгонять потусить, Питер - это всегда хорошо. Что скажете?

Стрим на часок https://youtu.be/8hrcdNOMRGA