К сожалению, на полную обзорную статью по всем методам я не готов. А те методы, которые используем мы - некоторым образом попадают под NDA :)
Из общеизвестных аналитических - это в первую очередь разные вариации SVM. Мне кажется, я не ошибусь, если предположу, что и очень многие проприетарные алгоритмы - SVM-Based, только с разным подбором критериев и оценок.
Кластеризация а ля k-means тоже используется, но больше на этапе анализа данных, как вспомогательный инструмент, насколько я могу судить.
Кроме того, крупные компании, типа GE, очень плотно используют экспертное знание и строят предиктивные модели чуть ли не по конкретным маркам агрегатов, после чего их и продают.
Кстати, статью Жеглова прочитал, и в целом вижу, что он так же, как и я, склоняется ныне (в 2019 году :) ) к мнению, что Вейбул - это вещь, которую можно притянуть к ситуации к задачами в неких идеализациях, типа описанной мной ниже, но предсказательной силы от этого знания мало.
А надо идти глубже, в процесс :) По удивительному совпадению - мои тезисы сходны с его.
Да, семейство распределений, обобщаемых через гамма-распределение. Сюда могут (в зависимости от того, какой смысл мы вкладываем в параметры и какую ситуацию рассматриваем) подходить и экспоненциальное, и Эрланг, и Вейбул.
Отвечая сразу на следующий комментарий - Вейбул параметрически подойдёт, если мы моделируем некую итерацию, где принимаем среднюю интенсивность задач изменяющейся в окрестностях константы в меньшую сторону, и рассматриваем распределение времени выполнения в смысле "от начала итерации до завершения задачи". Это имеет смысл, т.к. в начале задачи завершаются реже, а под конец - быстрее. К сожалению, предсказательная сила применения такого распределения мне кажется сомнительной.
Экспоненциальное - это реальная трудоёмкость задач одинаковой сложности, Эрланг - распределение трудоёмкости многоэтапных задач (поделённых между разными исполнителями).
У меня есть ряд дополнительных соображений, в том числе и с некоторой критикой, которую я собираюсь оформить в отдельную статью. Так что по выходу приглашаю к полемике :) .
Не могу не задать вопросы, касающиеся распределений.
а) Как можно интерпретировать "распределения Вейбула является логарифмическим"? Семейство Вейбула является частным случаем гамма-распределения (в определенном смысле, с точностью до замены). Логарифмическое распределение - это принципиально другой вид распределения.
б) Почему представленное распределение является именно Вейбулом? Вейбул - это непрерывное распределение, а количество задач строго дискретно.
Почему не дискретное распределение Пуассона (которое как раз описывает количество событий, происходящих с заданной интенсивностью, за единицу времени)?
Для определения типа распределения аргументации "похож график" недостаточно, потому что похожесть можно увидеть любую. Требуется использование критерия.
в) Подбор распределения для величин, зависимых друг от друга (чем, предположительно, являются выполняемые задачи) - задача, которую надо решать очень аккуратно.
В реальной жизни у этого класса будет хотя бы один метод, что не даст подставить пустой объект.
Более того, даже и не пустой объект с полем foo можно туда положить - и он всё равно будет не ClassFoo. Потому instanceof проверяет именно JS-ный прототип, что крайне странно для TS, с моей точки зрения, но, тем не менее, является визуальным противоречием.
Странно потому, что зачем нам проверять тип класса, если надо важно его содержимое, относительно которого прекрасно проходят все проверки.
Преступник в вакууме одинаково угрожает как ребёнку, так и старушке. Если мы оцениваем среднюю безопасность всех жителей - то 1 преступник на 100 жителей причинит конкретному жителю в среднем больше ущерба за год, чем 1 на 1 000 000.
Если мы оцениваем склонность жителей к сознательным криминальным поступкам то, конечно, несознательных априори мы должны исключить.
Для "плановой экономики" как раз статистика и первостепенна. На основе неё строится и проверяется корректность выполнения плана.
А так статистику хоть с планом, хоть без плана можно дорисовывать и доинтерпретировать. Любой мэр даже без плана с большей радостью заявит о "трёхкратном падении преступности".
Если мы оцениваем безопасность в целом - то, конечно, надо брать всё население, от мала до велика. Т.е. соотношение бандитов к количеству потенциальных жертв.
Если оцениваем среднюю уголовную наклонность сознательных дееспособных граждан - конечно, надо брать другое количество.
Как техническое средство, естественно, кафка для синхронного взаимодействия подходит не так хорошо, как непосредственный сетевой вызов. Поэтому, "некостыльно" - наверное, не могу.
Но тем не менее, как раз при "архитектурных" решениях типа "везде делаем кафку" эти костыли, при логической необходимости синхронного взаимодействия, будут возникать.
Непосредственно отвечая на вопрос - самый банальный вариант отправлять сообщение и входить бесконечный цикл, ожидая некоего ответного сообщения, прежде, чем возобновить поток управления.
Restful, в отличие от сокетов, не техническая, а логическая концепция. И когда мы размышляем, как будем воплощать ту или иную прикладную область в реализацию - естественно, мы начинаем с модели взаимодействия данных. И дальше на основании этой модели внедряем подходящие технологии.
Это не самоцель, это выбор, на основании которого надо принимать дальнейшие решения.
Как написали ниже - конечно, без всяких протофайлов можно сериализовывать, не сложнее, чем обычный json, те же атрибуты.
Чтобы использовать RESTful стиль взаимодействия с преимуществами малого объёма передаваемых данных.
Упоминать надо, поскольку на моей практике часто люди, вместо того, чтобы точечно решить проблемы с этим объёмом, начинают переделывать вообще всё на grpc.
Преимущества и недостатки gRPC изначально связаны с парадигмой взаимодействия.
Если предполагается restful взаимодействие с понятной предметной областью - то классический Rest однозначно лучше. В его соглашениях все взаимодействия описаны, и есть много средств, успешно их использующих.
А если требуется RPC в произвольной форме - тогда, конечно, grpc на данный момент в общем случае самый логичный первый выбор.
P.S. Очень жаль, что не рассказали о том, что протобаф доступен без всякого grpc и протофайлов как форматтер в "обычном" рест-взаимодействии. Может сложиться впечатление, что для решения всех описанных проблем обязательно тянуть весь grpc.
Я бы поспорил, что объяснительная часть важнее. Какой интерес просто так объяснять (т.е. придумывать некое явно не наблюдаемое обоснование) тому, что уже произошло в непосредственном наблюдении.
Как раз интерес в предсказании новых непосредственно ощущаемых фактов, для которых объяснение есть всего лишь проверка корректности теории.
Я бы сформировал вокруг человека соответствующее командное отношение. Т.е. дал бы понять команде, что перед нами негативный пример (с точки зрения моего видения команды как её руководителя), самому товарищу, естественно, так же — что в нашей команде подобный подход является недопустимым (при этом дав понять, что всё поправимо). Есть много способов сделать вышеозначенное — от стиля общения до материальных поощрений.
Далее бы уже решала личная мотивация сотрудника. Если уволится — значит, уволится. Если качество провалится ниже — значит сами уволим. Исправится или впишется в некий другой круг обязанностей, где его сильные качества проявятся лучше — замечательно.
Там много всего произошло, и начинать надо, по мнению некоторых историков, не с ВОСР (которая готовилась большой группой товарищей, как раз проводивших внутри себя демократические процедуры), а 1905-го, если не с отмены крепостного права. Группа большевиков подхватила и направила революционный процесс в нужное (им) русло, а не сформировала его.
У Пучкова на канале интересный курс лекций Яковлева о предпосылках и ходе революции и ГВ. Рекомендую.
К сожалению, на полную обзорную статью по всем методам я не готов. А те методы, которые используем мы - некоторым образом попадают под NDA :)
Из общеизвестных аналитических - это в первую очередь разные вариации SVM. Мне кажется, я не ошибусь, если предположу, что и очень многие проприетарные алгоритмы - SVM-Based, только с разным подбором критериев и оценок.
Кластеризация а ля k-means тоже используется, но больше на этапе анализа данных, как вспомогательный инструмент, насколько я могу судить.
Кроме того, крупные компании, типа GE, очень плотно используют экспертное знание и строят предиктивные модели чуть ли не по конкретным маркам агрегатов, после чего их и продают.
Как-то так.
Кстати, статью Жеглова прочитал, и в целом вижу, что он так же, как и я, склоняется ныне (в 2019 году :) ) к мнению, что Вейбул - это вещь, которую можно притянуть к ситуации к задачами в неких идеализациях, типа описанной мной ниже, но предсказательной силы от этого знания мало.
А надо идти глубже, в процесс :) По удивительному совпадению - мои тезисы сходны с его.
Да, семейство распределений, обобщаемых через гамма-распределение. Сюда могут (в зависимости от того, какой смысл мы вкладываем в параметры и какую ситуацию рассматриваем) подходить и экспоненциальное, и Эрланг, и Вейбул.
Отвечая сразу на следующий комментарий - Вейбул параметрически подойдёт, если мы моделируем некую итерацию, где принимаем среднюю интенсивность задач изменяющейся в окрестностях константы в меньшую сторону, и рассматриваем распределение времени выполнения в смысле "от начала итерации до завершения задачи". Это имеет смысл, т.к. в начале задачи завершаются реже, а под конец - быстрее. К сожалению, предсказательная сила применения такого распределения мне кажется сомнительной.
Экспоненциальное - это реальная трудоёмкость задач одинаковой сложности, Эрланг - распределение трудоёмкости многоэтапных задач (поделённых между разными исполнителями).
У меня есть ряд дополнительных соображений, в том числе и с некоторой критикой, которую я собираюсь оформить в отдельную статью. Так что по выходу приглашаю к полемике :) .
Не могу не задать вопросы, касающиеся распределений.
а) Как можно интерпретировать "распределения Вейбула является логарифмическим"? Семейство Вейбула является частным случаем гамма-распределения (в определенном смысле, с точностью до замены). Логарифмическое распределение - это принципиально другой вид распределения.
б) Почему представленное распределение является именно Вейбулом? Вейбул - это непрерывное распределение, а количество задач строго дискретно.
Почему не дискретное распределение Пуассона (которое как раз описывает количество событий, происходящих с заданной интенсивностью, за единицу времени)?
Для определения типа распределения аргументации "похож график" недостаточно, потому что похожесть можно увидеть любую. Требуется использование критерия.
в) Подбор распределения для величин, зависимых друг от друга (чем, предположительно, являются выполняемые задачи) - задача, которую надо решать очень аккуратно.
Более того, даже и не пустой объект с полем foo можно туда положить - и он всё равно будет не ClassFoo. Потому instanceof проверяет именно JS-ный прототип, что крайне странно для TS, с моей точки зрения, но, тем не менее, является визуальным противоречием.
Странно потому, что зачем нам проверять тип класса, если надо важно его содержимое, относительно которого прекрасно проходят все проверки.
И в России тренд, кстати, на увеличение продолжительности.
Повторю - смотря что сравнивать.
Преступник в вакууме одинаково угрожает как ребёнку, так и старушке. Если мы оцениваем среднюю безопасность всех жителей - то 1 преступник на 100 жителей причинит конкретному жителю в среднем больше ущерба за год, чем 1 на 1 000 000.
Если мы оцениваем склонность жителей к сознательным криминальным поступкам то, конечно, несознательных априори мы должны исключить.
Скорее всего, называет для краткости HTTP без дополнительных прикладных протоколов сверху просто REST-ом.
Для "плановой экономики" как раз статистика и первостепенна. На основе неё строится и проверяется корректность выполнения плана.
А так статистику хоть с планом, хоть без плана можно дорисовывать и доинтерпретировать. Любой мэр даже без плана с большей радостью заявит о "трёхкратном падении преступности".
Для разных миллионов - разные цели.
Если мы оцениваем безопасность в целом - то, конечно, надо брать всё население, от мала до велика. Т.е. соотношение бандитов к количеству потенциальных жертв.
Если оцениваем среднюю уголовную наклонность сознательных дееспособных граждан - конечно, надо брать другое количество.
Половой шантаж у нас тоже присутствует, особенно в отношении малолетних. И "сексуальные домогательства" - это не изнасилование.
Как техническое средство, естественно, кафка для синхронного взаимодействия подходит не так хорошо, как непосредственный сетевой вызов. Поэтому, "некостыльно" - наверное, не могу.
Но тем не менее, как раз при "архитектурных" решениях типа "везде делаем кафку" эти костыли, при логической необходимости синхронного взаимодействия, будут возникать.
Непосредственно отвечая на вопрос - самый банальный вариант отправлять сообщение и входить бесконечный цикл, ожидая некоего ответного сообщения, прежде, чем возобновить поток управления.
Restful, в отличие от сокетов, не техническая, а логическая концепция. И когда мы размышляем, как будем воплощать ту или иную прикладную область в реализацию - естественно, мы начинаем с модели взаимодействия данных. И дальше на основании этой модели внедряем подходящие технологии.
Это не самоцель, это выбор, на основании которого надо принимать дальнейшие решения.
Как написали ниже - конечно, без всяких протофайлов можно сериализовывать, не сложнее, чем обычный json, те же атрибуты.
Чтобы использовать RESTful стиль взаимодействия с преимуществами малого объёма передаваемых данных.
Упоминать надо, поскольку на моей практике часто люди, вместо того, чтобы точечно решить проблемы с этим объёмом, начинают переделывать вообще всё на grpc.
Синхронность и асинхронность мало общего имеют с очередями и интернет-протоколами. Они связаны с особенностями потока управления.
Кафка вполне может использоваться для синхронного взаимодействия. Grpc - для асинхронного.
Их корректно сравнивать как средство доставки сообщений, например.
Преимущества и недостатки gRPC изначально связаны с парадигмой взаимодействия.
Если предполагается restful взаимодействие с понятной предметной областью - то классический Rest однозначно лучше. В его соглашениях все взаимодействия описаны, и есть много средств, успешно их использующих.
А если требуется RPC в произвольной форме - тогда, конечно, grpc на данный момент в общем случае самый логичный первый выбор.
P.S. Очень жаль, что не рассказали о том, что протобаф доступен без всякого grpc и протофайлов как форматтер в "обычном" рест-взаимодействии. Может сложиться впечатление, что для решения всех описанных проблем обязательно тянуть весь grpc.
Я бы поспорил, что объяснительная часть важнее. Какой интерес просто так объяснять (т.е. придумывать некое явно не наблюдаемое обоснование) тому, что уже произошло в непосредственном наблюдении.
Как раз интерес в предсказании новых непосредственно ощущаемых фактов, для которых объяснение есть всего лишь проверка корректности теории.
Далее бы уже решала личная мотивация сотрудника. Если уволится — значит, уволится. Если качество провалится ниже — значит сами уволим. Исправится или впишется в некий другой круг обязанностей, где его сильные качества проявятся лучше — замечательно.
У Пучкова на канале интересный курс лекций Яковлева о предпосылках и ходе революции и ГВ. Рекомендую.