фантазирую что могут пойти туда продавать юные it-бизнесмены) был раньше один старый мобильный форум и там был примерно такой раздел, чего там только не продавали

тоже минусов отхвачу, но вполне согласен с вами, как-то уже совсем не то, совсем не Хабр. Передавалась больше не трансляция, а чье-то мнение на трансляцию, новости бы так писали СМИ, то вообще в шоке все были. Как то ожидаешь простой поток переведенной информацию как есть, а выводы уже должны делать читатели сами и обсуждать в комментариях, а тут что было не ясно. Да и при переводах статей не замечал авторов чтоб таким баловались, как минимум отмечают где их мнение, а где оригинальные текст. Либо я уже стар и теперь только таким образом передают информацию/переводят/транслируют)

Может вы и правы… но что-то сильно привязались к теме замены одного запроса на другой, ведь там есть разные механизмы зависимостей в том числе можно построить на своей какой-то логике, просто мне сама идея очень симпатична, что добавляется небольшой слой со своей логикой кэширования, а тут как-то все топорно… я сам за простоту, но как-то ждал более интересные решения)

Зависимости — хорошая идея, но часто просто просаживается по перформансу. Какой смысл лезть в базу, проверять когда обновилась сущность, если мы и сделали все кеширование ради того, чтобы как можно меньше трогать базу.

Так ведь запросы бывают разные) из пальца: показываем огромную таблицу, которая строится на основе сложного запроса с джойнами, агрегатными функциями и т.д. это все по нескольким миллионам записям… При этом у нас есть простой индекс на поле update_at, почему бы и не следить за max(update_at)?)

Как-то скудновато в Ларе с кэшем? Вся статья о кэшировании одной или массива моделей и их связей. По сути половину статьи можно было опустить Лару и просто рассказать про механизмы/практику кэширования. Если не ошибаюсь в PHP любые экземпляры классов можно кэшировать, проблемы лишь с ресурсами(открытые файл, соединения), что опять же решается через __sleep() and __wakeup().

Допустим, в Yii из коробки более интересные вещи есть, так, я не хочу кэшировать сами экземпляры (состояния моделей), а вот сам запрос к БД хочу закэшировать. Зависимости кэша тоже очень даже вкусная вещь, а тут выходит велосипедировать каждый раз с событиями? Я не противник событий) просто как по мне как-то громоздко выходит

Очень даже любопытно сколько в прошлом году по этому посту купили лицензию и вернулись сюда вчера-сегодня для продления =)

Про последнюю версию php, что-то в первые слышу. В системных требованиях getcomposer.org/doc/00-intro.md#system-requirements сказано, что достаточно и PHP 5.3.2

я тут про образ в котором «собирается»(?) композер, сейчас в нем FROM php:7-alpine сегодня может проблем нет, но что будет завтра? Как пример composer начал собираться FROM php:8-*, используется новая мажорная версия самого композера, а мы перетаскиваем его в контейнер, где стоит php7?) да и джуны могут начать юзать такой подход там где совсем нельзя. Я к тому, что разные компоненты собираются в разных средах/окружениях: fpm собирается от одного (docker FROM), php-cli под другим (docker FROM), а composer может совсем под другим. Выходит кто-то собрался от php7.1-alpine, кто-то от php7.3-debian, а кто-то умудрился от php7.4-windows(?). Вот и думал, может все что связано с php собрать в один образ-контейнер, где всегда одна версия php?

по зависимостям имел виду, что composer/docker собирается со своими зависимостями (it subversion openssh-client mercurial tini bash patch make zip unzip coreutils), модули php (zip opcache), со своими переменными окружениями композера и настройкой php-cli в контейнере образа composer/docker! А мы просто вытащили из этой среды сам composer, который если не ошибаюсь юзает системный php, а он скорее всего настроен совсем по другому. Выходит при таком подходе composer работает по дефолтным настройкам, а не от composer:latest?

COPY --from=composer:latest /usr/bin/composer /usr/bin/composer

Далее копируется composer из другого базового образа

