_>>>Сбертех подойдет?
G>>Во-первых что за проект? Скорее всего это автоматизация внутреннего документооборота или регистрация времени работы сотрудников в офисе. Во вторых у них там Grid Gain кажется так называется. Купили какую-то мутную лабуду.

_>Grid Gain — это коммерческая версия Apache Ignite. И название компании, которая разрабатывает Apache Ignite/Grid Gain.
Прекрасно, но проект какой? Что за данные хранятся в этой лабуде?

Здравствуйте, Gattaka, Вы писали:

_>>Сбертех подойдет?
G>Во-первых что за проект? Скорее всего это автоматизация внутреннего документооборота или регистрация времени работы сотрудников в офисе. Во вторых у них там Grid Gain кажется так называется. Купили какую-то мутную лабуду.
Grid Gain используется в одной Очень Большой Компании, в роли, которая может Сломать Весь Интернет. JFYI.

Здравствуйте, anton_t, Вы писали:

_>Зато LinkedHashMap сохранит существующий порядок ключей, а TreeMap может изменить его, получив "diff размером в пол-файла", которого опасается Cyberax.
TreeMap изменит порядок, если в изначальном файле ключи не были отсортированы. У меня они получаются в результате инспекции внешней системы с неопределённым порядком ключей, так что TreeMap как раз подходит.

Кстати, забыл до этого написать, что LinkedHashMap сохраняет порядок при перезаписи значения. Т.е.:

        Map<String, String> map = new LinkedHashMap<>();
        map.put("Hello", "world");
        map.put("1", "2");
        map.put("3", "4");

        map.put("1", "42");
        for(Map.Entry<String, String> entry : map.entrySet()) {
            System.out.println(entry.getKey()+" - "+entry.getValue());
        }

Hello - world
1 - 42
3 - 4

Но:

        Map<String, String> map = new LinkedHashMap<>();
        map.put("Hello", "world");
        map.put("1", "2");
        map.put("3", "4");
        map.remove("1");

        map.put("1", "42");
        for(Map.Entry<String, String> entry : map.entrySet()) {
            System.out.println(entry.getKey()+" - "+entry.getValue());
        }

Hello - world
3 - 4
1 - 42

Здравствуйте, Cyberax, Вы писали:

G>>Во-первых что за проект? Скорее всего это автоматизация внутреннего документооборота или регистрация времени работы сотрудников в офисе. Во вторых у них там Grid Gain кажется так называется. Купили какую-то мутную лабуду.
C>Grid Gain используется в одной Очень Большой Компании, в роли, которая может Сломать Весь Интернет. JFYI.
Давай конкретно. Что за проект и что за компания. Сломать весь интернет это одно, а потерять деньги это другое. Зарплату кто-нибудь считает на этой лабуде? Или сбережения свои хранит? Или может на бирже SQL эксепшены тебе прилетают от оракла просто так?

Здравствуйте, Gattaka, Вы писали:

C>>Grid Gain используется в одной Очень Большой Компании, в роли, которая может Сломать Весь Интернет. JFYI.
G>Давай конкретно. Что за проект и что за компания.
Компания — Амазон. Про проект рассказывать не буду.

G>Сломать весь интернет это одно, а потерять деньги это другое.
Это одно и то же.

G>Зарплату кто-нибудь считает на этой лабуде? Или сбережения свои хранит?
Зарплату компании любого размера нынче даже мои наручные часы могут посчитать.

G>Или может на бирже SQL эксепшены тебе прилетают от оракла просто так?
Нет, они прилетают от кривых рук программистов, которые считают, что достаточно знать про hashmap.

Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, Gattaka, Вы писали:

C>>>Grid Gain используется в одной Очень Большой Компании, в роли, которая может Сломать Весь Интернет. JFYI.
G>>Давай конкретно. Что за проект и что за компания.
C>Компания — Амазон. Про проект рассказывать не буду.
Ага это та самая контора с дурной репутацией в штатах. Типа работа для индусов, кто еще согласится работать по 10 часов и бежать на работу среди ночи.

