Pull to refresh
2
0
Дмитрий Пелевин @mrFleshka

Team Lead / Senior PHP Developer

Send message
А потом пытаться на кончиках пальцев контролировать все изменения данных, текущих условий и т.д.?

Когда много динамики в выдаче (эти блоки мы ему уже показывали, сегодня покажем эти), это контролирвоать очень трудно. Отсюда и кэш плодится, как незнамо кто…

Пока доверяю простым запросам к БД, которые должны сами по себе кэшироваться и простой шаблонизации/сериализации, но только для AJAX запросов. Основные страницы всё же из кэша.

А так да, можно сделать составные ключи, но я вот чувствую, что работать с ними слишком больно…
Лично делал хранение в кэше только реально существующих страниц (на основе карты сайта и ряда страниц исключений, которые не должны присутствовать в карте сайта).
Но проблема всё равно оставалась, т.к. на сайте все данные передаются по API и его я кэшировать не могу. API завязан на данные пользователя и ответ в некоторых случаев разный для разных пользователей. Вот что с API делать — загадка.
У всех разные подходы, у кого как исторически сложилось.
У меня так, думаю кому-то будет полезно, если схожая ситуация.
В статье.
Даже выделил (см. пункт «Итог»).

Но даже не в «срочно» смысл, просто неохота поднимать окружение на всех машинах. Да, и такое бывает. Не переводите всё на промышленные масштабы)
Вы серьезно?

Говорю же, срочно что-то поправить в рабочем сайте.
При чём тут докер или вагрант?

Да, на ноутбуке жены в поездке стоит всё окружение и настроен деплой)))))
Да, пробовали почти так, но вот автодеплой я всё же не позволил (слишком большой шанс чего-то не то залить), а настроить его именно на определённый скоуп файлов в рамках IDE не получилось.

Да и чес слово, ну проще же поставить один раз это всё на сервак, чем потом разбираться что на другой машине ещё и ноды нет, а последняя нода не билдит то что нужно и т.д.))

Жёстких требований к «отсутствию билда на сервере!» не было, поэтому почему бы не попробовать))
Возможно проще, смотря как настроено отслеживание и выкачивание.
— Можно ли этот процесс легко перенести на другую машину?
— А что если на самом сервере нужно сделать правки, не имея IDE под рукой?
— А заливается автоматически (ярый противник автоматического деплоя, особенно при работе с боевым сервером :D)?

Просто именно с такими трудностями столкнулись я и мои друзья при работе над сайтом при «заливке готовых ресурсов на боевой»…
Отчего не маленького?

Серёжа знает CMSку и готов покодить немного, Юра может чото поверстать, но дико далёк от PHP и системы. Вместе они делают какой-то сайт для подруги жены Серёжы… Я бы не парился там с деплоем, но скрасить время вёрстки для Юры я не откажусь)

Можно и заморочиться, но я вижу больше плюсов в таком подходе (читать как «более простом»).
Процесс деплоя тянет за собой одеяло с целой кучей проблем, к которым система может быть не готова, всё зависит от изначально выбранного подхода.

— Нет деплоя, есть админка, работаешь прямо на сервере? Статья для тебя.
— Хочешь автоматизировать деплой и не ставить на сервер инструменты для билда? Ищи другой подход, статья не об этом.

Как-то так.

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

Тем, что на сервер нужно подключаться.
Пользователь там один, а правки могут делать как программист, так и верстальщик.
Может ещё можно придумать, но это действительно неудобно. В таком процессе работы может даже и не быть Git'а совсем…

В данном случае мы живём лишь в рамках IDE и админпанели, которая за нас частично автоматизирует процесс. Просто и удобно (основной акцент на «просто»).
Сразу появляется куча проблем, когда:
— верстальщик правит один файл, а ему нужно заливать другой.
— верстальщик забывает залить все SCSS файлы на сервер, от этого страдают потом все.
— верстальщик не в состоянии адекватно настроить генератор на разных машинах (плохой аргумент, но и такое было)
— программист не хочет настраивать генератор и вообще лезть во фронтенд, но необходимо сделать мелкую правку. Здесь и сейчас…

Я не считаю интеграцию с PHP или установку NodeJS на сервер проблемой. Это (как и все остальные проблемы) задача, которая требует решения, возникшая во время выполнения другой задачи)
Нет, гит стоит только на локальной машине, файлы на хостинге полностью контролируются деплойментом, например, через IDE.

Прошу, не рассматривайте это как позыв к действию: «Как начать писать свой проект… с галпом через админку», это лишь попытка помочь тем, кто уже использует такой процесс разработки, либо просто не нуждается в чем либо более современном.
Да ну, бросьте. 2016 не означает, что все вокруг используют для разработки самые современные технологии, в том числе CI и билд сервера. Довольно много сайтов до сих пор поднимаются на коленке и заливаются копированием чего-то с локалки куда-то на хостинг.

Конечно это не туториал для профессиональных разработчиков мощных систем, но вот помочь связке Программист + Верстальщик, работающим с одним сайтом (каким-нибудь там dev.mysite.ru) это несомненно может.
Отчасти вы несомненно правы, но всё зависит от сложности и важности проекта.
Мой пример подходит для совсем лайтовых систем, которые не висят на автоматизированных Build & Deploy системах и, скорее всего, поддерживаются одним человеком.

Вряд ли для личного мини сайта или блога вы будете писать проект с использованием CI, но мелкие правки вы предусматриваете в будущем.

А если привык к хорошему (Gulp), то частичку этого можно и оставить, пусть и таким образом)

Кстати, отмечу, что даже не все свои проекты я запускаю с выгрузкой собранных сырцов. Некоторые настолько специфичны, что содержат большое количество хотфиксов, которые просто не удобно все билдить заранее, поэтому на продакшете всё же остается возможность запустить билд, хоть это и делает система деплоя)
Спасибо, исправил. Лучше в личку в следующий раз)

Information

Rating
Does not participate
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
Date of birth
Registered
Activity