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

Научиться играть в шахматы тоже довольно просто - запомнил как ходят фигуры и уже можешь играть. Но само по себе знание того как ходят те или иные фигуры не делает вас хорошим игроком. Так же как и умение складывать вместе команды в языке программирования не делает эти программы хорошими.

В шахматах есть целая теория, которая включает в себя изучение фаз партии - дебют, миттельшпиль, эндшпиль. Дает представление о тактике и стратегии, вводит понятие “жертва качеством”, “потеря темпа”, “развитие фигур” и самое важное - учит оценивать свою позицию.

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


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

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

Я постоянно анализирую активность вокруг архитектурных стримов, у меня есть наработанная статистика, которая показывает, что большая часть отваливается после двух-трех стримов (около 70%), из оставшихся 30%, только 10% охватывают больше 50% стримов, и лишь единицы просматривают их все.

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

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

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

Как архитектурные стримы соотносятся с целью стать хорошим архитектором?

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

Поэтому сегодня очень востребованны менторы, которые помогут и с теорией и с практикой. Самый простой способ получить ментора (да еще так, чтобы тебе за это платили) - это пойти на работу. Коллеги-менторы - это, наверное, самый простой и эффективный способ быстро прокачать свои знания и умения. Но есть проблема, в случае с архитектурой нет такой должности "джуниор-архитектор", т.е. чтобы получить ментора на работе нужно уже обладать базовым набором знаний по архитектуре. Их можно получить поднимаясь по карьерной лестнице на предприятии, а можно получить из книг и статей в Интернете.

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

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

Задача на подумать:
Архитектору аналитической системы высоконагруженного интернет-магазина приходит жалоба, что отчет по объемам продаж за месяц считаются неверно, так как за один и тот же месяц отчет, напечатанный во Владивостоке, и отчет напечатанный в Москве разнятся на несколько единиц проданного товара.

Вопрос: в чем причина, и какие варианты устранения вы можете назвать?

Все уловили суть предыдущей задачки, тогда дам задачку посложнее: "Сколько раз в России наступает восход солнца?".

"Сколько раз в России наступает восход солнца?"
Есть два рассуждения, которые мне импонируют:

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

Второй вариант отталкивается от определения "дня" - "День — промежуток времени от восхода до заката Солнца", таким образом "восход наступает один раз в день". Этот вариант ответа мне кажется самым правильным.

Начал переносить старые стримы, которые закрыты на youtube на свою платформу. Их можно посмотреть абсолютно бесплатно на https://platform.soer.pro/

1. Входите под учеткой гугла (или любой другой из списка)
2. Переходите в меню Материалы / Стримы
3. Выбираете папку "Архивы стримов"
4. Выбираете интересующий вас стрим из списка

P.S. пока опубликовал только один, но буду публиковать почти все старые стримы. Сейчас они просто лежат мертвым грузом, а так желающие смогут посмотреть.

Надежный веб-сайт, который невозможно взломать - это мечта любого веб-мастера. К сожалению многие сайты ломаются на этапе первичного сбора сведений о сайте. Утилит для такого анализа предостаточно. Вот довольно старенькая статья на хабре - https://habr.com/ru/company/dsec/blog/452836/ которая содержит неполный, но хороший список утилит для анализа сайтов.

От себя добавлю, что любая защита начинается с грамотного мониторинга. Я вижу, что мой сайт https://soer.pro анализируется постоянно. Боты его тестируют чуть ли не каждый час, на предмет открытых портов и стандартных паролей. Интеллектуальные атаки (привет подписчикам) совершаются чуть реже, где-то 1-2 раза в месяц, обычно проводят фазинг, проверку на xss, инъекции. Это автоматизированные проверки. А вот сегодня нашел аномалию, которая очень похожа на ручную попытку повысить уровень подписки с гостя, до PRO.

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

Поиск аномалий - дело сложное, но интересное. Самое простое - это когда вы сами определяете какие отклонения важны для вас. Тогда можно использовать обычные запросы к БД (вот, например, статья про запросы к Прометею - https://mcs.mail.ru/blog/kak-ispolzovat-prometheus-dlya-obnaruzheniya-anomalij-v-gitlab ).
Если хочется автоматического поиска аномалий, тот тут есть всякие регрессии, кластеризация и прочие методы стат. анализа, сейчас модным стало использовать ИИ для поиска аномалий, с помощью алгоритмов обучения без учителя. Самый простой алгоритм - ИИ выделяет фичи из "нормальных данных", и все наборы данных, где эти фичи отсутствует, показывает как аномалию. Очень часто фичи, которые находит ИИ, это статистические закономерности. Например, частота использования спец символов в логине пользователя, это очевидный признак для стат анализа, но ИИ его тоже обычно выделяет.

#ссылки #аналитика

Зрелость архитектурных идей можно отследить по наличию сформированных паттернов, направленных на решение практических проблем. У микросервисов такая зрелость наступает только сейчас, появляется много статей, которые рассказывают о подходах и шаблонах в микросервисных архитектурах.
Например, эта статья мне понравилась 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