Category Development

Guitr – the ease of git usage with multi-git-repo-project structure v0.0.4

Recently new version of the guitr ruby gem was pushed and ready to use.

There are following changes were made since my first post about this gem:

  • –unpushed operation – helps to check what was commited but havn’t pushed yet
  • –pull operation was refactored to a standard git pull command
  • –status operation was refactored to a standard git status command as well
  • git operation error stops guitr invocation bug was fixed
  • spec coverage was enhanced

What’s next.

In the future time I’m going to implement push operation and integrate with http://optionparser.rubyforge.org/ to handle command line arguments.

And in the far future time commits, think it can help to have one message for commits across several repositories related to one feature/user story.

That’s it, thanks for your time.

Enjoy playing guitr ;)

Guitr – the ease of git usage with multi-git-per-project structure

Today I’ve pushed a gem to ease of git pull/status actions on multi-modules projects with git repository per project.

What I mean about multi-modules projects – this is a case when you have some modules/projects with separate git repositories. To avoid manually entering into each directory to perform pulling or checking the status you can install guitr and relax a bit ;)

To install guitr use following command:

[sudo] gem install guitr

To check status use following command:

guitr --status [path_to_repo]  #path is optional argument and if not specified guitr will use current directory as a base directory to start walk from.
guitr --pull [path_to_repo] #Invokes git pull per each git working directory

Fow this time that’s it what guitr can do.

Stay up-to-date here http://webdizz.name/posts/guitr.

Enjoy playing guitr ;)

What’s new in up-coming BuildR

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

Итак, что же в этой версии ожидается:

  • поддержка JRuby 1.5, JMock 2.5.1, Ant 1.8.0, JUnit 4.7
  • устранена ошибка падения при работе с rubygems 1.3.6
  • include/exclude методы научились поддерживать лямбда выражения, принимать на вход таски Rake, а так же поддрежка регулярных выражений
  • улучшена поддержка Scala
  • имплементирована поддержка protobuf
  • поддержка в качестве билд-файла файлы buildfile.rb и Buildfile.rb на ряду с buildfile.

Полный список изменений можно узнать тут.

P.S. Немного рекламы – если вы используете Buildr для сборки вашего проекта и ваш проект на Java, то вооспользуйтесь екстеншеном для форматирования кода http://rubygems.org/gems/jstyler.

Jstyler v0.0.3 – code formatting extension for BuildR

There I’m going to post information related to Jstyler - code formatting extension for BuildR.
Some time ago the v0.0.3 was released and is ready to use.
Prelude…
The main goal of this gem is to provide functionality to perform java code formatting for buildr. I’ve made a little research but it had no luck and decided to make own extension with such functionality. But there was a requirement to not to implement whole staff by my self.  I knew there is a cool functionality built-in Eclipse, but I’d like to have it outside of IDE. After research I’ve found out a lot of libraries, but most of them were not feed my needs and I decided to concentrate my attention on functionality provided by Eclipse. That can be ran through command line, actually here you can find out how it can be configured. But this was not what I wanted also, but I believed in Eclipse “magic”.
Then I’ve tried to extract classes required to perform formatting and had a luck. Now I have a jar files to for this and my runners – 2 java classes to prepare context and invoke format action using  Eclipse classes. All that staff I packed into one jar file.
Now it’s a Ruby‘s turn…
With Ruby things were a bit complicated as I don’t know to much of this language, but have a big desire to make it closer to me. At the end I have several Ruby files with BuildR extension definition.
That’s all about pre-history of this gem.
How-to…
To use this extension you need to install BuildR and gem with extension itself.
sudo gem install buildr
sudo gem install jstyler
After installation you should add several lines of code into your project build-file (buildfile).
require 'jstyler' # this is inclusion of extension's code
And if you agree with Java convention about code formatting that’s it. To perform formatting you need to run command:
buildr format
But if you are disagree with Java conventions and want to use Eclipse convention you need to define a configuration options like following:
jstyler.options[:convention] = 'eclipse'
After all if you would like to have own style you should create it in Eclipse and save under some directory, then define path to it in your buildfile like following:
jstyler.options[:config] = 'path_to_your_org.eclipse.jdt.core.prefs'
Also you can define following configuration options:
  • jstyler.options[:config]  - receives path to config file with formatting style definition (Eclipse generated).
  • jstyler.options[:verbose] – if is specified output should be more detailed

  • jstyler.options[:convention] – java or eclipse – which convention should be used if config path was not specified, by default java is used.

