пятница, 28 декабря 2012 г.

Понятие Layout в Liferay

Layout -- это инстанция страницы портала. Лейауты хранятся в таблице Layouts, у него есть layoutId, праймери ки (plid, который сгенерирован из ownerId and layoutId).

Бывает следующих типов:
1) Портлет -- для размещения на нем портлетов.
2) Ембедед -- как я понял ифрейм.
3) Урл -- как я понял это просто редирект.
4) Артикл -- как я понял джорнал портлет создает страницы с таким типом, если не его вставляют на лейаут, а он с админки генерит.

понедельник, 24 декабря 2012 г.

Полезные фичи гита

Автокомплит для гита
Пользователям виндоус повезло, он идет по-умолчанию. Для маководов и линуксоидов нужно соответсвенно:
cp /path/to/git/sources/contrib/completion/git-completion.bash /opt/local/etc/bash_completion.d/
cp /path/to/git/sources/contrib/completion/git-completion.bash /etc/bash_completion.d/

Если нет доступа к глабальным каталогам, то можно сделать только для себя это:
cp /path/to/git/sources/contrib/completion/git-completion.bash ~/
cat "source ~/.git-completion.bash" > ~/.bashrc 
Теперь табы нам в помощь

Можно создавать алиасы для комманд:
$ git config --global alias.co checkout
$ git config --global alias.br branch
$ git config --global alias.ci commit
$ git config --global alias.st status
$ git config --global alias.unstage 'reset HEAD --'
Как можно догадаться гит на каждый такой алиаса применяет команду с префиксом git + {то что мы указали}. А если нам вообще нужно вызывать не гит, а какую-то другую утилиту, просто в контексте гита это логично и просто бы воспринималось? Чтобы не добавляляся префискс git, мы должны в тело команды на первом месте поставить знак восклицания:
$ git config --global alias.visual '!gitk'

Работы с удаленными репозиториями(серверами)

Когда мы дулаем клон, какого-нибудь проекта, то указанный урл, считается ремоутом с имененм origin. Мы можем получить по нем информацию
$ git remote
$ git remote -v

Если нам нужно добавить еще один удаленный сервер с которым мы работаем по данному проекту, то
$ git remote add {NEW_REMOTE_NAME} git://github.com/path/to/prj.git
Теперь наши бранчи имеют более сложные имена:

origin/master
...
NEW_REMOTE_NAME/master
...

 Для того, чтобы выбрать то, что есть в удаленке, но не делать мерджи:
git fetch [remote-name]
Если без имени, то origin по-умолчанию.

На самом деле наши гит-пуш имеет более сложную структору, чем та, что мы используем обычно, там просто подставляются поточные аргументы:
git push [remote-name] [branch-name]

Чтобы увидеть, что у нас за сервер скрывается за определенным псевдонимом - урл, что за ветки и п.п:
$ git remote show origin
Чтобы удалить или переименовать зарегистрированный удаленный сервер есть две команды:
$ git remote rename pb paul
$ git remote rm paul

Сохранить креденшиалсы в винде для гитхаба

https://github.com/downloads/anurse/git-credential-winstore/git-credential-winstore.exe

Восстановление ошибочных правок

Если забыл что-то застейджить и уже сделал комит, но не пуш, то не логично делать еще один комит, ведь было бы хорошо обьединить все это в один комит. Чтобы это сделать, делаем вот что:
$ git commit -m 'initial commit'
$ git add forgotten_file
$ git commit --amend

Чтобы отстейджить ошибочно застейдженный файл нужно:
git reset HEAD wrong-staged-file.ext
Чтобы сделать реверт по-свновски файла(восстановить его до прежнего состояния из поточной ревизии):
git checkout -- revert-me.ext

пятница, 21 декабря 2012 г.

git log

