https://www.youtube.com/watch?v=j2sJ8oDUVJg
Михайил Фленов - один из немногих людей, которого я уважаю и как специалиста, и как человека. Поэтому не могу не опубликовать ссылку на его интервью на канале "Мы обречены".

Поставил Vim плагин на VSCode под MacOS и Linux, на маке еще функцию Esc повесил на капслок.

Итог такой: на маке пользоваться удобно, так как там есть Command+<key> для всех быстрых операций, в первую очередь копипаст. На Linux идет наложение Ctrl+<key> и блокируются шорткарты к которым привык. Даже не всегда понимаешь что происходит, так как по привычке нажимаешь комбинацию клавиш, а результат - переход в непонятный режим.
Кстати, CapsLock в качестве escape - это очень удобно, но вот на Linux надо искать как перенастроить, на маке очень быстро выработалась привычка использовать, а на Linux каждый раз "WTF?".

Вывод такой: vim-плагин удобная штука, но на Linux надо тюнить (запрещать Ctrl+<key> в vim-плагине, подстраивать клавиши под себя). На маке гораздо удачнее интеграция проходит, почти незаметно.

Открыл для общего гостевого доступа первый архитектурный стрим.

https://platform.soer.pro/#!/pages/streams?fid=0

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

Знаю, что далеко не все знают, чем, например, отличается /mnt от /media, или /opt от /usr/local. Для всех кто хоть раз задумывался о том как содержать файловую систему своего линукса в нормальном состоянии, рекомендую посмотреть какие директории для чего должны использоваться. Да и для общего развития полезно.

https://unlix.ru/для-чего-нужна-каждая-директория-в-linux/

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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