10 навыков, которые потребуются девелоперам в ближайшие пять лет

По мотивам 10 skills developers will need in the next five years.

1) Знать что-то из "большой тройки" (.NET, Java, PHP)

2) Rich Internet Applications (RIAs)

Flash - это уже не просто анимация на страничках - взгляните в сторону Flex и AIR. Его конкуренты: JavaFx, Silverlight. Добавляйте сюда также HTML5 и AJAX.

3) Веб разработка

4) Веб-сервисы

REST или SOAP? JSON или XML? Сеть - это компьютер.

5) Иметь не только навыки разработки ПО

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

6) Знать еще один динамический и/или функциональный язык

Ruby, Python, F#, и Groovy - не помешает.

7) Знать гибкие методологии разработки

8) Знания предметной области

9) Гигиена разработки

Использовать систему контроля версий, баг-трекинг, документировать код, проводить тестирование.

10) Разработка под мобильные устройства

The Joel Test: 12 Steps to Better Code

Тест от Joel Spolsky: 12 шагов к лучшему коду (правда, пост довольно давний - аж от 9 Августа 2000 года).

Ответьте на 12 вопросов:
1) Используете ли вы систему контроля версий?
2) Сборка происходит в одно действие?
3) Проводятся ли ежедневные сборки?
4) Ведется ли баг трекинг (bug database)?
5) Перед написание нового кода происходит фикс багов?new code?
6) Имеется ли расписание разработки, которое к тому же и up-to-date?
7) Есть ли спецификация (спек)?
8) Программисты имеют спокойные условия для работы?conditions?
9) Используются ли лучший инструментарий?
10) Есть ли тестеры?
11) Новые кандидаты пишут код на интервью?interview?
112) Есть и юзабилити-тестирование?

Полная версия находится здесь - The Joel Test: 12 Steps to Better Code
by Joel Spolsky

Правка CruiseControl

CruiseControl - утилита для непрерывной интеграции (continouos integration) приложений. У нас в настоящее время в КруизКонтроле (КК) крутится около десятка проектов. Схема использования такова: девелоперы вносят правки в код, тестируют его на локальных машинах, затем коммитят свои изменения в SVN. На каждом проекте в КК настроен слушатель (listener) SVN, который отслеживает изменения в репозитории. После внесения изменений, делается автоматический чек-аут кода в свою область в workspace КруизКонтроля, он собирается, а собранные артефакты (JAR, WAR файлы, возможно, SQL-скрипты) публикуются в назначенном каталоге. Ход сборки можно затем посмотреть через веб-приложение Dashboard, которое поставляется в составе КК.

Все бы было хорошо, но в КК версии 2.8.2 есть одна досадная бага, осложняющая просмотр лога сборки - лог сборки показывается в браузере одной сплошной строкой, без символов новой строки (которые в HTML должны заменяться тегами <br>). Теги br в этой строке есть, но у них угловые скобки земенены на &lt; и &gt;? поэтому они не отрабатывают. В этом сообщении показано, как поправить этот баг.

Я скачал исходники КК, и провел поиск файлов, содержащих строку errors_and_warnings_element - это id div-элемента, который содержит лог ошибок. Оказалось, что эта строка содержится в классе net.sourceforge.cruisecontrol.dashboard.widgets.ErrorsAndWarningsMessagesWidget,
код которого находится в файле CC_SRC_HOME\reporting\dashboard\src\net\sourceforge\cruisecontrol\dashboard\widgets\ErrorsAndWarningsMessagesWidget.java (где каталог CC_SRC_HOME - это каталог, который содержит исходники КК). В этом файле имеется метод errorsAndWarnings(List, String), код которого приведен ниже:

private String errorsAndWarnings(List messages, String currentHtml) { StringBuffer sb = new StringBuffer(); for (Iterator iter = messages.iterator(); iter.hasNext();) { BuildMessage message = (BuildMessage) iter.next(); MessageLevel level = message.getLevel(); if (MessageLevel.WARN.equals(level) || MessageLevel.ERROR.equals(level)) { sb.append(message.getMessage()).append("<br/>"); } } String error = StringUtils.defaultIfEmpty(sb.toString(), "No errors or warnings"); String errorsAndWarningsHtml = StringUtils.replace(ERRORS_AND_WARNINGS_HTML, "$errors",StringEscapeUtils.escapeHtml(error)); boolean hasErrorsOrWarnings = !StringUtils.isEmpty(sb.toString()); return currentHtml + makeToggleable(errorsAndWarningsHtml, "errors_and_warnings_element", hasErrorsOrWarnings); }

Проблема заключается в вызове StringEscapeUtils.escapeHtml(error). Нетрудно догадаться по названию, что метод StringEscapeUtils.escapeHtml(String str) - заменяет специальные символы (угловые скобки, амперсанды и т.п.) в строке str на escape-последовательности. Поэтому у тегов <br> были заменены угловые скобки! Если соответствующую строчку переписать как

