Narrowing proxy

Если у вас Hibernate вдруг стал писать в логгере следующие строчки:
"WARN org.hibernate.engine.StatefulPersistenceContext.ProxyWarnLog - Narrowing proxy to class имя_класса - this operation breaks == "
То есть хорошее объяснение вот здесь https://forum.hibernate.org/viewtopic.php?p=2404391

Ужасный маппинг (Crazy Mapping)

Вчера отрефакторил одну "мега-фичу". Она заключалась в том, что маппинг для сущностей создавался автоматически и подключался при каждом старте системы. Это было очень плохо по следующим причинам:

1. Нет зафиксированного состояния БД. Непонятно, какие сейчас названия у колонок, внешних ключей, индексов и даже таблиц. Для нас это очень важно т.к. мы мигрируем БД из одного состояния в другое и нам обязательно нужно знать, как сейчас называются объекты в БД.
   
2. Смена логики формирования влечет смену всех имен объектов в БД.
3. У нас так не принято делать. Можете не считать это аргументом, но для меня это аргумент.
   

Я уже обрадовался, что больше такой "фичи" у нас нет, но не тут-то было. Начала вылезать ошибка, что сущности "ru.naumen.unids.archive.StudentArchive" нет в hibernate. Оказалось, что автор данной "фичи" маппил два класса в одну таблицу, а я вынес только один маппинг. То есть у него это выглядело вот так:
1) <class name="ru.naumen.unids.archive.StudentArchive" table="AR_STUDENT" lazy="false">
2) <class name="ru.naumen.unistudent.bobjects.student.StudentArchive" table="AR_STUDENT" lazy="false">
В остальном же весь маппинг полностью аналогичен. Вот так... Сейчас разгребаем.

О новом, старом и общем

Раньше думал, что создание нового - это всегда хорошо. Если создают новое, значит работа идет. Теперь я уже так не думаю. Мы постоянно создаем много нового, но количество работников не увеличивается. Теперь я радуюсь, когда вижу, что нечто удалили... но такое бывает крайне редко.

Понравилось недавнее высказывание Google, о том, что их система масштабируется горизонтально. Вся их система держится на нескольких основных технологиях, таких как Map-Reduce, Big Table, GFS и т.д. И оптимизация каждой из них ведет к оптимизации всей системы. Это замечательно.
Как такая идея может пригодиться нам, обывателям? Например, когда мы делаем систему кэширования, то она должна быть универсальной, единой для системы. Вообще же надо стремиться к универсализации и использовании open-source решений. Ресурсов не хватает все это поддерживать, не то что развивать.

Изобретатели велосипедов хуже идиотов

Настроение сегодня ни к черту из-за того, что целый день ковыряюсь в идиотском модуле, написанным одним "программистом". Этот хренов модуль, как и его автор ничего не слышали о MVC. Также они считают, что когда все понапихано в одном месте - это признак хорошего кода. Как же надо было хотеть изобретать велосипеды, чтобы заменить все стандартные компоненты на компоненты собственного производства ("@author FullIdiot"). Его уже давно не волнует, что теперь штук 300 выписок создано на основе его "наработок". И теперь от этого идиотизма никуда уже не деться, не помогут никакие книги про рефакторинг.
Да и ещё этот горе-программер решил похвастаться знанием шаблонов разработки. Применил "паттерны" Visitor, Adapter, AdapterProvider. Тошнит уже... Кому разгребать эту конюшню..?

p.s.: Изобретатели велосипедов хуже идиотов. идиоты хотя бы пользуются готовыми наработками.

Проблемы с кодировкой в патчах Eclipse

Проблема была с русскими символами при накате Eclipse патча (Apply Patch). Собственно выводилась "абракадабра". Наконец-то потратил немного времени, чтобы побороть эту проблему . У нас почти все файлы кодируются в UTF8. Я думал, что возможно патчи кодируются в ANSI и при перекодировке из UTF8 с ними что-то случается. Но оказалось, что патчи сохраняются в UTF8 (видимо тут учитываются настройки кодировки проекта), а вот накатываются, как ANSI. Решением здесь будет перекодировать патч в ANSI. Например, в NotePad++ это делается в один клик "Кодировки -> Преобразовать в ANSI". После этого патч накатывается без проблем.

update(добавлено позже): оказывается данная проблема очень легко решается установкой параметра "-Dfile.encoding=UTF-8" в настройках Eclipse (добавить эту строчку в файл eclipse.ini).

(Eclipse patch encoding problem, проблемы с кодировкой патча в Eclipse)

Признание ошибок

