Это радует.
Что касается правильности работы нового jquery ui, я поторопился. Откройте ссылку в хроме или IE, и там — январь 2014. В правильных браузерах (да и в бумажном календаре) январь 2014 должен начинаться в среду. Меня сбило с толку, что декабрь 2013 он показывает правильно )

Да, это действительно оно. Только автор заглядывал в будущее, а я в прошлое :). Тем не менее, приведенный патч

return new Date(year, month+1, 0).getDate();

поможет и в будущем (как видно по картинке в той статье, это c большой вероятностью тоже календарь из jquery ui)

Кстати, из приведенной ссылки на статью, да и из документации следует, что в некоторых случаях для записи на SD рут необязателен.
Например, если хотим, чтобы кеш яндекс карт сохранялся на SD, нужно в дополнительных настройках указать каталог, в котором данное приложение будет иметь полные права:

/storage/extSdCard/Android/data/ru.yandex.yandexmaps

для карт 2ГИС:

/storage/extSdCard/Android/data/ru.dublgis.dgismobile

К сожалению, не все приложения имеют такую возможность, например, для яндекс навигатора я не нашел способа смены каталога. Будем надеяться, что разработчики прочитают документацию и учтут разрешения на каталоги в будущих версиях, и «совместимо» с Android 4.4 можно будет писать без кавычек

На самом деле и теорема и доказательство оперируют с предельными значениями (limit), а в различных источниках формулировку упрощают, и в результате находят такие противоречия :)
А противоречия на самом деле нет: в пределе — равенство, но это не значит, что оно достигается, то есть в практическом применении можно говорить только о строгом неравенстве.

Сервис покетбуков конечно отпугивает.
Тоже раздавил экран, на pocketbook touch. Замена в авторизованном центре — 4000. Плюнул и купил за те же деньги paperwhite (первый, нового на тот момент еще не было), и нисколько не жалею.
Джейбрейк, CoolReader — и никаких проблем с fb2. Теперь жду освобождения второго paperwhite )

Очень похоже на алгоритмы библиотеки padeg, про которую я писал тут в прошлом году (а это тесты: test-rlab.rhcloud.com/). Только там все правила в коде, а тут — в «таблицах», и это очень хорошо: такую библиотеку проще портировать. Если говорить о портируемости, то не мешало бы еще бы поработать над форматом таблиц, какой-нибудь общеупотребимый формат, тот же xml или json.
А чего пока нет — это склонения китайских ФИО, плюс склонения должностей и подразделений.
Авторы, примете пожертвования в виде исходных кодов?

Процедура, знакомая многим владельцам XBOX 360 первых версий. Только там для прогрева использовалась не духовка, а сам видео чип ). Уж и не знаю, какой из методов более варварский.
К сожалению, решение временное, ибо оно отпаивается снова. Желательно сделать реболл, хотя после таких экспериментов ничего гарантировать уже нельзя.

Хороший девайс, а вот идея сим-лока — плохая. Ведь это идеальное устройство для дальних поездок, а тут ездить можно только в зоне действия конкретного оператора. Или 4900 — это субсидированная стоимость?

На самом деле все это писалось более 10 лет назад, а последний раз код я видел более 5 лет назад, так что только по памяти.
Идея такая: доступ к объектам БД осуществлялся либо через произвольный SQL, либо с помощью «словарных» функций (DAO). При произвольном SQL ничего не кешировалось, а вот если это словарный доступ, и объект имел признак кеширования, то результат запроса добавлялся в кеш.
Кеш представлял собой карту

ключ записи <-> запись

далее, если необходимо было получить такой объект по ключу, то сначала проверяли в кеше, потом обращались в базу.
Для каждого объекта из словаря велся свой кеш (суперкарта вида

название_объекта <-> кеш этого объекта

). Суперкарта имела ограниченный объем, если к объекту долго не обращались, его кеш удалялся из суперкарты путем замещения.
Ну и в добавок различные сервисные функции, типа
— принудительно прочитать таблицу в кеш
— очистить кеш таблицы
— очистить весь кеш
— начать и закончить кеширование принудительно (аналог сессии hibernate)
Писали по наитию, когда перешли на java, увидели много знакомого :)
Естественно, подход не универсальный, и есть риски. Но для работы со статическими данными (различные справочники, lookup-поля) — самое оно.

