То что вы описали это не задача, а ваше ее решение. Возможно у той исходной задачи, которую вы пытались решить генерированием миллионов объектов с несколькими стрингами внутри, есть лучшие решения на java.
Но если вы всерьез рассматривали вариант использовать UUID в качестве ключа, то получается в пакетах вендоров этот ключ может представляться строкой, а не числом. Вы не пробовали отдавать идентификатор как строчку-из-цифр, а не число?
Я правильно понимаю что у вас что-то сломалось на клиенте, и что бы это починить вы смело патчите серверную часть?
Если да то есть предположение что если сервер отдает валидные данные, а клиент на них ломается, то ошибка именно на клиенте, и именно там ее и нужно чинить.
Впринципе по статье уже понятно, что у вас критерий схожести - визуально похоже (в статье про синтаксис вспоминают постоянно), рекомендую при таком подходе наждачку и туалетную бумагу тоже вместе классифицировать - в названии и там и там "бумага", и та и та в руллонах...
Если бы вы собственную ссылку на вики прочитали внимательно, то как минимум нашли бы это:
Although Java and JavaScript are similar in name, syntax, and respective standard libraries, the two languages are distinct and differ greatly in design.
Если даже оставить за скобками претензии относительно использования модели в контроллере для представления данных ваша статья все еще плоха для новичков там, что содержит абсолютно не обязательные для воспроизведения вещи, которые зачем-то там присутствуют, и никак не комментируются.
Если не ошибаюсь основное назначение этой массивности - жесткость конструкции. Она критически важна если станок работает по шаблону, без обратной связи. Есть предположение что качественный контроль по оптическому каналу снимает необходимость столь монументальной жесткости - мясной токарь стоящий за станком бывает делает весьма точные штуки, а жесткость у него так себе
Из всей статьи так и не понял, основной плюс на который можно рассчитывать при использовании этого инструмента по сравнению с Postgres это отсутствие объемной документации?
По информации Forbes, после легализации параллельного импорта стоимость компьютерной техники и электроники для конечного потребителя может вырасти на 20-40%.
А может быть вы знакомы с методикой рассчета, использованного в этом прогнозе? Мне казалось что если что-то перестали привозить совсем, то у этого чего-то цены нет (т.к. нет предложений о продаже), далее мы должны какуют-то цену (полученную в результате использования схемы "параллельный импорт") поделить на несуществующую и получить что-то в диапазоне от 1.2 до 1.4 . Как-то очень непонятно, если есть данные - поделитесь пожалуйста.
А если бы просто сложил все в сет без проверки на наличие, и потом уже отправил весь полученный сет возможно сэкономил бы еще больше (особенно если там пакетная обработка возможна)
А про "прямо перед едущей машиной" и "под наркотиками" пруфы есть? Возможно речь про разные инциденты, я помню как минимум 1 когда Тесла заехала под прицеп, и ни о каких поворотах "прямо перед машиной" и близко не было речи. Тогда был -1 тесловод.
Вот я примерно об этом и говорю, подход "Не смотрите что я писаюсь, Васичкин вообще какается" считается в этой экосистеме нормой.
Сам имел дело с платформой уже больше 5 лет назад, сейчас сужу исключительно по рассказам друзей/коллег, кто еще не бросил: обнаружить в конфигурации отсутсвие заданных централизованно параметров (например проверки ролей пользователя) - норма, получить измемения поведения параметров документа в рамках перехода от одной минорной версии платформы к другой - обычное дело.
Видя размер (и возможности) компании, разрабатывающей платформу, и соотнося это с тем бардаком который наблюдается приходишь к выводу что это действительно не проблема - это такая бизнес-модель. Мы делаем так чтобы у всех всегда была работа, чтобы разработчик 1С был нужен как бухгалтер - на постоянной основе.
Статья похоже что пытается привлечь внимание новичков к платформе, для полноты формируемого представления было бы круто рассказать, как мне кажется, про показатели качества выпскаемых релизов платформы и типовых конфигураций (или почему среди людей сопровождающих 1с не принято ставить последние обновления, а "отставать" на 2-3).
Коллекция не работает с примитивными типами, дженерики тут похоже что не при делах. И да, Map он как-бы требует два параметра - тип ключа и тип значения (если только у автора не какой-то свой Map, со своим представлением о процессе)
То что вы описали это не задача, а ваше ее решение. Возможно у той исходной задачи, которую вы пытались решить генерированием миллионов объектов с несколькими стрингами внутри, есть лучшие решения на java.
Но если вы всерьез рассматривали вариант использовать UUID в качестве ключа, то получается в пакетах вендоров этот ключ может представляться строкой, а не числом. Вы не пробовали отдавать идентификатор как строчку-из-цифр, а не число?
Я правильно понимаю что у вас что-то сломалось на клиенте, и что бы это починить вы смело патчите серверную часть?
Если да то есть предположение что если сервер отдает валидные данные, а клиент на них ломается, то ошибка именно на клиенте, и именно там ее и нужно чинить.
Впринципе по статье уже понятно, что у вас критерий схожести - визуально похоже (в статье про синтаксис вспоминают постоянно), рекомендую при таком подходе наждачку и туалетную бумагу тоже вместе классифицировать - в названии и там и там "бумага", и та и та в руллонах...
Если бы вы собственную ссылку на вики прочитали внимательно, то как минимум нашли бы это:
Еще есть вот это:
Из этого можно сделать вывод что либо вы про JavaScript особо ничего не знаете, либо про Java (либо и про то и про другое).
Вы конечно не сказали после 25+ лет в какой профессии вы рекоммендации раздаете, но матчасть явно стоит подучить.
Писать такое в статье для новичков стыд и позор, прежде чем кому-то что-то советовать стоило бы ознакомиться с упоминаемыми вещами.
Подскажите пожалуйста, а вот без этого:
не заработает?
Если даже оставить за скобками претензии относительно использования модели в контроллере для представления данных ваша статья все еще плоха для новичков там, что содержит абсолютно не обязательные для воспроизведения вещи, которые зачем-то там присутствуют, и никак не комментируются.
Если не ошибаюсь основное назначение этой массивности - жесткость конструкции. Она критически важна если станок работает по шаблону, без обратной связи. Есть предположение что качественный контроль по оптическому каналу снимает необходимость столь монументальной жесткости - мясной токарь стоящий за станком бывает делает весьма точные штуки, а жесткость у него так себе
Не могли бы развернуть вашу мысль? В текущем изложении не очень понятно в чем вы видите угрозу безопасности
Из всей статьи так и не понял, основной плюс на который можно рассчитывать при использовании этого инструмента по сравнению с Postgres это отсутствие объемной документации?
А может быть вы знакомы с методикой рассчета, использованного в этом прогнозе? Мне казалось что если что-то перестали привозить совсем, то у этого чего-то цены нет (т.к. нет предложений о продаже), далее мы должны какуют-то цену (полученную в результате использования схемы "параллельный импорт") поделить на несуществующую и получить что-то в диапазоне от 1.2 до 1.4 . Как-то очень непонятно, если есть данные - поделитесь пожалуйста.
А если бы просто сложил все в сет без проверки на наличие, и потом уже отправил весь полученный сет возможно сэкономил бы еще больше (особенно если там пакетная обработка возможна)
понял, речь о "short circuit", бегло посмотрел не понял контекст, спасибо
подскажите пожалуйста, у вас тут "короткое замыкание" это вы имели ввиду "bug" или "closure" небольшой длины ?
А про "прямо перед едущей машиной" и "под наркотиками" пруфы есть? Возможно речь про разные инциденты, я помню как минимум 1 когда Тесла заехала под прицеп, и ни о каких поворотах "прямо перед машиной" и близко не было речи. Тогда был -1 тесловод.
"Обычный мелок" != "восковой мелок"
"Разница в трении между бумагой и мелом" != "разница в трении между бумагой и воском"
Там же вроде прямо на камеру показывают мелок - он восковой
Интересная штуковина: и работаешь, и в качалке :)
Вот я примерно об этом и говорю, подход "Не смотрите что я писаюсь, Васичкин вообще какается" считается в этой экосистеме нормой.
Сам имел дело с платформой уже больше 5 лет назад, сейчас сужу исключительно по рассказам друзей/коллег, кто еще не бросил: обнаружить в конфигурации отсутсвие заданных централизованно параметров (например проверки ролей пользователя) - норма, получить измемения поведения параметров документа в рамках перехода от одной минорной версии платформы к другой - обычное дело.
Видя размер (и возможности) компании, разрабатывающей платформу, и соотнося это с тем бардаком который наблюдается приходишь к выводу что это действительно не проблема - это такая бизнес-модель. Мы делаем так чтобы у всех всегда была работа, чтобы разработчик 1С был нужен как бухгалтер - на постоянной основе.
Статья похоже что пытается привлечь внимание новичков к платформе, для полноты формируемого представления было бы круто рассказать, как мне кажется, про показатели качества выпскаемых релизов платформы и типовых конфигураций (или почему среди людей сопровождающих 1с не принято ставить последние обновления, а "отставать" на 2-3).
Коллекция не работает с примитивными типами, дженерики тут похоже что не при делах. И да, Map он как-бы требует два параметра - тип ключа и тип значения (если только у автора не какой-то свой Map, со своим представлением о процессе)