ГлавТВ

О, нас становится больше =)

Да, книжные. В вашем случае использование глобалсов не катастрофическое, там по сути очень просится простенький registry. Есть по коду еще несколько мест, где этот же реестр будет полезен. Код сложнее не станет, ни медленнее, ни быстрее не стенет, но зато будет читабельнее, чуток быстрее можно будет искать что к чему, и добавится удобный инструмент, когда понадобится еще что-нибудь вынести в "глобал". Вот явный индикатор того, что вам нужен реестр:
Собственно, по поводу "излишней книжности". Книжки они пишутся на опыте, и брать из них нужно именно опыт, а не догмы, мол, так делать нельзя, а нужно только вот так. К примеру, те же паттерны проектирования -- это, так сказать, best practices решения тех или иных архитектурных задач. Это не означает, что они должны быть абсолютно везде, это означает, что не нужно изобретать велосипед для решения типичных кейсов. Ну как вот здесь с глобалами и registry, например. Возможно, вам с коллегой по TVonTop стоило терпимее относиться к позициям друг друга, тогда польза была бы для обоих.

Кстати, ультимативная форма общения не подойдет. Мне нет необходимости вам либо еще кому-то что-то доказывать, а значит и принимать условия ультиматума =)

По поводу парсинга. Я уже говорил, что у нас только один пользователь. Вопрос производительности в таком случае у нас возникает, когда тормоза в том или ином случае видны на глаз. Если бы у нас было хотя бы 20-30 тысяч пользователей онлайн на одном и том же апп-кластере, то чистка html-а регекспами и прочий закат солнца вручную в ParserTools вылез бы сильно боком. Допускаю, конечно, что php на плеерах сильно ограничен и различается в разных моделях, но не настолько же.
Кстати о ParserTools. Он у вас встречается довольно часто. Это хороший кандидат на то, чтобы убрать его явные статические вызовы и заменить его получение через тот же реестр. Это нужно затем, чтобы обеспечить слабое связывание (low coupling). Высокое связываение сильно усложняет жизнь, например, при написании тестов к коду или при попытках повторно использовать код. А тесты бы пригодились для выявления вот таких ошибок, как в у вас в классе ConfigFile:
Здесь обычная опечатка, переменная $contents не определена в контексте ConfigFile::writeFile(), там определена переменная $content. Как результат, содержание не криптуется даже если задан пароль.
Тесты вообще хороши как для самого кода, так, в случае ГлавТВ для проверки всех сервисов на предмет того, не изменилось ли у них чего в выдаче и не нужно ли подстроить парсинг.

Лапша в темплейтах. Есть же хорошие удобные средства работы с xml. Почему бы не использовать? А то логику вычитывать из этого спагетти -- это без поллитра никак. И сорвались с ОО стиля на процедурный в rss-funcs и rss-design. Или осталось как легаси?

Думаю, пока достаточно.

А слабо написать сервис, который даст возможность открывать любые интернет страницы ? (некий IE)

mephius писал(а): Да, книжные. В вашем случае использование глобалсов не катастрофическое, там по сути очень просится простенький registry. Есть по коду еще несколько мест, где этот же реестр будет полезен. Код сложнее не станет, ни медленнее, ни быстрее не стенет, но зато будет читабельнее, чуток быстрее можно будет искать что к чему, и добавится удобный инструмент, когда понадобится еще что-нибудь вынести в "глобал". Вот явный индикатор того, что вам нужен реестр:

Код: Выделить всё

global $cfg, $lang, $srv, $req, $keys;

Registry, кроме минимального повышения читаемости, не даёт в данном случае ничего. При использовании strict неправильное обращение приводит к исключению, которое соответствующим образом обрабатывается и показывается. Т.о. главный полезный эффект от registry покрывается стандартными средствами. Работа с массивом в PHP практически не отличается от работы с объектом. Т.е. введением registry ты по сути переименуешь GLOBALS в Registry. Как без этого до сих пор всё работает - неизвестно.

mephius писал(а): Собственно, по поводу "излишней книжности". Книжки они пишутся на опыте, и брать из них нужно именно опыт, а не догмы, мол, так делать нельзя, а нужно только вот так. К примеру, те же паттерны проектирования -- это, так сказать, best practices решения тех или иных архитектурных задач. Это не означает, что они должны быть абсолютно везде, это означает, что не нужно изобретать велосипед для решения типичных кейсов. Ну как вот здесь с глобалами и registry, например.

Буквально - открыл глаза. Ведь я этого, конечно же, не знал.

mephius писал(а): Возможно, вам с коллегой по TVonTop стоило терпимее относиться к позициям друг друга, тогда польза была бы для обоих.

Возможно, нет.

mephius писал(а): Кстати, ультимативная форма общения не подойдет. Мне нет необходимости вам либо еще кому-то что-то доказывать, а значит и принимать условия ультиматума =)

Покуда я не увижу пользы, ты отнимаешь моё время. А это очень и очень ценный ресурс. Особенных надежд, на то что из этого разговора выйдет какой-то толк, я не питаю. Поэтому так. Если это не устраивает - ты всегда можешь прекратить сюда писать. Ничего личного.

mephius писал(а): По поводу парсинга. Я уже говорил, что у нас только один пользователь. Вопрос производительности в таком случае у нас возникает, когда тормоза в том или ином случае видны на глаз. Если бы у нас было хотя бы 20-30 тысяч пользователей онлайн на одном и том же апп-кластере,

В этом и есть корень проблемы. Ты привык работать с апп-кластером на 20-30 тысяч пользователей и пытаешься перенести сюда известные тебе решения. Отчёт, что это неправильно, себе отдаёшь, но изменить не можешь. Начни с изучения предметной области и доступных средств. Потом попробуй с ними поработать. Взгляд на многие вещи изменится радикально.

