_winnie

Там, где в Java люди ради mock-тестирования пишут свой "интерфейс получения случайных чисел", свой "интерфейс файловой системы", "свой интерфейс получения времени" и "интерфейс вызова Sleep()" — программисты на питон просто заменяют в стандартном модуле стандартные функции файловой системы, случайных чисел или даты. В крайнем случае можно даже модуль целиком заменить ( sys.modules["time"] = my_object ), или переопределить функцию импорта модулей.

Сегодня порадовался такому диалогу:

Q: чуваки, я для тестирования переопределил стандартные дату и время, но в стороннем модуле стоит проверка isinstance(obj, datetime)! Что делать?

A: Не тормози, просто переопредели isinstance ( __builtin__.isinstance ) на свою функцию

Коллеги подарили конструктор, его сборка мне что-то напомнила. Я сейчас потратил около 20 минут и уже смог надеть шестерёнку на моторчик.

Чтобы открыть отсек для батарейки, нужна крестовая отвертка (защита от детей?). Батарейки не прилагаются.
Чтобы прикрепить шестерёнку к валу мотору, нужно зацепить его цеплялкой, которая соединяет этот вал и шестерёнку, не давая ей прокручиваться. Цеплялка цепляется за шестерёнку пятью выступами, которые расположены в вершинах шестигольника (да, пятью! да, шестиугольника!). Плоскость симметрии дырки для вала дополнительно повернута на 1/12 оборота.

Цеплялка фиксирует вращение относительно вала, но не продольное движение. Поэтому к цеплялке ещё есть держалка, которая прикрепляет цеплялку к валу, не давая ей соскользнуть. По изображению держалки в мануале непонятно что это за деталь, зато обозначен её четырёхзначный ID, 1128, по которому можно найти её изображение в другом ракурсе и понять, что это за деталь.

В конце получится вот такая штука:


Ах да, самое ужасное, что такое всё равно интересно собирать :)

Обычно решение проблемы создает некоторые новые проблемы. Мы их начинаем решать. Ряд в конце концов сходится. В случае Java он сходится очень медленно, как геометрическая прогрессия с фактором 0.95. Каждое новое решение порождает новые проблемы, для которых нужен новый инструмент со своими проблемами. Spring, Maven, Hibernate ... веб-сервисы для репозиториев мавена... IDE с рефакторингом, мерж рефакторингов в репозитории, вакансии для новых Java-программистов которые пишут ещё больше Java-кода... Тесты для тестирования кода решающего проблемы... Билд-фермы для паралельного запуска тестов, что бы за пару часов хотя бы тесты проворачивались...

Перманентно висящие демоны из-за долгого старта JVM... Динамическая перезагрузка jar демонов...

Перенос логики в XML-файлы... Такого же объема или больше, как java-код для написания этой логики.

Есть всякие clojure и scala, но из-за вот этой вот культуры обмазывания слоями решения проблем от решения проблем не хочется даже близко подходить к тому, что почему-то работает на платформе JVM.

Про java я уже бухтел, про её int getVal() { return val; }
Сейчас буду бухтеть про С++:

static const std::size_t size = 256;

maven теперь остался в том месте, где он хорошо справляется - разрешать зависимости библиотек, скачивать их из интернета, и исходники к ним качать.
К сожалению, даже тут он справляется на "хорошо", а не на "отлично". На 4 с плюсом, но не на 5.

Во-первых, когда при diamond-dependency-hell нужны библиотеки разных версий - он тупо выбирает самую большую, из-за этого возникают никогда не тестировавшиеся комбинации библиотек. Ну это ладно, похоже для java это неизбежное зло.

Во-вторых, мейтейнеры библиотек часто в библиотеках с разными именами используют одинаковые классы. Например, asm-3.1.jar в зависимостях hibernate и asm-all-3.3.1.jar.

В проекте используется три XML-парсера (org.xml.sax), лежащие в трёх следующих файлах, и выбирается рандомный из них. А они выдают разный порядок атрибутов из xml-тега, мля.
/usr/lib/jvm/java-6-sun-1.6.0.24/jre/lib/rt.jar
vendor/jars/xml-apis-1.3.04.jar
vendor/jars/gnujaxp-1.0.0.jar
( Read more...Collapse )

Хибернейт создан для того, что бы мавен смог разрулить его зависимости, а мавен сделан для того, что бы разрулить зависимости хибернейта.

