S0ER

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

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

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

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

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

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

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

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

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

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

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

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

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

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

TGIF а значит очередной конкурс с розыгрышом подписки уровня "STREAM".
Тема свободная, публикуйте свои авторские фото в этой теме и то фото, которое соберёт больше реакций, определит победителя.
Желательно убликовать что-то свящангое с лайфстайлом программиста.

Есть общее для всех наук определение "свойства" и только в информатике из него умудрились сделать не пойми что.
Тут наверняка и проблемы перевода, и то что информатика отдельно, а программисты отдельно. Нет системного подхода в программировании, все стихийно

Кстати, да. Но мне такой терминологией пользоваться неудобно. Я не знаю кто изначально придумал отделять поля (field) от свойства (property), думаю это впервые появилось в С#. Но проблема вот в чем: поле - это техническая реализация свойства, т.е. поле - это "переменная" класса, а свойство - это геттер или сеттер для этого поля. Запутались?

Проблем в том, что эта терминология еще хуже проявляет себя когда вы работаете с заказчиком (вспоминаем про DDD и Ubiquitous Language) у вас есть объекты предметной области, и для их описания вполне достаточно свойств и методов.
Более того, если сказать бизнес аналитику, что кроме свойств в обсуждаемом объекте есть еще и поля, то он просто этого не поймет.

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

Мне кажется такие детали несущественны и только запутывают.