Ох… А вы точно "банк"? Где же все эти традиционные soa и esb? Выглядит так что вы переизбрали их, только менее надёжные (очередь вместо шины и нет распределенных транзакций)
Расскажите, как у вас решается ситуация, когда "простое масштабирование" приводит к тому, что порядок транзакций в базе может произвольно не соответствовать порядку в очереди. Особенно в ситуации, когда бизнесовые правила успешности следующих зависят от предыдущих.
Так же вызывает вопросы надёжность вашего решения вот в каком кейсе: вы прочли сообщение из очереди, выполнили бизнессстранзакцию, сделали коммит в базе, и тут ваш процесс упал или случился сетеовой сбой и кафке вы не смогли сообщить об успешной обработке. Как система отработает?
В этом «феномене» важно не смешивать всё в одну кучу.
1)Когда работа сулит большой куш всем в случае успеха — тянуть лямку это нормально.
2)Когда достижение общей цели каким-то образом приведет тебя к достижению твоих внутренних целей — это тоже нормально радоваться погожему понедельнику
3)Когда ты находишься в конкурентном обществе где:
а)Уволить тебя могут совершенно законно по щелчку пальца (особенно если ты белый гетеросексуальный мужчина)
б)(хорошо)оплачиваемой работы катастрофически мало (см медиану)
в)при устройстве практически на любую следующую у тебя спросят и проверят рекомендации с прошлых мест
г)денег «вобрез» (погашение кредита за обучение, ипотека, пенсионные накопления, мед.услуги, дет.сады-школы) и каждая свободная сотня на счету.
В такой ситуации — будешь пахать (делать вид) как все и одобрительно встречать любую возможность по-овертаймить, в особенности если оплачиваемо.
Ну и в целом — все эти истории, что мы видим в фильмах, когда группа юристов какой-то компании проводит ночи, работая над «делом» клиента и изучая прецеденты — важно помнить что все эти часы отправятся в личный табель, а потом еще будут включены в счёт клиенту.
Странно, что в рассуждениях о "аудитория неоднородна, поэтому а/б не работает" не нашлось места упоменнанию о сегментации и а/а тестах, как подготовке к а/б что и решает/уменьшает масштаб обозначенной проблемы.
Приходилось решать похожую задачу. Ничего готового для русского языка не нашли (пришлось на котлине делать свой dsl для граматик + парсер текста).
Если вам известны решения для русского языка на jvm — поделитесь многим будет полезно
Это немного забавно, что когда-то «давно» (2011-12-13 годы) новообращенные разработчики часто любили «противопоставлять» «новые» «быстрые» языки и технологии разработки «старому» «медленному» «кровавому» энтерпрайзу.
Прошло время и народ с восторгом открывал для себя «паттерны»,«автоматическое тестирование» разного масштаба, «шины/очереди», «DI/IOC», SOA (хотя сейчас примерно тоже самое называется msa), SOLID, новые названия старых паттернов и т.д.
Те кто «отрицали», «отвергали» и «противопоставляли», теперь (часто дав новые названия) «пропагандируют» и несут в массы те же идеи.
Ты делаешь это потому что «хочешь», а не потому что «обещали з.п на 10 тыщ больше». Впрочем как и во всем остальном. Не хочешь — не делаешь. Направления роста они разные. Каждому свое найдется.
Ставки ФРС были низкими. Крупные игроки могли получать эти деньги под низкий процент и направлять их на рынки. Потому «дорожало все».
реальной экономики нет, дорожают «обещания». Один из способов роста цены обещаний: нанять много много умных инженеров задорого и всем об это рассказать. (Все эти «мы нанимаем 1000 датасантистов для развития нового направления»). Никто толком может не понимать что именно они сделают и почему это «ценно», но раз нанимают и задорого — значит не дураки. И опять — пара правильных прессрелизов, пара интервью экспертов в солидных изданиях и опять: твои «обещания» растут в цене, растет капитализация компании, топы в шоколаде, фондовый рынок тоже ликует.
Что делать дальше? Открывать новые направления, нанимать ещё больше инженеров и все по новой.
Но да — если кончатся дешовые деньги ФРС, наступит депрессия в экономике или технологический пессимизм — все закончится очень быстро.
Ирония в том, что что form/slot filling примерно так и работает.
Грубо говоря у нас есть «форма», которую нужно заполнить. Она состоит из списка полей. Для каждого поля есть «тип» и «вопрос».
Тогда получаются двай крайних случая:
Если пользователь присылает длинное развернутое сообщение — бот заполняет (в идеале) все поля формы.
Если бот присылает короткое сообщение или сообщение из которого понятно только «намерение», например «переговорка» — бот последовательно проходит по этим полям и задает «вопрос» (иногда сразу с вариантами ответов), как раз как в IVR
Для простых случаев все работает хорошо. Для «сложных» становится «сложнее» ). Например если есть какие-то бизнесовые ограничения, то после каждого шага проводить валидацию, итогом которой будет или заполнение очередного поля, либо сообщение о недопустимости такой комбинации, либо — сообщение о недопустимости с предложением выбрать от какого из конфликтующих значений «отказаться.»
Для заказчика: от определенных объемов и форм:
1)цена работы становится ниже, чем "вручную"
2)скорость — если нет необходимости делать в два слоя, то на больших ровных площадях производительность такая, что успевай только сухую смесь доставлять.
На условной однушке-двушке — выигрыша имхо почти нет. Наверняка и не возмутся: больше будут станцию расчехлять-зачехлять, чем работать
Мои 5 копеек:
1)На видео «Забронировать Стеклянная КТ», «Забронировать Кирпичная КТ» — зачем на каждой кнопке слово «Забронировать». Кажется, оно лишнее.
2)Мои попытки использовать dialogflow и wit.ai с русским языком оказались не слишком успешными. Возможно, что-то изменилось с тех пор, но мало вероятно.
3)Модель RASA NLU кмк позволяет добиться лучших результатов за счёт того, что при обучении «ответ» интерпретируется с учетом уже «заполненных» полей и последнего заданного вопроса. Это позволяет, с одной стороны извлекать «ключевые слова» из «широких фраз», но при этом правильно обрабатывать и ответы из закрытых уточняющих вопросов. Немного синтетический пример:
«Хочу забронировать столик у окна на 4х на 17-00 „
“Хочу забронировать столик» — «Какое количество гостей» — «4» — «Столик у окна» — «да» — «На какое время» — «5».
Во втором случае «4»,«да»,«5» — могут означать что угодно и «правильный» смысл определяется уже заполненными полями и текущим вопросом.
P.S. Если кто-то знает об opensource инструменте для «обучения» как в dialogflow — буду признателен за ссылки)
Я в курсе)
Решил, что с конкретным примером будет понятнее
Ох… А вы точно "банк"? Где же все эти традиционные soa и esb? Выглядит так что вы переизбрали их, только менее надёжные (очередь вместо шины и нет распределенных транзакций)
Расскажите, как у вас решается ситуация, когда "простое масштабирование" приводит к тому, что порядок транзакций в базе может произвольно не соответствовать порядку в очереди. Особенно в ситуации, когда бизнесовые правила успешности следующих зависят от предыдущих.
Так же вызывает вопросы надёжность вашего решения вот в каком кейсе: вы прочли сообщение из очереди, выполнили бизнессстранзакцию, сделали коммит в базе, и тут ваш процесс упал или случился сетеовой сбой и кафке вы не смогли сообщить об успешной обработке. Как система отработает?
Спасибо! Увидел письмо только сейчас, но заявка отправилась.
Вот черт! Регистрация уже закрыта
1)Когда работа сулит большой куш всем в случае успеха — тянуть лямку это нормально.
2)Когда достижение общей цели каким-то образом приведет тебя к достижению твоих внутренних целей — это тоже нормально радоваться погожему понедельнику
3)Когда ты находишься в конкурентном обществе где:
а)Уволить тебя могут совершенно законно по щелчку пальца (особенно если ты белый гетеросексуальный мужчина)
б)(хорошо)оплачиваемой работы катастрофически мало (см медиану)
в)при устройстве практически на любую следующую у тебя спросят и проверят рекомендации с прошлых мест
г)денег «вобрез» (погашение кредита за обучение, ипотека, пенсионные накопления, мед.услуги, дет.сады-школы) и каждая свободная сотня на счету.
В такой ситуации — будешь пахать (делать вид) как все и одобрительно встречать любую возможность по-овертаймить, в особенности если оплачиваемо.
Ну и в целом — все эти истории, что мы видим в фильмах, когда группа юристов какой-то компании проводит ночи, работая над «делом» клиента и изучая прецеденты — важно помнить что все эти часы отправятся в личный табель, а потом еще будут включены в счёт клиенту.
А ты точно "руководитель"?
Пока больше похоже, что хвост вилял собакой
Странно, что в рассуждениях о "аудитория неоднородна, поэтому а/б не работает" не нашлось места упоменнанию о сегментации и а/а тестах, как подготовке к а/б что и решает/уменьшает масштаб обозначенной проблемы.
Спасибо за статью. Будет полезна в качестве базы для обучения начинающих разработчиков, которым тяжело даётся английский.
P.s. возможно, "предшествует" более подходящий кандидат на перевод чем "произошло/случилось до" (хотя, может, просто мода изменилась)
Если вам известны решения для русского языка на jvm — поделитесь многим будет полезно
Прошло время и народ с восторгом открывал для себя «паттерны»,«автоматическое тестирование» разного масштаба, «шины/очереди», «DI/IOC», SOA (хотя сейчас примерно тоже самое называется msa), SOLID, новые названия старых паттернов и т.д.
Те кто «отрицали», «отвергали» и «противопоставляли», теперь (часто дав новые названия) «пропагандируют» и несут в массы те же идеи.
реальной экономики нет, дорожают «обещания». Один из способов роста цены обещаний: нанять много много умных инженеров задорого и всем об это рассказать. (Все эти «мы нанимаем 1000 датасантистов для развития нового направления»). Никто толком может не понимать что именно они сделают и почему это «ценно», но раз нанимают и задорого — значит не дураки. И опять — пара правильных прессрелизов, пара интервью экспертов в солидных изданиях и опять: твои «обещания» растут в цене, растет капитализация компании, топы в шоколаде, фондовый рынок тоже ликует.
Что делать дальше? Открывать новые направления, нанимать ещё больше инженеров и все по новой.
Но да — если кончатся дешовые деньги ФРС, наступит депрессия в экономике или технологический пессимизм — все закончится очень быстро.
Она же все расписала в заголовке. Просто опечаталась. Получился типичный scrumbutt
Грубо говоря у нас есть «форма», которую нужно заполнить. Она состоит из списка полей. Для каждого поля есть «тип» и «вопрос».
Тогда получаются двай крайних случая:
Если пользователь присылает длинное развернутое сообщение — бот заполняет (в идеале) все поля формы.
Если бот присылает короткое сообщение или сообщение из которого понятно только «намерение», например «переговорка» — бот последовательно проходит по этим полям и задает «вопрос» (иногда сразу с вариантами ответов), как раз как в IVR
Для простых случаев все работает хорошо. Для «сложных» становится «сложнее» ). Например если есть какие-то бизнесовые ограничения, то после каждого шага проводить валидацию, итогом которой будет или заполнение очередного поля, либо сообщение о недопустимости такой комбинации, либо — сообщение о недопустимости с предложением выбрать от какого из конфликтующих значений «отказаться.»
Для заказчика: от определенных объемов и форм:
1)цена работы становится ниже, чем "вручную"
2)скорость — если нет необходимости делать в два слоя, то на больших ровных площадях производительность такая, что успевай только сухую смесь доставлять.
На условной однушке-двушке — выигрыша имхо почти нет. Наверняка и не возмутся: больше будут станцию расчехлять-зачехлять, чем работать
Серьезно?
А как же свои "навыки", когда сторонний скрипт присылает текстовое сообщение. Они не озвучиваются? (Сам не пользуюсь, потому спрашиваю)
1)На видео «Забронировать Стеклянная КТ», «Забронировать Кирпичная КТ» — зачем на каждой кнопке слово «Забронировать». Кажется, оно лишнее.
2)Мои попытки использовать dialogflow и wit.ai с русским языком оказались не слишком успешными. Возможно, что-то изменилось с тех пор, но мало вероятно.
3)Модель RASA NLU кмк позволяет добиться лучших результатов за счёт того, что при обучении «ответ» интерпретируется с учетом уже «заполненных» полей и последнего заданного вопроса. Это позволяет, с одной стороны извлекать «ключевые слова» из «широких фраз», но при этом правильно обрабатывать и ответы из закрытых уточняющих вопросов. Немного синтетический пример:
«Хочу забронировать столик у окна на 4х на 17-00 „
“Хочу забронировать столик» — «Какое количество гостей» — «4» — «Столик у окна» — «да» — «На какое время» — «5».
Во втором случае «4»,«да»,«5» — могут означать что угодно и «правильный» смысл определяется уже заполненными полями и текущим вопросом.
P.S. Если кто-то знает об opensource инструменте для «обучения» как в dialogflow — буду признателен за ссылки)