>Зачем держать в сцене классы логики как MonoBehaviour, если можно создать их нормально
Например, модели сделаны как MonoBehaviour для возможности изменять значения прямо в редакторе.
А контроллеры можно и не делать MonoBehaviour.
А вот то, что свойство app в BounceApplication не кэширует ссылку — это странно. Ну и много чего, что можно было бы улучшить, хотя бы — служебные классы сделать абстрактным, события в BounceNotification — не строковые, перечисления, и т.п.
Я правильно понял, две платформы могут быть друг над другом, но ближе, чем высота персонажа? можно сказать — "под ногами" и "в поясе"? И тогда, если я иду по нижней платформе, то я могу идти сквозь верхней платформы. А если прыгну — то попаду на верхнюю платформу.
так это же бейсик! Я тоже так делал. В 1995 году у меня был советский компьютер БК-0010-01 (на гиктаймсе), в нём при входе сразу включался интерпретатор бейсика (а ещё был ещё один язык Фокал, в котором тоже нужно было ставить номера строк). И там обычно строки нумеровались десятками — 10, 20, 30… Это нужно было как раз для того, чтобы добавить строки между уже добавленными строками.
У "идеографической и иероглифической" информации иногда есть преимущество, если все адресаты точно понимают смысл и имеют ту же не-текстовую информацию (типа эмоций). Но попробуйте иностранцу показать эту картинку.
Если информация из большего количества слов, чем два-три, то прочитать быстрее. Особенно поэтому я не люблю видеоуроки.
Абсолютно согласен по поводу видео. Я тоже считаю, что текст гораздо понятнее, чем видео. Вы очень хорошо указали на недостатки подачи материала через видео. Если мне нужно посмотреть какой-то урок, то мне придётся смотреть его практически целиком, сложно пропустить часть и перейти к другому разделу. Например, если видеоурок идёт 20 минут, то такое же самое количество информации я смогу прочитать за 5-10 минут, а в некоторых случаях — вообще 2-3 минуты. Навыки быстрочтения вообще не работают в случае просмотра видео.
Хотя в некоторых случаях, конечно же, видео может быть полезным. Как вариант, хорошим компромиссом может быть мини-видео (лучше gif) на несколько секунд, чтобы показать сложный момент, который сложно объяснить текстом, чаще всего — показать работу с мышкой.
>а тут чудовищные названия классов типа «mdl-layout__header»
так же это БЭМ — именование классов соответствует яндексовской методологии БЭМ, и это хорошо! Они не чудовищные, они удобные, хотя бы тем, что именование классов стандартизировано, не только в этом проекте, но и во многих проектах, использующих БЭМ.
Если я уже оплатил сервер за $8, то вы вернёте эти деньги на счёт, и продолжите бесплатно обслуживать сервер до октября?
Тогда беру! lexx.pavlov аt gmail.com
>максимально ресурсоемкие задачи должны быть вынесены вообще на самый мощный, обычно это sql сервер
Тут есть большая потенциальная проблема. Дело в том, что масштабировать SQL-сервер на порядок сложнее, чем масштабировать веб-приложение. Серверов с кодом можно рядом поставить очень просто. А вот поставить рядом с текущим SQL-сервером такой же второй — нетривиальная задача (частично зависит от типа SQL-сервера).
Я решаю эту дилемму, о которой вы говорите, так. Если модель имеет какой-то код, который относится только к этой самой модели (не нужны данные из других моделей), то код в самой модели. Если какой-то код связан с несколькими моделями, то он должен быть в специальных классах (но не в контроллерах!), так называемых сервисах. А контроллер я делаю «тонкий», в нём пару вызовов сервисов и/или моделей.
Например, модели сделаны как MonoBehaviour для возможности изменять значения прямо в редакторе.
А контроллеры можно и не делать MonoBehaviour.
А вот то, что свойство app в BounceApplication не кэширует ссылку — это странно. Ну и много чего, что можно было бы улучшить, хотя бы — служебные классы сделать абстрактным, события в BounceNotification — не строковые, перечисления, и т.п.
У "идеографической и иероглифической" информации иногда есть преимущество, если все адресаты точно понимают смысл и имеют ту же не-текстовую информацию (типа эмоций). Но попробуйте иностранцу показать эту картинку.
Если информация из большего количества слов, чем два-три, то прочитать быстрее. Особенно поэтому я не люблю видеоуроки.
Хотя в некоторых случаях, конечно же, видео может быть полезным. Как вариант, хорошим компромиссом может быть мини-видео (лучше gif) на несколько секунд, чтобы показать сложный момент, который сложно объяснить текстом, чаще всего — показать работу с мышкой.
так же это БЭМ — именование классов соответствует яндексовской методологии БЭМ, и это хорошо! Они не чудовищные, они удобные, хотя бы тем, что именование классов стандартизировано, не только в этом проекте, но и во многих проектах, использующих БЭМ.
Тогда беру! lexx.pavlov аt gmail.com
Тут есть большая потенциальная проблема. Дело в том, что масштабировать SQL-сервер на порядок сложнее, чем масштабировать веб-приложение. Серверов с кодом можно рядом поставить очень просто. А вот поставить рядом с текущим SQL-сервером такой же второй — нетривиальная задача (частично зависит от типа SQL-сервера).
Я решаю эту дилемму, о которой вы говорите, так. Если модель имеет какой-то код, который относится только к этой самой модели (не нужны данные из других моделей), то код в самой модели. Если какой-то код связан с несколькими моделями, то он должен быть в специальных классах (но не в контроллерах!), так называемых сервисах. А контроллер я делаю «тонкий», в нём пару вызовов сервисов и/или моделей.