Books: Head First Design Patterns

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

Но сегодня я хочу написать о книге Head First Design Pattern от Kathy Sierra.
Head First Design Pattern on Amazon

Паттерны (и принципы ооп) это то, что должен знать и понимать каждый программист, но одолеть произведение Большой Четверки я если честно заставить себя не могу и не смогу никогда это факт. А вот найти достойную, но более веселую замену я хотела всегда, просто до сих пор это было не выполнимой задачей. Поэтому о паттернах у меня сложилось весьма размазанное и не структурированное знание.

И вот оно чудо :) Head First Design Pattern написана так, что чтение становится увлекательным. Разжевано все до мелочей в лучших американских традициях, но в тоже время нет постоянных повторений, зацикливаний и нудятины на Н страниц, которые обычно так раздражают русского читателя. Много иллюстраций, схем и прочего. Неожиданно грамотные и короткие примеры, над которыми можно крепко подумать. Много диалогов, в которых почти всегда можно найти ответы на свои вопросы:)
В общем, весело и рекомендую тем кто чувствует пробелы в своих знаниях:)

Кстати примеры на Java.

uDig: Как убрать Tool с CoolBar'a:

Описанный в предыдущем посте подход тем не менее не сработал для элементов uDig coolbar'a. Поэтому пришлось сочинять, кое что дополнительное. Надо сказать, что uDig производил и производит на меня угнетающее впечатление отсутствием документации, тем не менее зацепка нашлась:

http://www.mail-archive.com/udig-devel@lists.refractions.net/msg05384.html

однако в новых версиях совсем по жесткому хардкорить уже не надо. В целом получилось вполне симпотично:
1. Добавляем extension point:

<extension
      point="net.refractions.udig.project.ui.toolManagers">
      <toolManager
            class="com.neopux.udigproject.plugin.CustomUDIGToolManager"
            id="com.neopux.udigproject.customUDIGToolManager">
      </toolManager>
 </extension>

И класс CustomUDIGToolManager, который наследуем от ToolManager.

2. Этот extension point лишь регистрирует "кандидатов" в ToolManager'ы. Но тот, который будет рулить в вашем плагине задается в Preferences с ключом IToolManager.P_TOOL_MANAGER. Мы можем задать это значение явно прописав в файле plugin_customization.ini:

net.refractions.udig.project.ui/toolManager = com.neopux.udigproject.customUDIGToolManager

3. Tеперь у нас есть кастомный ToolManager и можно бесчинствовать сколько влезет. К тому же специально для преследуемой нами цели авторы Udig оставили костыль. Перееопределяем метод filterTool в котором отфильтровываем все тулы, которые не нужны:

@Override
protected boolean filterTool(String categoryId, ToolProxy proxy,
            Class categoryType)
{
     String filter = "net.refractions.udig.tool.info.infoMode";
     return filter.equals(proxy.getId());
}

4. Запускаем и радуемся, что исчезла вторая часть не нужных элементов :)

Eclipse RCP: Фильтрация UI элементов.

Недавно столкнулась с задачей по отфильтровыванию из моего плагинчика элементов графического интерфейса чужих плагинов.
Суть в том, что вместе со всеми чудесами и приятностями uDig'овского интерфейса, мой плагин наследует от него пару не нужных
мне совершенно кнопок и views, вот и пришлось их выкарчевывать. Ниже описывается стандартный для Eclipse подход.

1. Добавляем экстенш пойнт org.eclipse.ui.activities (примочка появилась с версии 3.0). В целом экстенш используется для управления элементами
пользовательского интерфейса и дает возможность временно или перманентно отфильтровывать эти элементы.

2. Создаем свою activity, задаем ей name и id. По умолчаию activity задизаблена. Тем не менее любители андерстабельных
xml'ей могут прописать явно:

<enabledWhen>
    <with variable="true">
      <equals value="false"/>
    </with>
</enabledWhen>

3. Биндим activity:

<extension point="org.eclipse.ui.activities">
    <activity name="Disablement" id="disablement">
        <enabledWhen>
          <with variable="true">
            <equals value="false"/>
          </with>
        </enabledWhen>
    </activity>
    <activityPatternBinding activityId="disablement"      
 pattern="net.refractions.udig.tool.info/net.refractions.udig.tool.info.infoView"/>
</extension>

4. Радуемся что view исчезла :)

Java вкусности: отрицаем, отрицаем, да не выотрицаем.

(запостчено позднее чем написано, все-таки по воскресеньям еще не работаем:)

Бывают такие нудные дни, когда компиляция отбирает все силенки у моего компа, и валится каждый раз за несколько минут до конца (причем не на моем. бля,
коде!)...Тогда остается только жрать печеньки и курить сановские трейлы. Сегодня как раз такой день, и поэтому я накопала интересную штуку:

Знаете, что выражение (-Integer.MIN_VALUE == Integer.MIN_VALUE) всегда верно? Если не знаете, то задумайтесь над этим.
Но фишка в общем-то не в этом. С одной стороны этот факт чистая теория, с другой он приводит к тому, что, например, делать так:

return -r1.name.compareTo(r2.name);

для получения обратного порядка сортировки, просто не прилично. Ведь, по джава доку, compareTo() может вернуть любой инт, а не только привычные -1, 0 и 1.