Имхо сей опус, перенасыщенный очевидностями и гиперболами, покрытый легким налетом пафоса и содержащий жалкие попытки сарказма, выглядит довольно нелепо.
Суть в том, что если есть люди у которых есть возможность и желание сделать что-то свое, пусть и велосипед, то не надо им высокомерно мешать, кто-то, пусть и не все, возможно сделают что-то более лучшее, symfony не является идеалом и конечной точкой развития.
А ведь очень печально думать, о том, что сейчас подобные штуки кажутся абсолютной наивностью.
Вот так вот изменилась страна, начав брать пример с «западного мира».
>Почему никто не пользуется CMS при разработке высоконагруженных проектов?
Что есть высоконагруженный проект для вас? Если 2кк уников в день на один сервер — то вполне себе используют.
Суть то не в высоконагруженности, а на сколько функционал подходит, на сколько все реально доработать и тд, на основе этого понимаешь что взять, CMS, фреймворк или что-то среднее.
>Суть сего такова, что любые операции с данными системы, вычисляемыми данными,
>данными других сервисов позиционируются как Сервис. Сервис по сути является обычным пакетом PHP
>с классами и собственным пространством имен.
Выше уже написали про symfony. В целом оно там так и есть, но на самом деле, на практике понимаешь, что это спорный подход. Рекомендую сначала поюзать symfony чтобы понять неприятные моменты.
> Множество раз я пытался писать, следуя патерну, но результат всегда доводил меня до безумия.
Не слушайте всяких, пишите так как нравится вам, главное пишите, пишите много, изучайте чужой код, когда не знаете как лучше сделать что-то конкретное. Про патерны надо просто знать, что они есть, в какой-то момент вы просто поймете что вы им и так следуете, потому что в большинстве случаев это оптимальный способ решить определенные кейсы.
На счет написания своей CMS — так пишите да, писать код это всегда лучше чем не писать код. К тому же так оно как-то получается, что Пхп программист это не полноценный Пхп программист, если не написал хотябы пару своих CMS и не был облит дерьмом за это)
>И как быть с ветками, которые должны жить постоянно (вроде beta release, release candidate, trunk),
>они считаются независимыми проектами? Как проходят мержи между ними?
Обычно проще иметь одну постоянную ветку master которая по сути является копией кода на продакшене, в остальных случаях создавать ветки от нее и убивать, когда в них необходимость пропала.
Ну т.е. например каждую неделю в пятницу необходимо все что сделано отдавать тестерам, а в среду выливать в продакшен.
В пятницу создаем ветку prereleaseN, мержим туда все изменения, выкатываем куда-то для теста.
По ходу обнаружения и исправления багов, мержим туда фиксы, выкатываем.
В среду мержим ветку в мастер и убиваем ее, мастер выкатываем на продакшен.
>Случай раз случился, когда я возжелал использовать merge --squash. Отличная, казалось бы, возможность переносить изменения из >приватной дев-ветки, где ты что-то делаешь, в общую ветвь репозитория, делая красивый коммит с комментарием «Исправлен баг #32143».
А зачем так делать? Почему просто незамержить? Объединять у себя надо было.
>Коммитить недоделанные вещи, потому что вы собрались в командировку или в отпуск, вам категорически не рекомендуется.
Фигня какая-то, можно комитить все что захочешь в контексте своей ветки, вот в паблик что-то неработающее отдавать нельзя да, при этом при сливе своей ветке в общую всегда можно все коммиты объеденить например в один, если хочется.
> гораздо удобней схема — ветка = версия продукта/модуля
Тут все можно делать так же, просто можно еще например любые изменения, пачки изменений в отдельный ветки выносить.
Т.е. к примеру есть основная задача, а есть необходимость хотфиксов. Все делаешь в разных ветках, почти моментально переключаясь между ними. Когда что-то готово, можно слить несколько любых веток в одну — влить их к примеру в ветку альфа.
Больше свободы конкретному разработчику, он может создавать веток столько сколько захочет, переключаться между ними, никому не мешая, а наружу отдавать уже нечто готовое так как ему сказали.
Долбить запросом, пока он не выполнится или не пройдет 10 (кстати почему именно 10?) попыток это пять.
Следующим шагом рекомендую аппаратный перезагрузчик сервака на основе анализа звука кулеров.
>проблема больших данных
Больших это сколько терабайт?
>Не использовать персистентность редиса
Т.е. вы надеетесь что все целиком никогда не рухнет, а если рухнет у вас будет даунтайм на время заполнения редисов?
Доходы за баннеры там скорее всего абсолютно незначительные копейки на фоне стоимости проекта.
В новой версии наверное впилили какие-то способы монитизации, которые нифига не сработали — ну и на фоне всеобщей истерики решили все вернуть обратно.
perl прогеры строгие и немногословные, на все вопросы отвечали, если отвечали: «man {непонятное слово}»
если учесть, что даже вывод hello world сопровождался приколами с разницей в переводах строк на window и linux, до джуниора доживали немногие. Если ты доживал до джуниора ты скорее всего умел собирать из исходников чего угодно что угодно, походу познакомившись с разработчиком этого чего угодно и прислав ему пару патчей.
php прогеры, по большей части даже не прогеры, а так, желающие запилить что-нибудь. Любой вопрос, даже банальный, вызывал флейм на неделю, обязательные советы убить себя и заканчивался предложениями «а давай те уже чего-нить запилим нормальное, например cms, ведь cms это круто». Пара месяцев разработки на пхп в то время давали понимание, как что угодно собрать из говна и палок.
А вот ведь даже не верится, что было время, когда было совершенно неясно что же выбрать, пхп или perl.
>корявенько, но работает…
Ну кстати тут даже не корявенько, а довольно добротно написано )
Так то на практике обычно бывает, что админы обмениваются и передают по наследству ацкие однострочники, как-то даже приходилось это дело расшифровывать.
А автора похоже олдскульный админский подход, т.е. накидать на перле по быстрому, используя стандартные средства, так чтобы работало.
В нем нет ничего плохого, всякие изыски из серии LWP::Simple::get или монструозного фреймворка для разбора html — оно как бы необязательные изыски, ведь задачу написанный код решает, при этом он даже понятен.
Однако смущает то, что не психи не говорят, что они не психи.
Вот так вот изменилась страна, начав брать пример с «западного мира».
Что есть высоконагруженный проект для вас? Если 2кк уников в день на один сервер — то вполне себе используют.
Суть то не в высоконагруженности, а на сколько функционал подходит, на сколько все реально доработать и тд, на основе этого понимаешь что взять, CMS, фреймворк или что-то среднее.
>Суть сего такова, что любые операции с данными системы, вычисляемыми данными,
>данными других сервисов позиционируются как Сервис. Сервис по сути является обычным пакетом PHP
>с классами и собственным пространством имен.
Выше уже написали про symfony. В целом оно там так и есть, но на самом деле, на практике понимаешь, что это спорный подход. Рекомендую сначала поюзать symfony чтобы понять неприятные моменты.
> Множество раз я пытался писать, следуя патерну, но результат всегда доводил меня до безумия.
Не слушайте всяких, пишите так как нравится вам, главное пишите, пишите много, изучайте чужой код, когда не знаете как лучше сделать что-то конкретное. Про патерны надо просто знать, что они есть, в какой-то момент вы просто поймете что вы им и так следуете, потому что в большинстве случаев это оптимальный способ решить определенные кейсы.
На счет написания своей CMS — так пишите да, писать код это всегда лучше чем не писать код. К тому же так оно как-то получается, что Пхп программист это не полноценный Пхп программист, если не написал хотябы пару своих CMS и не был облит дерьмом за это)
>они считаются независимыми проектами? Как проходят мержи между ними?
Обычно проще иметь одну постоянную ветку master которая по сути является копией кода на продакшене, в остальных случаях создавать ветки от нее и убивать, когда в них необходимость пропала.
Ну т.е. например каждую неделю в пятницу необходимо все что сделано отдавать тестерам, а в среду выливать в продакшен.
В пятницу создаем ветку prereleaseN, мержим туда все изменения, выкатываем куда-то для теста.
По ходу обнаружения и исправления багов, мержим туда фиксы, выкатываем.
В среду мержим ветку в мастер и убиваем ее, мастер выкатываем на продакшен.
А зачем так делать? Почему просто незамержить? Объединять у себя надо было.
>Коммитить недоделанные вещи, потому что вы собрались в командировку или в отпуск, вам категорически не рекомендуется.
Фигня какая-то, можно комитить все что захочешь в контексте своей ветки, вот в паблик что-то неработающее отдавать нельзя да, при этом при сливе своей ветке в общую всегда можно все коммиты объеденить например в один, если хочется.
Тут все можно делать так же, просто можно еще например любые изменения, пачки изменений в отдельный ветки выносить.
Т.е. к примеру есть основная задача, а есть необходимость хотфиксов. Все делаешь в разных ветках, почти моментально переключаясь между ними. Когда что-то готово, можно слить несколько любых веток в одну — влить их к примеру в ветку альфа.
Больше свободы конкретному разработчику, он может создавать веток столько сколько захочет, переключаться между ними, никому не мешая, а наружу отдавать уже нечто готовое так как ему сказали.
Следующим шагом рекомендую аппаратный перезагрузчик сервака на основе анализа звука кулеров.
Больших это сколько терабайт?
>Не использовать персистентность редиса
Т.е. вы надеетесь что все целиком никогда не рухнет, а если рухнет у вас будет даунтайм на время заполнения редисов?
В новой версии наверное впилили какие-то способы монитизации, которые нифига не сработали — ну и на фоне всеобщей истерики решили все вернуть обратно.
perl прогеры строгие и немногословные, на все вопросы отвечали, если отвечали: «man {непонятное слово}»
если учесть, что даже вывод hello world сопровождался приколами с разницей в переводах строк на window и linux, до джуниора доживали немногие. Если ты доживал до джуниора ты скорее всего умел собирать из исходников чего угодно что угодно, походу познакомившись с разработчиком этого чего угодно и прислав ему пару патчей.
php прогеры, по большей части даже не прогеры, а так, желающие запилить что-нибудь. Любой вопрос, даже банальный, вызывал флейм на неделю, обязательные советы убить себя и заканчивался предложениями «а давай те уже чего-нить запилим нормальное, например cms, ведь cms это круто». Пара месяцев разработки на пхп в то время давали понимание, как что угодно собрать из говна и палок.
А вот ведь даже не верится, что было время, когда было совершенно неясно что же выбрать, пхп или perl.
Ну кстати тут даже не корявенько, а довольно добротно написано )
Так то на практике обычно бывает, что админы обмениваются и передают по наследству ацкие однострочники, как-то даже приходилось это дело расшифровывать.
В нем нет ничего плохого, всякие изыски из серии LWP::Simple::get или монструозного фреймворка для разбора html — оно как бы необязательные изыски, ведь задачу написанный код решает, при этом он даже понятен.