git log - просмотр истории постранично, Enter - смотреть следующую страницу, q - выйсти из истории
git log -N - вывести N последних комитов.
git log -p - показывать diff измененных файлов.
git log --stat - выводится для каждого комита статистика, сколько файлов было изменено, сколько строк было добавлено, сколько удалено.

git log --pretty=oneline|short|full|fuller - меняет внешний вид логов.
Но самый интересное значение pretty - это формат:
git log --pretty=format:"%h - %an, %ar : %s"
Параметр Описание выводимых данных `%H` Хеш коммита `%h` Сокращенный хеш коммита `%T` Хеш дерева `%t` Сокращенный хеш дерева `%P` Хеши родительских коммитов `%p` Сокращенные хеши родительских коммитов `%an` Имя автора `%ae` Электронная почта автора `%ad` Дата автора (формат соответствует параметру --date= ) `%ar` Дата автора, относительная (пр. "2 мес. назад") `%cn` Имя коммитера `%ce` Электронная почта коммитера `%cd` Дата коммитера `%cr` Дата коммитера, относительная `%s` Комментарий


Параметр Описание `-p` Выводит патч (заплатку/diff) внесенный каждым коммитом. `--stat` Выводит статистику по файлам измененным в каждом коммите. `--shortstat` Отображает только строку с changed/insertions/deletions от вывода команды `--stat`. `--name-only` Выводит список измененных файлов после каждого коммита. `--name-status` Выводит список файлов вместе с информацией о добавлении/изменении/удалении. `--abbrev-commit` Выводит только первые несколько символов контрольной суммы SHA-1 вместо всех 40. `--relative-date` Выводит дату в относительном формате (например, “2 недели назад”) вместо использования полного формата даты. `--graph` Выводит ASCII граф истории ветвлений и слияний рядом с выводом лога. `--pretty` Выводит коммиты в альтернативном формате. Параметры включают oneline, short, full, fuller, и format (где вы можете указать свой собственный формат).


Опция Описание `-(n)` Показать последние n коммитов `--since`, `--after` Ограничить коммиты теми, которые сделаны после указанной даты. `--until`, `--before` Ограничить коммиты теми, которые сделаны до указанной даты. `--author` Показать только те коммиты, автор которых соответствует указанной строке. `--committer` Показать только те коммиты, коммитер которых соответствует указанной строке.

Вы также можете отфильтровать список коммитов по какому-либо критерию поиска. Опция --author позволяет фильтровать по автору, опция --grep позволяет искать по ключевым словам в сообщении. (Заметим, что, если вы укажете и опцию author, и опцию grep, то будут найдены все коммиты, которые удовлетворяют первому ИЛИ второму критерию. Чтобы найти коммиты, которые удовлетворяют первому И второму критерию, следует добавить опцию --all-match.)

четверг, 20 декабря 2012 г.

git mv

В отличии от друших систем контроля версий гит, не сохраняет связи между файлами, которые перемещаются интсументарием системы контроля версий.
Для гита это переименование, и ничего более:
$ git mv README.txt README $ git status # On branch master # Your branch is ahead of 'origin/master' by 1 commit. # # Changes to be committed: # (use "git reset HEAD ..." to unstage) # # renamed: README.txt -> README #
И эквивалентно это этому:
$ mv README.txt README $ git rm README.txt $ git add README

git rm

git rm file - удалит файл с диска и проиндексирует его как удаленным
git rm --chached logs/\*.log - удалит файлы с индекса, но оставит на диске

git diff

git diff - посомтреть, что изменилось, но не засдейджено(не проиндрексировано)
git diff --chached (а в с 1.6 или --staged) - то, что проиндексировано

Разница между revert, reset и checkout


Given one or more existing commits, revert the changes that the related patches introduce, and record some new commits that record them. This requires your working tree to be clean (no modifications from the HEAD commit).
Note: git revert is used to record some new commits to reverse the effect of some earlier commits (often only a faulty one). If you want to throw away all uncommitted changes in your working directory, you should see git-reset(1), particularly the --hard option. If you want to extract specific files as they were in another commit, you should see git-checkout(1), specifically the git checkout -- syntax. Take care with these alternatives as both will discard uncommitted changes in your working directory.

