Java: ArrayList vs LinkedList

Нужно было прожить жизнь и состариться, чтобы лишь перед смертью узнать страшную тайну.

LinkedList почти всегда медленнее.
Кроме одного случая -- когда требуются многократные удаления элементов из середины (вставки в середину) контейнера.

Шокирующие подробности здесь, здесь и здесь.

Про 22-й Emacs

Намучившись с производительностью CYGWIN, решил поставить Emacs, специально собранный под Win32.

21-й работает,
22-й запускается и виснет (кроме случаев, когда запущен в консоли с ключом -nw).

Естественный вопрос: что за ***ня?!

Оказывается, в PATH присутствовал /usr/X11R6/bin от CYGWIN,
а Emacs, собака, пытался загрузить оттуда libXpm.dll.

Резюме: значения PATH под Windows и под CYGWIN должны быть разными;
в идеальном случае -- не пересекаться.

Озаботился вопросом русификации X11 под Cygwin

Оказалось, mkfontscale находит в TTF/OTF-шрифтах (Microsoft, Monotype, etc.) символы для кодовой страницы KOI8-R, но никак не для необходимой CP1251.

В результате был написан следующий сценарий, генерирующий "правильный" файл fonts.scale
(файл fonts.dir создаётся на основании fonts.scale утилитой mkfontdir):
Collapse )

Сам файл доступен здесь.
Вопросы и замечания, разумеется, приветствуются.

Впрочем, некоторые русские получше индусов

Рассказал один знакомый программист.


Есть проект с одной библиотекой, которая присылает данные в формате MARC (стандартные библиографические описания), и эти данные нужно анализировать и складывать в базу данных.

Собственно, это лишь маленькая подзадача одной большой задачи и потому была поручена подмастерью рассказчика. Подмастерье -- не по годам шустрый студент не самого первого (впрочем, и не самого последнего) курса одного московского вуза.

Для определённости, будем называть вуз "МФТИ" (из песни слова не выкинешь).
Для определённости же, будем называть студента "Аникей" (есть такое русское имя).

Любые совпадения, разумеется, случайны.

Библиотека утверждала, что присылает данные в кодировке UTF-8.
(Сами файлы бинарные, но вот нек-рые внутренние поля там -- текстовые, причём в определённой кодировке.)

Аникей, впрочем, оказался парень не промах и решил проверить, правду ли говорит библиотека. Оказалось -- нишиша. Никакая не UTF-8, а старая добрая досовская CP866. О чём было радостно сообщено старшему программисту.

Аникею поверили, с библиотекой же был проведён серьёзный разговор, и первая часть проекта была успешно сдана.

Впоследствии старший программист решил собственноручно проверить, что же написал Аникей. От ужаса седые волосы зашевелились на голове старика.

Данные читались в кодировке CP866:

final MarcReader reader = new MarcStreamReader(..., "CP866")
а затем каждая считанная строка дополнительно преобразовывалась из CP866 в UTF-8:

final String s0 = ...;
final String s1 = new String(s0.getBytes("CP866"), "UTF-8");

CP866 в этом примере можно заменить на что угодно -- пример будет работать. Так же корректно -- и так же неэффективно. Почему было сразу не читать в UTF-8 (и вообще избавиться от преобразования строк) -- тайна за семью печатями.


Рассказ завершился весьма оптимистично: "С паршивой овцы -- хоть шерсти клок".


Снова индусофобия, только на этот раз не у меня.

Индусы

Сотрудники одной зарубежной компании, мирового лидера в своей области
(для определённости, назовём её "Контора "Бабочка", сайт
компании http://www.kontora-babochka.com),
создав на платформе Java продукт (для определённости, назовём его
RogaIKopyta™, сайт
проекта http://www.roga-i-kopyta.com),
решили создать к своему продукту Java API.

Получилось у них, мягко говоря, херово.


Ну зачем, скажите, обявлять в абстрактном классе X метод clone()
абстрактным лишь для того, чтобы обязать клиентов говноAPI (и
конкретных наследников класса X) явно
определять политику клонирования объектов?!

Интерфейс java.lang.Cloneable
уже что, отменили?