Those options can be defined in ~/.buildr/settings.yaml or per project folder in the build.yaml files.
Next I give you a buildfile for sample project to start with.
# Sample project buildfile
require 'jstyler' # include extension
 
jstyler.options[:config] = "path_to_config"
 
define 'testsrc' do
  # extend Jstyler::Beautify #to extend buildr only for this project
  project.version = 1.0
  project.group = 'name.webdizz.jstyler'
  compile.options.target = '1.5'
  package :jar
end
Source code of the gem can be find here http://github.com/webdizz/jstyler. And the gem itself http://rubygems.org/gems/jstyler
If you have any question related to gem ask here.
That’s it.
Have a fun formatting.

Git colorizing

Доброго времени суток!
Хочу поделиться небольшим, так называемым tips-and-tricks, в использовании Git, а именно в настройке цветовой схемы.
Некоторое время назад я решился поставить на своем лаптопе Kubuntu, что далось мне не так уж и легко, будучи поколнником FreeBSD, но легкость и доступность актуальных версии приложений все таки сделало свое дело. Недостатком в FreeBSD для меня было отсутсвие новых сборок Eclipse, Google Chrome и т.д. Так как работать на Windows уже немного поднаскучило и в виду того, что разработка на работе ведется на Pair Station, то решил и поставил.
Собственно вышеперечисленное вводная предыстория на этом будет завершена.
Для своих “проектиков” я использую Git в качестве системы контроля версий, а именно его консольный вариант. На Windows я использую MsysGit, который мен вполне устраивает, но установив оригинальный Git для Linux, я столкнулся с нехваткой некоторых настроек, а именно цветовой схемы.
Решение было очень простым и как может показаться из этого поста малобуквенным;)
vi ~/.gitconfig
Далее необходимо добавить следующие строки.
[color]
        ui = auto
Этого же эффекта можно достигнуть с помошью следующей комманды.
git config --global color.ui auto
Теперь вы можете наслаждаться цветным выводом всех комманд.
Удачи

Git with Subversion in one place

Доброго времени суток.

Недавно столкнулся с необходимостью настроить новый проект для использования Git в качестве системы контроля версий. Задача была следующей, необходимо иметь дополнительный RSA ключ к основному и обеспечить работу с двумя разными удаленными репозиториями на одной машине, так же нужно учесть что до того как возникла текущая задача исходники проекта хостились в Subersion и нужно так же иметь и его поддрежку для тех, кто еще не перешел на Git.

Опять же как обычно Google рулит ;) Погуглив, нашел статейку, которая очень помогла. Далее привожу последовательность моих действий.

Предполагается, что у вас уже имеется MsysGit и уже имеется небольшой опыт испоьзования Git.

Первоначально нужно создать RSA ключ для нового Git репозитория это делается следующим образом.

ssh-keygen -t rsa -C "ваш комментарий тут"

И на этом шаге нужно указать другой путь для ключа, например ~/.ssh/project2_id_rsa.

Затем делаем импорт исходников из Subersion в локальный Git репозиторий.

git svn clone http://svn.repo.hostname/trunk local_git_repo

Процесс клона должен пройти, пока он будет вытягивать все исходники мы можем приступить к настройке SSH. Нужно открыть файл в домащней директории пользователя, для Linux это ~/.ssh/config, для Windows – C:\Doc..and Settings\username\.ssh\config. Дописываем в этот файл следующие строчки

Host    project-git-repo-dev
          Hostname=remote-git-repo-host.com
          IdentityFile=~/.ssh/project2_id_rsa

Далее, после того как исходники импортятся в локальный Git репозиторий, нужно открыть файл в директории local_git_repo/.git/config и исправить имя хости удаленного Git репозитория на указанный в SSH конфиге.