среда, 19 декабря 2012 г.

JMS

Java Message Service - посредник для обмена сообщениями между приложениями(бинами) в платформе Java EE. Для обмена используется две архитектуры:

Модель «от пункта к пункту» характеризуется следующим:
  • Каждое сообщение имеет только одного адресата
  • Сообщение попадает в «почтовый ящик», или «очередь» адресата и может быть прочитано когда угодно. Если адресат не работал в момент отсылки сообщения, сообщение не пропадёт.
  • После получения сообщения адресат посылает извещение.
Модель «издатель-подписчик» характеризуется следующим:
  • Подписчик подписывается на определённую «тему»
  • Издатель публикует своё сообщение. Его получают все подписчики этой темы
  • Получатель должен работать и быть подписан в момент отправки сообщения
"Взято с вики"

понедельник, 17 декабря 2012 г.

Batch application

Бывают очень тяжелые операции:
-  какие-нибудь транзакции, на которые паралельн с которыми нужно выполнить другие операции; большие вычислительные операции и т.п;
- тяжёлые периодические операции( месячные отчеты например);
- синхронизация данных с какими-нибудь внешними данными (тут происходит много валидаций, подгонки формата и т.д.).
Для этого существут Job scheduler, в который через опеределенный интерфейса(Command line interface, EJB interface, Web-services interface, Job management console) мы указываем, какое приложение и с какими данными выполнить, Batch container - в нем выполняются приложения, есть база планироващика и база прилижения, они могут быть обьеденены. Часто приложения находятся на нодах, так называемого грида, за одну транзакцию побочно может быть нужно выполнить что-нибудь на десятках нодах.

воскресенье, 16 декабря 2012 г.

JMX

Java Management eXtentions--технология, которая позволяет создавать внешне управляемые  и расширяемые системы. Система всегда состоит из MBeanServer, из множества MBeans(нескольких типов Dinamic, Standart etc), и JConsole. MBean -- Managed Bean.

В этой системе условно выделяют три слоя.
Probe level -- тут находятся наши управляемые бины
Agent level -- тут находится MBeanServer
Remote Management level -- тут находятся Connectors ( к такому конектору и подключается JConsole, можно также написать что-то свое, чтобы подключаться управлять бинами), и Adpters (это товарищи, которые позволяют подключаться по любым протоколам и использовать нестандратное апи для управления бинами)

JMX является стандартом для виртуальной машины из версии 1.5, поэтому MBeanServer, конекторы/адаптеры, и JConsole входят в HotSpot по-умолчанию,

Чтобы управлять нашим приложением, мы должны для желаемых бинов определить интерфейсы вида {BeanName}MBean, в интерфейсе указать методы, которыми мы хотим чтобы управлялся наш бин. Потом в приложении получить инстанцию MBeanServer  и зарегистировать наш бин в нем.
MyBean bean = new MyBean();//implements interface MyBeanMBean
javax.management.MBeanServer mbs = java.lang.management.ManagementFactory.getPlatformMBeanServer();
javax.management.ObjectName name = new ObjectName("com.mypackage:type=MyBean");
mbs.registerMBean(neab, name);
Мы JConsole сможем в графическом режиме пользоваться указанными в интерфейсе методами.

пятница, 14 декабря 2012 г.

Бранчевание

В гите бранч - это легковестный обьект-ссылка, на какой-то комит. Поэтому в гите бранчевание такое скоростное, они ничего не копирует и не дублирует.
Создание ветки:
git branch {branch_name}
git checkout {branch_name}
или
git checkout -b {branch_name}