mephius писал(а): то чистка html-а регекспами и прочий закат солнца вручную в ParserTools вылез бы сильно боком. Допускаю, конечно, что php на плеерах сильно ограничен и различается в разных моделях, но не настолько же.

Давай сюда примеры немотивированного использования регекспов. ParserTools именно для того и был написан, чтобы минимизировать их использование.

mephius писал(а): Кстати о ParserTools. Он у вас встречается довольно часто. Это хороший кандидат на то, чтобы убрать его явные статические вызовы и заменить его получение через тот же реестр. Это нужно затем, чтобы обеспечить слабое связывание (low coupling). Высокое связываение сильно усложняет жизнь, например, при написании тестов к коду или при попытках повторно использовать код.

Чем ты хочешь динамически заменять ParserTools?
Попробуй ответить на этот вопрос, прежде чем объяснять мне про слабое связывание.

mephius писал(а): А тесты бы пригодились для выявления вот таких ошибок, как в у вас в классе ConfigFile:

Код: Выделить всё

        if (! empty($this->password)) {
            $contents = ParserTools::encrypt($contents, $this->password);
        }

Здесь обычная опечатка, переменная $contents не определена в контексте ConfigFile::writeFile(), там определена переменная $content. Как результат, содержание не криптуется даже если задан пароль.
Тесты вообще хороши как для самого кода, так, в случае ГлавТВ для проверки всех сервисов на предмет того, не изменилось ли у них чего в выдаче и не нужно ли подстроить парсинг.

Хорошо ли тебе понятна разница между коммерческим энтерпрайз проектом (читай: апп-кластер на 20-30 тысяч пользователей) и хобби проектом, изначально движимым двумя людьми? Невольно возникает вопрос, знаешь ли ты правильные соотношения кол-ва комментариев к коду и кол-ва кода к тестам?

mephius писал(а): Лапша в темплейтах. Есть же хорошие удобные средства работы с xml. Почему бы не использовать? А то логику вычитывать из этого спагетти -- это без поллитра никак. И сорвались с ОО стиля на процедурный в rss-funcs и rss-design. Или осталось как легаси?

Легаси.
Про хорошие удобные средства работы с xml. Это, кстати, для php они хорошие и удобные? Неважно. На апп-кластере с 20-30 тысячами пользователей ты всё сам установишь. А тут у тебя есть то, что предоставит коробка (одна из тысячи, см. список поддержки) и то, что ты с собой принёс.

А логику вычитывать ниоткуда не надо. Это на АКС23ТП тебе нужно обеспечить читаемость и понятность. А тут, как показала практика, граждане лезут в код ровно с одной целью - отломать весёлые картинки "Помоги проекту". Поэтому повышение читаемости, как задача, больше не стоит. Намеренно усложнять и спагеттизировать код у меня не поднимется рука, но делать его понятнее - просто нет объективных причин.

Хочу поделиться некоторыми наблюдениями:
- Вы любой фразой стремитесь показать свое превосходство
- Некоторые навыки разработки вы имеете, но считаете их абсолютно исключительными, а любое мнение или факт, показывающий несостоятельность такой позиции, в резкой и нелогичной форме предаете анафеме.
- Демонстрируете неспособность работать с критикой; вместо приведения контраргументов сосредотачиваетесь на нивелировании (прежде всего, в своих глазах) статуса оппонента.
- Чем больше вы согласны с приведенным оппонирующей сороной аргументом, тем яростнее вы его опровергаете.
- Легко поддаетесь предложенным зацепкам-оправданиям (вспомните: "Или осталось как легаси?", на что вы с радостью согласились)

Список можно продолжать.

Такое поведение характерно в двух случаях: астенический синдром либо юношеский максимализм. Учитывая обстоятельства здесь, очевидно, второе.

Жаль, много молодых разработчиков могло бы развиваться значительно быстрее, если бы им не мешала эта стадия.

Разрешите на этом попрощаться и благодарю за беседу.

Дорогой друг.

Не я, а ты пришёл ко мне с заявлениями, что ты знаешь как лучше. Далее вывалил тонны очевидных благоглупостей на уровне "Волга впадает в Каспийское море". Это, оказывается, критика. Чем сам занимаешься и откуда мы тебя якобы должны знать - скромно умолчал. Теперь для усиления эффекта эксперта во всех областях выступил как маститый психолог. Что характерно, всё с тем же комплектом копеечных заготовок. Правым рукавом взмахнул - кости полетели, левым - объедки.

Скатертью дорога. Буду сильно тосковать и не спать ночами.

Кстати да, для интересующихся и для тех кому что-то в этой беседе показалось странным или непонятным.

Соображения по улучшению проекта нужно формулировать в виде: "<Что><Чем><Выигрыш>".

"Мне кажется было бы лучше это, это и вот это, заменить тем, тем и этим. Тогда это не понадобится, то будет работать быстрее, а тут сэкономится память."

Выступления в стиле:
- надо чтоб всё было правильно!
- я в книжке читал, там не так!
- я занимаюсь холодильными установками, мы так не делаем!
- я скакала три дня, чтобы сказать, как вы мне безразличны!
- просто хотелось поговорить, я тоже крутой!
- наболело!
будут жесточайшим образом высмеиваться.

Мне достаточно собеседников, но сильно не хватает времени. Фиксирование проблем меня не интересует, меня интересуют только решения. Причём решения проработанные, а не на уровне псевдо-концепций "внутре у неё неонка" или "сделайте через инъекции, а трейсы - через замыкания"