Имхо, продумывать наперед лучше только в том случае, если примерно известно, куда дует бизнес. Иначе с большой вероятностью окажется, что архитектура неверно заложена не под те кейсы, в итоге придется делать тройную работу: 1) трата времени на первоначальную архитектуру 2) переделывание на новую 3) собственно, добавление фичей
Т.е. библиотек с коллбэками и созданием потоков не бывает?
Основное отличие фреймворка от библиотеки скорее в отношении к клиентскому коду, чем в наличии коллбэков/потоков. Т.е. библиотечный код нейтрален к клиентскому коду — он его просто вызывает и всё. Библиотечный код не имеет приоритета над клиентским. У фреймворка же полный авторитет над исполнением. И поэтому можно данный код пока называть фреймворком — если посмотреть исходники, то в случае ошибки, вызывается exit, убивая весь процесс, т.к. фреймворк считает себя главным. Библиотеке правильнее было бы просто возвратить код ошибки.
При этом если бы даже связь была найдена — не факт, что игры являются причиной агрессии. Ведь нельзя исключать факт, что заведомо агрессивные люди просто имеют тенденцию чаще играть в агрессивные игры (чтобы выплеснуть эмоции)
Ручное построение графа зависимостей можно разбить на составляющие подчасти, чтобы не было большой лапши где-то в main. У нас в проекте я решил делать так: для каждого корневого пакета завёл build.go с единственной функцией Build. Эта функция по сути "строит пакет". На входе принимает структуру Config с набором интерфейсов, на выходе — структуру BuildResult с набором полученных сервисов. Внутри функции — простое ручное построение (т.к. построение только в рамках пакета, то там кода не много). Функция Build может дальше делать запросы в подпакеты, в такие же соответствующие функции Build. В итоге это более-менее разумно компонуется. Но сервис у нас не большой, так что не могу точно утверждать, насколько это масштабируется. Самый корневый Build вызывается в main. В BuildResult может возвращаться интерфейс Stopper, на который делается defer для graceful shutdown. Эти интерфейсы можно тоже композировать.
Тут два варианта есть: как уже было сказано выше — паттерн Спецификация.
Второй (похожий) вариант это простейшая композиция (тоже в комментариях выше было упомянуто), т.е. есть интерфейс ProductProvider, базовая реализация возвращает все объекты, и её можно завернуть в другую реализацию интерфейса — фильтрующая/авторизующая прокси/middleware, которая вызывает другой ProductProvider и убирает ненужные элементы на основе известных ей специфичных правил (но тогда, правда, из БД будет всё тянуться в память).
Пихать кучи аргументов в функции, или множить функций (раздувая класс), так себе вариант. Штуки вроде Product::getProductsForCatalog тоже неудачный вариант, так как сущность Product начинает знать про какой-то специфичный каталог, хотя скорее должно быть наоборот (каталог знает про Product)
В нашей компании .NET используется с самого его рождения
Как вы относитесь к перенагромождению C# фичами? Помните, каким простым был C# 2? Ощущение, что фичи добавляются ради фич, чтобы имитировать деятельность. Напр., не вижу никакого смысла в новом обратном синтаксисе MyType t = new() Или, например, кому было худо от отсутствия маппинга System.IntPtr как nint?
Сейчас мне больше импонирует подход Go, где каждое новое изменение языка/стандартной библиотеки тщательно выверяется ("а стоит ли оно того?")
У вас на сайте написано «Tamagotchi for hackers», но Tamagotchi является торговой маркой Bandai; понятно, что это используется как имя нарицательное, но я бы на всякий случай убрал это слово из маркетинговых материалов.
Переводчика занесло:
Никаких "как и он".
Имхо, продумывать наперед лучше только в том случае, если примерно известно, куда дует бизнес. Иначе с большой вероятностью окажется, что архитектура неверно заложена не под те кейсы, в итоге придется делать тройную работу: 1) трата времени на первоначальную архитектуру 2) переделывание на новую 3) собственно, добавление фичей
Т.е. библиотек с коллбэками и созданием потоков не бывает?
Основное отличие фреймворка от библиотеки скорее в отношении к клиентскому коду, чем в наличии коллбэков/потоков. Т.е. библиотечный код нейтрален к клиентскому коду — он его просто вызывает и всё. Библиотечный код не имеет приоритета над клиентским. У фреймворка же полный авторитет над исполнением. И поэтому можно данный код пока называть фреймворком — если посмотреть исходники, то в случае ошибки, вызывается exit, убивая весь процесс, т.к. фреймворк считает себя главным. Библиотеке правильнее было бы просто возвратить код ошибки.
Поэтому игра "Угадай, где писал студент/джун, а где GPT2" была бы интереснее :)
Если что-то пойдет не так, что увидим в стектрейсе? Портянку внутренних деталей реализации? Как сложно отлаживать async/await?
Когда в руках молоток, все кажется гвоздями...
Эпл II создал Стив Возняк.
Стив Джобс выбрал дизайн клавиатуры.
Посещал панораму в 2019 году и никаких СМС не было.
При этом если бы даже связь была найдена — не факт, что игры являются причиной агрессии. Ведь нельзя исключать факт, что заведомо агрессивные люди просто имеют тенденцию чаще играть в агрессивные игры (чтобы выплеснуть эмоции)
"Driven" требует перед собой существительное, поэтому "mathematical driven" режет слух. По-моему, должно быть "mathematics driven", как, например, тут: https://www.researchgate.net/publication/3849483_Mathematics-driven_design
Как будто читал про себя
Ручное построение графа зависимостей можно разбить на составляющие подчасти, чтобы не было большой лапши где-то в main. У нас в проекте я решил делать так: для каждого корневого пакета завёл build.go с единственной функцией Build. Эта функция по сути "строит пакет". На входе принимает структуру Config с набором интерфейсов, на выходе — структуру BuildResult с набором полученных сервисов. Внутри функции — простое ручное построение (т.к. построение только в рамках пакета, то там кода не много). Функция Build может дальше делать запросы в подпакеты, в такие же соответствующие функции Build. В итоге это более-менее разумно компонуется. Но сервис у нас не большой, так что не могу точно утверждать, насколько это масштабируется. Самый корневый Build вызывается в main. В BuildResult может возвращаться интерфейс Stopper, на который делается defer для graceful shutdown. Эти интерфейсы можно тоже композировать.
Не вредит ли имиджу фонда на Западе присутствие Huawei в списке?
В оригинале — "US researcher Eugene Izhikevich… in 2006", в статье — "российским математиком… в 2005 году"
Забавно
Тоже об этом подумал. Может быть, автор считает себя джуном, а по факту он ближе к миддлу? Вот и "вам будет скучно", т.к. overqualified
Тут два варианта есть: как уже было сказано выше — паттерн Спецификация.
Второй (похожий) вариант это простейшая композиция (тоже в комментариях выше было упомянуто), т.е. есть интерфейс ProductProvider, базовая реализация возвращает все объекты, и её можно завернуть в другую реализацию интерфейса — фильтрующая/авторизующая прокси/middleware, которая вызывает другой ProductProvider и убирает ненужные элементы на основе известных ей специфичных правил (но тогда, правда, из БД будет всё тянуться в память).
Пихать кучи аргументов в функции, или множить функций (раздувая класс), так себе вариант. Штуки вроде Product::getProductsForCatalog тоже неудачный вариант, так как сущность Product начинает знать про какой-то специфичный каталог, хотя скорее должно быть наоборот (каталог знает про Product)
Хороший аргумент. Но большое число вариантов сделать одно и то же, конечно, вгоняют в грусть.
Как вы относитесь к перенагромождению C# фичами? Помните, каким простым был C# 2? Ощущение, что фичи добавляются ради фич, чтобы имитировать деятельность. Напр., не вижу никакого смысла в новом обратном синтаксисе
MyType t = new()Или, например, кому было худо от отсутствия маппинга System.IntPtr как nint?Сейчас мне больше импонирует подход Go, где каждое новое изменение языка/стандартной библиотеки тщательно выверяется ("а стоит ли оно того?")