просто скопировать достаточно? в дальнейшем можно спокойно делать composer selfupdate? как-то в composer/docker более интересные вещи происходят. Интересно куда кэш пойдет писать, зависимости в целом, php.ini для php-cli, к тому же можно выбрать php 7.1, а composer тянет последний PHP и т.д. со всем этим не будет проблем?
Интересно в целом работа с php-cli под докером, допустим тот же artisan.php от Лары и yii.php от Yii. Можно отдельный поднять контейнер от php:*-cli, но тогда как все будет или все в один контейнер закинуть?) npm и в целом сборку фронта если нужно поднять, то как лучше? или я рано начал про это все?)

думаю я бы воспользовался, чтоб хоть как-то подтянуть, но пока с наличными печаль и со временем, хочется как-то полностью погрузиться в обучение… понимаю что хорошо окупится

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

1Тб очень даже привлекает теперь по цене

пс. слежу именно за сата для старого ноута

и дублировать вопрос вроде как нельзя, типа уже спрашивали и Тостер не знает ответ?)

замечал что некоторые вопросы решаются в комментариях к вопросу, потом автор просит указать в ответах и только потом делает его правильным ответом. Либо сначала кто-то дал неправильный ответ, потом в комментах ответа находят правильный ответ и опять автор просит поправить ответ или не знает что с этим делать, некоторые пишут свой ответ и указывают что в комментах помогали. Может и комменты как-то считать, голосовать или выделять/выносить?

1. Простые сайты визитки (php, mysql). Можно сказать что нужно тестовый хостинг для них, но все контейнерах. Думал может какие-то общие сделать контейнеры с указанием хостов и папок. По сути выходит контейнеры для виртуальных хостов.

2. Выходит php-сli запускается из контейнера php-fpm? composer тоже? были проблемы что некоторые скрипты смотрят на /usr/bin/env

3. Наверно рано спросил, пока не юзаю автоматические интеграции, просто думал что на продакшн nginx поднимается с 80 портом, если я начну править конфиги контейнера для продакшн, то это скажется и для dev

1. что посоветуете, если проектов много и все нужно в запущенном состоянии держать на слабеньком тестовом VPS? Задача есть, но совсем еще не брался. Пока вижу проблемы с оперативкой и занятые порты.

2. php-cli (artisan) запускается под той же версии php что php-fpm?

3. если только для production нужно свои настройки nginx, то выходит нужно какой балансировщик свой впереди ставить, чтоб dev не отвалился? Допустим https c переадресация http->https.
Если на проект зайти под другим HTTP_HOST, то он запустит приложение?

Сам далек от Руби, но натыкался на такое github.com/rubocop-hq/ruby-style-guide

По опыту с PHP кодом тоже насмотрелся и навелосипедировал вариантов, после просто начал доверять нормальным редакторам, не знаю как под RubyMine, но под PHPStorm хорошо справляется автоматическое форматирование кода (под Мак Alt+CMD+L)


причем очень нравится вариант когда форматируется только выделенная область, так в коммитах только твой красивый код)

Был примерно подобный опыт, но использовали MongoId, на практике в одних папках лежало овер4к файлов, в других 2-3. Как тут с равномерностью? Пока новых задач не было под большое кол-во файлов, поэтому просто положил оригинальные файлы под primaryKey /files/000/000/001.jpg, при этом извне недоступны, дальше по запросу нарезается(?) раздается под кэшем со storage-(1-2-3).site.tld/access-key/$file_id/(full|120x90|...).ext. Таблица файлов естественно знает откуда раздается файл

webpack в целом смешной, максимально пытается сказать что он тут главный и сейчас все покажет- такой Нарцис, gulp на его уровне простой пацанчик Подай-Принеси-Сделай. И главное вроде по докам все хорошо, работает на ура и узнаешь много нового, но как только пытаешься внедрить куда, особенно где давно сидит дед-бэкенд…

У панели Plesk есть модуль Git и можно даже на обычные хостинге деплоить, вернее поставить на автомат чтоб тянул с какого репозитория настроив web-хуки