Ровно это я и говорю, что данные не нужно запрашивать. Их нужно отправлять. Если вы запрашиваете, значит данными не владеете. А владеет соседний компонент. Значит нагрузка растёт, потому что в большинстве случаев вы это будете делать регулярно, чего нельзя сказать об отправке
Только от сервиса А к сервису Б у вас будет регулярный запрос, потому что в одном из них нет данных. Во втором случае такого не происходит, если данные заранее передаются. Хотя, конечно, можно спроектировать всякое
Я не говорил про системы, которые не хранят данные. Я сказал только про то, что это не сервис в понимании, которое имеет ввиду большинство людей и один из популярных авторов.
Я также подразумевал, что такая конфигурация будет выдавать меньший lead time, чем могло бы быть в иных случаях. При этом, вероятно, будет иметь другие параметры. Про конкретную задачу сложно сказать. Вероятно, она будет оптимизировать пару нагрузка-деньги.
В первом случае почти со 100% вероятностью у вас не микросервис. Почему я это предполагаю. Если сервис обращается за данными, то значит они ему зачем-то нужны и он хочет ими воспользоваться. Возникает вопрос, почему он их не хранит внутри себя. В силу наличия синхронной связи, он "сильно" связан с соседом. То есть он не может существовать без этих данных
Таким образом, основываясь на идее о том, что микросервисы -- это слабосвязанные объекты, можем заключить, что эти объекты не являются микросервисами, в том смысле, как это понимает, например Chris Richardson тут:
Относительно двух других примеров, в явном виде не следует, что это не микросервисы. Без примера бизнес-задачи сказать этого невозможно. Но рассуждениями можно прийти к выводу, что в широком спектре бизнесов такие компоненты не будут микросервисами
На самом деле, мои кейсы-таки, довольно сложны. Выше и ниже есть толковые идеи, которые проще реализовать. А значит, они потенциально перспективнее (чем быстрее докатится до прода, тем быстрее будет понятна живучесть идеи).
Буду банальным и предложу сервис по "Доставке пиццы на летающих тарелках", пока ещё никто не предложил (=.
А если по-чесноку, то кажется, что есть несколько кейсов, которые могут оказаться востребоваными и принести дополнительные у.е. порталу. Предложения
Я несколько раз задавался вопросом, почему на хабре нельзя выполнить код? Рили, это же it-тусовка, детка… и нельзя. Есть ряд вопросов, почему это может быть проблемно. Например, дорого. Да… Но..., постойте. Есть же lambda-functions от Яндекса. Эти легковесные ребзя очень кстати (https://cloud.yandex.ru/docs/functions/concepts/function). Вообще, там ограничения 10 шт на тачку. Но я думаю, что Господа из Я с радостью пойдут на встречу и можно будет решить этот вопрос. Если посмотреть на ценник, то он реально смешной. 10000000 вызовов за 3900. 3900, Карл… Даже если умножить на 10, то оказывается не слишком много. https://cloud.yandex.ru/docs/functions/pricing. Окай, другим вариантом решения может быть AWS, но деплой у них отвратительный. А что насчёт mail.ru? Я думаю, этот вопрос решаем. На худой конец, если всё очень не очень, то можно обратиться в сторону компиляторов прямо в браузере. С нодой, думаю вопрос не стоит. python? Да, тоже, думаю, не вопрос (https://pythontips.com/2019/05/22/running-python-in-the-browser/). Собственно… как и ряд других языков.
В последнее время очень активно развивается DS, но на хабре ничего нет для того, чтобы удобно импортировать очень популярный нынче инструмент jupyter-notebook (возможно, я ошибаюсь и он есть). Кажется, что очень много потенциально крутых исследований так и не становятся крутыми, потому что разрыв между тем, что перенести их из юпитера в markdown — это рили нетривиально и нужно очень большое желание, чтобы это стало реальностью (например, даже у меня есть кое-какие исследования (не очень крутые), которые можно было бы опубликовать, но мне не охота с этим заморачиваться, потому как я не сделал никакого челледжа). Например, ребята из ODS проводят большую работу по подготовке статей. Здесь можно пообщаться с Алексеем Натёкиным и спросить (а лучше с mephestopheies), какие именно фичи нужны. Можно тупо jupyterhub сделать для песочницы вместе с отдельным списком постов с крутыми ноутбуками.
К сожалению, очевидно, если дать возможность всем подряд постить ноутбуки, то начнётся хаос. Поэтому нужна отдельная песочница (или не отдельная), в которой ноутбуки будут проходить валидацию.
Что ещё… очень много людей говорят про образование онлайн, про курсы. Но на мой взгляд курсов очень много рили глупых, которые дают какие-то оторванные от жизни навыки. А делать ещё одну типовую онлайн-платформу… А надо ли? В связи с этим, можно их дробить на несколько видов и решать конкретные боли людей.
Для студентов. Эти курсы закрывают gap между тем, что дают в универах и тем, что есть в жизни. Отсюда вытекает очень важная идея, которая постепенно начинает появляться во всём мире: интернет и всё виртуальное — это замечательно, но мы, люди, реальные, нам нужны физические вещи. Возможно, имеет смысл подумать о том, чтобы интегрироваться с универами и преподавать студентам в универах, в живую. Часто людям очень важно именно реальное общение. Тем более студентам. Цель всего этого: закрывать gap с поправкой на реальную жизнь.
Для школьников. Многие дети хотят поступить в универ. Но они не могут конкурировать с детьми из Москвы, потому что здесь качество образования, априори, выше. Хороший вариант — олимпиады универов. Кейс: курсы по подготовке школьников к олипиадам. Это несложно и доступно огромному количеству детей. Многие об этом просто не знают и из-за этого их жизнь часто даже не складывается.
Для репетиторов. У многих репетиторов нет возможности взять больше учеников. Физически время не хватает. А хотелось бы. Может быть им стоит в этом помочь? Давайте попробуем давать возможность преподам рассказывать на 2-3 человека. В таком случае цена уменьшится для учеников (т.е. это станет более доступно). И, конечно, преподы смогут больше зарабатывать. Только не нужно это делать грабительски, как делает foxford. Можно брать небольшой процент и жить за счёт рекламы, например.
...
Все три этих идеи, как можно заметить, очень близки друг к другу и дополняют друг друга. Для онлайн-образования важно иметь под рукой инструмены для качественного обучения. Первые два кейса их обеспечат. Кроме того, как легко увидеть, первые два кейса тесто связаны друг с другом и в пределе, вероятно, интегрируются друг в друга.
Что касается технической реализации, то мне кажется, что это не челленджи. Это обычные технические задачи, которые просто тупо нужно сделать. Они тупые как топоры, здесь нет много рисерча и примерно понятен профит. Многие из тех, кто прокомментил (прокомментит), наверняка, примерно понимают, как реализовать это и как это должно выглядеть. Всё как обычно: прорисуем архитектуру (несколько сервисов бэка), пару виртуалок, тесты, прикрутим авторизацию, мониториг, ELK и т.д. Хотел бы написать, что всё тривиально. Конечно, нет. Это хорошая задача.
Один препод мне сказал однажды примерно следующее. "В математике иногда говорят так: это элементарно, а иногда — это очевидно. В чём отличие, спросите Вы? Элементарно — это когда нужно сделать 1-2 действия, но до них ты будешь доходить, ох, как долго. Очевидно — это иное. Можно сделать 10-20 действий, но, в целом, понятно, какие они и если сесть и всё аккуратно расписать на листочке, то времени много не уйдёт и ты получишь ответ." Так вот эти задачи очевидные.
P.s. Да, к сожалению, это не совсем отдельные сервисы в кухонном комбайне "Хабр". Хотя, песочница для юпитер-ноутбуков выглядит таковой. Ещё одна ипостась истории про образование — тоже. Разве что кейс про выполнение кода в браузере стоит атоллом. Кажется, я тоже могу попробовать поучаствовать в конкурсе. Попробую.
Предположим, что 1 gpu стоит 10000 рублей в месяц (неправда). Глядя на Я и другие облачные сервисы — это 100 000 в месяц. Окей, 167 000 камер:
10000 * 167000 = 1 670 000 000 тыр
Даже если предположить, что на 1 нейронка работает на 10 камер, что возможно, но маловероятно (дополнительное оправдание денежного перехода 100 000 тыр -> 10 000 тыр), то получается 1.5 лярда, карл. Я не верю, что такую сумму тратит Москва на такую систему. Вот честно. А потому, данный пост и данная система с большой вероятностью — профанация.
Не удивлюсь, если, в реальности, они работают в трёх местах в час пик и не рилтайм, а офллайн, по ночам.
Основная идея довольно проста. Возьмём число x от 0 до 1. Будем постепенно заменять x на a x (1 – x). Допустим, мы начнём с x = 1/3, и a =3,2. Тогда вот какие последовательные значения x мы будем получать:
Ваш алгоритм аппроксимации — это фактически дерево решений. Только с модификацией. В вашем случае в каждом узле вы строите регрессию по ax+b. А в классике — выбирается просто b
Второй момент. У вас функция энергии (та, что для разделения вершины на 2 новых листа используется) похитрее. Но суть остаётся та же. Вообще говоря, функция вычисления приращения энергии, как правило мало на что влияет. Как правило, много более важно задать критерий останова
Начал смотреть ваши ноутбуки. Да, все, замечательно, много примеров, с графтками, с примерами кода, по-феншую.
Но… Честно… Расстроен. Вы не приводите решение не одной задачи. Как мне, человеку, который с дпф занимался примерно нисколько, начать все это добро юзать? Вот, например, есть задача про эпилептиков. Нужно дать предикт заблаговременно: будет припадок или нет. Как это добро мне поможет решить ее? Для меня оказывается куда проще нагенерить фичей и пихнуть это в бустинг, чем городить огород из преобразований, хаотично из применяя
Ровно это я и говорю, что данные не нужно запрашивать. Их нужно отправлять. Если вы запрашиваете, значит данными не владеете. А владеет соседний компонент. Значит нагрузка растёт, потому что в большинстве случаев вы это будете делать регулярно, чего нельзя сказать об отправке
Только от сервиса А к сервису Б у вас будет регулярный запрос, потому что в одном из них нет данных. Во втором случае такого не происходит, если данные заранее передаются. Хотя, конечно, можно спроектировать всякое
Скорее всего автор имел ввиду, что при синхронном взаимодействии происходит в среднем рост нагрузки на инфраструктуру
Синхронный подход ничем не плох. Важно понимать, чего вы хотите им добиться. Может, например, стоит объединить два компонента в один?
Я не говорил про системы, которые не хранят данные. Я сказал только про то, что это не сервис в понимании, которое имеет ввиду большинство людей и один из популярных авторов.
Я также подразумевал, что такая конфигурация будет выдавать меньший lead time, чем могло бы быть в иных случаях. При этом, вероятно, будет иметь другие параметры. Про конкретную задачу сложно сказать. Вероятно, она будет оптимизировать пару нагрузка-деньги.
Побуду токсичным
В первом случае почти со 100% вероятностью у вас не микросервис. Почему я это предполагаю. Если сервис обращается за данными, то значит они ему зачем-то нужны и он хочет ими воспользоваться. Возникает вопрос, почему он их не хранит внутри себя. В силу наличия синхронной связи, он "сильно" связан с соседом. То есть он не может существовать без этих данных
Таким образом, основываясь на идее о том, что микросервисы -- это слабосвязанные объекты, можем заключить, что эти объекты не являются микросервисами, в том смысле, как это понимает, например Chris Richardson тут:
https://microservices.io/patterns/decomposition/decompose-by-business-capability.html
и
https://microservices.io/patterns/decomposition/decompose-by-subdomain.html
Относительно двух других примеров, в явном виде не следует, что это не микросервисы. Без примера бизнес-задачи сказать этого невозможно. Но рассуждениями можно прийти к выводу, что в широком спектре бизнесов такие компоненты не будут микросервисами
Подскажите, в чём суть /a * b = 0? Почему так? Я легко это опровергну:
a /a b = -1
a /a b = -1 b
a 0 = -1 b
0 = -1 b
что, конечно же, неправда.
Привет. Как с Вами связаться?
На самом деле, мои кейсы-таки, довольно сложны. Выше и ниже есть толковые идеи, которые проще реализовать. А значит, они потенциально перспективнее (чем быстрее докатится до прода, тем быстрее будет понятна живучесть идеи).
Буду банальным и предложу сервис по "Доставке пиццы на летающих тарелках", пока ещё никто не предложил (=.
А если по-чесноку, то кажется, что есть несколько кейсов, которые могут оказаться востребоваными и принести дополнительные у.е. порталу.
Предложения
К сожалению, очевидно, если дать возможность всем подряд постить ноутбуки, то начнётся хаос. Поэтому нужна отдельная песочница (или не отдельная), в которой ноутбуки будут проходить валидацию.
Все три этих идеи, как можно заметить, очень близки друг к другу и дополняют друг друга. Для онлайн-образования важно иметь под рукой инструмены для качественного обучения. Первые два кейса их обеспечат. Кроме того, как легко увидеть, первые два кейса тесто связаны друг с другом и в пределе, вероятно, интегрируются друг в друга.
Что касается технической реализации, то мне кажется, что это не челленджи. Это обычные технические задачи, которые просто тупо нужно сделать. Они тупые как топоры, здесь нет много рисерча и примерно понятен профит. Многие из тех, кто прокомментил (прокомментит), наверняка, примерно понимают, как реализовать это и как это должно выглядеть. Всё как обычно: прорисуем архитектуру (несколько сервисов бэка), пару виртуалок, тесты, прикрутим авторизацию, мониториг, ELK и т.д. Хотел бы написать, что всё тривиально. Конечно, нет. Это хорошая задача.
Один препод мне сказал однажды примерно следующее. "В математике иногда говорят так: это элементарно, а иногда — это очевидно. В чём отличие, спросите Вы? Элементарно — это когда нужно сделать 1-2 действия, но до них ты будешь доходить, ох, как долго. Очевидно — это иное. Можно сделать 10-20 действий, но, в целом, понятно, какие они и если сесть и всё аккуратно расписать на листочке, то времени много не уйдёт и ты получишь ответ." Так вот эти задачи очевидные.
P.s. Да, к сожалению, это не совсем отдельные сервисы в кухонном комбайне "Хабр". Хотя, песочница для юпитер-ноутбуков выглядит таковой. Ещё одна ипостась истории про образование — тоже. Разве что кейс про выполнение кода в браузере стоит атоллом. Кажется, я тоже могу попробовать поучаствовать в конкурсе. Попробую.
1-2 кадра в секунду — это не рилтайм.
Подбор кандидатов для заданного лица задача решенная, но не самая легковесная
А вы посчитайте, сколько стоит в месяц рилтайма мейловые ГПУ теслы
Немного холодного рассчёта.
Предположим, что 1 gpu стоит 10000 рублей в месяц (неправда). Глядя на Я и другие облачные сервисы — это 100 000 в месяц. Окей, 167 000 камер:
10000 * 167000 = 1 670 000 000 тыр
Даже если предположить, что на 1 нейронка работает на 10 камер, что возможно, но маловероятно (дополнительное оправдание денежного перехода 100 000 тыр -> 10 000 тыр), то получается 1.5 лярда, карл. Я не верю, что такую сумму тратит Москва на такую систему. Вот честно. А потому, данный пост и данная система с большой вероятностью — профанация.
Не удивлюсь, если, в реальности, они работают в трёх местах в час пик и не рилтайм, а офллайн, по ночам.
Как происходит замена? x1 = a* x0 (1-x0)?
Ваш алгоритм аппроксимации — это фактически дерево решений. Только с модификацией. В вашем случае в каждом узле вы строите регрессию по ax+b. А в классике — выбирается просто b
Второй момент. У вас функция энергии (та, что для разделения вершины на 2 новых листа используется) похитрее. Но суть остаётся та же. Вообще говоря, функция вычисления приращения энергии, как правило мало на что влияет. Как правило, много более важно задать критерий останова
Начал смотреть ваши ноутбуки. Да, все, замечательно, много примеров, с графтками, с примерами кода, по-феншую.
Но… Честно… Расстроен. Вы не приводите решение не одной задачи. Как мне, человеку, который с дпф занимался примерно нисколько, начать все это добро юзать? Вот, например, есть задача про эпилептиков. Нужно дать предикт заблаговременно: будет припадок или нет. Как это добро мне поможет решить ее? Для меня оказывается куда проще нагенерить фичей и пихнуть это в бустинг, чем городить огород из преобразований, хаотично из применяя
Одно я знаю точно. Самый правый парень на фотке хакатон не выиграл...
Мне понравилось, как Вы написали слово "никогда". С такой экспрессией: "НИ КОГДА". Пять баллов.
Тема порно не достаточно раскрыта. Думаю, что автору тоже можно найти себе девушку
Странно, что ничего не упомянули про невозможный двигатель. Кстати, кто-нибудь в курсе чем эта история закончилась?