Хибернейт насмехается над старой системой настройки либ "укажем для либы список её jar-ников", похлопывая себя по большому теплому пузу.

иллюстрация зависимостей jar-ников общих для xalan/hibernate/commons-configuration/slf4j-log4j. В прямоугольники сгруппированны jar-ники, факторизованные по набору модулей проекта, их использующих.
( иллюстрация зависимостей jarCollapse )

Я предпочел бы что бы HashSet и LinkedHashSet в Java назывались бы UnorderedHashSet и HashSet

HashSet -> UnorderedHashSet
LinkedHashSet -> HashSet

У первого при итерации обход элементов не определён, иногда рандомен от запуска к запуску программы, при добавлении элемента его переколбашивает. У второго порядок обхода такой же, в котором в него клали элементы.

На двух проектах где я был, это дефолтное именование таблиц приводило к потере времени из-за недетерминированного порядка обхода Set. ИМХО, человеческого времени из-за ребилдов и кофликтов в svn было потеряно больше, чем выигрыш от сэкономленных килобайтов. А пользователи потратили больше времени на скачку патчей для для игры из-за диффов или из-за багов на сервере. А чуваки которые оптимизируют память - они вообще с каждым битом бегают, думая как покруче упаковать в byte[], а не только выбирают правильные контейнеры. А тем кто не думает о выборе контейнера - лучше давать более безопасную реализацию с детерминированным обходом.

На всякий случай об этом трюке, который делает обход хеш-таблицах детерминированным (и проще в реализации): Пусть хеш-таблица реализована как массив, элементы которого - связные указателями списки элементов ("корзины"). Можно дополнительно "перевязать" указателями эти элементы корзин во второй связный список, общий на всю хеш-таблицу. И для итерации использовать именно этот список.

В питоне до Python 2.7 были только словари и множества с недетерминированным порядка обхода. В python 2.7 появился collections.OrderedDict. Имхо, лучше бы сделали что бы в хеш-таблицах всегда был определенный порядок обхода, что бы не было как здесь - http://avva.livejournal.com/2323823.html

PS. Есть ещё TreeSet (TreeMap), априори нельзя сказать какой лучше в смысле стабильности по сравнению с LinkedHashSet (LinkedHashMap). Сортированный TreeSet может "абсорбировать" дамаг от того, что откуда-то вывод уже пришёл в недетерминированном порядке ( напр. ответ от компьютеров кластера ). Но зато при кодогенрации расставляет поля в алфавитном порядке, который иногда противоестествен (типа (old_value, new_value) превращается в (new_value, old_value)).

пиздец в виде java class path длинной в много-много тысяч символов (ну принято в java так, что бы всё было максимально нечитабельным), наталкивается на пиздец с ограничениями в коммандной строке в команде ps, которая не может показать командную строку длиннее чем 4096 символов. Не смотря на наличие 8 гигабайт оперативки на компьютере. Я вот сейчас сижу, и не могу посмотреть какие именно параметры у процесса унутре teamcity.
Типичный пример перемножения двух пиздецов, каждый из которых неприятен средне-мелко, а вот когда встречаются - то их общий ребёнок не дышит.

Помимо того что maven при стирании *.java не стирает *.class, он ещё и не пересобирает зависимый *.class если в *.class другого модуля изменилась сигнатура вызываемого метода. Эм, получается что надёжная не-clean-сборка вообще в принципе невозможна.

Сегодня прочитал строку из файла. Взял библитеку commons-io (благодаря maven она скачалась сама, никакого гемороя!), добавил в обще-проектный файл используемую версию библиотеки (1.4), добавил зависимость от библиотеки в том модуле, где я считываю строку из файла (всего две xml-ки).

Строчки, которые надо добавить в xml можно скопировать из online-репозитория maven в браузере, а не писать самому, всё для удобства программиста.

    <dependency>
      <groupId>commons-io</groupId>
      <artifactId>commons-io</artifactId>
      <version>${commons-io-version}</version>
    </dependency>

Добавил в исходный файл два import,

import org.apache.commons.io.FileUtils;
import java.io.File;

. Более того, второй import мне редактор сам написал, а первый я скопировал тоже из интернета. Всё само пишется, никакого ручного труда.

Ну и дальше уже можно одной строкой прочитать файл:
String info = FileUtils.readFileToString(new File("cfg/info.txt"))