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

Думал "напихают" за это, а "напихали" за градусник )

В дополнение к видео по моноидам выйдет еще один ролик с реализацией примера.
Пример уже сейчас можно посмотреть - https://github.com/soerdev/soer_examples/blob/latest/monoid/monoid.ts
А ролик выйдет либо в конце этой недели, либо в начале следующей.

Очень много ссылок прислали, на годные каналы. Вот такой список подписок у меня получился:

- Архитектура и теория программирования

Алексей Радзишевский https://www.youtube.com/c/АлексейРадзишевский

Максим Смирнов https://www.youtube.com/watch?v=4P5DLoaGPks

System Education https://www.youtube.com/c/SystemEducation

Эксперт по IT и организационному развитию https://www.youtube.com/user/rosssoxa

Андрей Созыкин https://www.youtube.com/c/AndreySozykinCS

- C#

Степан Береговой https://www.youtube.com/c/SBeregovoyRU

- Python

abglazov https://www.youtube.com/c/abglazov

Диджитализируй https://www.youtube.com/c/%D0%94%D0%B8%D0%B4%D0%B6%D0%B8%D1%82%D0%B0%D0%BB%D0%B8%D0%B7%D0%B8%D1%80%D1%83%D0%B9

- Java
https://www.youtube.com/c/DecembristITTV

Мне понравилось вот это видео - https://www.youtube.com/watch?v=oTz_OmgJFm8

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

Ответил на вопрос "Здраствуйте Soer. Какое у вас отношение к индустрии разработки игр? Стоит ли идти туда?" на soer.pro

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

Дима Рожков aka Senior Software Vlogger

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

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

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

Мало кто знает, что я так же был забанен во всех ресурсах SSV, может до сих пор забанен, не проверял давно.

Собственно, я пишу это к тому, что хорошие соперники могут быть гораздо лучше чем "хорошие друзья" (да, да именно в кавычках "друзья").

Вспомнилось потому что наткнулся на историю Димы на канале "Разрабы", ссылку прилагаю. А смысла в этом посте особо не надо искать, просто забавно как меняются люди и отношение к ним.


https://youtu.be/6C5joIH_amU

Иногда у меня складывается впечатление, что только я Маркса и не читал. Вокруг столько экспертов, которые в деталях цитируют Маркса, добивая цитатами Энгельса.
А вы тоже не читали Маркса? Если да - палец вверх ☝️ 👆 👍

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

Чтобы сэкономить вам время, вот ссылочка на статью, которая без воды и полезна с позиции практики.

https://borretti.me/article/lessons-writing-compiler

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

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

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

Поэтому я абсолютно серьезно рекомендую написать свой простенький компилятор, это большая инвестиция в свои профессиональные знания.

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

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

Из моих успешных друзей (т.е. кто к 40 обеспечил себя на всю оставшуюся жизнь) есть два успешных кейса:
1. сделать что-то свое (стартап или бизнес) и продать за хорошие деньги.

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

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

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

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


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

Поэтому сказать мол "сейчас" мне и так хорошо - это хорошо, но вот что будет через 10 лет - вопрос. Еси у вас есть крутая и работающая на 100% стратегия успеха, то поделитесь. Но мой опыт говорит, что вложение в свои знания - это один из основных элементов успеха.

Выпустил ролик по тому как реализовать моноид на практике.
https://www.youtube.com/watch?v=8f-BGof_JtI

Помните я рассказывал про шуточный челлендж? Где надо в течение двух недель заходить на сайт и отмечать один пункт выполненным.
Мне тут напомнили про него.
Результаты такие:
Участвовало: 38 человек

Выполнили без пропусков: 3
Выполнили с пропусками, т.е. забивали на 1-2 дня, потом вспоминали и продолжали (без предыдущих): 2
Выполнили больше половины (без предыдущих): 1

Не выполнили вообще (т.е. 0 процентов) - 8 человек
Остальные 5-16%

Таким образом результат который можно считать приемлемым у 5 из 38.

Помню когда впервые увидел проект CSS Zen Garden я был поражен тому как, используя только CSS, можно преобразить сайт (суть проекта в том, что при неизменной html верстке вы можете направить свой CSS который полностью преобразит сайт).

Сейчас есть еще более крутой ресурс - https://cssbattle.dev/

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

Почему в 2022 году все еще задают этот дурацкий вопрос "Стоит ли учить Golang?". Да, я понимаю, что есть ощущение, что важно сделать правильный выбор при выборе языка, что это каким-то образом облегчит или усложнит вашу дальнейшую карьеру.
Но почему язык, который из года в год болтается во второй десятке ЯП, вызывает столько вопросов? Потому что его сделал Google? Потому что он маленький и быстрый? Или потому что все еще есть надежда что он "выстрелит"?

Мне кажется, что Go достаточно долго существует на рынке (более 10 лет), чтобы в условиях ультра быстрой айтишной реальности было понятно, что язык обречен быть "местячковым", т.е. занимать узкую нишу для людей, которые любят выискивать "темных лошадок", которые якобы имеют большие перспективы.

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

Именно имидж делает язык популярным. Все знают, что Javanoscript - язык для школьников, Haskell - для ботанов, PHP - для душнил, С - для хакеров. А для кого создан Go? Для тех кто мечтал, но так и не попал в Google?

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

Так что учите лучше Rust, а не Go! Но это все равно не спасет от боли, потому что разрабатывать софт больно на любом языке программирования.

https://docs.microsoft.com/ru-ru/azure/architecture/guide/architecture-styles/

Лаконичная статья по основным стилям архитектуры. Ни добавить, ни убавить. Очень нравится, что есть схемы, которые легко запомнить и понять, а слов минимальное количество. Слова в архитектуре - вторичны, главное - схемы и другие визуальные средства представления идей.

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

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

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

Мне по кайфу писать на typenoscript, не потому что это лучший язык на планете, а потому что я могу сам принимать решение о том насколько жесткая система типов мне нужна.

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

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

Есть очень распространенная ошибка про "утиную типизацию", что она такая же "мощная" как строгие типы. Но это не так! Строгие типы показывают не только "наличие" нужных свойств, но так же и "отсутствие" лишних свойств.
Утиная типизация показывает только наличие "нужных" свойств, но эффективно проверить, что других "ненужных" свойств у объекта нет - невозможно (потому что множество "других" свойств бесконечно).
Строгая типипзция - exactly -> exactly car
Утиная типизация - like -> like car