Сегодня раздал четыре наклейки. Две планировал отдать, а две подарил подписчику которого рядом с ЖД вокзалом Сочи встретил. Так что если увидите меня, то смело подходите, у меня несеолько наклеек всегда с собой.

Закончил чтение книги. Что могу сказать? Довольно водянистый труд о масштабировании и надежности, вроде все базворды использованы "масштабирование", "надежность", "облака" и т.д. Но после прочтения складывается ощущение небрежности автора, как будто не хватило времени на оформление и продумывание деталей.
На протяжении всей книги пытаешься удержать смысл повествования, вместо того чтобы плавно переходить от темы к теме, идет какое-то постоянное разглагольствование ни о чем.

Не рекомендую эту книгу. Прочитал потому что надеялся, на чудо. Не получилось.
#обзор #книга

Почему кодинг проигрывает архитектуре?
Я думаю все хотя бы раз слышали, а может быть и сами говорили фразу смысл которой сводится к следующему - "бизнесу важен продукт, а не идеальный код". Это действительно так. Знание всех нюансов языка программирования уже давно не требуется от среднего разработчика. Более того, многие языки слишком сложны для одного человека, тот же С++ стал настолько сложным, что знать его во всех нюанса просто невозможно.
Если еще 10 лет назад активно продвигалась идея глубоко знания языков программирования, то сегодня это требование не играет основную роль. Если раньше была глубокая уверенность, что код вечен, то сейчас время от времени, да промелькнет вопрос про no code. И даже если код все равно нужно будет писать, не окажется ли, что писать код сможет AI (привет Copilot)?
Таким образом получается, что код хоть и важен для разработки, но глубоко знание языков программирования уже не так уж и важны. Писать код можно научить любого, да с ошибками, да не идеально. Но так или иначе все давно привыкли к тому, что программисты вечно ошибаются и потом исправляют свои ошибки.
Так же стоит отметить, что программисты пишут не так много кода, большая часть любого проекта - это готовые фреймворки и библиотеки, а меньшая - бизнес-логика.
Программистов становится больше, уникального кода становится меньше и все чаще возникает необходимость сделать так, чтобы в проекте можно было объединить много разработчиков, так чтобы они не мешали друг другу. И вот тут мы обращаемся к архитектуре - неважно, есть у нас код, нет у нас кода, архитектура до сих пор нужна на всех уровнях производства программного обеспечения. Без архитектуры предприятия не обходится ни одна крупная компания, без системной архитектуры не обходится ни один крупный проект, на уровне кода тоже активно внедряют архитектуру (не зря Роберт Мартин написав "Чистый код" решил написать "Чистую архитектуру").
Вот и получается, что в приложениях будущего значимость архитектуры будет все выше, а кодинга все ниже.

🎉 у меня в now первая сотня подписчиков. Прямо очень этому рад. Приложение становится круче и круче, оно мне даже больше чем инстаграм нравится.

Информация для всех у кого PRO.

Обновил архив двумя видео по архитектуре, которые выйдут в июне и июле. Темы видео - архитектурные границы, инверсия зависимостей и управления.

Так же учел ваше пожелание и добавил информацию о размере файла при скачке стримов.

Совсем забыл сказать, в этом месяце снова подарю PRO подписку на soer.pro, кандидат уже есть, он сделал хороший вклад - закрыл issue по отображению ответов на вопросы в виде списка.

Если кому-то хочется поучаствовать в OpenSource проекте на ангуляр, то я буду рад вашей помощи. Самый активный получит PRO.

https://github.com/soerdev/soer

Начал записывать короткие видео с простыми советами. Такие шорты для моего канала всегда были очень болезненны. Интересно ваше мнение, стоит снимать их дальше, или нет? Голосуем - палец вверх - нужно, все остальное - нет.
https://www.youtube.com/shorts/qOmcabTfRnA

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

Наблюдаемый в моем пузыре софт мало того, что не становится надежнее, а скорее наоборот, с каждым годом качество падает все сильнее.
Заметно упало качество визуальных интерфейсов. Кстати, с интерфейсами в отечественных продуктах чуть лучше, чем в европейских. Почему-то у нас еще стараются сделать "красиво". А вот европейский софт сугубо функционален и до невозможного прост. Что по идее должно было сделать его надежнее, но глюков и ошибок хватает.
Кстати, медицинский и банковский софт обновляется крайне медленно, многие продукты используются еще с прошлого века и никто не торопится их менять. Аппараты УЗИ, рентгены и прочее идет со старомодным десктопным софтом, которая сделан по-старинке. Во многих случаях требуется сертификация, которая строится на сложных процедурах, и никто не говорит, что их надо упростить или упразднить. Потому что контроль качества не достигается регулярными дейликами, а достигается осуществлением скучных регламентных процедур, которые плохо ложатся на Agile манифест.