String errorsAndWarningsHtml = StringUtils.replace(ERRORS_AND_WARNINGS_HTML, "$errors",error);

то проблема исчезнет, и лог ошибок будет отображаться в браузере в удобочитаемом виде. После исправления, данный класс можно перекомпилировать, и положить в каталог CC_HOME\webapps\dashboard\WEB-INF\classes\net\sourceforge\cruisecontrol\dashboard\widgets - где и находятся остальные class-файлы. При компиляции к качестве classpath следует использовать JAR-файлы из каталога CC_HOME\webapps\dashboard\WEB-INF\lib.

Можно также сделать и по другому: создать класс net.sourceforge.cruisecontrol.dashboard.widgets.ErrorsAndWarningsMessagesWidgetUpdated (его содержимое - полная копия класса ErrorsAndWarningsMessagesWidget),
заменить в нем строку в методе errorsAndWarnings(List, String), как показано выше. Скомпилировать его, и сделать либо JAR-файл, который положить в CC_HOME\webapps\dashboard\WEB-INF\lib, либо class-файл выложить в каталог CC_HOME\webapps\dashboard\WEB-INF\classes\net\sourceforge\cruisecontrol\dashboard\widgets. Затем в файле dashboard-config.xml (который находится в каталоге CC_HOME), который имеет следующее содержимое:

<dashboard> <buildloop logsdir="" artifactsdir="" /> <features allowforcebuild=""/> <trackingtool projectname="" baseurl="" keywords=""/> <subtabs> <subtab class="net.sourceforge.cruisecontrol.dashboard.widgets.ErrorsAndWarningsMessagesWidget" /> </subtabs> </dashboard>

заменить имя класса на net.sourceforge.cruisecontrol.dashboard.widgets.ErrorsAndWarningsMessagesWidgetUpdated.

И в этом случае также все будет работать - т.е. лог ошибок показываться в dashboard в удобочитаемом виде.

Пример build.xml для сборки:

<project name="ccfix" default="compile"> <path id="ccpath"> <fileset dir="d:/cc/webapps/dashboard/WEB-INF/lib"> <include name="*.jar"/> </fileset> <pathelement location="d:/cc/webapps/dashboard/WEB-INF/classes"/> </path> <target name="compile"> <javac srcdir="src" destdir="build" classpathref="ccpath"/> </target> </project>

FindBugs

FindBugs - утилита-анализатор исходного кода на Java на наличие потенциально опасных конструкций в нем. Тулза сделана в Университете Мэриленда, распространяется под лицензией LGPL.

FindBugs отлавливает так называемые bug patterns - т.e. конструкции в коде, которые, скорее всего, являются ошибкой. Причем, для ее работы не обязательно иметь исходный код приложения - на самом деле она выполняет анализ байт-кода, используя для этих целей библиотечку Apache BCEL (ByteCode Engineering Library), которая уже упоминалась в этом сообщении. Таким образом, можно даже сторонние JARы проанализировать на наличие ошибок - FindBugs может обрабатывать JAR-, ZIP-файлы, и, конечно, class-файлы.

Установка сей тулзы подробно описана здесь. Я устанавливал FindBugs таким образом: скачал findbugs-1.3.8.zip c SourceForge.net, разархивировал его в каталог D:\tools\findbugs-1.3.8, установил переменную среды FINDBUGS_HOME=D:\tools\findbugs-1.3.8.

Далее мы разберем работу с FindBugs c использованием Ant. Кстати, у FindBugs есть также плагин к Eclipse. Но поскольку я являюсь сторонником использования командной строки (и особенно люблю Ant =) ), то именно совместное использование Ant & FindBugs - предмет данного поста.

FindBugs довольно требователен к памяти - в руководстве на сайте программы еще в первой главе отмечают, что для работы FindBugs потребуется минимум полгигабайта оператиной памяти, а лучше больше, конечно. При первых запусках на моей машине FindBugs выбрасывал исключение java.lang.OutOfMemoryError до тех пор, пока я не увеличил объем памяти, доступной JVM до 512Mb. В команде <findbugs> (о ней речь пойдет ниже) есть параметр jvmargs, который, как понятно из названия, содержит параметры, передаваемые JVM. Установив jvmargs="-Xmx512M" я избавился от java.lang.OutOfMemoryError.

Далее предполагается, что Ant установлен в каталог ANT_HOME, а FindBugs установлен в каталог FINDBUGS_HOME. Как я уже говорил, у меня на компьютере установлена переменная среды FINDBUGS_HOME=D:\tools\findbugs-1.3.8. Первым делом самолеты надо скопировать два файла FINDBUGS_HOME/lib/bcel.jar и FINDBUGS_HOME/lib/findbugs-ant.jar в каталог ANT_HOME/lib. Затем в файле сборки (build.xml) декларируется новая команда - <findbugs>:

