Ютуб не очень подходит для этого. Какое-то видео «с приручением к горшку» задетектит как недопустимый контент и выпишет предупреждение. Если заливаешь сразу много клипов легко набрать три такие предупреждения и получить бан аккаунта. И иди жалуйся в спорт лото.
В декабре 2018 в Nutrients (вроде это уважаемый журнал, гугл говорит что индекс Хирша для него аж 100) опубликована статья Water Intake, Water Balance, and the Elusive Daily Water Requirement в которой авторы приводят таблицу рекомендуемого общего потребления воды опубликованные в Европе и в Америке. И там все не так просто, как 2 литра на человека. Надо учитывать пол, возраст, окружающий климат, индивидуальные особенности организма, количество физических нагрузок.
И что наиболее примечательное речь идет не только о чистой воде, но и воде из напитков и еды.
values refer to total water intake (TWI = plain water + beverages + food moisture)
Слишком мягкая вода приводит к коррозии. А что может пострадать от неё если в доме нет железных труб? (пластиковые трубы, латунные краны, медные теплообменники)
Интересный вопрос тут обсуждается. Хотел бы к нему присоединиться. Есть ли исследования обнаружившие вред для организма от слишком мягкой или вообще дистиллированной воды?
Мне кажется странной идея о «вымывании из организма электролитов дистиллированной водой», словно организм это не система обеспечивающая гомеостаз, а просто сосуд с насыщенным раствором. И пример с горцами согласуется с этим ощущением. Но хорошо бы оперировать исследованиями, жаль не умею их искать.
Кстати автор тоже ссылается на это же доклад ВОЗ, что и вы, но делает на его основании свои выводы:
В свете того, что Всемирная организация здравоохранения еще в 2011 году отметила, что не имеется достаточно данных для установления нижних (и верхних) пределов жёсткости воды, можно считать что наличие солей жесткости в воде — это обязательное условие нормальной жизнедеятельности человека.
Мне одному кажется, что некорректно приравнивать отсутствие рекомендаций по жесткости воды к признанию обязательности употребления именно жесткой воды?
Да, конечно же, читал вашу статью. Хороша.
Вы не рассматривали автоматическую компиляцию go приложения, а т.к. я столкнулся с ньюансом при его остановке, то решил все же написать ещё одну.
В нашем случае вынос второго микросервиса очень маловероятен. В противном случае, разумеется, делали бы более универсально.
Даже если поднимать не полную версию базы, Go приложение должно знать как это делать, это подразумевает дублирование информации и теоретическую возможность рассинхронизации. Например миграция в Rails затронет критическое поле, а в тестах go это изменение не внесем, тесты будут зеленые и проблема всплывет уже на QA/Production. Это маловероятно, разумеется, учитывая редкое изменения структуры базы. Но любое такое «дублирование» информации или кода не дает мне покоя.
Разработка это всегда компромисы, между простотой и расширяемостью, или эффективностью кода и его читаемостью.
Вероятно вы имеете в виду, что правильнее было бы общаться между двумя сервисами по отдельному внутреннему API разработанному специально для этой цели. Его создание и тестирование тоже не бесплатно. А если таблицы, нужные TheService, уже годами не меняются, почему не ходить в одну базу, допустив неизменность тех таблиц?
не надо делать вид, что один из них этой БД "не владеет", и по этой надуманной причине не может поднять себе тестовую базу
"TheService" знает о существовании нескольких таблиц и использует только некоторые столбцы из них. Он не знает как создать эти таблицы, и не подозревает о существовании других столбцов и таблиц. В моем понимании это как раз "не владеет БД". Все данные о структуре таблиц в миграциях Rails. Вы что, предлагаете дублировать их в Go приложении, что бы то могло создавать себе полную тестовую базу? Поступи мы так, можно было бы писать тесты с настоящими запросами в БД прямо в Go, это один из вариантов.
Про моки не понял зачем вы советуете. У нас проблема была как раз в их наличии, т.е. тест не затрагивал базу и не гарантировал работоспособность фитчи.
Для тренировки скорости печати есть http://klavogonki.ru/. Графика и звук самих машин там конечно не такая шикарная. В остальном не могу сравнить, т.к. Набираем.ру не пользовался.
При изменении base.html, например добавлении текста «test», эти изменения не отображаются на странице. Даже перезапуск приложения не помогает. Приходится удалять «ebin/*.beam».
Почему так получается, это баг или фитча?
Это такая «городская легенда» о том, что ширина колеи в Америке по историческим причинам зависит от использования колесниц в Римской империи, а от ширины колеи зависят размер двигателей на космических аппаратах NASA. ссылка
Но NASA опубликовала опровержение, в котором раскрывает понятие «городской легенды» и приводит доводы, почему это именно легенда. В кратце: во времена римской империи колесницы уже устарели, появились большие лошади, способные в одиночку нести всадника, а конница была мобильнее колесниц. Ну и в Америке было много стандартов ширины колеи, ведение войны потребовала пперейти к одному стандарту, для ускорения логистики, насколько я понял выбрали такую ширину, что бы переделывать как можно меньше проложенных колей.
И что наиболее примечательное речь идет не только о чистой воде, но и воде из напитков и еды.
Мне кажется странной идея о «вымывании из организма электролитов дистиллированной водой», словно организм это не система обеспечивающая гомеостаз, а просто сосуд с насыщенным раствором. И пример с горцами согласуется с этим ощущением. Но хорошо бы оперировать исследованиями, жаль не умею их искать.
Кстати автор тоже ссылается на это же доклад ВОЗ, что и вы, но делает на его основании свои выводы:
Мне одному кажется, что некорректно приравнивать отсутствие рекомендаций по жесткости воды к признанию обязательности употребления именно жесткой воды?
А я не знал, что можно открыть пустое diff window. Для сравнения приходилось вставлять одну часть в новый scretch файл, а вторую в буфер обмена.
Да, А еще отсутствие профильного образование можно компенсировать опытом работы по специальности.
Т.е. использовать Acronis для бекапа и восстановлени всего диска не получится?
Да, конечно же, читал вашу статью. Хороша.
Вы не рассматривали автоматическую компиляцию go приложения, а т.к. я столкнулся с ньюансом при его остановке, то решил все же написать ещё одну.
Даже если поднимать не полную версию базы, Go приложение должно знать как это делать, это подразумевает дублирование информации и теоретическую возможность рассинхронизации. Например миграция в Rails затронет критическое поле, а в тестах go это изменение не внесем, тесты будут зеленые и проблема всплывет уже на QA/Production. Это маловероятно, разумеется, учитывая редкое изменения структуры базы. Но любое такое «дублирование» информации или кода не дает мне покоя.
Разработка это всегда компромисы, между простотой и расширяемостью, или эффективностью кода и его читаемостью.
Вероятно вы имеете в виду, что правильнее было бы общаться между двумя сервисами по отдельному внутреннему API разработанному специально для этой цели. Его создание и тестирование тоже не бесплатно. А если таблицы, нужные TheService, уже годами не меняются, почему не ходить в одну базу, допустив неизменность тех таблиц?
"TheService" знает о существовании нескольких таблиц и использует только некоторые столбцы из них. Он не знает как создать эти таблицы, и не подозревает о существовании других столбцов и таблиц. В моем понимании это как раз "не владеет БД". Все данные о структуре таблиц в миграциях Rails. Вы что, предлагаете дублировать их в Go приложении, что бы то могло создавать себе полную тестовую базу? Поступи мы так, можно было бы писать тесты с настоящими запросами в БД прямо в Go, это один из вариантов.
Про моки не понял зачем вы советуете. У нас проблема была как раз в их наличии, т.е. тест не затрагивал базу и не гарантировал работоспособность фитчи.
Почему так получается, это баг или фитча?
Но NASA опубликовала опровержение, в котором раскрывает понятие «городской легенды» и приводит доводы, почему это именно легенда. В кратце: во времена римской империи колесницы уже устарели, появились большие лошади, способные в одиночку нести всадника, а конница была мобильнее колесниц. Ну и в Америке было много стандартов ширины колеи, ведение войны потребовала пперейти к одному стандарту, для ускорения логистики, насколько я понял выбрали такую ширину, что бы переделывать как можно меньше проложенных колей.
А где можно почитать про эти good practice?