G>>Сломать весь интернет это одно, а потерять деньги это другое.
C>Это одно и то же.
Нет. Это подмена понятий. В банках, биржах, финансах это все не используется.

G>>Зарплату кто-нибудь считает на этой лабуде? Или сбережения свои хранит?
C>Зарплату компании любого размера нынче даже мои наручные часы могут посчитать.
Нет. Это говорит о том, что у вас нет такого опыта. Что вобщем-то не удивительно учитывая высказывания выше. Клепать сайты, бизнес приложения и пр. непростое занятие. Вы знаете чем анемичная модель отличается от rich модели? Слышали про такое хотя бы?

G>>Или может на бирже SQL эксепшены тебе прилетают от оракла просто так?
C>Нет, они прилетают от кривых рук программистов, которые считают, что достаточно знать про hashmap.
Поправка. Подавляющему большенству программистов. Тем самым сайтоклепателям как вы выражаетесь. Если вы пишите базу или ОС то да, но это ведь единицы и еще сотни возомнившие себя Линусами и Гейтсами самоучками.

Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, anton_t, Вы писали:

_>>Зато LinkedHashMap сохранит существующий порядок ключей, а TreeMap может изменить его, получив "diff размером в пол-файла", которого опасается Cyberax.
C>TreeMap изменит порядок, если в изначальном файле ключи не были отсортированы. У меня они получаются в результате инспекции внешней системы с неопределённым порядком ключей, так что TreeMap как раз подходит.

Не совсем понял твой кейс.
Если данные

получаются в результате инспекции внешней системы с неопределённым порядком ключей

и

TreeMap изменит порядок, если в изначальном файле ключи не были отсортированы

, то как раз и получится

"diff размером в пол-файла"

Почему тогда тебе подходит TreeMap?

Здравствуйте, Gattaka, Вы писали:

C>>Компания — Амазон. Про проект рассказывать не буду.
G>Ага это та самая контора с дурной репутацией в штатах. Типа работа для индусов, кто еще согласится работать по 10 часов и бежать на работу среди ночи.
Угу. И мы ещё плачем по 5 часов в день на рабочем месте.

G>>>Сломать весь интернет это одно, а потерять деньги это другое.
C>>Это одно и то же.
G>Нет. Это подмена понятий. В банках, биржах, финансах это все не используется.
В банках и биржах вообще COBOL местами используется, так как объём данных совсем смешной.

G>>>Зарплату кто-нибудь считает на этой лабуде? Или сбережения свои хранит?
C>>Зарплату компании любого размера нынче даже мои наручные часы могут посчитать.
G>Нет. Это говорит о том, что у вас нет такого опыта.
Да. Я в детстве писал те самые опердени.

G>Что вобщем-то не удивительно учитывая высказывания выше. Клепать сайты, бизнес приложения и пр. непростое занятие.
Ну так никто и не спорит.

G>Вы знаете чем анемичная модель отличается от rich модели? Слышали про такое хотя бы?
Естественно, слышал. И причём здесь это?

C>>Нет, они прилетают от кривых рук программистов, которые считают, что достаточно знать про hashmap.
G>Поправка. Подавляющему большенству программистов. Тем самым сайтоклепателям как вы выражаетесь. Если вы пишите базу или ОС то да, но это ведь единицы и еще сотни возомнившие себя Линусами и Гейтсами самоучками.
Неверно. Интересные задачи бывают в очень многих областях. Причём во многих из них даже нет БД, от слова "совсем".

Здравствуйте, anton_t, Вы писали:

_>Почему тогда тебе подходит TreeMap?
Всё просто — инспектируем внешнюю систему, получаем JSON. Его потом можно импортировать обратно в другую копию системы, положить в VCS, добавить в мониторилку и т.д.

Так что изначально JSON будет отсортирован и при небольших изменениях не будет меняться целиком.

G>>Вы знаете чем анемичная модель отличается от rich модели? Слышали про такое хотя бы?
C>Естественно, слышал. И причём здесь это?
Что-то сомнительно. DRY слышал такое? И как считаешь везде нужно пихать алгоритмы? Или либы готовые использовать?