<taskdef name="findbugs" classname="edu.umd.cs.findbugs.anttask.FindBugsTask"/>

Рассмотрим параметры команды <findbugs> (в таблице ниже перечислены не все параметры, а только самые важные, на мой взгляд):

Параметр	Описание	Обязательный
class	Дочерний элемент, указывающий, что именно анализировать. Должен содержать атрибут location, в котором указывается путь к анализируемому объекту. Это может быть директория, JAR или ZIP файл, class-файл. Тэг <findbugs> может содержать несколько дочерних элементов <class>. Пример: <class location="${build.dir}"/> <class location="resulted.jar"/> <class location="Test.class"/>	Да
auxClasspath	Дочерний элемент, содержащий библиотеки, которые используются в анализируемом коде, но которые пользователь не будет анализировать. Этот элемент объявляется так же, как и classpath в команде <java>. Пример: <auxClasspath refid="main.classpath"/> - здесь идет ссылка на main.classpath, который ранее объявлен в файле сборки. Например, он может быть объявлен следующим образом: <path id="main.classpath"> <fileset dir="${lib.dir}"> <include name="**/*.jar"/> </fileset> </path>	Нет
home	Этот атрибут должен содержать имя каталога, где находится FindBugs. Пример: <findbugs home="${findbugs.home.dir}">	Да
reportLevel	Этот атрибут определяет уровень ошибок, которые выводятся в файл результатов. Есть три уровня: low - рапортуются все ошибки medium - (значение по умолчанию) рапортуются только ошибки уровня medium, high high - рапортуются только ошибки уровня high Пример: <findbugs reportLevel="low">	Нет
output	Этот атрибут определяет формат файла отчета. Принимает следующие значения: xml - (значение по умолчанию) формат XML. Файл отчета в этом формате можно затем открыть с помощью GUI-интерфейса xml:withMessages - вывод в формате XML дополнен поясняющими сообщениями. Файл отчета в этом формате также можно затем открыть с помощью GUI-интерфейса. Этот файл с сообщениями можно затем обработать XSLT-процессором, чтобы получить, допустим, расширенный отчет в HTML. html - вывод в формате HTML text - вывод в текстовом формате emacs - вывод в формате сообщений об ошибках, принятых в Emacs xdocs - вывод в формате sdocs для дальнейшей обработки в Maven Пример: <findbugs output="xml:withMessages">	Нет
outputFile	Этот атрибут определяет имя файла отчета. Пример: <findbugs outputFile="${reports.file}">	Нет
jvmargs	Этот атрибут определяет параметры, передаваемые JVM. Чаще всего для анализа проектов следует увеличить память, доступную JVM. Делается это с помощью параметра -Xmx, пример: <findbugs jvmargs="-Xmx512M">	Нет
failOnError	Этот логический атрибут определяет, следует ли останавливать процесс сборки, если в при проверке обнаружены ошибки. Принимает значения true/false, по умолчанию false	Нет
errorProperty	Этот атрибут определяет имя свойства, которое будет установлено в true, если при проверке будут обнаружены ошибки. Пример: <findbugs errorProperty="errors.present">	Нет
warningsProperty	Этот атрибут определяет имя свойства, которое будет установлено в true, если при проверке будут сгенерированы предупреждения. Пример: <findbugs warningsProperty="warnings.present">	Нет

Остальные параметры можно посмотреть здесь.

Теперь напишем цель для файла сборки, которая будет проверять наш (а может быть, и не наш) код на наличие ошибок.

<target name="findbugs" depends="compile"> <findbugs home="${findbugs.home.dir}" output="xml:withMessages" outputFile="${home.dir}/findbugs.xml" jvmargs="-Xmx512M"> <sourcePath path="${src.dir}" /> <class location="${build.dir}"/> <auxClasspath refid="main.classpath"/> </findbugs> </target>

После прогона FindBugs по коду одного из проектов (который писал не я =))) ) командой

> ant findbugs

были получены, например, следующие сообщения (всего получено сообщений 261):

Class defines clone() but doesn't implement Cloneable
May expose internal representation by returning reference to mutable object
Comparison of String objects using == or !=
Class defines compareTo(...) and uses Object.equals()
int division result cast to double or float
clone method does not call super.clone()
Method concatenates strings using + in a loop
Unread field

+ куча сообщений по поводу неосовобождения ресурсов после их использования (незакрытые java.sql.PreparedStatement, java.sql.ResultSet и т.п.).

FindBugs имеет удобный графический интерфейс для просмотра файла отчета. На Windows для запуска GUI можно запустить файл FINDBUGS_HOME\bin\findbugs.bat, или выполнить команду

