А вот мне кажется, вы самый важный вопрос задали. Когда деньги из средства превращаются в цель, происходит некая подмена понятий, и что-то очень важное теряется. В частности, ответ на вопрос — а зачем это все?
Иногда параметр чтеца работает в положительную сторону. Открыл для себя на Литресе Пратчетта в исполнении Клюквина, и это настолько хорошо, что уже иначе Пратчетта воспринимать не могу :).
Но вообще да — в узких кругах известна история об аудиокнигах Макса Фрая, первые 18 историй читает Денис Веровой, и это прекрасно. А затем, уж не знаю по какой причине, меняется чтец, и все становится настолько плохо, что дальше одной главы слушать не хочется.
Хм, интересный вопрос, я об этом серьезно не задумывался. Для английской у меня в фоне висит Grammarly, а раскладка как раз доработанная чешская, т.е. оно тоже включено, по идее. Как граммарли с чешским не ссорится — не знаю, it just works.
О, знакомая история. Я, правда, наоборот оставил чешскую раскладку qwerty, но допилил ее до совместимости с английской. Также сделал alt-связки, но основной набор оставил на цифровой, для слепой печати гораздо удобнее. Сейчас думаю, чтобы режимы чешская vs цифровая сделать переключаемыми по §, сделав субрежимы в раскладке.
Я бы даже уточнил, что четыредцать и девятьдесят. В том смысле, что 40 сохраняет окончание от линейки двадцать-тридцать, а 90 — от пятьдесят-восемьдесят.
Полностью поддерживаю! Думал, я крамолу несу, а оказалось, не я один :)
Вообще, разумеется, все зависит от конкретного проекта и конкретной реализации, универсальных ответов не бывает. Но в нашем кейсе (а у нас геймдев) запросы на изменение приходят очень часто, и юниты от таких изменений просто трещали по швам. Вроде выделил юнит, вынес зависимости, завязал на узкий интерфейс, все красиво… но первый же запрос на изменение требует рефакторинга смежных сущностей, расширения интерфейса, вынесения базовых классов, внедрения новых зависимостей — и все, тест даже не переписать, проще выбросить и новый сделать.
С интеграционными (а то и системными) ситуация обратная, система устойчива к рефакторингу, причем очень серьезному, и даже после крупных изменений можно быть в достаточной степени уверенным, что ничего не сломалось.
В какой-то серии саус-парка Картман предлагал перевернуть пирамиду питания, здесь мы имеем примерно похожую ситуацию :) Но возможно, мы просто неправильно ее читаем. Приемочные, системные, интеграционные тесты — все они отвечают на важный вопрос «Работает ли программа?», «Работает ли подсистема» и т.д. Это база, это то, что позволяет спокойно вносить крупные изменения на уровне архитектуры, и быть уверенным, что враги не пройдут, а косяки всплывут. Это основание пирамиды. А юниты — вишенка на торте, для действительно независимых юнитов, которые будут меняться с малой вероятностью (например, алгоритмы).
Собственно, сейчас мы умудряемся на интеграционных сценариях даже работать в парадигме test-first, и это дает очень хорошие результаты.
Значит, я просто потерялся в литературных вставках и к концу статьи уже забыл ее начало и неправильно понял основной посыл. Полностью моя вина, приношу извинения :)
Ох, 2009. Тогда был уже год как мы выпустили Sublustrum, и в 2009 мы уже работали над Phobos 1953, а игровая индустрия в России стремительно входила в штопор. Веселое было время :)
Все бы хорошо, да вот английский язык очень любит одно и то же слово делать и глаголом, и существительным. Ну вот step например :) Разумеется, в каждом конкретном контексте можно обыгрывать сущность/действие по-разному, просто хотел отметить, что правильное именование — довольно-таки непростая задача.
Если вкратце, то мы используем MVP — бизнес-логика и логика отображений уходит в unity-независимые слои, на компонентах остается только относительно тонкий view-слой, который практически не принимает решений, только визуализирует изменения в слое презентеров. Отдельно, правда, приходится оговаривать физику и навигацию — у них довольно сложное положение в этой иерархии.
Также очень хорошие результаты показывает ECS-подход, но мы пока недостаточно осмелели для полного перехода на него.
В двух из трех статей или книг по Юнити вся логика взаимодействия обязательно завязывается на GameManager, который при сколько-нибудь заметном наращивании объемов превращается антипаттерн GodObject. Если нанимаешь нового юнитиста, обязательно приходится переучивать не делать эти GameManager.
Да, вы все очень точно подметили. Автор статьи пытается манипулировать читателем, навешивая на него комплекс вины за банальное «потому что не хочу», на которое он, читатель, имеет полное себе право.
Вот кстати да, согласен с вами. Если вторую команду не поощрить, мотивация упадет очень сильно. Можно управлять размером премии, способом выплат и т.п., но премия нужна.
Любой таск-менеджер хороший. Я вам в дополнение к статье ОЧЕНЬ советую прочитать книжку Максима Дорофеева Джедайски техники да и все его работы и выступления за последние несколько лет тоже. Основная его идея в том, что если в таск-менеджере можно завести хотя бы три списка, то он уже прекрасен. А все остальное зависит от иных факторов :)
Строже. Переход от статической типизации к динамической куда проще, чем обратно. По своему опыту преподавания языков скажу, что в самом начале язык нужен очень строгий.
А вот мне кажется, вы самый важный вопрос задали. Когда деньги из средства превращаются в цель, происходит некая подмена понятий, и что-то очень важное теряется. В частности, ответ на вопрос — а зачем это все?
Иногда параметр чтеца работает в положительную сторону. Открыл для себя на Литресе Пратчетта в исполнении Клюквина, и это настолько хорошо, что уже иначе Пратчетта воспринимать не могу :).
Но вообще да — в узких кругах известна история об аудиокнигах Макса Фрая, первые 18 историй читает Денис Веровой, и это прекрасно. А затем, уж не знаю по какой причине, меняется чтец, и все становится настолько плохо, что дальше одной главы слушать не хочется.
Ну вот хоть историю переезда расскажите :) Сам сейчас документы в Чехию оформляю, надеюсь тоже скоро там окажемся. Так что с удовольствием послушаю!
Хм, интересный вопрос, я об этом серьезно не задумывался. Для английской у меня в фоне висит Grammarly, а раскладка как раз доработанная чешская, т.е. оно тоже включено, по идее. Как граммарли с чешским не ссорится — не знаю, it just works.
О, знакомая история. Я, правда, наоборот оставил чешскую раскладку qwerty, но допилил ее до совместимости с английской. Также сделал alt-связки, но основной набор оставил на цифровой, для слепой печати гораздо удобнее. Сейчас думаю, чтобы режимы чешская vs цифровая сделать переключаемыми по §, сделав субрежимы в раскладке.
Сумерки.
Вообще, разумеется, все зависит от конкретного проекта и конкретной реализации, универсальных ответов не бывает. Но в нашем кейсе (а у нас геймдев) запросы на изменение приходят очень часто, и юниты от таких изменений просто трещали по швам. Вроде выделил юнит, вынес зависимости, завязал на узкий интерфейс, все красиво… но первый же запрос на изменение требует рефакторинга смежных сущностей, расширения интерфейса, вынесения базовых классов, внедрения новых зависимостей — и все, тест даже не переписать, проще выбросить и новый сделать.
С интеграционными (а то и системными) ситуация обратная, система устойчива к рефакторингу, причем очень серьезному, и даже после крупных изменений можно быть в достаточной степени уверенным, что ничего не сломалось.
В какой-то серии саус-парка Картман предлагал перевернуть пирамиду питания, здесь мы имеем примерно похожую ситуацию :) Но возможно, мы просто неправильно ее читаем. Приемочные, системные, интеграционные тесты — все они отвечают на важный вопрос «Работает ли программа?», «Работает ли подсистема» и т.д. Это база, это то, что позволяет спокойно вносить крупные изменения на уровне архитектуры, и быть уверенным, что враги не пройдут, а косяки всплывут. Это основание пирамиды. А юниты — вишенка на торте, для действительно независимых юнитов, которые будут меняться с малой вероятностью (например, алгоритмы).
Собственно, сейчас мы умудряемся на интеграционных сценариях даже работать в парадигме test-first, и это дает очень хорошие результаты.
Окончание необходимо только для порядковых (второй как 2-й) числительных.
Также очень хорошие результаты показывает ECS-подход, но мы пока недостаточно осмелели для полного перехода на него.