Любую таску удобнее всего делать в отдельном браче: Допустим в главном бранче мы имеем следующую историю разработки a-b-c Создали ветку:
git checkout -b bag1
Пофиксили, закомитить еще никто-ничего не успел в главную ветку, значит:
git checkout master
git merge bug1
На выходе красивая история a-b-c-d главной ветки.
Если же кто-то успел что-то закомитить(стало a-b-c-E), и мы не хотели бы делать автомердж и раздваивать историю, то:
git checkout master
git pull
# ага увидели что были комиты
git checkout bug1
git rebase master # пересадить историю изменений a-b-c-E
git checkout master
git merge bug1
Выходит, что на выходе получилась итория мастера a-b-c-E-D, D именно большая потому-что комит получается дублируется.

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

git stash

git stash : добавить текущие незакоммиченные изменения в стек изменений и сбросить текущую рабочую копию до HEAD'а репозитория;
git stash list : показать все изменения в стеке;
git stash show : показать последнее измененеие в стеке (патч);
git stash apply : применить последнее изменение из стека к текущей рабочей копии;
git stash drop : удалить последнее изменение в стеке;
git stash pop : применить последнее изменение из стека к текущей рабочей копии и удалить его из стека;
git stash clear : очистить стек изменений.

Слить проект с удаленного репозитория

git clone -b branchname https://github.com/path/to/project.git local-folder

Если на удаленный сервер улетела кака

Если были сделаны комиты, которые можно восстановить, то делаем смело следующие операции:

git pull
git reset --hard {revision_hash}
git push -f


Если же после нас накомитило кучу людей кучу полезных фишек, тут уже труба... Нужно просто договариваться и всех останавливать и исправлять свою ошибку с принятием отвественности.
Если же мы мерджанули не нужное мы можем этот мерж удалить, делаем мы это так:
git revert -m 1 {revision_with_merge_hash}

среда, 12 декабря 2012 г.

Стадии кода

Итак после того как мы сделали изменения нашего кода, код может попасть в стейджинг простанство, это называется индексирование. Чтобы измения туда попали(добалвенные новые файлы, удаленные старые, редактированные старые) мы выполняем команду:
git add path/to/file
Если в svn это мы метим файлы, которые хотим начать отслеживать системой контроля версий, то в гите это не то, это мы переводим файл в режим стейджинг пространства, то есть это нужно делать не только с новыми файлами, которые мы пока не трекаем, а и с уже отслеживаемыми, но которые мы отредактировали.
Састейдженнные файлы мы можем отправить в локальный репозиторий комитом.
git commit -m "My msg"
Поскольку если изменний было сделанно очень много, и добавлено, и удалено, и отредактировано, то это может быть слишком утомительно проработать каждый файл git add, мы можем использовать команду комита с ключем, который означает все изменений перед комитом застейджить(правки, новые, удаленные)
git commit -a -m "My msg"

вторник, 11 декабря 2012 г.

Чтобы скомпилированные файлы идеи сразу попадали в томкат

Если у нас настроен томка через сервер томка идеи, то нужно в vm options указать -Dfile.root .

Основные "кодовые" имена git

master -- основная ветка разработки
HEAD -- последний комит поточной ветки
origin -- так называется по-умолчанию удаленный репозиторий

Теги в git


Тег(а точнее лекоговесный) в гите, это алиас на какой-то комит.
Если мы сливаем тег, то у нас нет поточного бранча.
Чтобы понять что за тег у нас слит нужно:
git describe --tags

Чтобы увидеть какие у нас создано локальные теги(список локальных тегов):
git tag
Если у нас очень много тегов, то логично из немного фильтрануть
$ git tag -l 'v1.4.2.*'

Теги бывают двух типов:

  • lightweight 
  • annotated