Недавно на работе создал один классик, выполняющий кое-какую функцию. Думал, что данная функция не реализована. Недели через 2 понял, что данную функцию можно реализовать, используя стандартные механизмы. После этого, без страданий и мучений удалил свой классик, переписав на стандартную реализацию. Также стал теперь отмечать флагами "TODO:" те участки своего кода, где я недоволен им. Бывает, времени нет, либо ты чего-то не понял, а задачу нужно доделывать. Раньше тратил много времени, гоняясь за красотой, сейчас же ставлю "TODO:" комментарий и продолжаю работу. Данный "TODO:" бывает исправляю сам же, в течение пары дней. В любом случае, видя "TODO:" комментарий, сразу понимаешь, что здесь что-то может быть не так, либо есть решение красивее.
Нужно признавать свои просчеты или ошибки, не замалчивать их. Если ты чего-то не знаешь, нужно говорить об этом открыто.

PHP

Ужасаюсь всему известному и написанному на PHP: Joomla, phpBB, OSCommerce. Это популярно, но невероятно уродливо. От этого такое отторжение к самому PHP. Сам когда-то начинал именно с него. Ничего не понимал про ООП, да вообще ничего не понимал тогда. Отторжение такое, что кажется проще написать все своё с нуля на любимом языке. Все эти php-детища живут, дышат и даже "развиваются". Ими пользуются по причине отсутствия бесплатных аналогов. Тем более php-хостинг очень распространен.

Сам "язык" PHP я никогда не полюблю...

Простые советы

1. Методы, возвращающие булево значение, называйте "is" + проверяемое условие. Без всяких отрицаний в названии метода. Никаких "isNotNull()" или "isWithoutValidation()" не может быть. Иначе при вызове "!isNotNull()" или "!isWithoutValidation()" получаем отрицание отрицания. А это плохо при чтении кода. Сравните: "!isEmpty()" и "!isNotEmpty()". Что проще понять?
2. Избегайте регулярных выражений, где возможно. Конкретный пример из практики: "String.format("%s %s %s", last, first, middle)". В данном простом случае, косвенно используются регулярные выражения. Вариант "last + ' ' + first + ' ' + middle" работает в 3-5 раз быстрее и жрет намного меньше памяти.
   

О плохих вещах в программировании

Есть несколько вещей, которые меня доводят (отсортировано в произвольном порядке):

1. Суровость. Программер пишет новый модуль/класс, которым должны пользоваться другие программеры и не оставляет ни единой строчки комментариев. Встречал мнение, что написание комментов означает нечто плохое, якобы ты "снижаешь свой уровень программирования" тем самым. Возможно, твой код действительно лучший и читаемый, но поверь, что это сразу не поймешь. Моё мнение, что такого быть не должно. Сам столкнулся с кучей недокументированного кода. Ну а смысл? Там, где я разобрался бы за 1 минуту, мне приходится разбираться 15. А если я лезу в новые дебри, то несколько часов разбирательств гарантированны.
2. Изобретательство велосипедов. Ну это вообще бред.
   
3. Нешаблонное мышление в плохом смысле этого слова. Когда ты делаешь некий компонент или класс, то должен понимать "ага, тут мы следуем MVC модели, а это значит, что в вид нельзя запихивать получение данных". Это серьезный вопрос. Старшие товарищи должны объяснять младшим "как надо".
   
4. Отсутствие контроля со стороны старших программистов. К сожалению, code-review для меня несбыточная мечта. Плохо.
5. Присутствие "индуса" в команде. Это вообще тихий ужас. К счастью, такого сейчас нет.
6. Отсутствие амбиций у команды... это когда просто кодят, выполняют свою работу и ничего больше. Скучно работать становится.
7. Отсутствие автоматических тестов. Это просто большая ошибка. Твои заказчики будут тебя ненавидеть за то, что они являются твоими тестерами. Хоть часто и говорят "все не протестируешь", "у нас тут gui", "сложная логика", но мое мнение, что надо разрабатывать соответствующие механизмы, инструменты и такие проблемы решатся. Да это затраты, да это время. Может я просто никогда не был тим-лидом, поэтому так и считаю...?
8. Нарушение DRY (Don't repeat yourself) принципа. Очень тоскливо, но зачастую, как мне кажется, невероятно сложно избегать DRY. Нужно видимо быть по-настоящему крутым прогером, чтобы такие вещи в твоем продукте не допускались.
9. Отсутствие общей "багзиллы". Это провоцирует такие вещи, как "да это же известный баг!". Да, конечно он очень известный и был в рассылке аж полгода назад. Глупо. Тем более зачастую если я нашел баг, то мне не хочется или не хватает квалификации его исправить. Так бы я занес его в багзиллу и кто-то "постарше" исправил. Действия по принципу "сам нашел - сам и исправляй" на мой взгляд неуместны.