C>>>Нет, они прилетают от кривых рук программистов, которые считают, что достаточно знать про hashmap.
G>>Поправка. Подавляющему большенству программистов. Тем самым сайтоклепателям как вы выражаетесь. Если вы пишите базу или ОС то да, но это ведь единицы и еще сотни возомнившие себя Линусами и Гейтсами самоучками.
C>Неверно. Интересные задачи бывают в очень многих областях. Причём во многих из них даже нет БД, от слова "совсем".
А если их нет, начинаете их себе придумывать там где их нет. Давай так. Что такое кардиналити? Слышал хоть?

Здравствуйте, Gattaka, Вы писали:

G>>>Вы знаете чем анемичная модель отличается от rich модели? Слышали про такое хотя бы?
C>>Естественно, слышал. И причём здесь это?
G>Что-то сомнительно. DRY слышал такое? И как считаешь везде нужно пихать алгоритмы? Или либы готовые использовать?
DRY означает "don't repeat yourself" и означает, что для каждой функциональности или данных должен быть ровно один владелец. Какое отношение он имеет к алгоритмам?

Хватит уже повторять незнакомые слова.

G>>>Поправка. Подавляющему большенству программистов. Тем самым сайтоклепателям как вы выражаетесь. Если вы пишите базу или ОС то да, но это ведь единицы и еще сотни возомнившие себя Линусами и Гейтсами самоучками.
C>>Неверно. Интересные задачи бывают в очень многих областях. Причём во многих из них даже нет БД, от слова "совсем".
G>А если их нет, начинаете их себе придумывать там где их нет.
Вот когда такие пейсатели начинают пейсать сайты, то получается сон разума.

Сайт занимает 20Мб на страничку и не работает на мобильных устройствах? Ну так никому же не нужно, иначе поддерживать нельзя и вообще полный анемичный DRY!!!

G>Давай так. Что такое кардиналити? Слышал хоть?
А вы слышали про фермент "Nextera" и почему он хорошо работает с blunt ends? Нет? Вон из профессии!!!

Здравствуйте, Cyberax, Вы писали:

G>>Давай так. Что такое кардиналити? Слышал хоть?
C>А вы слышали про фермент "Nextera" и почему он хорошо работает с blunt ends? Нет? Вон из профессии!!!
Вот! Не слышал про кардиналити, тему переводит на nextra какую-то. Вот так я и знал, что не шарит в базах. И вот всегда вы норовите сами написать свой велосипед вместо того чтобы почитать доки.
При чем здесь гены? Гены это узнакая специализация, базы все должны знать в совершенстве. Их учат еще в университете, чтобы потом самому не реализовавывать то что уже есть.
Знаете почему сайты по 20 минут загружаются? Потому что супер алгоритмисты влепят самопальную реализацию бинарного дерева им и в голову не придет что в зависимости от объема данных, в зависимости от распределения в этих данных
нужны разные алгоритмы. База сама все подбирает, основываясь на статистике. Вы только говорите ей что нужно, вы не говорите как! Ваша примитивнейшая реализация, которую вы пилили 7 недель (да она при этом до убожества примитивна) не
содержит в себе такое понятие как эскалация блокировок и еще кучу всего не содержит. Так что только книги, просвещение и скромность!

Здравствуйте, Gattaka, Вы писали:

G>>>Давай так. Что такое кардиналити? Слышал хоть?
C>>А вы слышали про фермент "Nextera" и почему он хорошо работает с blunt ends? Нет? Вон из профессии!!!
G>Вот! Не слышал про кардиналити, тему переводит на nextra какую-то.
Именно. Как можно не знать про биоинформатику и работать программистом?!?

У слова "cardinality" примерно 100500 значений, в зависимости от области применения. Какое именно мне надо телепатировать? Даже в области РБД у него не одно значение.

G>Знаете почему сайты по 20 минут загружаются? Потому что супер алгоритмисты влепят самопальную реализацию бинарного
Нет. Они по 20 минут загружаются из-за тех, кто считает, что "база сама посчитает". Программисты ОБЯЗАНЫ знать детали базовых структур данных.

Здравствуйте, Cyberax, Вы писали:

