По сути весь hashCode() можно написать как return key.hashCode(); если всё же считать, что key != null (а именно так на мой взгляд и следует считать, и мб кидать из конструктора NPE или IllegalArgument).
public V get(K key)
{
return globalMap.get(new Key(key, default_timeout));
}
Зачем здесь параметр default_timeout передавать в конструктор? Создайте для Key конструктор с одним аргументом key и используйте его. Всё равно же сравнения не по таймауту делаются. И вообще как-то на каждый get по объекту создавать — не самая лучшая идея…
Дублирование кода в методах put, setAll и addAll.
Для методов
public void setAll(Map<K, V> map) ...
public void setAll(Map<K, V> map, long timeout) ...
не нужно писать один и тот же код в реализации. Просто из первого метода вызывайте второй — иначе зачем вам жуткий копипаст? Для put и addAll аналогично.
Неправда ваша. Закэшированная БД — правильное решение для скорости, когда не нужно напрягать 1С на каждый чих («показать список .....»).
Веб-сервисы — правильное решение для активной бизнес-логики.
Преимущество веб-сервисов в удобстве (вы можете вызывать функции 1С, и обратно — 1С может вызывать ваши функции) и кросс-платформенности. Сайт, разрабатываемый мной по долгу службы, именно так и работает. И других вариантов нет, если нужны активные действия 1С при некоторых действиях на сайте.
Не подумайте что я фанат веб-сервисов — они мне не очень нравятся, от них веет «энтерпрайзностью», тяжёлостью, XML, SOAP и прочим :( В современном мире это далеко не мейнстрим для сайтов.
Далее, я немного тестировал реализацию веб-сервисов 1С, опять же по работе, — на практически обычной машине что-то около 70-100 вызовов в секунду, при 4+ потоках. 100 — для совсем быстрого метода (аля пинг), 70 — для немного более нагруженного.
Но, самое главное не в этом.
Самое главное в том, что в вашем случае можно и нужно заниматься и еженощной выгрузкой.
Единственное что — у вас выгруженная база получается read-only?
В web-интерфейсе нет никакой активной логики получается?
Про «Open Type» — в IDEA есть давным-давно, и работает получше, на мой вкус. То есть если матчинга мало — она попробует downcase-нуть какую-нибудь из букв и заматчить. Это будет верно в том случае, если вы опечатались и набрали 2 заглавных буквы подряд.
Еще, я бы добавил, что в IDEA на порядок лучше поиск-замена и всё такое, потому что хоткеи гораздо удобнее и лучше продуманы. То, что в Eclipse требует 3-4 кликов, в IDEA делается за один-два. Это легко заметить, если показать эклипсоцвам как работает C-f и C-F в идее :)
И только мне название "обратная разработка" кажется издевательством над читателем? (да, я в курсе, что так reverse engineering переведена на википедии).
Последнее время на Хабре пошла какая-то волна насильственных переводов терминов.
Подождите, почему бы не использовать out-of-source билд и имя каталога привязывать например к бранчу, как-нибудь так?
То есть /build/<branch_name> — папка для сборки бранча?..
Системным диспетчером задач — возможно (и то, если понимать что к чему — то по его данным можно делать выводы правильно), но вот насчет хромовского — не согласен.
Простите что влезаю, но по-моему, они решают одну и ту же задачу — быстрое и масштабируемое (с количеством сокетов в отличие от select/poll) уведомление приложения о сетевых событиях. В чем же не аналогичность?
Объясняю. Предлагаю вам конкретную, достаточно эффективную реализацию.
Как только хэш-таблица заполняется более, чем на 80%, то она расширяется.
Как только заполняется менее, чем на 40% — сжимается.
Среди всех способов разрешения коллизий наиболее эффективный — квадратичное пробирование (метод квадратичных проб, Quadratic collision resolution).
Поэтому используем именно его, это даст лучшие оценки для количества сравнений элементов между собой (точные оценки можно найти здесь).
Еще раз повторюсь.
Во-первых, данное количество сравнений элементов при коллизиях пренебрежимо мало по сравнению с количеством элементов в хэш-таблице (особенно в большой), отсюда и возникает оценка O(1) (на бесконечности).
И два, не надо экономить на памяти, она очень дешёвая. Делайте большие хэш-таблицы, не бойтесь. Сейчас все реализации должны хорошо работать с памятью :)
В том-то и дело, что оценка O(1) — точна и верна, так как она — асимптотическая. В эту оценку входит то, что иногда операции могут выполнятся больше одного раза.
Более строго: в хорошей хэш-таблице оценка количества элементов с совпадающим хэшем пусть и не точно единица, но всё же пренебрежимо мала по сравнению с количеством элемментов, и также мало отличается от единицы. Случаи вырождения хэша в линейный список не рассматриваем :)
Несколько лет назад они окончательно монетизировались, в открытую предлагая всевозможные игровые преимущества (чОрную материю, особые бонусы и т.п.) за деньги. Таки да, теперь там полно читеров.
Ну, например, в играх типа оГейм
> И интерфейс игры приводили к нормальному (консольному, в т.ч.) виду — люди могли с телефонов по ssh примитивные действия делать.
— это самый ужасный чит, какой можно придумать.
return key.hashCode();если всё же считать, что key != null (а именно так на мой взгляд и следует считать, и мб кидать из конструктора NPE или IllegalArgument).public V get(K key)
{
return globalMap.get(new Key(key, default_timeout));
}
Зачем здесь параметр default_timeout передавать в конструктор? Создайте для Key конструктор с одним аргументом key и используйте его. Всё равно же сравнения не по таймауту делаются. И вообще как-то на каждый get по объекту создавать — не самая лучшая идея…
Дублирование кода в методах put, setAll и addAll.
Для методов
public void setAll(Map<K, V> map) ...
public void setAll(Map<K, V> map, long timeout) ...
не нужно писать один и тот же код в реализации. Просто из первого метода вызывайте второй — иначе зачем вам жуткий копипаст? Для put и addAll аналогично.
Веб-сервисы — правильное решение для активной бизнес-логики.
Тут всё более чем просто.
Не подумайте что я фанат веб-сервисов — они мне не очень нравятся, от них веет «энтерпрайзностью», тяжёлостью, XML, SOAP и прочим :( В современном мире это далеко не мейнстрим для сайтов.
Далее, я немного тестировал реализацию веб-сервисов 1С, опять же по работе, — на практически обычной машине что-то около 70-100 вызовов в секунду, при 4+ потоках. 100 — для совсем быстрого метода (аля пинг), 70 — для немного более нагруженного.
Но, самое главное не в этом.
Самое главное в том, что в вашем случае можно и нужно заниматься и еженощной выгрузкой.
Единственное что — у вас выгруженная база получается read-only?
В web-интерфейсе нет никакой активной логики получается?
Еще, я бы добавил, что в IDEA на порядок лучше поиск-замена и всё такое, потому что хоткеи гораздо удобнее и лучше продуманы. То, что в Eclipse требует 3-4 кликов, в IDEA делается за один-два. Это легко заметить, если показать эклипсоцвам как работает C-f и C-F в идее :)
Последнее время на Хабре пошла какая-то волна насильственных переводов терминов.
То есть /build/<branch_name> — папка для сборки бранча?..
Как только хэш-таблица заполняется более, чем на 80%, то она расширяется.
Как только заполняется менее, чем на 40% — сжимается.
Среди всех способов разрешения коллизий наиболее эффективный — квадратичное пробирование (метод квадратичных проб, Quadratic collision resolution).
Поэтому используем именно его, это даст лучшие оценки для количества сравнений элементов между собой (точные оценки можно найти здесь).
Еще раз повторюсь.
Во-первых, данное количество сравнений элементов при коллизиях пренебрежимо мало по сравнению с количеством элементов в хэш-таблице (особенно в большой), отсюда и возникает оценка O(1) (на бесконечности).
И два, не надо экономить на памяти, она очень дешёвая. Делайте большие хэш-таблицы, не бойтесь. Сейчас все реализации должны хорошо работать с памятью :)
Более строго: в хорошей хэш-таблице оценка количества элементов с совпадающим хэшем пусть и не точно единица, но всё же пренебрежимо мала по сравнению с количеством элемментов, и также мало отличается от единицы. Случаи вырождения хэша в линейный список не рассматриваем :)
Тут с Вами все понятно.
> Для ikariam они выпустили android-версию
Несколько лет назад они окончательно монетизировались, в открытую предлагая всевозможные игровые преимущества (чОрную материю, особые бонусы и т.п.) за деньги. Таки да, теперь там полно читеров.
> И интерфейс игры приводили к нормальному (консольному, в т.ч.) виду — люди могли с телефонов по ssh примитивные действия делать.
— это самый ужасный чит, какой можно придумать.