Признаки того, что у программиста все хорошо с абстрактным мышлением:
1. Умение проектировать "на бумаге", не используя синтаксис ЯП
2. Присутствие интерфейсов и абстрактных классов в коде (dip)
3. Умение построить мат. модель или модель предметной области
4. Умение разбивать задачу на уровни абстракции
5. Понимание архитектурных границ и разделения обязанностей.

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

На soer.pro опубликовал 24ое архитектурное видео (архитектурные стримы) по проектированию RESTful приложений.

Согласны ли вы с утверждением, что принцип инверсии зависимостей (DIP) в JavaScript не применим? Палец вверх - да, остальное нет.
Если считаете, что применим, то в комментах интересно услышать как это должно выглядеть?

Вот еще один вопрос, который показывает понимание DI и IoC. Вопрос звучит так "Всегда ли при использовании (dependency injection) DI осуществляется инверсия управления (IoC)"? Палец вверх - да, остальное - нет.
Объяснение своего понимания можно дать в комментариях.

Я не зря спросил про DI и IoC. Это пример того как первоначально прозрачная и понятная концепция "замусорилась". Появился IoC 1,2,3 типа и DI (что тоже самое).
Хотя по смыслу DI куда ближе к обычному полиморфизму, а не IoC. Но концепция "управления" сложная, поди разберись кто там кем управляет и у кого прямой поток, а у кого инвертированный. Практика, как всегда, не требует таких сложных "измышлений".

Источник: https://web.archive.org/web/20040202120126/http://www.betaversion.org/~stefano/linotype/news/38/

Вопрос из чата, интересно мнение сообщества на этот вопрос.

TGIF, ну что снова пятница и снова розыгрыш подписки STREAM на soer.pro
Напоминаю, что эта подписка дает доступ к более чем 25 часам записей на тему архитектуры софта.
Сегодня у нас тема забавные случаи из жизни Айтишника. Напишите в комментариях какой-то забавный случай который произошел не обязательно с вами, но чтобы было связано с айти.
Пост который наберет больше всего реакций - победил.

Награда "Золотой Соер" наконец-то дошла до ее законного обладателя. Поздравляю еще раз!
https://www.youtube.com/watch?v=VKVE8dnAjtI

Запускаю стрим...
https://youtu.be/MARm6ttnExs

На soer.pro открыл доступ к ответам на вопросы для всех участников. Так что все желающие, совершенно бесплатно, могут заходить на platform.soer.pro в раздел "Вопрос ответ" - "Все вопросы" и слушат записи (там в основном аудио).

Я тут подумываю делать разборы на код своих коллег, сравнивать стиль, искать хорошие практики.
Отсматривая видосы, у Димыч АйТи Камасутра нашел примерчик, где он начинает id нумеровать с нуля.
Это не очень хорошая идея, потому что в JS, ноль - это falsy значение, а все остальные значения truthy.
В целом ID - это не индекс массива, он должен быть положительным числом. А ноль использовать как аналог "незаполненного поля" или null

Очень распространенное заблуждение, что идентифицируются только реальные данные.
Построение математических моделей наглядно показывает эту проблему. По сути убрав "единичный элемент" или "нейтральный элемент" мы увеличиваем количество исключений в нашей системе в разы.
Хороший пример единичного элемента - ноль. Без этого элемента даже базовая школьная математика ломается. Тоже самое происходит в программе, в которой не предусмотрен нейтральный элемент. Попытки сделать "универсальный" нейтральный элемент в виде - null в большинстве случаев не решают проблему исключений. Поэтому и появился паттерн null object.
Рекомендую всегда использовать единичный элемент для любых наборов элементов из предметной области, с уникальной идентификацией этого элемента. Этот технический момент в разы повышает устойчивость и надежность программ, позволяет легко строить математические модели, например, используя моноиды.

Илья Климов - красавчик, мне нравится его методы донесения информации. Он сильно заморачивается на методологию и я внимательно присматриваюсь к его манере подачи информации.
У UlbiTv слишком поверхностные уроки, я думаю, что они наносят больше вреда, чем пользы.

TGIF, а значит ещё один розыгрыш. Сегодня победит тот кто приведёт больше всего примеров кода в стиле "плохо/хорошо". Нужно просто привести пример двух реализаций где было не очень хорошо, а стало лучше.
Можно сделать как картинкой, так и просто вставить код в сообщение.
Автор большего количества примеров получит доступ уровня stream на soer.pro