Практическое применение Ubuntu One в разработке

Ubuntu One это бесплатный online storage service который предоставляет Сanonical. После инсталляции клиента на Убунту у вас появляется папка содержимое которой синхронизируется с сервером. Бесплатно дают 2 GB. Также есть доступ к файлам через web интерфейс. В Википедии написано что Ubuntu One использует Amazone S3. Это очень удобная вещь если вы работаете с разных компьютеров над одним проектом. Мне часто приходится переключаться с ноутбука на workstation и обратно (на обоих стоит Ubuntu), поэтому я храню конфиг файлы для приложений в папке которая синхронизируется с сервером. Например, я работаю над web application которое читает конфиги из папки ${CATALINA_HOME}/data. Есть папка ${HOME}/Cloud_Storage на воркстейшене и ноутбуке которая шарится через Ubuntu One.

На воркстейшене делаю

mv ${CATALINA_HOME}/data ${HOME}/Cloud_Storage
ln -s ${HOME}/Cloud_Storage/data  {CATALINA_HOME}/data

теперь кликаю мышей на меню "сonnect" Ubuntu One, файлы записываются на сервер

на ноутбуке
ln -s ${HOME}/Cloud_Storage/data  ${CATALINA_HOME}/data


теперь конфиг файлы на ноутбуке и воркстейшене одинаковы. Закончил работать с ноутбуком, опять кликаю мышей на меню "сonnect" Ubuntu One. Потом прихожу на работу, синхронизирую папку и вижу последние измненения в конфигах.

Билдим Flex используя Maven

Год назад я начал работать над RIA, клиент - flex, сервер - java. Решил использовать maven для билда, java билдилась без проблем, а вот с flex пришлось повозиться. Тогда я нашел единственный maven плагин для flex, Israfil Mojo. С ним были проблемы, потому что плагин не поддерживает все опции для компилятора, поэтому часть опций я вынес в конфиг файл, и указал плагину что нужно использовать конфиг файл. Вторая задача которую нужно было решать - это запаковать flex приложение в war. Задача решилась просто, Israfil Mojo позволяет копировать flex-артефакты из репозитория maven в указанную папку.

Месяц назад случайно нашел еще один maven плагин для flex, mvnflexplugin. Этот плагин мне нравится намного больше, потому что он поддерживает больше опций компилятора и поддерживает rsl, поэтому я перевел мой проект на этот плагин. Mvnflexplugin не копирует flex-артефакты из репозитория в war, но эта задача решается с помощью maven-dependency-plugin.

Вышел Review Board 1.0

Недавно вышел Review Board 1.0. Это замечательный code review tool, я использую на работе beta версию и очень доволен. Рекомендую всем кто хочет улучшить code review процесс. Review Board намного лучше чем Codestriker о котором я писал раньше.

книга "My Job Went to India: 52 Ways to Save Your Job"

Cейчас я читаю замечательную книгу, и чем дальше, тем веселее. На обложке изображен программист c обьявлением "Кодирую за еду" в руках :) Цитирую текст который меня повеселил:

How would you write a program, in pure Java, that would make the Java Virtual
Machine crash? Dead silence. Hello?
I’m sorry. I’m not getting you. Could you repeat the question, please? The voice
sounded desperate. I knew from experience that repeating the question
wasn’t going to help. So, I repeated the question, slowly and more loudly.
How would you write a program, in pure Java, that would cause the Java Virtual
Machine to crash?
Uh...I’m sorry. I’ve never done this before.
I’m sure you haven’t. How about this question: how would you write a program
that would NOT cause the JVM to crash? I was looking for really good Java
programmers. To start the interview, I asked this person (and all the others
I had interviewed that week) to rate himself on a scale of one to ten. He
said nine. I’m expecting a star here. If this guy rates himself so high, why can’t
he think of a single abusive programming trick that would cause a JVM to crash?

И таких ярких моментов в книге много :)

Книга о том, как выжить программистам в США в условиях когда все больше заказов уходит на аутсорсинг и количество рабочих мест сокращается. Лучшая из книг прочитанных мной в этом году. Автор анализирует сильные и слабые стороны американских программистов и их конкурентов в Индии и дает советы как правильно построить карьеру. Во многом его мысли совпадают с моими, например, он рекомендует изучать несколько языков программирования чтобы стать универсальным специалистом способным принимать архитектурные решения. Рекомендую почитать. Книга написана живым языком , автор обладает отличным чувством юмора, в то же время пишет о серьезных вещах. Читается легко.

Почему я не люблю JSTL

Вступление

