6 янв. 2009 г.

Сюрприз первый. Читать всем подписчикам!

Итак первый сюрприз. Этот блог закрывается. Но открывается новый! Добро пожаловать на alp-it.ru! Всем, кто подписан на RSS ленту, нужно обновить адрес: http://alp-it.ru/feed/ - лента сообщений, http://alp-it.ru/comments/feed/ - лента комментариев.
Кроме смены адреса я сменил и движок блога. Надеюсь все от этого только выиграют. На alp-it.ru переехали все записи, касающиеся it тематики и конечно же все ваши комментарии. В этом блоге новые комментарии публиковаться не будут.
Читайте alp-it.ru, пишите в alp-it.ru.

24 дек. 2008 г.

Всех поздравляю!

Всех читателей поздравляю с наступающими праздниками!
Я сейчас нахожусь в заслуженном отпуске до 5-го января, который отбываю на Родине в Минске. Надеюсь, что читателей за это время меньше не станет, а только прибавится.
В наступающем году всех читателей этого блога ждут несколько сюрпризов. Один из них я готовлю сразу по возвращению из отпуска, так что ждать осталось недолго. Еще один надеюсь сделать к марту. Пока сохраню интригу и не буду раскрывать что это за сюрпризы.
Желаю всем успехов в новом году!

13 дек. 2008 г.

Управление проектами

На dev.by появился перевод обзора 15-ти инструментов для управления проектами. Полезно почитать.
Сам работаю с Jira и Trac. Первая вызывает исключительно негативные эмоции. Trac очень даже ничего. Из обзора вызвали интерес Basecamp, Creative pro Office и Simply Invoices.

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

12 дек. 2008 г.

SQLDeveloper 1.5.3

С вчерашнего дня доступен для скачивания и патчевания SQL Developer версии 1.5.3
Скачивать целиком здесь. Патчить версию 1.5.1 можно прямо из девелопера: пункт меню Help -> Check for updates.
Я пропатчился - у меня слетели все сохраненные соединения. Правда я их восстановил без проблем. Но осадок остался.

26 нояб. 2008 г.

Буду в Минске.

Итак, примерно с 20 декабря по 3 января собираюсь посетить город-герой Минск. Родина ждет. Очень жаль что не успеваю посетить вот эту встречу BYJUG. Java меня мало занимает, а вот про Flex и RIA в целом с удовольствием бы пообщался.
Если у кого-то есть пожелания и предложения встретиться - пишите, звоните, приходите :)

Составная форма

Вот этот вопрос на sql.ru сподвиг написать пример составной формы. Сам пример можно заценить здесь.
Суть в том, чтобы отдельные части сложных форм писать отдельно, как независимые пэйджи. А потом с помощью htmldb_Get эти части аккумулировать в одном месте. Получается эдакий эффект фрэймов.
Более того, этот приём очень эффективен, если нужно ообновить только какую-то часть страницы, а не перегружаться полностью. Собственно ajax в действии.
Добавлю еще, что если у вас на такой аггрегированной странице какой-нибудь из встроенных PPR репортов использует pagination (переход по страницам отчета) или сортировку, то они не будут работать корректно. Чтобы исправить ситуацию нужно на главной странице переопределить javascript функцию $a_report.

function $a_report(G,D,F,C,A){
lThis=$u_js_temp_drop();
var B=$x("report_"+G+"_catch");
B.id="report_"+G+"_catch_old";
var E="p="+$v("pFlowId")+":"+СЮДА_НУЖНО_ПОДСТАВИТЬ_НОМЕР_ПЭЙДЖА+":"+$v("pInstance")+":FLOW_PPR_OUTPUT_R"+G+"_";
if(!!A){
E+=A+"::RP&fsp_region_id="+G}
else{
E+="pg_R_"+G+":NO&pg_max_rows="+F+"&pg_min_row="+D+"&pg_rows_fetched="+C}
var H=new htmldb_Get(null,null,null,null,null,"f",E);
var I=H.get();
lThis.innerHTML=I;
B.innerHTML=$x("report_"+G+"_catch").innerHTML;
B.id="report_"+G+"_catch";
lThis.innerHTML="";
return
}


