Еще раз о создании jQuery плагина или применяем на практике

Так и не надо ничего тащить за собой, достаточно bootstrap-collapse.js. Данный фреймворк удобен в использовании, можно использовать любой функционал не таща за собой все остальное.

Еще раз о создании jQuery плагина или применяем на практике

Понимаю, что тема статьи скорее о создании плагина в целом чем о описанном плагине, но…
В сторону bootstrap не смотрели? Есть там такой плагин collapse.

Во-первых, он должен уметь скрывать/раскрывать блоки с информацией.

Умеет.

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

Кликабельная полоса создается с помощью разметки и css и видна еще до момента загрузки джаваскрипта. Позволяет использовать не только текст, но и любой другой контент.

В-четвертых, должна быть возможность управлять изначальным состоянием открыть/закрыт при инициализации плагина.

Управляется с помощью css, что дает преимущество изначально скрытого или открытого контента еще до загрузки джаваскрипта.

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

Умеет.

Кроме того можно подключить с помощью data-api(не нужно писать ни строчки джаваскрипта), не зависит от сторонних библиотек кроме jquery(можно даже поключить отдельно от других bootstrap плагинов), lazy-load если подключать через data-api — не создается объект до первого клика по триггеру, возможно построить на его основе accordion, когда может быть открыт контент только одного елемента из группы.

Интеграционные тесты с Maven, JUnit и Spring

<profile>
  <id>it</id>
  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-failsafe-plugin</artifactId>
        <executions>
          <execution>
            <id>integration-test</id>
            <goals>
              <goal>integration-test</goal>
            </goals>
          </execution>
          <execution>
            <id>verify</id>
            <goals>
              <goal>verify</goal>
            </goals>
          </execution>
        </executions>
      </plugin>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-invoker-plugin</artifactId>
        <executions>
          <execution>
            <id>integration-test</id>
            <goals>
              <goal>install</goal>
              <goal>integration-test</goal>
              <goal>verify</goal>
            </goals>
          </execution>
        </executions>
      </plugin>
    </plugins>
  </build>
</profile>

Наболевшее об исходном коде объектов БД

Согласен, но не только для тех, кто работает с ораклом. Вообще БД, как и исходники проекта, обычно постоянно изменяется и эти изменения нужно как то накатывать. Используют различные подходы от самописных инструментов, механизмов, библиотек до каких-либо готовых решений, например liquibase. Смысл один — версионирование БД, т.е. последовательное накатывание скриптов с запоминанием некой метаинформации об выполненных скриптах (версия, чексумма, автор и т.д.) иногда с возможностью откатить скрипты.
У себя на проекте сейчас используем liquibase, БД — MySQL, до этого в другом проекте использовались raw-changelog-и и свой инструмент. Считаю этот функционал must-have частью для большинства порядочных и уважающих себя проектов.

Организация разработки веб-приложений с JQuery виджетами

Приведенный пример переписанный с использованием jquery-ui будет выглядеть примерно так:

  $.widget('custom.base', {
    options: {
      name: ''
    },

    _create: function() {
      //some staff
    },

    func1: function(val) {
      //some staff
    },
    func2: function(val) {
      //some staff
    }
  });

  $.widget('custom.child', $.custom.base, {
    options: {
      name: 'some default value'
    },

    _create: function() {
      //some staff
    },

    func3: function() {
      //some staff
    },
    func4: function() {
      //some staff
    }
  });

  $('#div').child({ name: 'hello world' });

Организация разработки веб-приложений с JQuery виджетами

похожий подход используется в jquery-ui:
Widget factory

Тестирование в Java. Spock Framework

Дело в том, что java-код одновременно является валидным groovy-кодом, со scala не знаком, не могу сказать ничего по этому поводу, но в том же www.scalatest.org не заметил ничего, что делает его принципиально более аккуратным, тут скорее дело привычки(смотрел только примеры данные на сайте, поэтому мое мнение может быть не совсем объективным). Выглядит кстати довольно таки похоже, тот же подход только другой язык и конструкции.

ICQ 7.6: коротко о главном

Круто, теперь мои друзья icq-шники смогут разговаривать со мной(gtalk). Только вряд ли они будут настраивать gtalk внутри аськи(им это надо?), а я по-прежнему буду общаться с ними через xmpp-шлюз.
Более полезной фичей считаю facebook, хотя тоже не то — люди, которые пользуются аськой, обычно сидят в контакте, хотя это справедливо только для русскоязычных пользователей.

