«Астрологи обьявили неделю политоты...» вот почему нефть растет с января 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 то я уверен что обычный алгоритм сложения сработает значительно быстрее (при одинаковом быстродействии железа, само собой)
Технология не причем, но разработчик хвалит такой подход в статье (
Скажем, человек купил пару обуви, солнцезащитные очки и книгу. В рассылке для него мы покажем обувь, солнцезащитные очки и книги.
), а с чего он взял что мне нужна вторая пара обуви, вторые очки и какая-то книга (непонятно как подобранная, та же что я уже купил? или ORDER BY random limit 1?)?
По сути дела меньше всего глаза напрягаются от картинки, к которой они «привыкли» за годы эволюции. Завышенная контрастность, чрезмерная яркость, не встречающийся «в природе» спектральный состав или динамические их изменения приводят к ускоренной усталости.
а нет ли у вас ссылок на какие-нибудь исследования по этой части? Для меня не очевидно, почему от созерцания костра ночью глаза должны меньше уставать чем от просмотра VS Code Dark Theme на моем ЖК-мониторе
«На EInk экране писать код» — лучше уж в блокноте, он хотя бы не лагает.
Я это к тому, что, если я все правильно понимаю, тот кто в статье предложил писать код на таком экране сам код никогда на нем не писал, иначе бы очень быстро понял что отличить зеленоватый, розоватый и синеватый на градациях серого невозможно, а без нормальной подсветки синтаксиса сейчас наверное уже вообще никто работать не будет. А скорость обновления экрана это уже мелочи по сравнению с этим недостатком.
Если не ошибаюсь у современных ЖК-дисплеев углы обзора такие, что незначительные отклонения от нормали (которые неприменно возникают когда мы держим устройство в руках) не влияют на спектр излучения экрана со сколько-нибудь различимой для глаза силой. Смотреть что читает сидящий рядом в метро, вероятно, не так удобно, но это же не кейс для личной читалки.
Насчет контрастности слышал ровно обратное суждение — чем она ВЫШЕ тем читать легче и глаза напрягаются меньше.
Подскажите пожалуйста, а какое дело глазу до равномерности рассеивания света вне текущего угла обзора? вроде как весь свет в глаз не попавший учитываться глазом не должен
— не понял вас, что значит «поехать»? При копировании файлов владельцем у файлов могут поменятся права?
я и не спорю что его так можно использовать, пока что не понял почему вы отказываете ему в функции фиксации состояния системы? Потому что вы используете готовые контейнеры и не можете полностью положиться на систему тегов?
А если так:
я забэкапил 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 то я уверен что обычный алгоритм сложения сработает значительно быстрее (при одинаковом быстродействии железа, само собой)
Так вот откуда берутся эти разработчики интернет-магазинов, которые предлагают мне купить шкаф после того как я купил шкаф. Уж лучше ML чем такой SQL.
а нет ли у вас ссылок на какие-нибудь исследования по этой части? Для меня не очевидно, почему от созерцания костра ночью глаза должны меньше уставать чем от просмотра VS Code Dark Theme на моем ЖК-мониторе
Я это к тому, что, если я все правильно понимаю, тот кто в статье предложил писать код на таком экране сам код никогда на нем не писал, иначе бы очень быстро понял что отличить зеленоватый, розоватый и синеватый на градациях серого невозможно, а без нормальной подсветки синтаксиса сейчас наверное уже вообще никто работать не будет. А скорость обновления экрана это уже мелочи по сравнению с этим недостатком.
Насчет контрастности слышал ровно обратное суждение — чем она ВЫШЕ тем читать легче и глаза напрягаются меньше.
У вас правда такая бедная подсветка синтаксиса? Я в 16 градациях серого с трудом различу все варианты подсвечиваемых конструкций
Подскажите пожалуйста, а какое дело глазу до равномерности рассеивания света вне текущего угла обзора? вроде как весь свет в глаз не попавший учитываться глазом не должен