Между занятиями будет по неделе практики, общения с ментором и командой, изучения дополнительных материалов по теме. Это, возможно, важнее, чем сами занятия. Не стоит списывать это со счетов.
Мы не берёмся делать архитекторов и техлидов из новичков, программа курса подобрана так, чтобы сформировать у ребят понимание, с чем разработчики сталкиваются в работе над продуктом. Более глубокое понимание придёт на стажировке и в штате, моя задача — научить понимать мотивацию за принятыми на проекте решениям, рассказать, как многочисленные инженерные инструменты и практики служат развитию продукта, чтобы было не так страшно первый раз видеть продакшн-код вживую.
Ничего страшного, если материал курса не будет усвоен на 100%, мы не торопим. Главное – чтобы был прогресс относительно стартовой точки.
Первый нанятый нами стажёр бросил университет за ненадобностью и сейчас уже проектирует свою первую небольшую фичу для продукта, так что мы знаем, как мало иногда значит высшее образование. Я готов рассмотреть любых кандидатов, готовых в течение года выйти на полный день, «3-4 курс бакалавриата» можно рассматривать как ориентир по базовым навыкам в computer science и в эффективной коммуникации.
Да, там и в их области есть кажущиеся мне существенными проблемы именно с количеством табов. Табы на нужную мне музыку я нахожу там примерно в 75% случаев, остальное либо слишком андеграунд (и UG вроде и никак не стимулирует пользователей делать и загружать табы), либо внезапно ограничено правообладателями (что UG не решает самостоятельно, а отдаёт на откуп пользователям, предлагая им писать трогательные истории правообладателям, почему именно они хотят поиграть именно эту песню). Это, конечно, самый высокий процент, который есть, но не который возможен.
Работай я у них, обязательно попробовал бы продать идею о чём-то вроде опенсорсного редактора табов с пул реквестами.
Мне основной целью этого абсурда видится создание соломенного чучела для дискредитации нормальных криптовалют среди широких слоёв населения. Последовательность такая: создаём крипторубль, называем его национальной криптовалютой, ставим галочку в графе "идём в ногу с технологическими трендами", бахвалимся, много говорим об этом в новостях. Оборот и хранение любой другой криптовалюты здорового человека запрещаем под предлогом бесконтрольности и "непрозрачности". Каждый раз, когда речь заходит о криптовалюте, тыкаем всех в крипторубль — у нас всё есть, гештальт закрыт, со своими басурманскими суррогатами не лезьте. Оказываем вялую поддержку всем энтузиастам, которые почему-то захотели этой валютой пользоваться, но в целом даём ей тихо умереть без похорон. Иногда вспоминаем её как Спутник и другие отечественные "передовые" технологии для галочки.
С удовольствием бы пользовался таким способом авторизации. Единственным минусом считаю, что при должном распространении этой модели история переписок действительно будет захламлена сообщениями от разных ботов. Но, думаю, в Telegram что-нибудь придумают с группировкой.
Не нашёл нужных скриншотов четвёртого периода, и, мне интересно, вы избавились от пиктограмм Kayle, Olaf и Karma на панели покупки юнитов и, если нет, то что об этом думает Riot Games?
Мы видимо в разных реальностях с вами работаем. В моей реальности и у меня на практике самые большие проседания по перфомансу сосредоточены в одном-двух местах. Ситуация, отражённая в приведённой вами статье, тоже кажется мне весьма искусственной. Вполне возможно, что написанный код в целом непроизводительный, если сравнивать его с аналогичным кодом на низкоуровневом языке, но если искать узкие места, то всегда находится то, что сравнительно хуже влияет на производительность приложения, чем всё остальное. И это вполне объяснимо, потому что мы вряд ли способны в начале проекта абсолютно точно знать, какая функция или какой модуль будут использоваться и переиспользоваться на полную катушку, а что будет вызываться раз в два месяца одним тестировщиком-аутсорсером. Выделять при этом одинаковые усилия на оптимизацию и того, и другого — расточительство, гораздо экономнее по результатам тестирования выявить проблемы (если они будут) и прицельно, точечно переработать кусок кода.
Моё мнение, если Unity позволяет писать на высокоуровневом языке, значит весьма бессмысленно отказываться от его достоинств. Предпочитаете производительность из коробки во вред поддерживаемости — берите низкоуровневый язык.
Я мимо проходил, Юнити не знаю, но разве здесь преждевременные оптимизации в цене? Высокоуровневые языки разработки неспроста придуманы, предполагается, что с их помощью вы можете больше времени уделять предметной области и меньше техническим деталям. Разве игры не про предметную область в первую очередь? Я сам сильно раздражаюсь, когда игра не оптимизирована и тупит на предназначенном для неё девайсе. Однако мне думается, что игры, при разработке которых все силы были брошены на преждевременные оптимизации, до меня, как до конечного потребителя, не добрались вовсе.
Реализуйте игровые концепты, делайте стройную гибкую архитектуру, используйте паттерны по необходимости. Сделайте проект легко читаемым и поддерживаемым, а потом берите профайлеры, снимайте дампы и определяйте узкие места. А то можно подумать, что ваши велосипеды будут производительнее и продуманнее, чем вдоль и поперёк исследованные проверенные годами инструменты Microsoft.
Если дотошный преподаватель принимает зачёт\экзамен только при наличии рукописных конспектов, он, наверняка, сверит почерк в конспекте и на листе с ответами. Раньше — как защита от чужих конспектов, выданных за свои, сейчас — как защита от подобных решений.
Решение хорошее, я видел рукописи, даже больше похожие на печатные шрифты и почерки с разным наклоном тоже встречал.
Если для вас это действительно важно и это не просто «хотелка», то можно сделать метод не параметризованным, а работающим, например, с double и уже результат его работы приводить к тому или иному численному типу с нужными допущениями (округления, отсечение дробной части).
Можете так же посмотреть на Scala, если у вас есть выбор. Там у операторов нет привелегированного положения и они являются обычными методами, что позволит сделать generic-метод с нужными constraints.
Как мне теперь на C# писать с такими чудовищными недостатками? Я ведь так хотел получить исключение в рантайме, просуммировав два объекта, в классах которых не определён оператор сложения.
Я бы в вашем кейсе сделал так: добавил книгу, опубликовал событие предметной области, обработчик которого создал бы автора, изменил общую статистику и изменил статистику по автору. С трудом верится, что для последних двух изменений необходима strong consistency, но для добавления книги+автора может по какой-то причине добавиться. В таком случае сначала бы добавил автора, одной транзакцией, другой транзакцией — книгу. Если добавление книги отвалится, ничего страшного, новый автор в базе никому не помешает. От конкретного кейса зависит, конечно, но в целом проблем не вижу.
Я решил, что под отчетом подразумевается «информация оформленная в удобном для пользователя виде» — статистика, графики и т.п. Если же «отчет» — это термин предметной области, то спору нет.
Так это Hydro спросил, может ли отчёт быть больше, чем просто read-модель. Да, может, но я говорю о ситуации, когда отчёт необходим как статистика, графики и т.п. И да, там достаточно только read-модели.
Но не могли бы вы пояснить (или поделиться ссылкой) — почему наличие read-логики делает CQRS неполноценным?
Автор тезисом указал, что это не реализуется с использованием DDD. Я же в этом сценарии не вижу в DDD никакой помехи: если отчёт — это бизнес-понятие, то оно должно быть отражено в виде сущности в том или ином контексте, а в терминах CQRS стать частью write-модели. Если отчёт — это лишь ещё одна проекция состояния системы и собственного жизненного цикла не имеет, то вы можете на основе имеющейся в системе информации подготовить read-модель, именуемую «отчёт» и сохранить её в максимально удобной для получения форме. Именно подготовить, а не строить на лету какие-то SQL запросы с JOIN'ами и кверить все агрегаты в системе.
Про это писал Vaughn Vernon в книге Implementing Domain Driven Design, часть его труда посвящена как раз использованию CQRS вместе с DDD.
Если в вашем приложении отчёт является полноценной сущностью со своим жизненным циклом (пусть и коротким), то он будет корнем агрегата или находится в составе агрегата.
У read-model не должно быть деталей реализации, read-model — это проекция состояния системы на определённый клиентский запрос, она должна быть в оптимальной для этого запроса форме и в идеале, доставаться за один запрос в БД. Когда у вас есть какая-то логика в получении read-модели, возможно, у вас не полноценный CQRS.
Да, если у вас составление отчёта кастомизируется, требует вызовов внешних систем, продолжительно во времени (сага), то вам понадобится для этого сценария write-модель.
Все руководители разработки, применяющие DDD, с которыми я обсуждал тему, отметили «дороговизну» этой методологии, в первую очередь из-за отсутствия в книге Эванса ответов на практические вопросы «как мне сделать FooBar, не нарушая принципов DDD?».
Странно у вас как DDD используется. DDD это ведь не набор правил, это набор рекомендаций к дизайну приложений, в конечном счёте сводящийся к тому, что бизнес превыше всего. Если у вас есть бизнес-необходимость, сделайте отдельную read-модель для отчёта.
DDD предполагает делегирование части задач по аналитике разработчикам.
Не предполагает. Предполагается понимание аналитиков разработчиками и наоборот, но работу аналитиков делают по прежнему аналитики.
В неустоявшихся бизнесах (особенно стартапах) часто нет никакого понимания предметной модели. Все может меняться ежедневно. В этих условиях бесполезно требовать от участников бизнес-процесса использовать единую терминологию.
В стартапах или нет, модель всегда эволюционирует вместе с её пониманием разработчиками. DDD не предполагает единовременное формирование всех знаний о предметной области, DDD лишь про фокус на модели.
Event Sourcing требует CQRS
Строго говоря, это неверно. Я вполне могу представить себе как клиенты делают запросы напрямую в агрегат, который собирается из эвентов. Это убивает некоторые возможности, но это возможности CQRS, а не ES.
В случае DDD, чтобы знать где искать ту или иную бизнес-логику необходимо понимать предметную область. В случае CQRS программист всегда знает, что запись происходит в обработчиках команд, а для доступа к данным используются Query.
Почему вы их противопоставляете? CQRS отлично работает на DDD бэкграунде, потому что конкурировать там нечему. Это всё равно что говорить, что CQRS лучше Agile.
Стоит отметить, что даже если вы не заводите под DataAccessLayer отдельную сборку, хранить репозиторий в Namespace Models не совсем верно. Модели — это DTOшки, любая логика должна храниться отдельно, за исключением, разве что, логики валидации этих моделей.
Упомянули Gearbest, стало интересно, с английской версией винды только в предзаказе, в наличии есть с китайской, ей кто-то пользовался? Возникали ли проблемы со сменой языка на английский? На Home-версии это вообще доступно? BIOS на английском или на китайском?
Доменный слой — это не только набор интерфейсов необходимых объектов, это ещё и бизнес-сценарии, стоящие за ними. Когда бизнес-сценарии так тесно вплетены в инфраструктуру, коей является БД, это не DDD. В идеале доменная логика контекста должна быть абсолютно независима от инфраструктурных особенностей и быть самодостаточна в любом окружении. Здесь же самодостаточность на уровне подростка-позёра, который выставляет отличный интерфейс, но реализует его за него его папаша SQL.
Мы не берёмся делать архитекторов и техлидов из новичков, программа курса подобрана так, чтобы сформировать у ребят понимание, с чем разработчики сталкиваются в работе над продуктом. Более глубокое понимание придёт на стажировке и в штате, моя задача — научить понимать мотивацию за принятыми на проекте решениям, рассказать, как многочисленные инженерные инструменты и практики служат развитию продукта, чтобы было не так страшно первый раз видеть продакшн-код вживую.
Ничего страшного, если материал курса не будет усвоен на 100%, мы не торопим. Главное – чтобы был прогресс относительно стартовой точки.
Работай я у них, обязательно попробовал бы продать идею о чём-то вроде опенсорсного редактора табов с пул реквестами.
Мне основной целью этого абсурда видится создание соломенного чучела для дискредитации нормальных криптовалют среди широких слоёв населения. Последовательность такая: создаём крипторубль, называем его национальной криптовалютой, ставим галочку в графе "идём в ногу с технологическими трендами", бахвалимся, много говорим об этом в новостях. Оборот и хранение любой другой криптовалюты здорового человека запрещаем под предлогом бесконтрольности и "непрозрачности". Каждый раз, когда речь заходит о криптовалюте, тыкаем всех в крипторубль — у нас всё есть, гештальт закрыт, со своими басурманскими суррогатами не лезьте. Оказываем вялую поддержку всем энтузиастам, которые почему-то захотели этой валютой пользоваться, но в целом даём ей тихо умереть без похорон. Иногда вспоминаем её как Спутник и другие отечественные "передовые" технологии для галочки.
Моё мнение, если Unity позволяет писать на высокоуровневом языке, значит весьма бессмысленно отказываться от его достоинств. Предпочитаете производительность из коробки во вред поддерживаемости — берите низкоуровневый язык.
Реализуйте игровые концепты, делайте стройную гибкую архитектуру, используйте паттерны по необходимости. Сделайте проект легко читаемым и поддерживаемым, а потом берите профайлеры, снимайте дампы и определяйте узкие места. А то можно подумать, что ваши велосипеды будут производительнее и продуманнее, чем вдоль и поперёк исследованные проверенные годами инструменты Microsoft.
Решение хорошее, я видел рукописи, даже больше похожие на печатные шрифты и почерки с разным наклоном тоже встречал.
Можете так же посмотреть на Scala, если у вас есть выбор. Там у операторов нет привелегированного положения и они являются обычными методами, что позволит сделать generic-метод с нужными constraints.
Так это Hydro спросил, может ли отчёт быть больше, чем просто read-модель. Да, может, но я говорю о ситуации, когда отчёт необходим как статистика, графики и т.п. И да, там достаточно только read-модели.
Автор тезисом указал, что это не реализуется с использованием DDD. Я же в этом сценарии не вижу в DDD никакой помехи: если отчёт — это бизнес-понятие, то оно должно быть отражено в виде сущности в том или ином контексте, а в терминах CQRS стать частью write-модели. Если отчёт — это лишь ещё одна проекция состояния системы и собственного жизненного цикла не имеет, то вы можете на основе имеющейся в системе информации подготовить read-модель, именуемую «отчёт» и сохранить её в максимально удобной для получения форме. Именно подготовить, а не строить на лету какие-то SQL запросы с JOIN'ами и кверить все агрегаты в системе.
Про это писал Vaughn Vernon в книге Implementing Domain Driven Design, часть его труда посвящена как раз использованию CQRS вместе с DDD.
У read-model не должно быть деталей реализации, read-model — это проекция состояния системы на определённый клиентский запрос, она должна быть в оптимальной для этого запроса форме и в идеале, доставаться за один запрос в БД. Когда у вас есть какая-то логика в получении read-модели, возможно, у вас не полноценный CQRS.
Странно у вас как DDD используется. DDD это ведь не набор правил, это набор рекомендаций к дизайну приложений, в конечном счёте сводящийся к тому, что бизнес превыше всего. Если у вас есть бизнес-необходимость, сделайте отдельную read-модель для отчёта.
Не предполагает. Предполагается понимание аналитиков разработчиками и наоборот, но работу аналитиков делают по прежнему аналитики.
В стартапах или нет, модель всегда эволюционирует вместе с её пониманием разработчиками. DDD не предполагает единовременное формирование всех знаний о предметной области, DDD лишь про фокус на модели.
Строго говоря, это неверно. Я вполне могу представить себе как клиенты делают запросы напрямую в агрегат, который собирается из эвентов. Это убивает некоторые возможности, но это возможности CQRS, а не ES.
Почему вы их противопоставляете? CQRS отлично работает на DDD бэкграунде, потому что конкурировать там нечему. Это всё равно что говорить, что CQRS лучше Agile.