C>Именно. Как можно не знать про биоинформатику и работать программистом?!?
C>У слова "cardinality" примерно 100500 значений, в зависимости от области применения. Какое именно мне надо телепатировать? Даже в области РБД у него не одно значение.
Хех... это какие же?!

G>>Знаете почему сайты по 20 минут загружаются? Потому что супер алгоритмисты влепят самопальную реализацию бинарного
C>Нет. Они по 20 минут загружаются из-за тех, кто считает, что "база сама посчитает". Программисты ОБЯЗАНЫ знать детали базовых структур данных.
Обязаны знать это не значит, что они должны сами реализовывать каждый раз.

Здравствуйте, Gattaka, Вы писали:

C>>У слова "cardinality" примерно 100500 значений, в зависимости от области применения. Какое именно мне надо телепатировать? Даже в области РБД у него не одно значение.
G>Хех... это какие же?!
"кардинальность связи" — один-к-одному, один-ко-многим, многие-ко-многим.
"кардинальность поля/индекса" — мощность множества значений поля/индекса.

C>>Нет. Они по 20 минут загружаются из-за тех, кто считает, что "база сама посчитает". Программисты ОБЯЗАНЫ знать детали базовых структур данных.
G>Обязаны знать это не значит, что они должны сами реализовывать каждый раз.
Про "реализовывать" здесь речи не идёт — смотри на свой топик.

Но вот свою хэш-таблицу, например, я писал. Из-за того, что дефолтная глючила (вопрос: почему ключи в hash-таблице в Java должны реализовывать Comparable правильно?)

Здравствуйте, Cyberax, Вы писали:

C>>>Нет. Они по 20 минут загружаются из-за тех, кто считает, что "база сама посчитает". Программисты ОБЯЗАНЫ знать детали базовых структур данных.
G>>Обязаны знать это не значит, что они должны сами реализовывать каждый раз.
C>Про "реализовывать" здесь речи не идёт — смотри на свой топик.
Уже хорошо. Теперь идем дальше. Утверждение. Программист не ОБЯЗАН знать различие между бинарным деревом и хэш таблицей. Во всяком случае менее обязан, чем знать принципы ООП.

C>Но вот свою хэш-таблицу, например, я писал. Из-за того, что дефолтная глючила (вопрос: почему ключи в hash-таблице в Java должны реализовывать Comparable правильно?)
Вот! И куда ты свою реализацию положил? Где она у тебя в проекте? Скорее всего внедрена в код настолько плотно, что фиг ее выковыряешь. Должен был сделать либу, положить ее на github. Я бы звездочку проекту поставил. Но нет.
Замонолитил в бизнес логику скорее всего, никого выделения в отдельный модуль. Класс небось лежит в папочке helpers и понеслась... Через полгода приходит молодой падава, "улучшает" этот класс. И все! Концов не найдешь.

Здравствуйте, Gattaka, Вы писали:

G>>>Обязаны знать это не значит, что они должны сами реализовывать каждый раз.
C>>Про "реализовывать" здесь речи не идёт — смотри на свой топик.
G>Уже хорошо. Теперь идем дальше. Утверждение. Программист не ОБЯЗАН знать различие между бинарным деревом и хэш таблицей. Во всяком случае менее обязан, чем знать принципы ООП.
Обязан знать, причём куда лучше "принципов ООП".

Из принципов ООП важно знать, что "ООП с наследованием и паттернами" в большинстве случаев нафиг не нужен.

C>>Но вот свою хэш-таблицу, например, я писал. Из-за того, что дефолтная глючила (вопрос: почему ключи в hash-таблице в Java должны реализовывать Comparable правильно?)
G>Вот! И куда ты свою реализацию положил? Где она у тебя в проекте? Скорее всего внедрена в код настолько плотно, что фиг ее выковыряешь. Должен был сделать либу, положить ее на github. Я бы звездочку проекту поставил. Но нет.
Какая разница где лежит код? От положения кода функциональность не меняется. Одним условием приёмки у нас является покрытие кода тестами минимум на 85% (с редкими специальными исключениями), так что пусть кто хочет улучшает.