Не только Аська в ICQ-клиентах

А что вы думаете о плавном переходе с бинарного асечного протокола на джаббер? Тогда и неоффициальные клиенты будет проще разрабатывать, и интеграцию с FB и VK будет просто сделать, и в контакт лист будет возможно добавлять контакты из других джаббер сетей.

Тестирование в Java. TestNG

В идее все проще, контекстное меню -> запустить или продебажить тест-метод(тест-класс) -> создается временный xml-ничек во временной папочке и тесты пошли.

Тестирование в Java. TestNG

Я пользуюсь идеей, поддержка TestNG отличная, иногда запускаю в ней тесты через мавен, есть возможность дебажить запущеные так тесты.

Плагины для мавена:
maven-surefire-plugin — без комментариев
maven-failsafe-plugin — интеграционные тесты, запускаются после сборки модуля.
maven-invoker-plugin — для запуска отдельного проекта с тестами(запускаемыми первыми двумя плагинами), полезно для тестов в различной среде исполнения, с различными зависимотсями и т.д.

Тестирование в Java. TestNG

К счастью с данными проблемами не знаком, возможно потому что использую всегда последнюю версию обоих. Насчет плохой поддержки со стороны мавена не согласен, что такого особенного у поддержки JUnit-а, чего нет у TestNG?

Тестирование в Java. TestNG

Все зависит от того, что вам нужно. Возможно это:
testng.org/javadoc/org/testng/annotations/ObjectFactory.html

Тестирование в Java. TestNG

Также прошу не считать ответ хамством, это всего лишь мое мнение :)

Целью для этой статьи ставил обзор именно TestNG, не охватывая при этом другие фреймворки(собираюсь рассмотреть их в следующих статьях). Да, примеры тестов просты, но если бы я использовал сложные примеры, многим они были бы непонятны.

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

1. Тесты для отдельных компонентов. Все(или почти все) связи заменяются на мок-объекты, тестируется каждый предоставляемый метод(или что там еще может быть). У метода есть входные параметры и ожидаемый результат. Таким образом, эти тесты сводятся к простым, создаем набор данных (входные параметры, ожидаемый результат) и тестируем на этих данных метод.

2. Тесты для групп компонентов либо модулей в целом. Здесь используются реальные компоненты, на мок-объекты заменяются компоненты из других групп/модулей. Принцип такой же как и в предыдущем примере.

3. Тесты для всей системы в целом. Здесь уже используются только реальные компоненты, причем могут прогоняться в различных средах(различные апп-сервера, различные БД). Тот же принцип, все тесты сводятся к простым.

Конечно, архитектура приложения может быть сложной иногда даже пластилиновой, и это повлечет за собой создание такой же сложной архитектуры тестов, которая скорее всего будет находится в базовых классах в методах before и after, и будет использоваться многократно для тестирования различных компонентов. Но таккая архитектура тестов создается однажды и дальнейшее написание тестов сводится к вышеописанным действиям.

Рецепт универсального слушателя (listener)

Если я не ошибаюсь, Thread.currentThread().getContextClassLoader() иногда может возвращать null. Рекомендую если null использовать ClassLoader.getSystemClassLoader().

Тестирование в Java. JUnit

Пример — в статье рассмотрена утилита, проверяющая строку на пустоту. Допустим есть сервис, который что-то делает, что-то таинственное, использует при этом эту утилиту, где то в коде использует проверку на пустоту. Естественно, если не будет работать утилита, то не будет работать и сервис, тест сервиса зависит от теста утилиты.

Тестирование в Java. JUnit

Обожаю easymock. В очереди easymock, jmock, mockito.

Тестирование в Java. JUnit

Извините, с эклипсом мало знаком, но тут другое, можете попытаться отлавливать Throwable ;)
Насчет прогона тестов, чаще всего пользуюсь мавеном из терминала, иногда дебаг под идеей.

Тестирование в Java. JUnit

Да, в планах продолжения по TestNG, Spock Framework, инструментарий maven-а, и д.р. Материала много, было бы время :)

Использование SPI механизма для создания расширений

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