Хм, в google тоже есть люди, которые не любят гуглить? Навскидку отличий от проверенной временем Apache Commons Collections не находится. Кроме разве что com.google.common.collect.Ordering.
Подскажите пожалуйста, кому есть что, — что можно интересного аналитического еще вытащить из из тех данных опроса, которые я получил? Спасибо.
Насколько я помню, книги были сгруппированы по жанрам — можете посчитать популярность жанров (индивидуальную; парную; у наименее знакомых с фантастикой).
99% необъяснимых багов в ExtJS вызваны использованием неподходящего layout'а. Мне сложно поверить, что замена «new types[config.xtype || defaultType](config)» на эквивалентное (см. документацию на Ext.Component) «new Ext. ...» может что-то сломать или починить. Если заменить на неэквивалентное — да, верю :)
Проблемы с метками полей в формах возникают, когда «правильный» контрол кладётся не на FormPanel. Обернули часть полей в какой-нибудь ColumnLayout, а потом забыли добавить внутрь ещё панелей с layout:'form' — и прощайте, надписи. Те самые 99%.
Есть и другой вариант — когда на форму кладут контрол, не относящийся к элементам формы с точки зрения ExtJS (например, ColorPalette. думаю, у разработчиков было похмелье в тот день, когда они приняли такое решение). Однако это не лечится никакими правками в клиентском коде, так что продолжаем считать виновным именно layout.
Стили — ну, тут зависит от того, что это были за стили. Если какие-либо отступы, то это опять-таки проблемы с layout. С другими стилями проблем не припомню.
Попробуйте вспомнить, может быть, помимо конструктора Вы меняли в коде что-то ещё?
Быть коротким, конкретным и лаконичным — это не самоцель. Запрос должен быть похож на нужный результат («чтобы правильно задать вопрос, надо знать половину ответа»), и обычно таки да, конкретные и лаконичные запросы содержат меньше «мусора» и дают хорошие результаты.
Однако если заранее представлять, где (форум, руководство, статья, блог,...) и в каком контексте должно содержаться то, что ищешь — лучше добавить одно-два слово к запросу («проблема», «bug», «tutorial», "-цена" ....). И хотя добавленное слово есть на сотнях миллионов страниц в интернете — сейчас оно поможет сразу отобрать (или убрать) определённую категорию результатов.
Но я Вас уверяю — подобными методами можно получить только тривиальные результат («каждую зиму температура понижается по сравнению с летом»). Если бы всё было так просто, компьютеры, на которых считается погода, не входили бы в Top500 (а японский NEC Earth-Simulator так и вообще держался на первом месте года два).
Спасибо.
Мы не используем onreadystatechange с синхронными запросами и, оказывается, не зря :) Просто проверяем .status и затем получаем .responseText — и всё работает.
«К сожалению, хотя и верно, но срабатывает только в части браузеров, а, например, последний firefox 3.5 просто не выполняет такой запрос.»
А можно пруфлинк? Используем синхронные запросы не один год на всём зоопарке браузеров, и горя не знаем. В FF 3.5 не было замечено никаких проблем (используем для динамической загрузки js, так что невыполнение или асинхронность загрузки заметили бы сразу же).
Если уж Вы так смело сравниваете строки через ==, то не забудьте добавить, что при создании парсера надо выполнить (применительно к SAXParserFactory или XMLReader) операцию setFeature("http://xml.org/sax/features/string-interning", true);
Во-первых, все 4 варианта содержат ошибку, так как не обрабатывают surrogate pairs из Unicode 5.0 (посмотрите для примера код AbstractStringBuilder.reverse()).
Во-вторых, время выполнения ArrayToArray можно уменьшить процентов на 15-20, если отказаться от создания дополнительного массива reverseBytes и переворачивать строку прямо в data.
Дело не в том, нужно это или не нужно (читай: было бы удобно или неудобно), а в том, что такое изменение в Java невозможно — будет потеряна обратная совместимость. А желающие странного всегда могут написать «if (строка1.intern() == строка2.intern())». Если они желают странного очень сильно, то могут автоматизировать этот процесс правкой байт-кода или написанием препроцессора. Или поправить исходники java.
ps я бы с интересом посмотрел на опровержение примера с IdentityHashMap+synchronize.
Выше есть код equals строк, посмотрите — там сначала проверяется равенство ссылок, так что, думаю IdentityHashMap не сломался бы
В огороде бузина, в Киеве дядька. IdentityHashMap не имеет никакого отношения к equals. То, что Вы предлагаете, изменит поведение кода
String s1 = new String(«asdf»);
String s2 = new String(«asdf»);
Map<String, String> m = new IdentityHashMap<String, String>();
m.put(s1, s1);
if (m.containsKey(s2)) {
…
}
поскольку s1.equals(s2) и, по Вашей логике, надо сделать так, чтобы при этом s1==s2, а IdentityHashMap сравнивает ключи только через "==".
Но это разные объекты, и если в одном месте сделать synchronize(s1) {}, а в другом — synchronize(s2) {}, то оба блока будут спокойно выполняться одновременно. До изменения поведения "==" один из них заблокировался бы.
Если же вмешиваться в работу "==" не на уровне синтаксического сахара, а реально менять поведение оператора в run-time (при каждом сравнении Object с Object или со String выяснять реальный тип этих Object), то немедленно вылезут другие глюки.
Ага, в работу + для строк вмешались же — много глюков вылезло?
Изменение поведения "+" — это синтаксический сахар в чистом виде, никаких проверок во время работы не происходит. Компилятор меняет одну строчку на другую. Если тупо менять "==" для строк на equals (кстати, ещё и на null проверять надо), то возникнет потенциальная проблема, о которой я написал в первую очередь — результат ((String)x)==((String)y) не будет совпадать с результатом ((Object)x)==((Object)y).
Пожалуйста, читайте внимательнее.
Например, тем, что если передать две равные по перегруженному "==" строки в другой метод как Object, там повторное сравнение скорее всего даст другой результат. Если же вмешиваться в работу "==" не на уровне синтаксического сахара, а реально менять поведение оператора в run-time (при каждом сравнении Object с Object или со String выяснять реальный тип этих Object), то немедленно вылезут другие глюки.
Например, сломается IdentityHashMap (если Вы не в курсе, то это такой специальный Map, который сравнивает свои ключи именно через равенство ссылок) — два физически разных объекта он будет считать одним, что противоречит его контракту. Достаточно связать с ним какую-нибудь логику по синхронизации, и всё пропало — часть кода синхронизируется по одному объекту, часть — по другому.
floor(($month*4+23)/10) — это формула для вычисления количества лишних дней, получившихся в результате предположения о том, что в каждом месяце 31 день ("$delsum = 365*$year+31*($month-1)+$day;" выше по тексту). Для января и февраля она не работает (выдаёт 2 и 3 дня вместо 0), поэтому там стоит if.
Начните не с картинки, а с простых и коротких файлов — например, файл из 1 байта, файл из 256 одинаковых байт, файл с последователностью символов A,B,C,D,… С такими данными получить ответ на вопрос о заголовках, сжатии и примитивном шифровании должно быть проще, чем с файлами на дцать килобайт.
Туше. Но, простите, но из Ваших слов о nested set (и более ранних) никак не следовало, что в дереве 100000 узлов.
А с самими запросами ничего не делалось. просто вставлялся узел, потом апдейтилось дерево
Сложно что-то предлагать, не зная деталей, но я бы начал с упрощения операции вставки. Никто же не заставляет значения leftBound и rightBound быть строго последовательными — создавайте их с шагом хоть в 10000, тогда вставка и перемещение узлов будут приводить к пересчёту дерева гораздо реже (хотя «балансировку» время от времени выполнять придётся, конечно), новые узлы будут просто укладываться в резерв родительского диапазона.
Кстати, не поделитесь — что это за предметная область такая, что надо постоянно перемещать участки иерархии и добавлять новые кусты больших размеров?
«Потому как при больших (ударение на первую букву) размерах, вставка узла в середину начинает занимать около МИНУТЫ на не самом отстойном железе и внятно сконфигуренной базой.»
Вставка в дерево в ~700 узлов занимала от 2 до 4 секунд до переделки запроса на batch (bulk) update. После такой переделки изменение дерева в ~1300 (это ведь больше 800?) узлов никогда не занимала больше 1-1.2 секунды. Oracle, p4 несколько лет назад (т.е. максимум, что там было — HT, никаких Quad Core). От работы с nested sets на PostgreSQL впечатления аналогичные.
Я затрудняюсь представить себе, что нужно сделать c подобными запросами, чтобы обновление заняло минуту.
Мы используем простую самописную утилиту, которая вносит изменения во все конфиги проекта (Java). В каждом новом проекте от человека, ответственного за сборку, требуется один раз научить эту утилиту новым кофигам (добавить в её собственный конфиг относительные пути к файлам, xpath'ы или regexp'ы), а от разработчика (или того, кто поднимает приложение на сервере) — один раз указать настройки проекта во втором конфиге утилиты.
Дальше конфигурационные файлы проекта поддерживаются в актуальном для инстанса состоянии автоматически.
Для xml-конфигов можно также воспользоваться включением файла (<!ENTITY myConfig SYSTEM ...>, <root>&myConfig;</root>). Файл с индивидуальными для окружения данными (включаемой частью) — не коммитить. Но это уже близко к понятию извращения.
Насколько я помню, книги были сгруппированы по жанрам — можете посчитать популярность жанров (индивидуальную; парную; у наименее знакомых с фантастикой).
Проблемы с метками полей в формах возникают, когда «правильный» контрол кладётся не на FormPanel. Обернули часть полей в какой-нибудь ColumnLayout, а потом забыли добавить внутрь ещё панелей с layout:'form' — и прощайте, надписи. Те самые 99%.
Есть и другой вариант — когда на форму кладут контрол, не относящийся к элементам формы с точки зрения ExtJS (например, ColorPalette. думаю, у разработчиков было похмелье в тот день, когда они приняли такое решение). Однако это не лечится никакими правками в клиентском коде, так что продолжаем считать виновным именно layout.
Стили — ну, тут зависит от того, что это были за стили. Если какие-либо отступы, то это опять-таки проблемы с layout. С другими стилями проблем не припомню.
Попробуйте вспомнить, может быть, помимо конструктора Вы меняли в коде что-то ещё?
Однако если заранее представлять, где (форум, руководство, статья, блог,...) и в каком контексте должно содержаться то, что ищешь — лучше добавить одно-два слово к запросу («проблема», «bug», «tutorial», "-цена" ....). И хотя добавленное слово есть на сотнях миллионов страниц в интернете — сейчас оно поможет сразу отобрать (или убрать) определённую категорию результатов.
Пару лет назад данные лежали просто в виде .txt.zip, было гораздо удобнее. Вот ещё полезная ссылка: www.tutiempo.net/en/Climate/
Но я Вас уверяю — подобными методами можно получить только тривиальные результат («каждую зиму температура понижается по сравнению с летом»). Если бы всё было так просто, компьютеры, на которых считается погода, не входили бы в Top500 (а японский NEC Earth-Simulator так и вообще держался на первом месте года два).
Мы не используем onreadystatechange с синхронными запросами и, оказывается, не зря :) Просто проверяем .status и затем получаем .responseText — и всё работает.
А можно пруфлинк? Используем синхронные запросы не один год на всём зоопарке браузеров, и горя не знаем. В FF 3.5 не было замечено никаких проблем (используем для динамической загрузки js, так что невыполнение или асинхронность загрузки заметили бы сразу же).
Во-вторых, время выполнения ArrayToArray можно уменьшить процентов на 15-20, если отказаться от создания дополнительного массива reverseBytes и переворачивать строку прямо в data.
java -Dmy_daemon=true …
ps ax | grep my_daemon
ps я бы с интересом посмотрел на опровержение примера с IdentityHashMap+synchronize.
поскольку s1.equals(s2) и, по Вашей логике, надо сделать так, чтобы при этом s1==s2, а IdentityHashMap сравнивает ключи только через "==".
Но это разные объекты, и если в одном месте сделать synchronize(s1) {}, а в другом — synchronize(s2) {}, то оба блока будут спокойно выполняться одновременно. До изменения поведения "==" один из них заблокировался бы.
Изменение поведения "+" — это синтаксический сахар в чистом виде, никаких проверок во время работы не происходит. Компилятор меняет одну строчку на другую. Если тупо менять "==" для строк на equals (кстати, ещё и на null проверять надо), то возникнет потенциальная проблема, о которой я написал в первую очередь — результат ((String)x)==((String)y) не будет совпадать с результатом ((Object)x)==((Object)y).
Пожалуйста, читайте внимательнее.
Например, сломается IdentityHashMap (если Вы не в курсе, то это такой специальный Map, который сравнивает свои ключи именно через равенство ссылок) — два физически разных объекта он будет считать одним, что противоречит его контракту. Достаточно связать с ним какую-нибудь логику по синхронизации, и всё пропало — часть кода синхронизируется по одному объекту, часть — по другому.
А с самими запросами ничего не делалось. просто вставлялся узел, потом апдейтилось дерево
Сложно что-то предлагать, не зная деталей, но я бы начал с упрощения операции вставки. Никто же не заставляет значения leftBound и rightBound быть строго последовательными — создавайте их с шагом хоть в 10000, тогда вставка и перемещение узлов будут приводить к пересчёту дерева гораздо реже (хотя «балансировку» время от времени выполнять придётся, конечно), новые узлы будут просто укладываться в резерв родительского диапазона.
Кстати, не поделитесь — что это за предметная область такая, что надо постоянно перемещать участки иерархии и добавлять новые кусты больших размеров?
Вставка в дерево в ~700 узлов занимала от 2 до 4 секунд до переделки запроса на batch (bulk) update. После такой переделки изменение дерева в ~1300 (это ведь больше 800?) узлов никогда не занимала больше 1-1.2 секунды. Oracle, p4 несколько лет назад (т.е. максимум, что там было — HT, никаких Quad Core). От работы с nested sets на PostgreSQL впечатления аналогичные.
Я затрудняюсь представить себе, что нужно сделать c подобными запросами, чтобы обновление заняло минуту.
Дальше конфигурационные файлы проекта поддерживаются в актуальном для инстанса состоянии автоматически.
Для xml-конфигов можно также воспользоваться включением файла (<!ENTITY myConfig SYSTEM ...>, <root>&myConfig;</root>). Файл с индивидуальными для окружения данными (включаемой частью) — не коммитить. Но это уже близко к понятию извращения.