coder4web

Контейнеры данных

Они не нужны, используйте named volumes вместо этого (с версии 1.9 докера).

Исходный код и локальные npm-модули (или лучше это в предыдущий контейнер, и при старте выполнять

Нет, npm install надо выполнять ДО сборки образа. Когда контейнер стартует - внутри у него уже все должно быть. Опять же я лично против того, что бы выносить исходники проекта в отдельный контейнер-пустышку. У вас есть контейнер с нодой - исходники для ноды должны быть там. Есть некоторые нюансы связанные со сборкой контейнера но это так.

На файловой системе хоста

Ничего.

Логи прокидываются в stdout/stderr контейнера и собираются на хосте через докер любым подходящим драйвером (читаем документацию).

Конфигурация - все что в конфигах от окружения к окружению меняется - в ENV переменные. Все остальное - не меняется и потому просто вшито внутрь контейнера.

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

• Если у вас есть бизнес-план, то у вас есть и ответ на вопрос о бюджете.
  
• Если у вас нет бизнес-плана, то на вопрос "реально ли", ответ отрицательный.
  

Я уже более 2-х лет активно тренируюсь и могу поделиться опытом.

Спортзал - штука очень спорная. Я не верю в то, что можно заниматься бесконечно долго по одной и той же схеме без утомления. В моём случае получался такой расклад, чтобы пойти потренироваться:
- собрать сумку с необходимыми вещами для тренировки
- добраться до спортзала
- переодеться
Только на этот этап можно потратить порядка часа.
Далее сама тренировка около 1 часа.
Затем душ, переодевание и обратный путь и вынуть просушиться вещи - ещё час.

Итого: чтобы потренироваться пойти в спортзал нужно заложить 3 часа времени. А если ещё график не очень гибкий, то можно и в час пик попасть, когда зал переполнен и это вызывает неудобства из-за плотного графика упражнений.

Лучше всего ориентироваться на домашние и уличные тренировки. Плюс тут несомненный в том, что как только появилось желание подвигаться - пошёл и поделал упражнения. Ещё один: можно делать несколько тренировок в день с минимальными затратами времени.

Главный секрет поддержания интереса к тренировкам - научиться получать удовольствие от них. Для этого нужна непринужденная атмосфера и медленное сосредоточенное выполнение.

Есть замечательная книжка Пола Уейда "Тренировка заключенных", где очень системно описаны группы упражнений для любого уровня подготовленности и практически в любых окружающих условиях.

Но это только то, что касается силового тренинга.
Я считаю, что есть смысл хотя бы 1-2 раза в неделю выполнять аэробную тренировку: бег, велосипед и т.п. В спортзале это делать чрезвычайно быстро надоедает - вокруг только серые стены, никакой реальной движухи. Через месяц уже тошно становится от беговой дорожки или велотренажера.

Наверное еще добавлю, что на первых порах очень важно придерживаться плана тренировок. Это касается и графика по дням недели, и по составу. Где-нибудь через полгода-год можно уже импровизировать.

Что касается питания. На мой взгляд самой прогрессивной диетой сегодня является LCHF. Суть сводится к уменьшению потребления быстрых и медленных углеводов до нуля, а калорийность обеспечивать жиром. Соответственно, белок само собой тоже нужен. Хороша она тем, что организм не ощущает каких-то лишений, голода нет. Жиры очень долго расщепляются, а без углеводов излишки будут выводиться организмом, вместо переноса в жировую ткань.
Градации потребления пищи в зависимости от времени суток считаю профанацией. Можно разве что избегать питания тяжелой пищей менее, чем за 2 часа до сна.

По первому вопросу - смотрите код, ищите хуки и фильтры. Направление в котором копать (кроме документации, конечно же):
stackoverflow.com/questions/21709826/woocommerce-o...

По второму - billing address и shipping address - это два разных адреса. Биллинг - это адрес плательщика. Шиппинг - адрес куда доставить. Первый всегда один и тот же будет при повторных покупках, второй может меняться - заказать доставку в офис, родителям домой, девушке на работу и т.д. - вариантов масса. При первой регистрации надо заполнить оба адреса, во второй раз же billing уже будет заполнен. Чтобы сделать процесс удобнее для покупателя, есть опция "галочка - использовать адрес биллинга для доставки". Не помню только это родная фича WooCommerce или есть для этого плагин. Но точно есть - посмотрите настройки WC и поищите плагин через админку, если в настройках не найдете.

"ленивая загрузка" - то есть использование объекта при необходимости, если надо будет, она возьмёт объект и загрузит его. В ZF2 это всё дело разруливается через ServiceManager с типом конфигурации invokables, там вы можете помещать как непосредственно классы, так и службы (по сути одно и тоже, только семантика разная). Например, вы создали какую то уникальную обработку данных для какого то конкретного случая, и вы хотите её использовать в своём модуле, или даже в конкретном контроллере какого то модуля (а потом оказалось, что вам её нужно ещё где-то использовать). И вот как раз на помощь приходит "ленивая загрузка", где вам нужно класс с уникальной обработкой данных указать в конфигурационном файле. Теперь, как только вашему приложению понадобится этот функционал (например пользователь запросил какие то ресурсы, которые обрабатываются на сервере именно вашей уникальной обработкой данных), то он (ServiceManager) возьмёт этот класс, то есть при необходимости подгрузит. К стати, как я выше писал в скобках, что возможно вам понадобится ещё где-то использовать, то вы можете ещё дальше пойти, то есть уже в конфигурационном файле указать тип factories, где поместить ранее созданный класс фабрики реализованный с помощью FactoryInterface, и после чего класс с уникальной обработкой данных будет создан независимо от возможных требований лишь тогда, когда он был первый раз вызван, а дальше вы его можете использовать на уровне всего приложения. То есть в одном месте объявили, вызвали его, а дальше вызываете его где угодно и сколько угодно. Стоит заметить, что при повторном вызове, возвращается один и тоже объект, и если вам всё таки понадобится новый объект для какого то конкретного случая, то нужно сделать кое какую поправку, и вы получите новый объект.

Как определить, что часть приложения стоит оформить в отдельный модуль?

Если эту часть приложения можно реюзать и она ни от чего не зависит. Модули нужны исключительно для вынесения кода, который можно переиспользовать.

Как определить, что часть приложения нужно вынести в отдельный контроллер?

Никак. Читайте про тонкие контроллеры и жирные модели или на худой конец толстите сервисный слой. Реюз контроллеров дело совсем не благородное.

www.ustream.tv/recorded/22783515 - рекомендую

Для связи EM и RoR есть gem websocket-rails.
Судя по всему, он относительно живой (внутри у него, кстати, faye). Вообще, веб-сокеты и RoR работают по принципиально разным схемам взаимодействия с клиентом, и я бы рассмотрел вариант их в одну кучу не мешать. Для того, чтобы веб-сокеты работали, понадобится асинхронный веб-сервер - websocket-rails использует Thin, можно и Puma приспособить, а вот Unicorn уже не пойдет.

Если файлы статические и лежат локально - не понятен смысл прокси. Можно отдавать сразу файлы, прописав путь в соответствующем location.

Если файлы лежат на удаленном хосте, то можно настроить их кэширование на некоторое время. После протухания кэша, новый файл загрузится с удаленного хоста и будет положен в кэш.
Есть возможность принудительно запросить файл минуя кэш, используя заголовки запроса.

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