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

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

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

Выпустил ролик-обзор по двум рест-плагинам для VSCode по Rest Clinet-у не "дожал", потому что использую его сильно меньше чем Thunder. Но там функциональности тоже много.
https://www.youtube.com/watch?v=HtZGpakYdeY

Успех - это когда твои стримы по архитектуре начинают использовать другие люди, для подготовки своих обучающих курсов. Если вы тупо не копируете видео, а просто используете информацию, которую я рассказал, то спрашивать у меня разрешения не нужно.
Я всего лишь собрал материал воедино из многих источников, плюс добавил описание своего опыта. Я не обладаю "исключительными правами" на эти знания. Более того, все мои ролики на Ютубе выходят по Creative Commons, их тоже можно использовать как хотите, не спрашивая у меня разрешения.

Комментарий к видео про REST-плагины.
У меня только один вопрос: а почему не Katalon?

На ютуб канале Sacred Developer вышло дополнение к моему ролику по рест клиентам: https://www.youtube.com/watch?v=8sn-m37lC4I
В видео детально рассмотрен Rest Client для VSCode

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

Выпустил ролик с обзором API https://www.youtube.com/watch?v=cWW-dRWedXM

https://www.youtube.com/watch?v=lKRD9ZnIYWk
На it каналах в ютубе периодически пытаются сделать видео в формате шоу. Я помню Форт Боярд математиков, трансляции от ExtreamCode, что-то подобное пытались делать и другие ребята. Но мне зашел вариант от Ромы Сакутина. У него уровень производства роликов значительно вырос за последнее время. Так что для пятничного расслабона можно посмотреть.

Осторожно маты!

Частый вопрос на многих стримах и интервью: "насколько сильно русскоговорящее, а в частности российское комьюнити разрабов?". Если коротко - очень сильно, вероятно одно из лучших (может быть лучшее) в мире. Нет такой сферы разработки, где не были бы представлены продукты разработанные нашими. Чтобы не быть голословным, на вскидку могу перечислить следующие направления и примеры:
- разработка языков программирования (пример Kotlin)
- редакторы кода (Intellij Idea и линейка продуктов)
- поисковые системы (Яндекс и целая ферма веб-продуктов)
- веб-серверы ( nginx)
- 3d движки реального времени (пример, unigine, который по технологиям бьет даже Unreal Engine)
- СУБД (например, ClickHouse)
- Виртуализация (Parallels)
- Потоковое вещание видео (Flussonic Media Server)
- Картография (2gis)
- Инженерный софт (Compas 3d)

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

https://www.youtube.com/watch?v=T2ciVvHripM
Я поддерживаю Владилена, а Борода пусть идет нахуй со своим мнением.

Научиться писать код - дело нехитрое. У меня ребенок в 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