Легковесный тег - это то, что я описал в самом начале, это как бранч, который не имеет дальнейших комитов. Аннотированный - это уже отдельный обьект, который хранится в базе гита, у него своя чексумма, имя, имя комитера, емейл, дата, он также подсисан и провалидирован с помощью GNU Privacy Guard (GPG).
Чтобы создать легковестный, нужно просто:
$ git tag {NAME_OF_LIGHTWEIGHT}
Как мы видим мы к нему не вяжем не отдельного сообщения ничего, у нас просто на чексумму конкретного комита привязывается имя.
Если мы попробуем посмотреть данные этого тега, то увидим данные именно комита, на который он был применен:
$ git show v1.4-lw
commit 15027957951b64cf874c3557a0f3547bd83b3ff6
Merge: 4a447f7... a6b4c97...
Author: Scott Chacon 
Date:   Sun Feb 8 19:02:46 2009 -0800

    Merge branch 'experiment'


Чтобы сделать аннотированный тег нужно:
1) Закомитить наши измения и запушить куда-то
2) Создать тег на этот комит (ключ "а" именно и указывает, что это аннотированный тег):
git tag -a {TAG_NAME} -m "Comment"
Если мы делаем тег на комит, который уже не в HEAD, то нужно еще и указать хеш-код комита
git tag -a {TAG_NAME} -m "Comment" {9fceb02HASH_CODE}
3) Запушить тег:
git push --tags
# OR
git push {remote-name} --tags
Но эта команда запушит все наши локальные теги, если нам не нужны они все на удаленном сервере мы можем запушить конкретный:
git push origin {concrete-tag-name}
4) Перепроверить появился ли он в списке существующих тегов:
git tag
Чтобы увидеть всю информацию аннотированного тега нужно:
$ git show {ANNOT_TAG}



Чтобы развернуть наш тег на другой машине нужно:
git fetch
git checkout NAME_OF_TAG

понедельник, 10 декабря 2012 г.

Мониторить логи с нескольких файлов одновременно



> tail -n100 -f  /path/to/logs/* | grep "^ERROR:\|^Cause by"

Ключевые моменты:
* -- мониторить все файлы с логами
\| -- оператор или
^ -- начало строки

Переключиться на локальную другую ветку



>git branch
Получим список локальных бранчев:



>branch_1
  branch_2
  branch_3


Теперь в принципи само переключение:

git checkout branch_2

Залить комит из другой ветки в поточную (cherry-pick)

git cherry-pick dfgkdjhfgkjdhfHESHCODE_OF_NEEDED_COMMIT_FROM_NEEDEDBRANCHsdfs
git cherry-pick BRANCH_WHERE_LAST_COMMIT_NEEDED
git cherry-pick TAG_NAME

понедельник, 3 декабря 2012 г.

Определение библиотек тегов типа *.tag не через tagdir, а через uri

web.xml
<?xml version="1.0"?>
<web-app xmlns="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd"
 version="2.4">
    ...
    <jsp-config>
        <taglib>
            <taglib-uri>http://myurl.com/mytags</taglib-uri>
            <taglib-location>/WEB-INF/tld/mytags.tld</taglib-location>
        </taglib>
    </jsp-config>
</web-app>

WEB-INF/tld/mytags.tld:
<?xml version="1.0" encoding="ISO-8859-1"?>

<taglib xmlns="http://java.sun.com/xml/ns/j2ee"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-jsptaglibrary_2_0.xsd"
        version="2.0">

    <tlib-version>1.0</tlib-version>
    <short-name>mytags</short-name>
    <uri>http://playtech.com/gala-tags</uri>


    <tag-file>
        <name>registrationFormPasswordRow</name>
        <path>/WEB-INF/tags/registration/registrationFormPasswordRow.tag</path>
    </tag-file>

    <tag-file>
        <name>registrationFormRow</name>
        <path>/WEB-INF/tags/registration/registrationFormRow.tag</path>
    </tag-file>

    <tag-file>
        <name>validationResult</name>
        <path>/WEB-INF/tags/registration/validationResult.tag</path>
    </tag-file>

</taglib>