Спасибо за рассказ. Удивительно, насколько вы логично и правильно рассуждаете. И насколько грамотно рассказываете о тонких и скользких моментах. Я давно не читал настолько продуманную расшифровку от женского лица. Это супер.
Мы подавали на Старт-1 Fasie в этом году проект с инновационной идеей. Грант не получили и общение с "экспертами" оставило негативное впечатление. Каждый вопрос был в таком духе: мы уже знаем, что ваш проект не будет поддержан, а теперь скажите нам, почему он не будет поддержан. Так же понравилась экспертная мысль: "у вас тут есть прототип, а чего вы продукт то не сделали еще. Вот сделайте продукт и приходите тогда". Cцена из театра абсурда. В целом осталось впечатление, что эта структура себя изжила. Никакие инновации "со стороны" они не поддерживают, там уже все распределено. У них там у всех всё хорошо.
То, что фактор своей подачи - сильный, очевидно для всех, кто играет в бадминтон. Картина игры на своей подаче и по подаче соперника совершенно разные. Когда будет больше данных, эту гипотезу можно отдельно проверить, конечно.
Да, верно, пользователь должен фиксировать каждый удар, чтобы собрать данные.
Тренер может сказать свое субъективное мнение. Отследить компоненты игры у каждого игрока тренер не в состоянии, так как зачастую у него много спортсменов. И тем более он не может оценить прогресс или регресс в компонентах игры по времени.
У JSON Schema есть минус, на мой взгляд: схему для данных не удобно писать руками.
Гораздо быстрее и понятнее написать JSON примеры, а из них уже сгенерировать схему.
Причем, если добавить еще какой-нибудь «side-car язызок» к примерам, то генерировать схему из примеров можно 1 к 1, скорей всего (тем более, если допустить, что примеров для генерации схемы может быть несколько).
Что вы об этом думаете? Не знаете ли тулзов, которые это умеют?
С проблемой формулировки модели данных, для которой JSON подходит обычно идеально, встречаются 100% разработчиков. Поэтому и подобного рода тулза была бы крайне востребована.
Интересная статья. Согласен с тем, что информации о ноде и ECMAScript/js очень много, поэтому люди просто тонут в этой информации *И* не находят основные вещи.
Где почитать концентрированную инфу о Node.js (без воды), чтобы там были ответы на эти вопросы?
Интересная статья, но SLI и SLO у вас определены либо неправильно, либо нестандартно.
SLI — это метрики, которые меряют пользовательский опыт.
SLO — это числовые границы SLI метрик, внутри которых значение SLI принимается как ОК.
SLA — это время, в котором SLI метрики находились в SLO диапазоне. Т.е. SLA — это итоговая производная метрика из SLI метрик, пересчитанная на время.
Ага, совпадает с моим собственным мнением.
У нас была проблема как раз с тем, что через HTTP ходит нормально, а вот через HTTPS — нет (были настроены два server_name, скажем a_server_name и b_server_name и если первый запрос приходит к a_server_name, то все остальные запросы и к a_server_name и к b_server_name идут все равно через a_server_name).
>… Можете со мной не согласиться, но я считаю, что Kubernetes больше предназначен для микросервисов, а не stateful.
Из того, что в Kubernetes есть StatefulSet следует, что Kubernetes можно использовать для задач, для которых нужен StatefulSet.
>Вы можете использовать данную инструкцию для любых целей, всё ограничивается лишь вашей фантазией)…
Пока только понятно, что нужно было поднять Kafka и Jmeter, так как, догадываюсь, Jmeter принимает данные из Kafka.
Стенд для такой связки можно было вначале собрать в minikube.
Зачем нужны Flannel, Kafka Connect, MirrorMaker 2.0, Apache Zookeeper, а также «production» и «backup» среды не понятно.
Но, спасибо за скрипты.
А для какой задачи нужно было поднять этот стенд? Без точного понимания задачи, чтобы понять что мы хотим сделать нужно сначала вчитаться во все скрипты. Ну Kafka, ну Jmeter, а сделать то, что мы хотели исходно?
>Обращаю внимание на то, что установка stateful в контейнерах — далеко не лучшая идея, поэтому данная инструкция не предназначена для развертывания промышленного стенда.
Не совсем понятно. Использовать StatefulSet для перечисляемых имен подов вполне нормальная практика (это написано в документации).
>Почему Docker, а не CRI-O? Мне интересен CRI-O и я планирую изучить его в будущем
А можете чуть пояснить «Зелёному», в чем суть этой правильно архитектуры?
Типа хотим подружить физические разные ноды, которые были под рукой?
Физические сетевые карты чем-то принципиально отличаются от виртуальных?
Clojure как раз по-середине :).
Как только модель данных полностью сформулирована и пазл сошелся, ничто не мешает в Clojure коде перейти на static typing.
Привет, я — Андрей и я — фанат Clojure :).
По нашему опыту, задачи на Clojure решаются в 2-3 раза быстрее, чем на Java (без потери качества).
Субъективно, года 2 назад был бум Clojure, но сейчас этот бум почему-то стих. Нет ли у вас такого ощущения? И если есть, то какие вы бы могли назвать причины этого?
Я не согласен с тем, что эта модель способна предсказать цену в принципе.
Результат предсказания по этой модели известен заранее, до проведения какого-либо моделирования (вы получите ровно то, что вы задавали в самом начале).
Причем тут идеи об эффективном рынке и как они связаны с представленной моделью пока тоже не понятно.
Не надо перекладывать с больной головы на здоровую ;).
Контекстный подход успешно решает:
1) проблему декомпозиции кода (когда код метода не влезает в один экран);
2) упрощает тестирование и, как результат, ускоряет разработку;
3) предлагает альтернативный вариант к гибкой реализации retry фичи, когда можно делать retry не всей операции полностью, а только тех шагов, которые нужны.
А, и да, самое главное: Disclaimer: этот метод не улучшает качество кода криворукого разработчика, а наоборот ухудшает его экспоненциально :).
Эти же теоремы будут выполняться, если данные можно разбить на независимые куски. Тогда зависимость внутри кусков будет влиять только на то, что нужно больше данных (и это нужно учитывать в значениях уровня значимости). Другими словами, зависимость внутри кусков влияет только на то, что количество фактической информации меньше N, где N — размер выборки (и будет пропорционально количеству независимых кусков, с фактором порядка единицы).
1) по закону больших чисел (теоремам Хинчина и Чебышева), для выборки из любого количества разных распределений с конечными матожиданиями и дисперсиями — среднее значение выборки сходится к среднему значению матожиданий
2) по центральной предельной теореме, для выборки из одного любого распределения с конечной дисперсией — среднее значение, при большом размере выборки, будет нормальной случайной величиной
3) по закону больших чисел, теореме Чебышева, для выборки из любого количества разных распределений с конечными матожиданиями и дисперсиями и дополнительным условием на сходимость дисперсий — среднее значение, при большом размере выборки, будет нормальной случайной величиной
А что именно печально? Печально было бы если государство ничего не делало.
Спасибо за рассказ. Удивительно, насколько вы логично и правильно рассуждаете. И насколько грамотно рассказываете о тонких и скользких моментах.
Я давно не читал настолько продуманную расшифровку от женского лица. Это супер.
Мы подавали на Старт-1 Fasie в этом году проект с инновационной идеей.
Грант не получили и общение с "экспертами" оставило негативное впечатление.
Каждый вопрос был в таком духе: мы уже знаем, что ваш проект не будет поддержан, а теперь скажите нам, почему он не будет поддержан. Так же понравилась экспертная мысль: "у вас тут есть прототип, а чего вы продукт то не сделали еще. Вот сделайте продукт и приходите тогда". Cцена из театра абсурда.
В целом осталось впечатление, что эта структура себя изжила. Никакие инновации "со стороны" они не поддерживают, там уже все распределено. У них там у всех всё хорошо.
То, что фактор своей подачи - сильный, очевидно для всех, кто играет в бадминтон. Картина игры на своей подаче и по подаче соперника совершенно разные. Когда будет больше данных, эту гипотезу можно отдельно проверить, конечно.
Нет, не пробовал. Прикольно, что оно само что-то меряет. Но замерять оно может только частоту ударов и, возможно, силу удара и положение ракетки.
Да, верно, пользователь должен фиксировать каждый удар, чтобы собрать данные.
Тренер может сказать свое субъективное мнение. Отследить компоненты игры у каждого игрока тренер не в состоянии, так как зачастую у него много спортсменов. И тем более он не может оценить прогресс или регресс в компонентах игры по времени.
Гораздо быстрее и понятнее написать JSON примеры, а из них уже сгенерировать схему.
Причем, если добавить еще какой-нибудь «side-car язызок» к примерам, то генерировать схему из примеров можно 1 к 1, скорей всего (тем более, если допустить, что примеров для генерации схемы может быть несколько).
Что вы об этом думаете? Не знаете ли тулзов, которые это умеют?
С проблемой формулировки модели данных, для которой JSON подходит обычно идеально, встречаются 100% разработчиков. Поэтому и подобного рода тулза была бы крайне востребована.
Где почитать концентрированную инфу о Node.js (без воды), чтобы там были ответы на эти вопросы?
SLI — это метрики, которые меряют пользовательский опыт.
SLO — это числовые границы SLI метрик, внутри которых значение SLI принимается как ОК.
SLA — это время, в котором SLI метрики находились в SLO диапазоне. Т.е. SLA — это итоговая производная метрика из SLI метрик, пересчитанная на время.
У нас была проблема как раз с тем, что через HTTP ходит нормально, а вот через HTTPS — нет (были настроены два server_name, скажем a_server_name и b_server_name и если первый запрос приходит к a_server_name, то все остальные запросы и к a_server_name и к b_server_name идут все равно через a_server_name).
Из того, что в Kubernetes есть StatefulSet следует, что Kubernetes можно использовать для задач, для которых нужен StatefulSet.
>Вы можете использовать данную инструкцию для любых целей, всё ограничивается лишь вашей фантазией)…
Пока только понятно, что нужно было поднять Kafka и Jmeter, так как, догадываюсь, Jmeter принимает данные из Kafka.
Стенд для такой связки можно было вначале собрать в minikube.
Зачем нужны Flannel, Kafka Connect, MirrorMaker 2.0, Apache Zookeeper, а также «production» и «backup» среды не понятно.
Но, спасибо за скрипты.
>Обращаю внимание на то, что установка stateful в контейнерах — далеко не лучшая идея, поэтому данная инструкция не предназначена для развертывания промышленного стенда.
Не совсем понятно. Использовать StatefulSet для перечисляемых имен подов вполне нормальная практика (это написано в документации).
>Почему Docker, а не CRI-O? Мне интересен CRI-O и я планирую изучить его в будущем
И почему тогда Docker? ;)
Типа хотим подружить физические разные ноды, которые были под рукой?
Физические сетевые карты чем-то принципиально отличаются от виртуальных?
Как только модель данных полностью сформулирована и пазл сошелся, ничто не мешает в Clojure коде перейти на static typing.
По нашему опыту, задачи на Clojure решаются в 2-3 раза быстрее, чем на Java (без потери качества).
Субъективно, года 2 назад был бум Clojure, но сейчас этот бум почему-то стих. Нет ли у вас такого ощущения? И если есть, то какие вы бы могли назвать причины этого?
Результат предсказания по этой модели известен заранее, до проведения какого-либо моделирования (вы получите ровно то, что вы задавали в самом начале).
Причем тут идеи об эффективном рынке и как они связаны с представленной моделью пока тоже не понятно.
Контекстный подход успешно решает:
1) проблему декомпозиции кода (когда код метода не влезает в один экран);
2) упрощает тестирование и, как результат, ускоряет разработку;
3) предлагает альтернативный вариант к гибкой реализации retry фичи, когда можно делать retry не всей операции полностью, а только тех шагов, которые нужны.
А, и да, самое главное:
Disclaimer: этот метод не улучшает качество кода криворукого разработчика, а наоборот ухудшает его экспоненциально :).
2) по центральной предельной теореме, для выборки из одного любого распределения с конечной дисперсией — среднее значение, при большом размере выборки, будет нормальной случайной величиной
3) по закону больших чисел, теореме Чебышева, для выборки из любого количества разных распределений с конечными матожиданиями и дисперсиями и дополнительным условием на сходимость дисперсий — среднее значение, при большом размере выборки, будет нормальной случайной величиной