Если не ошибаюсь на железной дороге есть специальность «машинист», а есть «водитель электровоза», такое ощущение что за штурвалами в этих двух случаях были не пилоты, а «водители самолета»
какую именно ситуацию лучше отображает тренд на максимальном сроке? средней температуры по больнице? где границы этого максимального срока? по дате открытия торгов на бирже по нефти?
по такой логике глобус лучше отображает ситуацию чем сотка по местности
Если так рассуждать то любой рост и любое падение локально (оно так и есть в масштабах вечности), другое дело что сейчас рост (может быть «локальный», длиною > 2 лет) а на картинке пчм-то бочка вниз катится.
Ну статья-то вроде как свежая, т.е. предполагаю что и иллюстративный материал должен быть актуальным, а он актуален для промежутка до января 2016 — странно как-то.
«Астрологи обьявили неделю политоты...» вот почему нефть растет с января 2016 (не без локальных падений, но тренд виден), а на карикатурах до сих пор рисуют бочки нефти катящиеся вниз?
Вы делаете странное предположение что я тащу контейнеры из общего репозитория, для продакшена я такого никогда не делаю и вам не советую. У меня есть мой Dockerfile, из него собранный образ, и в нем совершенно точно лежит именно та версия которая работала до начала обновления.
кстати, он у вас КОПИЯ, т.е. где-то могли права доступа к файлам «поехать»
— не понял вас, что значит «поехать»? При копировании файлов владельцем у файлов могут поменятся права?
Понимаете, докер — это про rolling release
я и не спорю что его так можно использовать, пока что не понял почему вы отказываете ему в функции фиксации состояния системы? Потому что вы используете готовые контейнеры и не можете полностью положиться на систему тегов?
А если так:
я забэкапил volume с БД
убил контейнер с mysql 5.6 (не volume с данными)
запустил контейнер с mysql 5.7 смонтировав ему этот volume
если надо откатить:
я убил контейнер mysql 5.7, volume с данными тоже убил
я создал volume с бэкапом
я запустил контейнер с mysql 5.6 подцепив ему этот volume
почему вы считаете что в данной схеме docker не помогает мне вернуться к стабильному состоянию системы? Или вы считаете что состояние будет не соответствовать исходному?
Сама БД у меня забэкаплена, развернуть не долго. Опасения вызывает ситуация "загаживания" системы конфигами/обновленными зависимостями новой версии СУБД, и трудности по выкорчевыванию этих изменений для успешного отката на предыдущую версию. Проще говоря контейнер дает мне состояние системы к которому я могу легко вернуться.
Мне кажется что есть еще один момент, который добавляет смысла в идею контейнеризации СУБД: обновление версии СУБД. Лично мне очень приятно иметь всегда чистый хост и не переживать что в результате обновления версии СУБД, а потом отката обратно (всякое бывает, тестирование не всемогуще) я не смогу вернуть систему к ее предыдущему состоянию быстро.
вообще говоря сотрудник которому проще подделать документ нежели договориться об отгуле (в счет отпуска, либо под отработку, либо за свой счет) вызывает определенные опасения
Создаешь в нужном месте div с нужным id, потом инициализируешь vue.
именно так, а Vue лезет в DOM и ищет этот div, мне кажется тут присутствует некоторая избыточность — если бы я мог просто передать ссылку на элемент то и искать его в DOM было бы незачем
похоже что разработчики Vue смотрят на ситуацию под схожим углом — если посмотреть в доки Vue, то окажется что в параметр el можно передавать не только селектор, но HTMLElement (https://vuejs.org/v2/api/#el)
И, наконец, все три фреймворка используют привязку к элементу #app. В каждом из них эта операция выполняется по-разному. Надо отметить, что в Vue эта операция выглядит самой простой и понятной и даёт разработчику более гибкую конструкцию, работая с селектором элемента, а не с самим элементом.
Т.е. передать селектор это удобнее чем самому подобрать элемент и отдать фреймворку? Точно?
В случае если я отдаю элемент я сам решаю как его выбирать, возможно я даже его буду сам динамически создавать, подцеплять в DOM и потом уже инитить фреймворк. В случае селектора — извините, запихайте пожалуйста вначале элемент в разметку, а потом отдайте селектор фреймворку чтобы он опять пошел щупать DOM на предмет элемента, на котороый у меня вроде как уже ссылка есть.
*Фишка нейронок — они очень и очень быстро решают задачи на которые обучены. Никакой алгоритм не сделает того же с подобной скоростью.
а можете какую-то ссылку дать или как-то пояснить ваше утверждение?
я утрирую конечно, но если я обучаю нейросеть вычислять сумму двух целых чисел, скажем, в диапазоне от 0 до 1000000 то я уверен что обычный алгоритм сложения сработает значительно быстрее (при одинаковом быстродействии железа, само собой)
а чтоб совсем подходило, то сколько надо? 12?
какую именно ситуацию лучше отображает тренд на максимальном сроке? средней температуры по больнице? где границы этого максимального срока? по дате открытия торгов на бирже по нефти?
по такой логике глобус лучше отображает ситуацию чем сотка по местности
— не понял вас, что значит «поехать»? При копировании файлов владельцем у файлов могут поменятся права?
я и не спорю что его так можно использовать, пока что не понял почему вы отказываете ему в функции фиксации состояния системы? Потому что вы используете готовые контейнеры и не можете полностью положиться на систему тегов?
А если так:
я забэкапил volume с БД
убил контейнер с mysql 5.6 (не volume с данными)
запустил контейнер с mysql 5.7 смонтировав ему этот volume
если надо откатить:
я убил контейнер mysql 5.7, volume с данными тоже убил
я создал volume с бэкапом
я запустил контейнер с mysql 5.6 подцепив ему этот volume
почему вы считаете что в данной схеме docker не помогает мне вернуться к стабильному состоянию системы? Или вы считаете что состояние будет не соответствовать исходному?
Сама БД у меня забэкаплена, развернуть не долго. Опасения вызывает ситуация "загаживания" системы конфигами/обновленными зависимостями новой версии СУБД, и трудности по выкорчевыванию этих изменений для успешного отката на предыдущую версию. Проще говоря контейнер дает мне состояние системы к которому я могу легко вернуться.
Мне кажется что есть еще один момент, который добавляет смысла в идею контейнеризации СУБД: обновление версии СУБД. Лично мне очень приятно иметь всегда чистый хост и не переживать что в результате обновления версии СУБД, а потом отката обратно (всякое бывает, тестирование не всемогуще) я не смогу вернуть систему к ее предыдущему состоянию быстро.
а можно источник, откуда "запускать БД в Docker это нерекомендуемая практика"? или это вы так не рекомендуете делать?
для какого-нибудь apache вытаскивать webroot в volume тоже не рекомендуете? или вебсерверы тоже не стоит в контейнеры помещать?
например если я начинающий разработчик мне лучше чтобы "вжух" и работает, менять там mysql на postgres я не собираюсь
насчёт gitlab — та же история, хочу попробовать запустить и посмотреть чего как, если ок то соберу свое в прод
думаю что вы ошибаетесь: чтобы письма были красивыми достаточно data uri
я так понял что он переписывался с рабочей машины, иначе как бы логи в систему попали
именно так, а Vue лезет в DOM и ищет этот div, мне кажется тут присутствует некоторая избыточность — если бы я мог просто передать ссылку на элемент то и искать его в DOM было бы незачем
похоже что разработчики Vue смотрят на ситуацию под схожим углом — если посмотреть в доки Vue, то окажется что в параметр el можно передавать не только селектор, но HTMLElement (https://vuejs.org/v2/api/#el)
Т.е. передать селектор это удобнее чем самому подобрать элемент и отдать фреймворку? Точно?
В случае если я отдаю элемент я сам решаю как его выбирать, возможно я даже его буду сам динамически создавать, подцеплять в DOM и потом уже инитить фреймворк. В случае селектора — извините, запихайте пожалуйста вначале элемент в разметку, а потом отдайте селектор фреймворку чтобы он опять пошел щупать DOM на предмет элемента, на котороый у меня вроде как уже ссылка есть.
я утрирую конечно, но если я обучаю нейросеть вычислять сумму двух целых чисел, скажем, в диапазоне от 0 до 1000000 то я уверен что обычный алгоритм сложения сработает значительно быстрее (при одинаковом быстродействии железа, само собой)