Эта книга как-то прошла мимо меня. Недавно посоветовали ее прочитать, оказалось, что книга очень годная.
В книге есть пара слов про "ментальное программирование", довольно хорошо написано про UML, приведены основные паттерны проектирования, хоршо описан SOLID. В общем рекомендую почитать шарпистам, особенно новичкам.
Правда, один из авторов - Роберт Мартин, отсюда большое пересечение с другими его трудами и много длинных историй (которые на любителя)
#обзор #книга

https://vc.ru/flood/20942-agile-victims
Хорошая статья про Agile и ожидаемые комментарии "вы просто не умеете готовить".

https://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mistake-Tony-Hoare/
Вечно забываю кто виноват в создании NULL, теперь надеюсь будет проще найти

Я считаю, что называть callback признаком функционального программирования - неверно. Но это мнение очень распространенно, мол если есть callback, то это функционально. На самом деле нет и вот почему:

1. Callback можно было использовать еще в Си, там это делалось через передачу указателя на функцию, которую нужно выполнить. Ничего функционального в этом нет, это все та же подпрограмма, которая вызвана косвенно, а не напрямую.

2. Чего не было в Си, так это анонимных функций, т.е. подпрограмм без имени, которые еще называют лямбдами, такие вещи появились в более поздних языках, но сказать что лямбда - это функциональное программирование тоже нельзя, так как функциональное программирование - это парадигма в рамках которой функции рассматриваются в их математическом смысле, т.е. декларативно. Функция в функциональном программировании - это не подпрограмма.

3. В теории программирования есть понятие функция первого порядка, это значит что функция может быть передана как аргумент функции. Этот принцип используется и в ФП, и в структурном программировании, и в ООП. Но вот "чем" является функция определяется в каждой парадигме по разному. Поэтому сказать, что если у нас есть функция и мы можем ее использовать как представителя первого класса, то это ФП - неверно. Обязательно еще нужно рассмотреть как в ЯП реализована работа с функциями, если это декларативный подход, то да, речь о ФП, но если это императивная процедура, то ни о каком ФП речи не идет.

Что если я вам скажу, что если вы пишите ООП код в котором есть синус, или косинус, или любое арифметическое действие, то вы пишите в функциональном стиле? Или если я скажу, что функциональные языки позволяющие использовать полиморфизм используют объектно ориентированный стиль?
Звучит как минимум странно, потому что ни ФП, ни ООП не обладают монополией на использование тех или иных инструментов.

Чуть логичнее выглядит рекурсия, тут, наверное, большее количество согласится с тем, что рекурсия - это из мира ФП, хотя это тоже не так. Рекурсия все так же - математический термин. Если у вас в ЯП есть возможность вызвать любую функцию, то это значит, что себя вызвать тоже можно.
Вот только эта возможность в ООП языках не особо нужна, так как есть циклы. А в ФП языках это вещь без которой не обходится ни одна сколько-нибудь серьезная программа.

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

Поэтому математические метафоры в информатике это не 100% матчинаг на первоначальную математическую модель.

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

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

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

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

Как я уже сказал, монады в ООП стали просто интерфейсами (т.е. метафора приняла ограничения парадигмы), причем интерфейсами которые ограничивают реализацию. Такие вещи принято называть "паттерн", т.е. мы говорим не только какие методы должны быть в классе, чтобы он реализовывал интерфейс монады, но и ограничения, которая являются монаидическими законами.

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

Чем хороши монады? Основное их свойство - не нарушать цепочки вызовов, т.е. зная что ваш класс реализует интерфейс монады вы можете с высокой долей уверенности сказать, что он будет корректно вести себя в цепочках вызовов.

Является ли это ФП стилем? На мой взгляд нет. На самом деле интерфейс монады состоит всего из двух методов, причем к ним можно прийти вполне интуитивно, как было сделано в том же итераторе. При этом даже нарушив законы монады, мы не сломаем нашу программу, потому что у нас ООП, а не математика.