dborovikov правильно подменил о погружении в проект. Получается, и в свой проект нужно погружаться и в opensource. Либо полагаемся на наличие простейших задач в багтрекере, но они и тут и там. Остаётся только решить, что важнее свой проект или нет? Пускай не свой, но его улучшение должно быть полезным компании.
Разумно, если на OpenSource проекте держится компания. Иначе смысл погружать человека в левый проект, если целесообразней в свой? Или в чём смысл стажировки?
Средние цвета не очень, не сохраняют восприятие исходной картинки. Например в предпоследнем варианте нет синего, его мало, но без него плохо. Использование доминирующих цветов тоже считаю неполноценным. Удачные палитры получаются только на контрастных изображениях или когда цель именно в получении пастельных оттенков. Вот возьмем кусок градиента, получим средние цвета, которые неприменимы для повторения эффекта.
Не знаете ли готовых решений составления палитр по изображению, так чтобы прямоугольники цветов были пропорциональны частоте использования цвета и упорядочены в соответствии с сочетаниями их в картинке?
Не хватает решаемых проблем и получаемого результата. Этим паттерны должны учить приёмам декомпозиции задачи и композиции её решения, а не тупо быть шаблоном.
Извиняю) Вы перегружены теорией. Прочли, что пассивная модель плохо, всё, нигде её нельзя. Поделитесь своим опытом, почему вся логика приложения должна находится в моделях? Я вам расскажу, почему не всегда должна, при этом принцип MVC сохранится.
От предметной области зависит, где будет преобладать бизнес логика. Может в модели, как вы всегда думали, может в контроллере, может в представлении, хотя, с ней всё расплывчато. Всё зависит от решаемой задачи.
Мансарда это ведь чердак? :) Человечество постоянно что-то изобретает и придумывает именования изобретению, как первичный классификатор. Получается вполне конкретное определение по названию. Так было и с MVC, когда его придумали для настольных программ с графическим интерфейсом. Но пытливые умы, двигающие прогресс, придумывают новое, применяют новые технологии, улучшая, расширяя возможности, сферы применения и первичный классификатор (именование изобретения) становится всё более абстрактным.
Граница четкая между Views и Model, если ею является Controller как связующий элемент. Где граница контроллера с моделью и представлением не стоит даже пытаться выявлять)) Дополнительные слои в MVC как раз и образуются в попытках её выявления. Например, граница между головой и телом человека — шея, а где граница между шеей и головой? какие клетки уже принадлежат шеи… может на атомном уровне есть граница? ))
Логика есть у каждого из трех элементов MVC, о полном переносе бессмысленно говорить. Явной границы между элементами сложно достичь, приходиться идти на компромиссы. Вы цитируете википедию, обратите внимание, в ней написано о двух вариантах реализации MVC — пассивном и активном, как результат компромиссов. MVC — это концепция без конкретики реализации. Всё остальное — это варианты реализации MVC, пытающиеся претендовать на звания концепций с конкретной реализацией. Не приписывайте к MVC одного способа реализации.
Концепция дома подразумевает наличие двери стены, крыши. MVC декомпозирует приложение на три компонента, подразумевая для них обобщенное назначение. Стена дома может быть кирпичной, бетонной, иметь окна. Окна могут быть панорамными, выполнять функцию стены. Модель может быть пассивной, может активной, содержать бизнес логику. Контроллер «толстым» или «тонким». Вариаций множество, суть остается та же. Зарекомендовавшие себя реализации закрепили за собой названия. Коттедж, замок, хрущевка)) HMVC, MVVM, MVP… Теперь мы спорим, какими должны быть стены, двери у дома, считая что дом это нечто конкретное.
Вся суть MVC в названии, ничего больше. То что вы понимаете под MVC — одна из реализаций проявляющаяся себя в лучших и худших сторонах в зависимости от задачи. Предложенная в статье реализация также имеет свои плюсы и минусы. Автор намудрил с терминами, сравнивая свою реализацию с некой другой часто употребляемой.
Не знаете ли готовых решений составления палитр по изображению, так чтобы прямоугольники цветов были пропорциональны частоте использования цвета и упорядочены в соответствии с сочетаниями их в картинке?
Граница четкая между Views и Model, если ею является Controller как связующий элемент. Где граница контроллера с моделью и представлением не стоит даже пытаться выявлять)) Дополнительные слои в MVC как раз и образуются в попытках её выявления. Например, граница между головой и телом человека — шея, а где граница между шеей и головой? какие клетки уже принадлежат шеи… может на атомном уровне есть граница? ))