Веб-страницы, выводящие списки с традиционной постраничной навигацией по номерам страниц (например, тут), в подавляющем большинстве случаев не имеют возможности мгновленно перехода к произвольной странице, так как содержат лишь малую часть ссылок: 1, 2, 3 [пробел, многоточние] N. Все ссылки просто на страницу не поместятся. Так что ее работа мало чем отличается от последовательного скроллинга, а проблем с производительностью такой способ создает много.
К тому же содержимое книги постоянно, а списки из БД могут меняться. их элемены могут добавляться/удаляться, поэтому что на какой странице находится не так уж и важно по большому счету. Никто такие списки не просматривает, начиная со страницы M. Аналогия с книгами неуместна, потому что списки на веб-страницах в общем случае не являются книгами, а не наоборот. К ним другие требования и возможности у них другие.
И я бы посмотрел как они предложат уместить ссылки на каждую из 100500 страниц. А вариант с многоточнием посередине чем принципиально отличается от последовательного просмотра с точки зрения UX?
Ключ к богатству и процветанию IT-гигантов — «с миру по нитке». Низкая платежеспособность с лихвой компенсируется большим количеством пользователей. Я бы так сказал — если у вас целевая аудитория небольшая (небольшой рынок сбыта, например, один город), или вообще система работает в интранете, то вам не нужны такие оптимизации. Если это глобальный масштаб — очень нужны.
Прикладной код с использованием фреймворков и библиотек, который они привыкли писать каждый день, не может считаться надежным, если они пишем его без достаточного понимания разных аспектов его выполнения. Хорошей иллюстрацией этому из мира JavaScript служит судьба библиотеки JQuery, которая когда-то была двигателем прогресса а сегодня, будучи самозамкнутой областью знания, оторванной от всего остального языка, занимает свое естественное место на рынке — полупрофессиональные наспех написанные и работающие как придется скрипты в подарок к такой же быстрой верстке на бутстрапе от недорогих фрилансеров.
Для меня верно и обратное — слишком увлекаться деталями тоже не надо, а то закопаешься и вообще ничего не сделаешь. Главное это решить поставленную задачу так, как это устроит заказчика. Понимание всех аспектов придет с опытом. Матерыми специалистами не выпускаются из учебных заведений, не становятся, прочитав правильную книгу или статью, только опыт, только шишки. Про книги и спеки, безусловно, не стоит забывать, но практика имеет приоритет.
У меня такие же мысли) Я копирую эти файлы на старте, ведь часто в проектах бывают свои оригинальные docker-зависимости, напрмер в одном проекте может быть mysql, в другом postgres, в третьем еще нужен redis или очереди. Все это добавляется в docker-compose.yml, так что делать библиотеку какую-то смысла особого не вижу, если только под что-то наподобие composer create-project, чтобы консольная команда клонировала репозиторий и производила начальную настройку.
А, понял. Нужно чтобы веб-сервер в контейнере писал файлы с uid/gid что и текущий пользователь хозяйской системы. В этом случае можно usermod www-data (а hostuser вообще не добавлять) в ENTRYPOINT скрипте делать, тогда пересборка не потребуется. Я посмотрю, как это сделать, чтоб Apache или php-fpm в этом случае норм запускались, отпишусь попозже.
Тоже так делал, потом понял, что можно то же самое, но без ARG и ребилда. Используя ENTRYPOINT, т.е. добавлять юзера и приводить в соответствие UID и GID не на стадии сборки, а на стадии запуска.
Для решения проблемы с правами я использую Docker entrypoint, переменные окружения и команду runuser:
docker-php-entrypoint:
#!/usr/bin/env bash
set -e
if [ -z "${UID}" ]; then
echo "Необходимо задать значение переменной окружения UID"
exit 1
fi
if [ -z "${GID}" ]; then
echo "Необходимо задать значение переменной окружения GID"
exit 1
fi
groupmod -g ${GID} hostuser
usermod -u ${UID} hostuser > /dev/null 2>&1
exec runuser -u hostuser -- "$@"
Dockerfile:
COPY docker-php-entrypoint /usr/local/bin/
RUN chmod +x /usr/local/bin/docker-php-entrypoint
RUN useradd -m -U -s /bin/bash hostuser
ENTRYPOINT ["docker-php-entrypoint"]
CMD ["php", "-a"]
Команды будут выполняться внутри контейнера под hostuser, uid и gid которого настраиваются при запуске контейнера. Если не указать их — не запустится. С консольными командами помогает, с веб-сервером, возможно, тоже поможет. Можно попробовать в Entrypoint модифицировать uid и gid www-data (я пробовал, но не помню чем кончилось)))).
Юзаю один контейнер — один процесс (группа схожих процессов). Даже под консоль и веб-сервер разные контейнеры). docker-compose хорош.
Если кто-такое пробовал, или есть какие-то замечения, пишите, указывайте на недостатки. Свежий взгляд со стороны всегда полезен.
А чем 777 на ассеты и кеш не устраивают? По моему это хуже чем когда владельцем файлов с кодом является пользователь для запуска веб-сервера. Это гораздо более опасно. Из каталогов с ассетами и кешем просто выполнение php запретить и всё.
IONDV. Framework это кодогенератор? Напоминает Gii из Yii, также быстро можно что-то сделать, но у вас возможностей на первый взгляд побольше. MongoDb какой версии под капотом, что с транзакциями? И еще вопросик, как организована работа в многопользовательском режиме, как построена защита от перезатирания данных при одновременной работе нескольких пользователей с одним экземпляром сущности?
К тому же содержимое книги постоянно, а списки из БД могут меняться. их элемены могут добавляться/удаляться, поэтому что на какой странице находится не так уж и важно по большому счету. Никто такие списки не просматривает, начиная со страницы M. Аналогия с книгами неуместна, потому что списки на веб-страницах в общем случае не являются книгами, а не наоборот. К ним другие требования и возможности у них другие.
Для меня верно и обратное — слишком увлекаться деталями тоже не надо, а то закопаешься и вообще ничего не сделаешь. Главное это решить поставленную задачу так, как это устроит заказчика. Понимание всех аспектов придет с опытом. Матерыми специалистами не выпускаются из учебных заведений, не становятся, прочитав правильную книгу или статью, только опыт, только шишки. Про книги и спеки, безусловно, не стоит забывать, но практика имеет приоритет.
Этот код по работе с СУБД опасный. Возможны SQL-иньекции. Используйте подготовленные выражения.
docker-php-entrypoint:
Dockerfile:
COPY docker-php-entrypoint /usr/local/bin/
RUN chmod +x /usr/local/bin/docker-php-entrypoint
RUN useradd -m -U -s /bin/bash hostuser
ENTRYPOINT ["docker-php-entrypoint"]
CMD ["php", "-a"]
Команды будут выполняться внутри контейнера под hostuser, uid и gid которого настраиваются при запуске контейнера. Если не указать их — не запустится. С консольными командами помогает, с веб-сервером, возможно, тоже поможет. Можно попробовать в Entrypoint модифицировать uid и gid www-data (я пробовал, но не помню чем кончилось)))).
Юзаю один контейнер — один процесс (группа схожих процессов). Даже под консоль и веб-сервер разные контейнеры). docker-compose хорош.
Если кто-такое пробовал, или есть какие-то замечения, пишите, указывайте на недостатки. Свежий взгляд со стороны всегда полезен.
А чем 777 на ассеты и кеш не устраивают? По моему это хуже чем когда владельцем файлов с кодом является пользователь для запуска веб-сервера. Это гораздо более опасно. Из каталогов с ассетами и кешем просто выполнение php запретить и всё.