Обратите внимание в скрипте на "СЮДА_НУЖНО_ПОДСТАВИТЬ_НОМЕР_ПЭЙДЖА". Там должен быть номер страницы, которая содержит PPR отчет, в котором должен работать pagination. Естественно лучше туда этот номер подставить динамически, например функцией $s.

Напоминаю, PPR отчет - это отчет в котором рефреш страницы и сортировка происходят при помощи ajax, т.е. без полной перерисовки страницы.

23 нояб. 2008 г.

Крэкс, фэкс, пэкс или архитектура приложений под Oracle

Хотел написать полноценную статью, но из-за загруженности решил, что лучше уж напишу заметку, чем вообще ничего. Итак...
Если у вас стоит задача написания нового приложения с использованием базы данных Oracle, то естественно возникает и вопрос: на чем его писать и, соответственно, какую архитектуру приложения выбрать.
Конечно, для некоторых команд этот вопрос может быть заведомо решен - пишем на Java, .Net, Forms... и так далее. Список огромный - каждый выбирает по вкусу, или точнее то, чем владеет. Относительно с недавних пор всё больше разработок ведется на Apex. Отличный инструмент, но и не лишен некоторых недостатков. Ну и совсем свежачок - Flex. Вот на счет последних двух и хотелось написать. Собственно, заклинание из заголовка статьи немного созвучно набору технологий Apex, Flex, Ajax.

Для начала Apex. Инструмент простой, но очень эффективный. В принципе, позволяет создавать web приложения любой сложности. При этом избавляет от значительной части рутинной работы. Архитектура Apex приложений по сути проста – база данных сама генерирует html контент. Т.е. никаких специфических средних звеньев не требуется, если не брать в расчет web сервер (встроенный либо нет). И само приложение всё хранится в таблицах базы данных. А дальше идут недостатки, обусловленные как раз такой архитектурой. Неудобство разработки внутри html приложения, отсутствие нормальной версионности файлов, сложность вклиниться во внутренние механизмы рендеринга страниц – особенно критично в случаях, когда вы строите приложение сильно отличающееся от стандартных шаблонов. Опять же рендеринг создаёт дополнительную нагрузку на базу, хотя я и не сталкивался пока с серьезными проблемами по этой части, но тем не менее.

А теперь Flex. Очень богатые интерфейсные возможности при минимуме усилий. Можно создавать полноценные десктоп приложения. Разработка ведется вполне классическим способом, с поддержкой всевозможных сопутствующих систем версионности и т.д. Короче, конфетка! Но есть и «но». Flex общается с базами данных посредством web или http сервисов. Еще вроде Adobe предлагает Data Services, middle tire компонент для взаимодействия с базами данных, но я этим вопросом вплотную не занимался, потому как мне не интересен вариант использования дополнительного звена между приложением и базой, да ещё и java based.

Но во Flex очень просто реализуется взаимодействие приложения с javascript страницы, в которую он встроен. Причем это взаимодействие работает в обе стороны: javascript может вызывать методы flex приложения, и flex может вызвать любую внешнюю javascript функцию. Собственно в этом вся и соль – встроить Flex приложение внутрь Apex. Сам Apex при этом выполняет функции доставки данных, контроля доступа, управления сессиями, а Flex в свою очередь выполняет функции клиентского приложения.

То есть получается приложение, интерфейс которого полностью сделан во Flex. Такие вещи как авторизация, жизненный цикл сессий и транзакций управляется Apex. Вся логика обработки данных лежит в базе. Apex перестаёт создавать дополнительную нагрузку, поскольку он уже не рендерит страницы (Flex приложение грузится разом).

Чем не идеальная архитектура? И главное, ничего лишнего и всё бесплатно :)
Подумайте, может оно того стоит! Я кстати уже опробовал - мне понравилось.