В далекое время в далекой Галактике мы занимались разработкой веб приложения на java, другими словами добавляли новую функциональность и рефакторили код. Когда продукт поступил на аутсорсинг в Украину, он состоял из сотен JSP, в которых HTML был смешан с логикой в виде скриплетов. Иногда встречались JSP размером в тысячи строк. Постепенно мы переводили это безобразие на Spring MVC . Мы выделяли логику из скриплетов в контроллеры. Также было принято решение отказаться от скриплетов и перейти на чистый JSTL.

Недостатки JSTL

• Плохая читабельность
  

И вот в один прекрасный день я открываю страницу которая была отрефакторена со скриплетов на JSTL, и вдруг понимаю что ничего не понимаю. JSTL оказался абсолютно не читабельным. На странице были вложенные ветвления и и объявления переменных . Несмотря на то, что уровень вложенности конструкций ветвления был не больше двух, когда я смотрел на страницу то не мог понять как она работает.
Это случилось потому что теги XML не могут сравниться в наглядности с языком программирования для описания алгоритма. XML создан для автоматического обмена данными между компьютерными системами, а не для чтения людьми. Конечно, для кода на любом языке можно построить эквивалентное описание в XML. Создатели JSTL создали XML теги для операторов ветвления для объявления переменных, но при этом читабельность кода стала хуже.

• Слабая типизация

После замены скриплетов на JSTL появились баги вызванные ошибками в EL выражениях JSP страниц. При написании этой статьи я использовал NetBeans. Оказалось что даже когда опция"Test compile JSP page during builds" включена, то все равно не отлавливаются обращения к несуществующим property бинов в EL выражениях.
Отказавшись от скриплетов на java с их строгой типизацией в пользу cвязки EL+JSTL мы утратили проверку типов на этапе компиляции на на уровне view.

Пример

Рассмотрим страницу которая отображает информацию о пользователе и его правах доступа. Данные о пользователе инкапсулирует класс web.User. Страница отображает имя пользователя и список его прав. Права доступа разделяются запятой.

Вот как это реализуется на скриплетах:


А это то же самое на JSTL:


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

Поэтому я считаю что если мы используем JSP, то вместо тегов JSTL и EL лучше использовать скриплеты. Код будет более читабельным и больше ошибок выявим на этапе компиляции при условии что мы не злоупотребляем наворачиванием логики в скриплетах. Если сильно не нравятся скриплеты, то вместо JSTL лучше использовать Velocity или FreeMarker.

Энвер Измайлов

Making code review easier with Codestriker

The big brother is watching you
George Orwell

Introduction

Everybody agrees that code review is crucial for any software project. I don't believe that it is possible to do good code reviews on a regular basis without a code review tool. I you are not using a code review tool, the following scenarios might happen:

1. You have just finished with your task and want the code to be reviewed. The reviewer and you work in the same office. Unfortunately, the reviewer is not available at the moment. There are many reasons why it can happen. The reviewer might have flexible working schedule which differs from your working schedule, he might be ill, he might be at a meeting, visiting the dentist, stuck in a traffic jam. Of course, you can't wait until the reviewer appears in the office, you switch to another task instead. It is easy to forget about code review.
   
2. You have a distributed team. One or two developers work in one office, the rest of developers work in another office which might be located in another country. We had this situation at my last place of work. In this case the only way to send a code review request is an email with an attached patch file which contains your changes to code. The reviewer is supposed to read your email, save the attached patch to a folder, then apply the patch to the right version, examine your code. It is time-consuming and not efficient.

Without a code review tool the team leader doesn't have the whole picture of what is going on with code reviews. How many code review requests are pending ? Which topics are the most discussed ? These questions need to be addressed, and a code review tool helps.

There are many code review tools available, most of them are commercial, some are free. The one I introduced in my team was Codestriker. It's a free tool written in Perl. Although its functionality has minimum features, it can be successfully used. Basically, it is a web appplication running on Apache. Although Codestriker has no built-in security support, you can secure Codestriker with Apache's auth module.

Learning and setting up Codestriker took me one day. Configuration is simple but requires knowledge of Linux or Unix. You tell Codestriker what database to use and where is the code repository. We used MySQL and Subversion.

Features of Codestiker

• The creator of a topic gets notifications by e-mail when reviewers post comments.
• You can have multiple reviewers
• All the members of the team can post comments on any topic
• You can browse changes to code through Codestriker's web interface
• You can add comments to a single line of code and to a whole topic.

Conclusion

Even though we were using the simpliest code review tool, the quality of code reviews increased dramatically. The code became controlled better by the team lead. More members became involved in code review. Intreraction between offices improved. It turned out that it is possible to misuse code review tool. If the team lead is a dictator and willing to blame and critisize everyone, he can abuse the code review tool. Other members would feel like "the big brother is watching you".The programmers would feel that their every step is under attack, they would loose motivation or leave the company. So be careful with code review tools. Small teams with limited budget who don't want to spend money on commercial code review tools can use Codestiker fine.