smilingcheater

Выключить компьютер из розетки.
Запомнить какой конкретно использовался кабель (надписать).
Запомнить настройки в BIOS.

Ни в коем случае не пушить туда-сюда.

• В идеальном случае ваш проект должен поддерживать миграции:
  
• Каждая ревизия кода, которая нарушает совместимость с БД относительно предыдущей, должна содержать скрипт миграции. В этом скрипте создаётся структура, модифицируются старые данные, переименовываются поля и т.д. Иногда такие скрипты делают двунаправленными, чтобы поддерживать обратные миграции.
  
• В БД нужно хранить версию или номер ревизии, которой соответствует текущее состояние БД.
  
• При запуске приложения нужно проверять версию и выполнять цепочку миграций, необходимых для приведения версии к требуемому состоянию.
  

Так вы можете добиться того, чтобы продуктовая БД была отдельно, тестовая отдельно, девелоперская отдельно. Очень плохая идея работать на девелоперской машине с данными из продовой базы. Так происходят утечки перс-данных.

Монга - это schema less БД, которая толерантно относится структуре коллекций и не валится при запросе несуществущих полей. Нужно стараться писать код максимально толерантно к отсутствию наполнения БД.

В любом случае у вас в БД есть обычно:

1. структура (в случае монги, как я уже сказал, это не так важно)
   
2. справочники
   
3. пользовательские данные
   
4. производные данные (кэш), которые можно безболезненно удалить, а затем они перегенерятся сами по мере запросов.
   

Нужно писать код так, чтобы он всю структуру и технические справочники, отсутствующие в предоставленной БД и необходимые для работы, умел инициализировать сам. Или, на худой конец, сделайте команду или скрипт init_db.

Если какие-то тестовые данные нужны для тестов или отладки, то можно сделать скрипт, который заполнит БД ими. Это называется фикстуры.

Никогда не храните код в БД. Всякие хранимые процедуры и прочее в БД - это зло. Код должен быть в системе контроля версий, а БД к этому не приспособлены. Если уж нужны хранимки, то храните их в системе контроля версий и заливайте их в БД при инициализации или миграциями.

Ну, наверное, потому что вы ничего не возвращаете из функции.

То, что вы присвоили переменной number новое значение — не значит, что вы переопределили ее в приложении. У каждой функции свой скоуп. Этот number останется внутри функции. Вы передаете переменную в функцию не по ссылке, а по значению. То есть, значение вашей num1 копируется в функцию, но вне этой функции оно останется прежним.

Сделайте return конвертированного числа из функции и запишите результат в константу.

const result = num_translate(num)

Что у вас docker-compose ps показывает - все ли контейнеры запущены?

192.168.0.1

Это ip хоста, там Редиса нет.

127.0.0.1

Это локалхост, там Редиса нет.

0.0.0.0

Это вообще невалидный ip.

redis

А вот по имени он должен бы работать. Вам нужно выяснить имя сети и сделать docker network inspect %name%, чтобы увидеть ip Редиса - с ним должно работать точно.

Правильное решение: получить и установить таки серитиикат для своего сервера. С lets encript это быстро и бесплатно.

Костыль: поставить на сайте:

<meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests">

По сути это хак, т.к. основное предназначение этого заголовка - заставить всё работать через https, но если браузер не получает ответа по https порту - он разрешает работу по http.

Любым способом настроить https у сервера с нодой.

Например настроить обратный прокси на домене сайта.

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

веб – пожалуй, самая обширная и востребованная область сейчас. но, и в ней есть 100500 областей, требующих различных умений; да и вне ее жизнь не закончилась.

можете в web? плюс один пункт в списке скилов.
не можете? не вопрос, если хороши в своей области.

Как только открыли сессию через session_start, файл сессии блокируется до завершения работы скрипта или завершения работы с сессией через session_abort, session_commit или session_write_close.
Если ваш тяжёлый скрипт не нуждается в данных сессии до самого конца работы, то можете просто закрыть сессию сразу после использования сессионных данных.