Конкретно этот код лежит в библиотеке разделяемых типов и используется несколькими командами внутри компании.

Здравствуйте, Cyberax, Вы писали:

G>>Уже хорошо. Теперь идем дальше. Утверждение. Программист не ОБЯЗАН знать различие между бинарным деревом и хэш таблицей. Во всяком случае менее обязан, чем знать принципы ООП.
C>Обязан знать, причём куда лучше "принципов ООП".
Не обязан. Обязан лишь знать, что хеш таблицы быстрее. Все! Остальное — опциальные знания никак не влияющие на результирующие системы. Даже наоборот не знание уменьшает вариатность блеснуть и улучшает качество кода. Потому что самое главное в программировании это сопровождаемость кода, который вы выдаете. Он должен быть простой и понятный только что пришедшему человеку.

C>Какая разница где лежит код? От положения кода функциональность не меняется. Одним условием приёмки у нас является покрытие кода тестами минимум на 85% (с редкими специальными исключениями), так что пусть кто хочет улучшает.
После этого вопроса можно инфаркт схватить. Это самое главное! В программировании. Где что лежит, как называются классы, какова сложность. Самое главное — бороться со сложностью систем. Если у вас все лежит абы где — сложность возрастает. В итоге вы получаете говнокод и говнопроект с которым никто не может разобраться кроме автора. Да и автор со временем забывает где и что он назвал, пложил.

C>Конкретно этот код лежит в библиотеке разделяемых типов и используется несколькими командами внутри компании.
Ну это вроде как норм. Хотя сама постановка вопроса побуждает сомнения.


В любом случае нужно бороться со сложностью. Ваши кастомные реализации эту сложность увеличивают ничего не давая в замен. Ну может пару тактов процессора выигрышь. Оно того не стоит. И зачем лукавить, в глубине души вы надеетесь стать незаменимым экспертом по проекту.

Здравствуйте, Cyberax, Вы писали:

C>Но вот свою хэш-таблицу, например, я писал. Из-за того, что дефолтная глючила (вопрос: почему ключи в hash-таблице в Java должны реализовывать Comparable правильно?)

"To ameliorate impact"... — это?

А в каком JDK глючила?

И почему они продолжают звать "это" хэш-таблицей?

Здравствуйте, Gattaka, Вы писали:

G>>>Уже хорошо. Теперь идем дальше. Утверждение. Программист не ОБЯЗАН знать различие между бинарным деревом и хэш таблицей. Во всяком случае менее обязан, чем знать принципы ООП.
C>>Обязан знать, причём куда лучше "принципов ООП".
G>Не обязан. Обязан лишь знать, что хеш таблицы быстрее. Все!

Нет, потому что если у заметного количества ключей hashcode совпадает — типовая хэш-таблица будет медленнее.

Если нет инкрементального ресайзинга (у >90% реализаций его нет), а важно максимальное время на ключ — хэш-таблица будет медленнее.

Так что если кому-то это "Все!", то он просто некомпетентен.

G> Остальное — опциальные знания никак не влияющие на результирующие системы. Даже наоборот не знание уменьшает вариатность блеснуть и улучшает качество кода. Потому что самое главное в программировании это сопровождаемость кода, который вы выдаете. Он должен быть простой и понятный только что пришедшему человеку.

Не самое главное.
Не должен.

Если мы говорим о программировании в целом, а не сайтоклепании на формочках.

G>После этого вопроса можно инфаркт схватить. Это самое главное! В программировании. Где что лежит, как называются классы, какова сложность. Самое главное — бороться со сложностью систем. Если у вас все лежит абы где — сложность возрастает.

Ваши фантазии про "лежит абы где", повторенные в этой теме уже несколько раз — неадекватны.

G>В любом случае нужно бороться со сложностью. Ваши кастомные реализации эту сложность увеличивают ничего не давая в замен. Ну может пару тактов процессора выигрышь. Оно того не стоит. И зачем лукавить, в глубине души вы надеетесь стать незаменимым экспертом по проекту.

А вы — хозяином галеры с типовыми копеечными гребцами. Что ж, и таким есть работа.