java [JVM arguments] -jar $FINDBUGS_HOME/lib/findbugs.jar options...


Просмотр ошибок в GUI выглядит следующим образом:



В общем, после такой проверки, я предложил использовать FindBugs в нашем стандартном цикле разработки на каждой девелоперской машине. Каждый девелопер перед коммитом своих изменений в SVN обязан проверить свой код с помощью FindBugs и исправить конструкции в коде, на которые FindBugs ругается. Мое предложение было принято, и я ожидаю, что качество кода в наших проектах повысится благодаря использованию этого инструмента.

Получение Revision Number из SVN с помощью Ant

Несколько часов назад у меня появилась задача: в веб-интерфейсе разрабатываемой системы необходимо показывать номер ревизии (Revision Number) из Subversion. Все исходники проекта хранятся в Subversion, поэтому перед компиляцией (или перед сборкой) необходимо запрашивать Subversion на получение Revision Number проекта, и его вставлять в интерфейс. Естественно, это должно выполняться автоматически перед каждой сборкой.

Решено сделать следующее:
1) на место, куда требуется вставлять Revision Number (страничка head.jsp, которая вставляется инклюдом во все остальные странички), вставляется лексема __REVISION_NUMBER__, которая перед компиляцией заменяется на актуальный Revision Number, полученный из Subversion
2) создается цель (target) в Ant, которая получает Revision Number из SVN, и сохраняет его в соответствующее свойство (property)
3) применяется команда <replace>, которая заменяет лексему __REVISION_NUMBER__ на значение свойства, куда сохранили Revision Number

Все стандартно, но встает вопрос - как получить Revision Number из Subversion. Немножко погуглив, я нашел решение, про которое и расскажу.

В Subversion есть команда info, которая выдает информацию о локальном либо удаленном (находящимся в репозитории) файле. Выдается следующая информация:

• Path
  
• Name
  
• URL
  
• Revision
  
• Repository Root
  
• Repository UUID
  
• Node Kind
  
• Last Changed Author
  
• Last Changed Revision
  
• Last Changed Date
  
• Text Last Updated
  
• Properties Last Updated
  
• Checksum
  
• Lock Token
  
• Lock Owner
  
• Lock Creation Date
  

Например, при выполнении команды

svn info build.xml

на консоль будет выведена следующая информация:

Path: build.xml
Name: build.xml
URL: svn://svn/PROJECT/trunk
Repository Root: svn://svn
Repository UUID: (UUID репозитория)
Revision: 3558
Node Kind: file
Schedule: normal
Last Changed Author: awm
Last Changed Rev: 3443
Last Changed Date: (date goes here...)
Text Last Updated: (date goes here...)
Checksum: (checksum goes here....)

Для нас здесь важно свойство Revision. Именно его значение мы и собираемся вставлять вместо лексемы __REVISION_NUMBER__. Причем не важно, какой именно файл будет передан в качестве аргумента команде svn info. Дело в том, что номер ревизии является общим для всех файлом в проекте, поэтому выполнить команду svn info мы можем для любого файле проекта, в частности, и для файла сборки build.xml.

Удобно и то, что формат представления информации командой svn info понимается командами Ant, в частности, командой <property file=""/> и <loadproperties/>. Это означает, что скинув дамп вывода в какой-нибудь файл, мы затем можем без изменений передать этой файл этим командам, и они прочитают свойства, которые выведены командой svn info:
Name, URL, Repository Root, Repository UUID, Revision, Node Kind, Schedule, Last Changed, Author, Last Changed Rev, Last Changed Date, Text Last Updated, Checksum.

Была написана следующая цель в файле сборки:

<target name="get.revision.and.replace" description="Get revision number, and places it into JSPs"> <exec executable="svn" output="svndump"> <arg value="info"/> <!-- any filename can be here, because we need only Revision property, which is general for all filenames --> <arg value="build.xml"/> </exec> <loadproperties srcfile="svndump"/> <echo message="current revision is ${Revision}"/> <delete file="svndump"/> <replace file="${basedir}/project/WebContent/templates/head.jsp" token="__REVISION_NUMBER__" value="${Revision}"/> <replace file="${basedir}/project/WebContent/templates/head_login.jsp" token="__REVISION_NUMBER__" value="${Revision}"/> </target>

Атрибут output команды <exec> определяет файл, куда записывается вывод исполняемой команды. Как уже говорилось, формат этого вывода таков (Имя: значение), что понимается командами загрузки свойств Ant без изменений, что очень удобно. После загрузки свойств командой <loadproperties srcfile="svndump"/> файл вывода svndump удаляется командой <delete file="svndump"/>. В конце концов, два раза вызывается команда <replace>, которая и заменяет в определенных файлах требуемую лексему на номер ревизии.