class=«js-someAction» — для привязки событий, data-someProperty=«value» — для параметров, передаваемых в эти события. Так все логически разделено, а значит удобно, и свойства используются по прямому назначению.
Так «сбор уикэнда» — это необходимость при крупных инвестициях. «Деньги студиям приносит прокатчик» — это не нерушимый закон, а то что есть сейчас. Любой рынок подвижен. В прошлом посте я говорил о тенденциях, о том в какую сторону он может начать развиваться.
Вообще, в большом кино давно уже тенденция к повышению ставок, которая связана со сверхприбыльностью удачных проектов. Ну а в малом, повторюсь, тенденция к повышению качества с малыми бюджетами (и скромными техническими средствами).
Просто Вы говорите о том, что следует делать большому кино, и тут я не спорю, а я — о том что если они этим не будут заниматься, есть кому и нишу заполнить, и вообще поменять правила игры.
«Торгаши с рынка» — это подходит, разве что, в качестве нелестного эпитета. Торгаши живут в условиях острой конкуренции, а костность — удел монополий. Борьба с пиратством идет как раз со стороны монстров киноиндустрии, а небольшим студиям это и не по карману, и не особо нужно (они-то как-раз обычно понимают всю силу бесплатного контента). Как было ПО — сначала все просто покупалось, сейчас есть OpenSource, есть просто бесплатное и условно-бесплатное ПО в т.ч. со всяческими альтернативными моделями монетизации, часто бесплатное п.о. используется в качестве рекламы производителя, семимильными шагами развивается краудфандинг. Что-то подобное должно происходить и с киноиндустрией. Да, в целом и происходит. Тем же краудфандингом уже пользуются вовсю, на ютьюбе какие только студии не пиарится — а многие ролики вполне имеют художественную ценность. Тем более — технологии кинопроизводства дешевеют, сейчас имея полупрофессиональную камеру и компьютер можно много чего сделать. А имея две камеры — еще и в 3d.
А костность — она в первую очередь у потребителей. Ею гиганты и пользуются.
Дело в нагрузке, js — статика, ее проще раздать, а сокращение времени на генерацию — это прямое сокращение процессорного времени, а значит экономия на серверах.
Был недавно проект, в котором скрестили NetCat и Symfony2. Причины те же — клиент хотел NetCat, а схема данных весьма сложная. Кроме того, пригодился twig, т.к. нужен был кастомизируемый шаблон с кучей параметров для клепания дочерних сайтов менеджерами из админки. В целом, проект живет и здравствует.
Ребята как-то сразу решили, что девушка может отдыхать, они сами справятся. <...> Не думаю, что это на что-то влияет. Просто интересный факт, который надо учесть.
Имею ввиду, что если появляется необходимость обращаться к второстепенному классу, когда основной еще не загружен (через автозагрузку) — тут правильно вытащить его в отдельный файл, с его же второстепенными классами (тогда для него автозагрузка заработает). Если такая ситуация несколько раз повторится (т.е. повытаскиваем классы для которых нужна автозагрузка в отдельные файлы), то в каком из файлов лежит нужный (не автозагружаемый) класс будет не очевидно. И по факту, скорее всего, придется еще тестировать все классы на зависимости (вдруг какой-нибудь класс, например, исключения, нужен в нескольких наших файлах — тогда его тоже нужно выносить в отдельный файл для автозагрузки).
А при совместной разработке такой подход может быть особенно неприятен — про это второй пункт.
В общем, совсем маленькую библиотеку, без какого-либо потенциала для развития, и которой никто больше точно не будет пользоваться, еще можно так реализовывать (все в одном файле). Но зачем себя к такому приучать, если придется переучиваться при разработке чего-то более серьезного?
Они как раз и помогают расширить этот «обычный круг задач PHP».
А из интересного в непосредственной практике — сразу вот сейчас буду использовать новинки роутинга в Симфони-проектах, PropertyAccess — в старом проекте, который медленно, но верно рефакторю (и явно класс еще не раз пригодится), а Stopwatch — отправляется в дебаг тулкит.
Что же такого отвлекающего и утомительного, особенно при наличии автозагрузчика? Создать файл? Скорее уж утомительно потом лазать по файлу и искать где же нужный класс. Или при необходимости использовать такой второстепенный класс вне основного — автозагрузчик не сработает >> выскочит ошибка >> догадываемся «ага, значит не вынесен класс» >> залезаем в библиотеку, выносим в отдельный файл (или есть альтернативная реальность в которой мы инклудим нужный нам файл, но предположим что мы все-таки хотим пользоваться автозагрузкой) >> и если это самопальный одноразовая библиотека, то радуемся жизни (но что-то не похоже это на упрощенный подход).
Существуют еще версии:
— это n-ая итерация и мы играем в игру «из какого же файла выносить»;
— эта библиотека лежит в репозитории и мы делаем весьма забавный коммит (или еще смешнее, пулл реквест, а если не примут, тогда форк).
Тавтология — да, поспорить сложно. Но в чем двусмысленность?
Повторение связано с тем, что по PSR-0 namespace соответствует расположению файла, и последний уровень — это название файла. Symfony\Component\PropertyAccess\PropertyAccess находится в
Особенно когда в директории Component достаточно много вложенных директорий (а так и есть), решение вынести из каждой по одному файлу не выглядит особо рациональным.
Смысла же в этом не видно совсем:
use Symfony\Component;
...
Component\PropertyAccess
Правда не понимаю чем же такая запись лучше.
По крайней мере, в случае полной записи названия класса в use сразу видны зависимости, а также проще рефакторинг в случае замены класса.
Тот самый принцип «лысый-волосатый» («плохая-хорошая винда») вряд ли объясняется простой случайностью (или, например, тем что MS расслабляется после успешной версии). Больше похоже на то, что каждая вторая Windows выпускается во многом для получения фидбэка, на основе которого разрабатывается следующая версия. Так что, WIn8, скорее сама по себе платформа для «исследования пожеланий пользователей». А Win7 не куда не исчезает — ее все еще можно купить, а значит она приносит прибыли.
В такой ситуации пропорция между win7 и win8 далеко не так показательна, как общие позиции windows (как на рынке PC, так и планшетов).
Вообще, в большом кино давно уже тенденция к повышению ставок, которая связана со сверхприбыльностью удачных проектов. Ну а в малом, повторюсь, тенденция к повышению качества с малыми бюджетами (и скромными техническими средствами).
Просто Вы говорите о том, что следует делать большому кино, и тут я не спорю, а я — о том что если они этим не будут заниматься, есть кому и нишу заполнить, и вообще поменять правила игры.
А костность — она в первую очередь у потребителей. Ею гиганты и пользуются.
Вот это и есть наш подход к политкорректности)
А при совместной разработке такой подход может быть особенно неприятен — про это второй пункт.
В общем, совсем маленькую библиотеку, без какого-либо потенциала для развития, и которой никто больше точно не будет пользоваться, еще можно так реализовывать (все в одном файле). Но зачем себя к такому приучать, если придется переучиваться при разработке чего-то более серьезного?
А из интересного в непосредственной практике — сразу вот сейчас буду использовать новинки роутинга в Симфони-проектах, PropertyAccess — в старом проекте, который медленно, но верно рефакторю (и явно класс еще не раз пригодится), а Stopwatch — отправляется в дебаг тулкит.
Существуют еще версии:
— это n-ая итерация и мы играем в игру «из какого же файла выносить»;
— эта библиотека лежит в репозитории и мы делаем весьма забавный коммит (или еще смешнее, пулл реквест, а если не примут, тогда форк).
Повторение связано с тем, что по PSR-0 namespace соответствует расположению файла, и последний уровень — это название файла.
Symfony\Component\PropertyAccess\PropertyAccessнаходится вЧто, в целом, логичнее чем:
Особенно когда в директории Component достаточно много вложенных директорий (а так и есть), решение вынести из каждой по одному файлу не выглядит особо рациональным.
Смысла же в этом не видно совсем:
Правда не понимаю чем же такая запись лучше.
По крайней мере, в случае полной записи названия класса в use сразу видны зависимости, а также проще рефакторинг в случае замены класса.
В такой ситуации пропорция между win7 и win8 далеко не так показательна, как общие позиции windows (как на рынке PC, так и планшетов).