Мне нравится MVC подход и очень хотелось разделить код логики с кодом модели.

На самом деле модель это данные и бизнес-логика. Хотя, довольно часто случается встречать такое понимание, что модель это бездумный persistence слой, а вся логика — в контроллере. В данном же случае скорее речь идет о паттерне DAO.
А конкретно по реализации: действительно RTTI это копейки по сравнению с сетевым обменом (с базой данных), так что опасаться за быстродествие действительно не стоит.
Я когда-то тоже делал что-то подобное, только там DAO слой реализовали с помощью нескольких словарных таблиц (они использовались для генерации SQL, и много для чего еще). Плюс был признак кеширования — объекты с таким признаком сохранялись некоторое время в кеше и при последующем обращении уже не извлекались из базы. Вот это действительно позволило увеличить быстродействие на порядки. Кстати, способность к кешированию есть во многих современных ORM.
По коду: в Delphi нет сборщика мусора, так что надо повнимательней. Если создал какой — то объект, то в конце следует обязательно удалить, лучше оформить это в try-finally:

someObject:=TSomeObject.Create();
try {
  ..
} finally {
  someObject.Destroy();
}

Сейчас в коде есть явные утечки

Привлекла первая фотография. Неужели инопланетянин?

Судя по тому, что плюсов и минусов к данному комментарию примерно поровну, точно так же и 50% людей не парятся насчет названия и называют Javascript яваскриптом :). Лично мне в русской речи проще назвать Javascript яваскриптом, ну а в английской — так, как положено в английском языке. Самое главное, я уверен, что как бы не назвал скрипт в разговоре по-русски, меня поймут, даже ортодоксы.
А вот Jazz язью вряд ли кто назовет, разве что спьяну.
Другое дело, интересно, как выходят из положения носители языков, где J соответствует звуку Й, например эстонцы?

Последний вариант из статьи — идеальный. Автоматизировать контору, работая в ней. Особенно, если основной доход конторы не связан с производством софта. Действительно, это сплошные стартапы, и большинство обречены на успех. Можно совершенствовать код до бесконечности и постоянно внедрять новые фишки, ведь, фактически, вы и заказчик и исполнитель.
Но в таких тепличных условиях легко потерять хватку

Подписываюсь под каждым словом.
Сам, правда, полностью от производства не отрывался, но полгода совмещения хватило. Возможно, все было бы не так плохо, если бы не было интереса к IT, и было бы все равно чем управлять, как указанным менеджерам.
Сейчас действительно время «незамутненных» управленцев, возьмите хоть наше правительство, кого там министрами назначают. То же и в любой компании можно встретить.

Да, это 2 большие разницы:
— сделать за 2 дня (пусть даже по 16 часов), а с заказчика получить оплату за 48 часов
— работать 2 суток без сна (48 часов), а оплату получить за 2 дня
Не огорчайте нас вторым вариантом.
Конечно, если вы не в одном лице и заказчик и исполнитель

Так и есть. С иностранными фамилиями ошибки возможны, и для этого имеется словарь исключений. Фамилию Дюма библиотека склоняет так же, как и фамилию Кострома, и чтобы объяснить, что в первом случае имеем дело с иностранной фамилией, без словаря, скорее всего, уже не обойтись.
А практически, надо смотреть на условия эксплуатации, чтобы понять, насколько приемлем уровень ошибок. В моем случае система, в которой применялась библиотека padeg, имеет дело с гражданами РФ, и за 5 лет эксплуатации ни одного французской фамилией не попалось.
Кроме того, пользователям была предоставлена возможность внесения исправлений: в базе данных заведено 6 полей (для каждого падежа), и после автоматического вычисления ФИО пользователь может исправить ошибки вручную. В дальнейшем, при подготовке документов, padeg уже не используется, а берутся значения, сохраненные в базе данных.
Возможно также, в оригинальной padeg.dll указанные ошибки исправлены, java библиотека соответствует padeg.dll 5-летней давности

100% не уверен, но по-моему, для C# сгодится оригинальная padeg.dll

Да, я как-то не задумывался об обратной совместимости байт-кода, мажорная версия то одна и та же. В таком случае поздравляю: библиотекой можно пользоваться начиная с j2se 1.2.
А вот насчет volatile переменных: скомпилированные в байт-код они будет правильно работать в версиях < 1.5?

Просто сравните за какую сумму дарят в других местах