Вообще не хотел туда лезть.. но
а) я для подобной хрени (при нагрузке чуть более, чем..) использую memory-таблицы и триггеры (+cron при необходимости обновить данные в основных таблицах)
б) это, строго говоря, денормализация и с edogs-ами я согласен...
Sitealert, речь о банальном непонимании разницы между функциями (-> задачи.. что сделать) и ответственностью (кто сделал).
Просто (так уж сложилось) full-stack-программер "может всё" (на то он и "фуллстэк"), что между хостером и владельцем-клиентом... (сам или опосредованно..), но это явно за пределами по-хА-Пэ программирования (не видел такового в .htaccess)
Попробуйте внимательно прочитать.. пост
Программирование и знание смежных областей - это не одно и то же.. (равно, как и администрирование и знание смежных областей)
видите, как.. а у меня язык не повернётся назвать их дилетантами, хотя в некоторых моментах я с ними не согласен..
p.s. Да и WapGraf-а не могу назвать дилетантом, хотя упорно пытаюсь ему разъяснить своё понимание
Welcome )) Надёргал чуть ниже (из контекста для понимания). Я понимаю, что лень читать, многабукаф и всё такое..
При этом изначальный посыл срача дискуссии ИМХО в том, что
Так см. вторую цитату выше.. "Каждый должен заниматься своим делом".. Просто с точки зрения бизнес-процессов (и бизнес-результатов) это ["прям ваще как"] не выгодно..
Жаль.. а я пытался донести разницу между программированием (.htaccess) и администрированием (.htaccess) именно с технической точки зрения.
Мой первый начальный посыл 5 страниц назад как раз и был про отделение мух от котлет разделение функций и разграничение ответственности..
Под этим, в том числе понималось и то, что "программист" (веб-мастер), поправивший .htaccess, выполнил функцию администрирования (а не программирования, поскольку.. мы всё же пришли к единому мнению? что это конфигурационный файл web-сервера, а не программный код) и при этом несёт за неё ответственность.---------- Добавлено 15.09.2019 в 21:34 ----------
Клиентом, к примеру, может быть юр. лицо, а исполнитель - веб-студия (другое юр.лицо), у которой в штате на должности (программиста/веб-мастера/верстальщика) работает человек. При этом от имени клиента общаться с техподдержкой может IT-директор, помощник руководителя, секретарь..
И совсем не обязательно клиент хостинга (потребитель услуги) самостоятельно разбирается "во всём этом".. Просто хорошим тоном (я считаю) аккаунт регистрировать на владельца, чтобы он мог самостоятельно оплачивать (как ему удобно), общаться с ТП при желании и в случае чего он спокойно мог сменить "веб-мастера", "веб-студию"...
Моё видение я уже подытожил выше:
WapGraf, мне было несложно Вас порадовать.. И настоящих программистов тоже =)
Я понимаю, что Вы далеки от программирования.. и я готов объяснить разницу между конфигурационным файлом и программным кодом. И преимущество файла .htaccess перед остальными файлами в каталоге. Однако, это всё про техническую/формальную сторону вопроса разделения администрирования и программирования.
Просто технически некорректно писать про "программирование" в .htaccess
Вы же теперь пытаетесь в другую плоскость уйти.. Про ответственность, про "наболевшее" (и тут я с Вами полностью согласен.. о чём и писал ранее.. про "рамки предоставления услуги")
В рамках услуги хостинга.. действующие лица (упрощённо): хостер, клиент (владелец сайта) и исполнитель (Вы его называете "программистом", но он может быть достаточно далёк от программиста в моём понимании.. пусть будет "веб-мастер".. или даже некая "веб-студия" со штатом дизайнер-верстальщик-"программист"-тестировщик(о_О)
- если сайт работал до внесения изменений, то нормально, если исполнитель сделает, чтоб работало и после. В идеале это должен проверить тестировщик.. после прохождения unit-тестов и автоматизированного тестирования. Однако, вполне вероятны ситуации, когда всё-в-одном-мастер в силу отсутствия времени залил одно, сломал другое и не проверил, ибо "не оплачено" (в условных человекочасах).. Тут довольно сложно валить вину на хостера, если клиент адекватный. Более того, если общение с ТП проходит через аккаунт клиента - хостер может напрямую объяснить, где накосячил программист.
- если у хостера нет подходящего тарифа, а клиент хочет скачивать и обрабатывать бубильоны файлов, кучу соединений открытыми держать, лимиты малы, то вариант смены хостера/переезда на VPS и прочее технари могут обсудить и прийти к совместному решению, которое устроит обоих (в том числе и прощание с неподходящим клиентом).
- нормально, когда исполнитель (он же "веб-мастер", он же "программист") обладает базовыми знаниями об администрировании и может залезть в .htaccess, php.ini (если хостер даёт возможность настраивать посайтово) .. а также рассказать, какие версии и модули (php, apache) ПО ему нужны для работы.. А в идеале - включить их в панельке управления. Хоть это и не программирование ("писать код"), а настройка рабочей среды для сайта.
Вот.. вместо "админ / не админ" теперь пришли всё же к юрисдикции.. разграничение ответственности т.е. Я вроде об этом писал.
Функция-то конфигурирования (администрирования) web-сервера Apache (пусть и в пределах своей "песочницы"). Т.е. (как и smart2web сказал) программист немножко админ.. Вот Вы сами и пришли к несостоятельности Вашего же "нельзя без администратора" и "каждый должен своим делом заниматься"...
Вообще, зависит от того, как он используется. Если файл include-ится и выполняется, то это программный код (пусть даже HTML). Если файл открывается программным кодом и обрабатывается, то это файл данных. Но здесь с появлением <?php и шаблонизаторов границы размыты, поскольку шаблоны <?php выполняются интерпретатором, а шаблоны, к примеру, Smarty или twig - обрабатываются ("парсятся").. т.е. формально - это не PHP-код, а файл данных. (ещё более формально - это отдельный язык программирования)
По поводу дискриминации - .htaccess он "выше" всего этого.. в нём конфигурация web-сервера (!) для обработки файлов этой и нижележащих директорий. Одной строчкой в нём можно сделать так, чтоб весь программный код не выполнялся. (или вообще сайт лёг 😂) Но:
а) это не программный код
б) это администрирование
в) это вне зоны ответственности хостера, в зоне ответственности владельца сайта - потребителя услуги хостинга.
Довольно часто хостеры даже за плату отказываются разбираться в том, что другой админ настраивал.. ))) Проще заново поднять.. И администрирование, как правило, предоставляется для стандартных конфигураций (сервер с панелью, ни шагу влево-вправо)
p.s. А ещё в .htaccess-ы иногда заглядывают SEO-шники.. =) Им для этого не всегда нужны квалифицированные администраторы..
WapGraf, Вы передёргиваете.
Речь о конкретном конфиге, конкретного серверного (типового/стандартного/открытого/документированного) ПО. И утверждение, что он не является программным кодом.
Разбираться.. но это ведь не администрирование..)) Хотя нет.. постойте-ка.. для начала проверить index.php, blabla.txt отработает?
Строго говоря, и на процесс программирования это вряд ли похоже (особенно, если автор неизвестен).. На самом деле ковыряться в чужом коде (порой "плохопахнущем") - та ещё затея..
Был интересный "глюк", когда ты файл на хостинге меняешь.. а на сайте всё по-старому.. загружаешь, проверяешь.. да, всё загружено.. А в браузере - всё "как было".. загружаешь новый текстовый файл - он в браузере 404.. Оказалось, хостер перенёс сервер на другой IP, на NS-серверах своих прописал.. (про уведомление ничего не скажу.. почти уверен, что было, но я не в курсе) А старый сервер по какой-то причине работал.
Ну, как бэ аналогично и "админ" во многих ситуациях с .htaccess-ом мог бы заглянуть в логи ошибок и понять, что туда сыпется..
Кому надо - тот и делает. Своими силами, или делегирует.. с оплатой или безвозмездно.. Всё просто же.. Другой момент, что порой с кадрами проблемы.. и "Shut up and take my money" не работает..
suffix, люди разные.
.htaccess - это не вотчина хостера..
Можно уточнить, какие из директив поддерживаются, как, и можно ли клиентский php.ini использовать.. Но обычно это можно посмотреть самому (phpinfo) и/или достаточно подробно расписано в ЧаВо.
Программист, который "тупо код" вполне может сказать, что "это не его" и будет отчасти прав (в том смысле, что кесарю - кесарево).. Зачем лезть в чужое, каждому своё и т.д.
Меня не напрягает разобраться с проблемой (пофиг, .htaccess это, модули или ещё чего) и решить её самому (если хватит прав), или подёргать техподдержку... или другими способами.. вплоть до выбора.. и дальнейшего переезда к другому хостеру, если у этого проблема не решается.. (ну, вот нужен под эти задачи такой конфиг.. сам так сделал.. или так надо /сайт подрос, прикрутили жрущую память плюшку и т.д./.. а у хостера нет.. )---------- Добавлено 15.09.2019 в 16:47 ----------
Точно! 😂 выполнять функции администрирования..
Собственно, я о том же.. ))---------- Добавлено 15.09.2019 в 16:48 ----------
Вы опять всё путаете..
При таком раскладе неизвестно ведь и на чём накодил.. Вдруг там рельсы или джанго.. или Perl, или ASP... Есть серверные истории и на Java.. (под виндой 😂)
Я не говорю, что разбираться с .htaccess должен администратор хостинга. Я говорю, что .htaccess - это из области администрирования, а не программирования.
Но функцию эту, как правило, выполняет не хостер (да блин.. есть хостеры с бесплатным включенным администрированием клиентского VPS.. с кучей условий-ограничений, но есть).
Хотя прописать в .htaccess стандартные реврайты для типовых CMS сейчас могут и многие пользователи этого форума.. Т.е. решить задачу администрирования(!)
