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.

Java хитрости: На какие грабли можно наступить, если не любишь массивы.

Если честно я очень люблю листы из Java Collection Framework. Работать с ними гораздо удобнее, чем ** себе мозг с массивами, поэтому я довольно часто пользовалась методом Arrays.asList, не особо задумываясь, что при этом происходит. Точнее я просто предполагала, что оно делает нечто вроде:

List<String> list = new ArrayList<String>();
    for (String a : array)
        list.add(a);

Однако сегодня у меня наконец дошли руки посмотреть, что никакого копирования на самом деле не происходит. Arrays реализует свой ArrayList который пишет в массив, переданный ему в качестве параметра. То есть все изменения в листе приводят к изменению в массиве и наоборот. Ну и, очевидно, возвращаемый этим методом лист не является полноправной реализацией интерфейса List, ибо методы add и remove поддерживать он не может. Странно, что я ни разу не наступила до этого на грабли с удалением:)

Кстати, еще одно, уже приятное открытие - иногда очень-очень хочется создавать листы на манер массивов. А-ля:

List<A> list = new ArrayList<A>(a1, a2, a3, a4);

И вот возможный вариант:

List<A> list = Arrays.asList(a1, a2, a3, a4);

Эх, все-таки полезно читать джава доки :)

@g

Java хитрости: как удалить все элементы А из коллекции.

Мне всегда казалось, что удалять все элементы А из коллекции с помощью цикла или итератора - это подозрительно некрасиво (ну неужели Collecion Framework
не предусматривает нормального способа это сделать?). Сегодня на меня снизошло откровение:

collection.removeAll(Collections.singleton(A));

Откровение номер два - оказывается метод removeAll совсем не так прост как изначально притворялся. Всегда думала, что он делает что-то вроде

boolean removeAll (Collection collection){
   for(E e: collection){
      this.remove(e);
   }
}

и ведь нифига :

public boolean removeAll(Collection c) {
   boolean modified = false;
   Iterator e = iterator();
   while (e.hasNext()) {
      if (c.contains(e.next())) {
         e.remove();
         modified = true;
      }
   }
   return modified;
}


Eclipse RCP: резолвим и редактируем файлы

Ранее всю работу по резолвингу, открытию и редактированию файлов в своем Eclipse плагине я проворачивала через интерфейс IWorkspaceRoot. Из рута получала ссылку на проект, а дальше оставалась только радоваться удобству интерфейсов IFile, IResource, IProject и прочих.

Зарезолвленный таким образом файл открыть было проще простого:

IWorkbenchPage page = ...;
IFile file = ...;
IEditorDescriptor desc = PlatformUI.getWorkbench().getEditorRegistry().getDefaultEditor(file.getName());
page.openEditor(new FileEditorInput(file), desc.getId());

Первыми граблями на которые я наступила стала линка.

IFolder#createLink(IPath localLocation, int updateFlags,IProgressMonitor monitor);

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

IResource.REPLACE

Все бы ничего если бы мне вдруг не приспичило получить location этого одноименного файла (очень уж хотелось открыть этот файлик и поредактировать обычными средствами IO):) Так много я никогда не материлась, зато с тех пор я читаю доки внимательно, а не как обычно:) При использвании флага REPLACE одноименный файл замещается в воркспейсе линкой !
В итоге был сооружен костыль:

IWorkspaceRoot root = ;
IProject project = root.getProject(name);
IPath location = project.getLocation().append(fileName);

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

Ладно, с файлами которые (хотя бы просто географически) лежат внутри воркспейса все более или менее понятно. Но как открыть файл который лежит где-нибудь у черта на куличках? Лично я со своим воркспейс подходом к ресурсам впала в некоторый ступор :) Зарезолвить такой фал нельзя (то есть получить удобоваримую и такую милую сердцу ссылочку на IFile). В голове тут же пронеслась масса вариантов с созданием ссылки на удаленный файл, однако все оказалось куда проще:

IFileStore fileStore = EFS.getLocalFileSystem().getStore(fileToOpen.toURI());
IWorkbenchPage page = PlatformUI.getWorkbench().getActiveWorkbenchWindow().getActivePage();
IDE.openEditorOnFileStore( page, fileStore );

Заметьте, этот код откроет дефолтный эдитор, хотя там же в IDE есть метод для открытия файла по его URI, в эдиторе с заданным ID. Вобщем, настоятельно рекомендую поразглядывать классик IDE - можно узнать кое что полезное.

Пока все:)