ru_java, posts by tag: tricky - LiveJournal (original) (raw)
Если кто (не) глубоко копался в создании ГУИ на Vaadin, может ли сказать, почему так часто при "тонкой" настройке дают советы по введению новых "аатрибутов" в соотв. CSS файл??
Например RichTextArea имеется. И чтобы настроить ее - убрать/видоизменить панель инструментов - изменяют css
( Читать дальше.....Collapse )
Почему бы метОды не ввести аля setToolBarVisibility(boolean value). С.харило запрограммировать, проблемы с виджетами или это специфика CSS???
August 20th, 2011
Я понимаю, почему 128 - не очень удачная база для вычисления хэша. И я понимаю, почему надо выбрать что-то поменьше, даже если вероятность коллизий увеличится. Но почему во всех учебниках используют 37?! Я не могу найти этому никакого логического объяснения. Кто-нибудь знает, в чем собака порылась?
May 6th, 2011
Вопрос не совсем про java, но в контексте java приложения. Грубо говоря хранится лог, постоянно добавляются
новые записи, удаляются старые, редко делаются запросы найти небольшую группу данных по дате и 1-2 признакам.
Сейчас все лежит в MySql.
Неожиданно стало известно что объем данных станет 10 терабайт. 100 миллионов записей каждый день.
В чем такое сейчас принято хранить? У кого есть практический опыт?
upd:
Требуется максимально легкое (и дешевое) опенсорс решение. Есть уже несколько предложений in-memory баз.
Столько памяти конечно не будет и не надо. Данные не меняются. Только удаляются старые и добавляются новые.
И агрегация к сожалению невозможна. Время запроса выборки нужно до 5 минут,
но это не должно быть проблемой, так как в запросе всегда есть дата.
Java + SSL(pkcs12) - небольшое HowTo
April 21st, 2010
Хочу поделиться с обществом моим How-To по подсоединению через Java ко всяким HTTPS-секьюрным серверам. Итак, имеем:Java и SSL!
Не так то просто наладить взаимодействие этой сладкой парочки. В порыве гугления я обнаружил некоторые типовые рецепты работы:
http://www.agentbob.info/agentbob/79-AB.html
http://www.sslshopper.com/article-most-common-openssl-commands.html
Но соеденить их воедино достаточно проблематично, ибо не ясна логика.
( читать многа английских букавCollapse )
То же самое, но в моём дневничке можно почитать тут.
November 17th, 2006
По мотивам http://community.livejournal.com/ru_java/342205.html
Не могу удержаться :)
Что неверно в следующем коде?
int low = произвольные 32 бита;
int high = произвольные 32 бита;
long result = ((long)low) | (((long)high) << 32);Предполагается, что result будет 64-битовым словом, объединяющем в себе биты low (младшие 32 бита) и high (старшие 32 бита). К стыду своему, должен сознаться, что вначале я написал именно так - несмотря на 10 лет программирования в Java и других C-подобных языках.
Чем не вопрос для собеседования? :)
Кстати, даже сейчас чаще всего я ошибаюсь именно в логике работы с целыми числами. И эти ошибки - самые неприятные, так как, как правило, долго остаются незамеченными. Например, приведенный код отлично будет работать, если тестовые значения low и high оба заполнены либо нулевыми, либо единичными битами, либо даже очень многими "взятыми наугад" значениями.