[remote "origin"]
       #url = ssh://remote-git-repo-host.com/repo.git
       url = ssh://project-git-repo-dev/repo.git
       fetch = +refs/heads/*:refs/remotes/origin/*

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

Далее при изменениях в Subersion репозитории нужно будет выполнить следующие команды.

git svn rebase
git push

При изменениях в локальном Git

git add .
git commit -m "Some nice functionality was added"
git push
git svn rebase
git push
git svn dcommit #эта комманда создать ревизию для каждого комита в Git

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

git stash 
git svn dcommit
git stash apply

На этом все, успехов.

GWT based Chrome extension

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

Как обычно знакомство с чем-то новым и неизведанным является очень интересным и занимательным занятием, помимо этого еще и с присутствием “challenges” . Ближе к делу…

Итак в этот раз я взялся за написание плагина для Chrome. Я не буду описывать архитектуру API для написания расширений, т.к. заинтересовавшийся разработчик сможе ознакомиться с ней тут. Вкратце – плагин представляет собой файл-декларация плагина – manifest.json, background-html страницу (содержит общую логику расширения) и подключаемые js-файлы. Написание плагина на чистом JavaScript не представляет собой огромного интереса, в отличии от использования для этого GWT.

Как оказалось официальной поддержки Chrome extensions в GWT нет, но погуглив я наткнулся на кое-какую информацию по эьлму вопросу. В релиз GWT 2.0 включается расширение для Chrome Speed Tracer, которое написано с использованием GWT. Заложенные возможности к гибкому расширению с помошью GWT linker позволяют применять этот замечательный фреймворк очень широко.  Сделав чекаут проекта Speed Tracer я начал вникать в способ написания расширения. Как оказалось линкер в Speed Tracer не поддерживает ряд появившихся в новом API Chrome методов и типов, так мною были дописаны возможность подключать скрипты в background page, пости-инициализация подключаемых скриптов и немного доработан линкер до нужд моего расширения.

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

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

На этом пока все, продолжение следует…

Test multipart request in Grails

Прошло относительно немного времени с момента последнего поста и я уже нахожусь на родине :) . Вторую часть повествования моего пребывания заграницей я продолжу в следующий раз, а сегодня хочу поделиться одним незатейливым решением одной небольшой проблемы.

И так, немного вводной информации – на данный момент происходит мое знакомство с Grails методом написания демо-проекта. И в одной из задач проекта была реализация возможности загружать файлы, а именно изображения на сервер. Сам процесс загрузки собственно не сложен, а как и все в Grails, очень прост. Возможность загрузки файлов обеспечивается с помошью установки аттрибута формы enctype в виде:

<g:form action="save" enctype="multipart/form-data">
...
</g:form>

Либо следующим образом, разница только в том, что enctype уже “multipart/form-data”

<g:uploadForm action="save">
...
</g:uploadForm >

А в котроллере файл можно получить следующим образом:

def multipartFile = request.getFile('file')

где “file” – имя параметра из запроса, далее с этим объектом можно работать как со стандартным http://static.springsource.org/spring/docs/3.0.x/javadoc-api/org/springframework/web/multipart/MultipartFile.html.

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

К счастью, Groovy распологает возможностью динамически расширять возможности объекта в режиме выполнения. Это обеспечивается с помошью Mixin. Таким образом с помошью следующей конструкции я могу расширить возможности стандартного мокового объекта запроса:

....
def controller = new SomeController()
def imageMultipartFile = new MockMultipartFile("file", "test_image.jpg", "image/jpg", file.readBytes())
//add multipart nature to the mock request
controller.request.metaClass.mixin MockMultipartHttpServletRequest
controller.request.addFile(imageMultipartFile)
....

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

FitNesse with Maven

Доброго времени суток.

Вот и завершилась, как уже кажется, безконечная череда праздников и все возвращается на “круги своя”. И как было обещано в предыдущем посте, в этот раз я поделюсь небольшими навыками с интеграции FitNesse в Maven build  lifecycle.

На первый взгляд, мне так тоже казалось, что тут нет ничего сложного и все уже есть. Проштудировав документацию + internet на предмет наличия интеграции FitNesse с Maven, я кое что нашел. Тут доступен fitnesse-maven-plugin plugin для Maven, который должен обеспечить вас возможностью выполнять ваши FitNesse тесты и создавать репорты. Но что бы выполнить тесты, FitNesse сервер должен быть запущен. Для этих целей я подходящего ничего не нашел, к тому же это все должно происходить во время выполнения билда.

Для запуска FitNesse сервера я написал plugin для Maven, исходники можно найти тут.  Далее привожу пример конфигурации плагина:

<plugin>
	<groupId>name.webdizz</groupId>
	<artifactId>maven-fitnesse-server</artifactId>
        <version>0.0.1-SNAPSHOT</version>
	<executions>
		<execution>
			<phase>pre-integration-test</phase>
			<id>start-fitnesse-server</id>
			<goals>
				<goal>start-server</goal>
			</goals>
			<configuration>
				<background>true</background>
				<port>9292</port>
				<baseDir>${basedir}/src/test</baseDir>
				<root>fitnesse</root>
				<omitUpdates>true</omitUpdates>
			</configuration>
		</execution>
	</executions>
	<dependencies>
		<dependency>
			<groupId>org.fitnesse</groupId>
			<artifactId>fitnesse</artifactId>
			<version>20091121</version>
		</dependency>
		<dependency>
			<!-- Тут идут ваши зависимости - т.е. фитнесс-тесты -->
		</dependency>
	</dependencies>
</plugin>

Запуск сервера настроен на pre-integration-test фазу, так как сами тесты выполняются в integration-test фазе.

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

<plugin>
	<groupId>org.codehaus.mojo</groupId>
	<artifactId>fitnesse-maven-plugin</artifactId>
        <version>1.0-custom</version>
	<configuration>
		<classPathProvider>maven</classPathProvider>
		<!-- FitNesse servers list -->
		<fitnesses>
			<fitnesse>
				<hostName>localhost</hostName>
				<port>9292</port>
				<!-- The should be a suite to run all tests -->
				<pageName>FitNesse.UserGuide.SlIm.ScriptTable</pageName>
				<type>test</type>
			</fitnesse>
		</fitnesses>
	</configuration>
	<executions>
		<execution>
			<id>integration-test-fitnesse</id>
			<phase>integration-test</phase>
			<goals>
				<goal>run</goal>
			</goals>
		</execution>
	</executions>
</plugin>

Но на этапе запуска возникла проблема с выполнением тестов. Как оказалось fitnesse-maven-plugin немного устарел – последнее обновление было аж “04/06/2008″ и запуск тестов валился с ошибкой неверных коммандных атрибутов. Проблема была с параметром “-html” – версия FitNesse, которую я использовал, уже не поддерживала такой аттрибут. Пришлось править код – заменил этот “-html” на “-xml” – заработало :) .

На этом мне еще не удалось выполнить тест, так как появилась новая проблема – результат выполнения тестов сохранялся в виде XML, плагин же ожидает его в HTML. В итоге пришлось еще немного допилить пару классов, как результат – все заработало. Модифицированные исходники можно взять отсюда.

Теперь, используя стандартную команду

mvn clean install

будет стартовать FitNesse сервер и выполняться тесты.

На этом все, спасибо за внимание и удачного тестирования…

FitNesse или еще один подход приемочного тестирования

Как я уже писал, хотел сказать выше, но в нашем контексте это не очень соотвествует реальности, поэтому говорю ниже – с недавних пор я на новом проекте и продолжаю получать впечатления определенного характера;)

Еще одним из таковых является Acceptance Tests. В качестве движка для этого на проекте используется FitNesse – как написано на официальном сайте – “The fully integrated standalone wiki, and acceptance testing framework.“. Рассказывать что такое приемочное тестирование и FitNesse я не буду (можно пройтись по ссылкам и получить достаточное количество знаний), а хочу описать способ применения этого фреймворка на нашем проекте.

Итак, мы используем возможность, предоставляющую фреймворком – создавать Fixture для приемочных тестов в виде таблиц. Но я бы не писал об этом, если это бы это было простое использование FitNesse. Наши тесты используют так называемую Narrative идеологию. То есть каждый тест состоит из набора предусловий, действий и проверок и выглядит очень читаемым для участников проекта, не принимающих участие в разработке и тестировании – то бишь менеджмент. Ниже приведу пример теста:

| Given that | Actor | Able to do something | – Предусловие, что пользователь может что-то делать. Например залогиниться в приложение.

| When | Actor | Attempts to click on view story button | – Действие, пользователь приложение нажимает или делает что-то с элементами интерфейса.

| Then | Displayed story is | id “some id” | – Проверка, что после действий пользователь интерфейс изменился и состояние соотвествует определенным значением. В данном случае это ID истории должен быть равен “some id”.

Получается очень даже читабельно и удобно.

В нашем случае тестированию подлегает интерфейс приложения, web-приложения. Технически это выглядит следующим образом. FitNesse выполняет код Narrative фикстур, а фикстуры в свою очередь используют WebDriver для работы с DOM моделью браузера.

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

На жтом все. В следующем топике хочу поделиться своим опытом использования FitNesse с Maven.

Copyright © Lead your flow
Just another blog about someone' …

Built on Notes Blog Core
Powered by WordPress