Алгоритм не может подобрать что им надо, он подбирает в лучшем случае с достаточным приближением. Я вполне допускаю, что люди в целом непритязательные, и синицу в инстраграме вполне могут предпочесть журавлю на маркетплейсе с нормальными инструментами подбора и описаниями - в конце концов, на типичном вещевом рынке общая механика торговли устроена в целом так же (в смысле что ты находишь не товар, а продавца, у которого есть что-то примерно похожее, а дальше уже в режиме диалога выясняешь, есть ли твой размер, в нужном ли цвете, сколько стоит, и какую скидку тебе дадут), и на таких рынках покупателей мало только когда погода плохая.
Но не надо только оправдывать плохой интерфейс тем, что люди им всё равно пользуются.
Но ведь ни категорий, ни сортировки, ни фильтра по размерам, ничего этого в интерфейсе Инстаграма нет, а продажи есть.
Думаете, если бы там были фильтры и категории - продажи бы упали?
А по-моему, вы путаете причину и следствие. Продавцы туда выставлялись не потому что там нет фильтров, а потому что там много людей видит, есть рекомендательные алгоритмы, которые могут им ваш товар показать, и создать там канал - очень дёшево (т.е. подходит для очень маленького продавца, у которого нет прибыли себе сделать сайт). Пользователи там покупали не потому что там нет фильтров, а потому что вот именно это вот именно сейчас продаётся только здесь, и алгоритм рекомендаций это посоветовал. Отсутствие вменяемых фильтров - это не плюс, а даже скорее минус, потому что без него находить в поиске именно то, что надо покупателю - это сложнее.
Начали мы с того, что "нафиг не нужон никакой этот контекст ваш", и через пару наводящих вопросов пришли к тому, что "контекст на 10000 токенов стоит совсем недорого".
Но при этом в Java уже давно JSR310, и его предшественник JodaTime. А в JS - js-joda (только что нашёл). Негусто, конечно, но что поделать - видимо, разработчикам на JS и так нормально было (я сам вживую до этого видел только datejs и momentjs, но это вообще не то).
Поэтому, чтобы не усложнять ситуацию - лучше в тех случаях, когда обрабатывать не нужно
Как я уже говорил, полное отсутствие обработки - это фантастика. Должны же вы проверять эти данные, что там действительно даты? Хотя если конкретно ваше приложение нужно только как труба для значений, то там и строки не нужны - гораздо точнее будет всё принимать и отправлять в виде бит-массива. Вот уж где точно не будет никакой возможности что-то по дороге испортить неверной типизацией.
в Андроиде, например, на момент, когда это еще актуально было, не было Самарской таймзоны
Насколько я знаю, JodaTime таскает Tzdata с собой, как раз на такой случай.
Какого размера меню на 1000 токенов, сколько это позиций? Правильно ли я понимаю, что у вас по итогу система жёстко разделена на конкретные сценарии, и система не сумеет поддержать несложный диалог с пользователем и что-то про меню рассказать?
С того, что произвольный запрос от пользователя на такое вполне способен, если поперёк индекса влезет неудачно.
Вы эксперименты проводили?
Куда уж нам, кувшиноликим. Вы же ни единой настоящей технической подробности не сказали за всё обсуждение - на чём тут можно экспериментировать, на чьих-то фантазиях?
Если вы не станете гонять в API историю разговора - это значит, что пользователю придётся заново каждый раз проговаривать свои хотелки с самого начала. Никаких "а хотя постой, американо замени на лавандовый раф" - без истории ваша сетка не поймёт, какие ещё элементы списка в заказе.
Если государство решило ОДНУ проблему, и за это демос его в попу целует и в ножки кланяется - государство обнаглеет, осмелеет и быстренько станет диктатурой, и по-другому не бывает
Это умозрительно, и требует доказательств, которых вы привести сейчас не сможете - поэтому вам и нужно будет нормальное исследование собрать. Вы, например, не учитываете, что демос не продолжит целовать в тёмные места власть, которая начинает наглеть. А так же то, что государство и власть - это не одно и то же, и в конкретной администрации в государстве действительно могла быть только одна функция.
Вот такие как ты и приводят к власти гитлеров
Опять гадания по аватарке и обвинения в фашизме. Успокойтесь, и приведите хорошие доказательства исходного тезиса. Гитлеров к власти привело не обожание текущего правительства, а по крайней мере как раз недовольство предыдущим.
У вас государство это спасатель и палочка-выручалочка
Это ваши домыслы. Из моих прямых слов таких выводов сделать невозможно. Более того, я любому государству предпочту минимальное, близкое к либертарианским заветам.
Но продолжение этой ветки переводит диалог на мою личность, тогда как самое интересное здесь - это доказательства вашей теории.
Но зачем же проблему чинить не там, где она возникает?
День рождения человека, скажем - это не момент его рождения, так что зачем вообще в этих рассуждениях использовать слово "полночь", и давать этой дате какое-то время, да ещё и отбрасывать его потом? По-моему, проблема ваша была на самом деле в этом, а не в опоздавшем обновлении tzdata.
"Другие" - это которые с ещё меньшей маржой работают? Это какие, например?
Я из примеров в реальной жизни такое могу вспомнить только когда крупная компания демпингует, и выдавливает с рынка мелких конкурентов, которые не могут на этой точке работать в минус, потому что у них никакой другой и нет. Эта ситуация, к слову, на долгую перспективу невыгодна ни покупателям, при продавцам (даже тому конкретному Горцу не всегда выгодно, ведь он потом станет монополистом, и к нему придут антимонопольщики).
Вот только продавцу выгодно чтобы я купил не то, что нужно мне - а то, что у продавца на складе залежалось, потому что берут плохо, а лежание товара на складе уже само по себе стоит денег.
Это зависит. Я работал с американскими биржевиками и у них часть операций определена в центах, а часть (типа комиссии за биржевую операцию) в 1/10000 цента. Это та же валюта, но дискрет таки другой.
Fair. Поэтому они и доменные типы, что нужен контекст. В противовес биржевым операциям, все эти вещи могут совершенно не понадобиться при написании B2B Value Chain.
Decimal, а не просто Money или что-то подобное
Monetary{Money, Currency} - порождает ещё один вопрос - "а что такое Money ?". Где-то эта цепь должна сходиться к чуть более абстрактным вещам, вроде какого-никакого численного типа, пусть даже и отсутствующего в стандартной библиотеке (i.e. Decimal|Rational).
Непонятно, зачем вы пытаетесь защищаться.
Просто началось всё с указания, на мою личную неопытность. У меня бывает.
По-моему, как раз оптимальный метод дискуссии, чтобы получить какой-то конструктивный результат, это попытаться расширить и углубить полученное от другого и на этом основании уже с чем-то соглашаться, чему-то возражать - но без своего взноса оно превращается в бессмысленную полемику.
Чтобы полностью в конструктивном режиме выбрать, каким именно будет отдельный заданный тип - начинать тогда следует с описания того, для каких действий он будет применяться, в том числе действий в реальном мире.
Например, в моём изначальном предположении деньги нужно хранить с точностью, которая предположила бы их итоговый вывод в реал - а потому, в принципе, можно и не заморачиваться хранением честных третей, которые можно делить и складывать в любую сторону вообще без потерь, причём на любых временных отрезках. Но следом в то же приложение была добавлена поддержка дележа акций и их владение, биржевых финансовых операций, всех валют мира с их деноминациями. А началось всё вообще с того, что UserID - это вообще-то не число совсем даже, а enum.
Я так же по поводу дат считают - пока арифметики с ними нет, нет смысла ко всяким системным и не очень типам приводить
Смысл есть - потому что обычно от вашей системы будут ожидать, что вы таки не принимаете дат "25-15-2025", независимо от особенностей работы с датами где угодно (мы же предполагаем ISO-шную систему, а не любую из альтернатив? даже если нет, то это где-то придётся выразить, и почему не в типах данных?). И ещё что вы сортировку по датам сравнительно честную будете делать, а не лексическую в зависимости от того, как эту дату вводил пользователь. Да и просто даты пользователю смотреть будет удобнее, если они все будут в общем форматировании, даже если вводились как придётся. Ничего из перечисленного сделать нормально не получится если их как-то когда-то не парсить. Ну а если вы чаще показываете даты, чем их сохраняете в store - то эффективнее их будет парсить при сохранении, и сохранять таки в соответствующих системных типах.
вдруг базу данных таймзон обновить забыли?
Стирать из своей системы важные для пользовательского опыта метаданные только потому, что девопсы могут забыть подложить правильный tzdata - это, по-моему, покруче всякого религиозного следования SOLID.
Алгоритм не может подобрать что им надо, он подбирает в лучшем случае с достаточным приближением. Я вполне допускаю, что люди в целом непритязательные, и синицу в инстраграме вполне могут предпочесть журавлю на маркетплейсе с нормальными инструментами подбора и описаниями - в конце концов, на типичном вещевом рынке общая механика торговли устроена в целом так же (в смысле что ты находишь не товар, а продавца, у которого есть что-то примерно похожее, а дальше уже в режиме диалога выясняешь, есть ли твой размер, в нужном ли цвете, сколько стоит, и какую скидку тебе дадут), и на таких рынках покупателей мало только когда погода плохая.
Но не надо только оправдывать плохой интерфейс тем, что люди им всё равно пользуются.
Думаете, если бы там были фильтры и категории - продажи бы упали?
А по-моему, вы путаете причину и следствие. Продавцы туда выставлялись не потому что там нет фильтров, а потому что там много людей видит, есть рекомендательные алгоритмы, которые могут им ваш товар показать, и создать там канал - очень дёшево (т.е. подходит для очень маленького продавца, у которого нет прибыли себе сделать сайт). Пользователи там покупали не потому что там нет фильтров, а потому что вот именно это вот именно сейчас продаётся только здесь, и алгоритм рекомендаций это посоветовал. Отсутствие вменяемых фильтров - это не плюс, а даже скорее минус, потому что без него находить в поиске именно то, что надо покупателю - это сложнее.
Скажите, вы потом число комментариев под статьёй кому-то продавать собираетесь, и поэтому отвечаете только односложно?
Судя по структуре предложения, человек(?), который его написал, уже думает, по сути, на английском.
Видимо, все эти дни изучения принесли свои плоды.
В смысле? eBay заплатила, чтобы Operator чаще пользовался их сервисами?
Начали мы с того, что "нафиг не нужон никакой этот контекст ваш", и через пару наводящих вопросов пришли к тому, что "контекст на 10000 токенов стоит совсем недорого".
Вас ничего не смущает?
Но при этом в Java уже давно JSR310, и его предшественник JodaTime. А в JS - js-joda (только что нашёл). Негусто, конечно, но что поделать - видимо, разработчикам на JS и так нормально было (я сам вживую до этого видел только datejs и momentjs, но это вообще не то).
Как я уже говорил, полное отсутствие обработки - это фантастика. Должны же вы проверять эти данные, что там действительно даты? Хотя если конкретно ваше приложение нужно только как труба для значений, то там и строки не нужны - гораздо точнее будет всё принимать и отправлять в виде бит-массива. Вот уж где точно не будет никакой возможности что-то по дороге испортить неверной типизацией.
Насколько я знаю, JodaTime таскает Tzdata с собой, как раз на такой случай.
Какого размера меню на 1000 токенов, сколько это позиций?
Правильно ли я понимаю, что у вас по итогу система жёстко разделена на конкретные сценарии, и система не сумеет поддержать несложный диалог с пользователем и что-то про меню рассказать?
Так модель не выдаёт никакого человекочитаемого ответа?
Ок, а меню тогда где передаётся? Меню - разве не контекст?
С того, что произвольный запрос от пользователя на такое вполне способен, если поперёк индекса влезет неудачно.
Куда уж нам, кувшиноликим. Вы же ни единой настоящей технической подробности не сказали за всё обсуждение - на чём тут можно экспериментировать, на чьих-то фантазиях?
То есть, система запускается несколько раз - один раз чтобы создать человекочитаемый ответ, и второй - для машиночитаемого?
Что делать если "результат выполнения запроса" - это подвешенный сервер?
Если вы не станете гонять в API историю разговора - это значит, что пользователю придётся заново каждый раз проговаривать свои хотелки с самого начала. Никаких "а хотя постой, американо замени на лавандовый раф" - без истории ваша сетка не поймёт, какие ещё элементы списка в заказе.
Это умозрительно, и требует доказательств, которых вы привести сейчас не сможете - поэтому вам и нужно будет нормальное исследование собрать. Вы, например, не учитываете, что демос не продолжит целовать в тёмные места власть, которая начинает наглеть. А так же то, что государство и власть - это не одно и то же, и в конкретной администрации в государстве действительно могла быть только одна функция.
Опять гадания по аватарке и обвинения в фашизме. Успокойтесь, и приведите хорошие доказательства исходного тезиса. Гитлеров к власти привело не обожание текущего правительства, а по крайней мере как раз недовольство предыдущим.
Это ваши домыслы. Из моих прямых слов таких выводов сделать невозможно. Более того, я любому государству предпочту минимальное, близкое к либертарианским заветам.
Но продолжение этой ветки переводит диалог на мою личность, тогда как самое интересное здесь - это доказательства вашей теории.
Но зачем же проблему чинить не там, где она возникает?
День рождения человека, скажем - это не момент его рождения, так что зачем вообще в этих рассуждениях использовать слово "полночь", и давать этой дате какое-то время, да ещё и отбрасывать его потом? По-моему, проблема ваша была на самом деле в этом, а не в опоздавшем обновлении tzdata.
Постойте, зачем гонять все токены? Можно ведь историю хранить на бэкэнде в сессии, а гонять только недавно добавленные токены.
"Другие" - это которые с ещё меньшей маржой работают? Это какие, например?
Я из примеров в реальной жизни такое могу вспомнить только когда крупная компания демпингует, и выдавливает с рынка мелких конкурентов, которые не могут на этой точке работать в минус, потому что у них никакой другой и нет. Эта ситуация, к слову, на долгую перспективу невыгодна ни покупателям, при продавцам (даже тому конкретному Горцу не всегда выгодно, ведь он потом станет монополистом, и к нему придут антимонопольщики).
Вот только продавцу выгодно чтобы я купил не то, что нужно мне - а то, что у продавца на складе залежалось, потому что берут плохо, а лежание товара на складе уже само по себе стоит денег.
Fair. Поэтому они и доменные типы, что нужен контекст. В противовес биржевым операциям, все эти вещи могут совершенно не понадобиться при написании B2B Value Chain.
Monetary{Money, Currency}- порождает ещё один вопрос - "а что такоеMoney?". Где-то эта цепь должна сходиться к чуть более абстрактным вещам, вроде какого-никакого численного типа, пусть даже и отсутствующего в стандартной библиотеке (i.e. Decimal|Rational).Просто началось всё с указания, на мою личную неопытность. У меня бывает.
Чтобы полностью в конструктивном режиме выбрать, каким именно будет отдельный заданный тип - начинать тогда следует с описания того, для каких действий он будет применяться, в том числе действий в реальном мире.
Например, в моём изначальном предположении деньги нужно хранить с точностью, которая предположила бы их итоговый вывод в реал - а потому, в принципе, можно и не заморачиваться хранением честных третей, которые можно делить и складывать в любую сторону вообще без потерь, причём на любых временных отрезках. Но следом в то же приложение была добавлена поддержка дележа акций и их владение, биржевых финансовых операций, всех валют мира с их деноминациями. А началось всё вообще с того, что
UserID- это вообще-то не число совсем даже, аenum.Смысл есть - потому что обычно от вашей системы будут ожидать, что вы таки не принимаете дат "25-15-2025", независимо от особенностей работы с датами где угодно (мы же предполагаем ISO-шную систему, а не любую из альтернатив? даже если нет, то это где-то придётся выразить, и почему не в типах данных?). И ещё что вы сортировку по датам сравнительно честную будете делать, а не лексическую в зависимости от того, как эту дату вводил пользователь. Да и просто даты пользователю смотреть будет удобнее, если они все будут в общем форматировании, даже если вводились как придётся. Ничего из перечисленного сделать нормально не получится если их как-то когда-то не парсить. Ну а если вы чаще показываете даты, чем их сохраняете в store - то эффективнее их будет парсить при сохранении, и сохранять таки в соответствующих системных типах.
Стирать из своей системы важные для пользовательского опыта метаданные только потому, что девопсы могут забыть подложить правильный tzdata - это, по-моему, покруче всякого религиозного следования SOLID.