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

В Киеве

Добрался до Киева. Тут мороз почище нашего, зато весь город очень нарядно выглядит (может за счет чистого белого снега на улицах)
Квартира досталась отличная, по цене ниже чем я снимал во Владике, но несравненно уютней и комфортней.
Из окна отличный вид, был бы, если бы его, как и во Владивостоке, не портили недостроенные многоэтажки.
А еще выяснилось, что 3G есть только у киевстара и только при заключении контракта на год... как то странно, такое ощущение что продавец меня напарил.

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

Поиск билетов

Не рекламы ради, а просто интересное наблюдение.
Для поиска билетов я чаще всего пользуюсь сайтом Eviterra/ Знаю, таких сервисов много, просто как-то увидел рекламный пост в блоге Темы Лебедева, начал пользоваться и привык. Причем часто просто нахожу Авиакомпанию которая предлагает наиболее низкий перелет и потом смотрю билет уже на ее сайте.
Хотя, иногда Eviterra может делать вещи, которые сайт какой-то одной компании вам не сделает:

  • Например когда на майские нам надо было купить билет из Хельсинки в Амстердам, а обратный и Парижа в Хельсинки. Eviterra подобрала нам билет на KLM туда, на Air France обратно (смешно - по оператором в обоих случаях все равно выступил FinnAir!). Билет получился дешевым - значительно дешевле чем отдельно на сайтах этих компаний покупать билет туда и отдельно обратно.
  • Если надо запланировать перелет с несколькими посадками - тут вообще без вариантов - все компании летают через свои хабы, на сайте одной компании-перевозчика вы такие варианты никогда не подберете.
Сегодня получилось вообще интересно - покупал билеты в Киев. Тот вариант который меня устроил - на  S7  из Петербурга в Киев с пересадкой в Москве. ОК, иду на сайт S7 - и тот же самый билет, на те же самые рейсы на родном сайте получился на 3000 дороже!
Это скорее исключение (раньше с такой серьезной разницей не сталкивался), но приятное.

ИТОГ

Пользуйтесь Eviterrа-ой!

PS Хоть пост и не рекламный, но от каких-нибудь бонусов от сайта eviterra не откажусь ;)

Как удалить всех пользователей в Liferay

Например в определенном Portal Instance.  Можно конечно штатно - через UI -  но если их много - то это займет много времени. К тому же удаление идет не напрямую - а сначала надо отключить, а только потом удалить.

Есть более просто решение -  Script панель в Control Panel -> Server Administration
Там можно вызвать относительно любой код используя различные сервисы  Liferay.

В частности - если надо удалить пользователей для какого-то определенного Portal Instance (companyId) можно использовать следующий  Script:

// get users

users = Packages.com.liferay.portal.service.UserLocalServiceUtil.getUsers(-1,-1);
companyId = xxxxx; // put companyid here
out.println(users.size());
count=0;

// enumerate all users 
for (var i = 0; i < users.size(); i++) {
    user = users.get(i);

  if (user.getCompanyId() == companyId) {
    // we cannot remove "default" user
    if (!user.isDefaultUser()) {
    Packages.com.liferay.portal.service.UserLocalServiceUtil.deleteUser(user);
    count++; // count removed users
    }
  }
}

out.println(count);

MySQL vs PostgreSQL на примере Liferay

Еще одно сравнение (что-то потянуло меня на них).
Некоторое последнее время пришлось плотно заниматься нагрузочным тестированием одного из проектов. Там у нас используется Liferay 6.1.0 CE и база данных MySQL 5.5
Так вот - в ходе тестирования под нагрузкой обратили внимание - что в какой-то момент времени распределение процессорного времени начинается не в пользу Liferay: мускул начинает отъедать 300% - оставляя Liferay только 100%.

Это показалось странным, так как обычно картина обратная - Liferay (вернее скорость процессора под него) является бутылочным горлышком - и именно Liferay в основном грузит систему - влияние базы минимально.

Более детальный разбор полетов позволил выяснить - что виноват во всем  Asset Publisher (Публиктор по русски) - а вернее те запросы к таблице  AssetEntry & co которые он генерит. Иногда запрос "вставал" на 15 секунд(!!!) - при том что записей у нас там примерно 25k

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

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

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

В ходе тестирования было высказано экспертное мнение, что PostgreSQL должен вести себя на таких запросах лучше.

Итак, в какой-то момент мы все-таки нашли время и провели эксперимент: запустили две одинаковые машинки на амазоне, поставили там один и тот же Liferay (со всеми портлетами и данными), на одном копию базы на  MySQL, на другом сделали миграцию данных на  PostgreSQL ( кстати, миграция данных средствами  Liferay  прошла на ура)

И стали смотреть.  MySQL работал как и ожидалось, а вот PostgreSQL  удивил.... дикими тормозами. То есть - главная страница могла открываться минуту!

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

К тому же скорей всего сказалось то, что PostgreSQL более критичен к скорости дисковых операций - а у нас EC2 были подняты на "медленном" EBS - видимо это тоже внесло свою лепту.

Что делать?

После некоторых изысканий была найдена следующая бага: http://issues.liferay.com/browse/LPS-28364 - как раз про наш случай -  Asset Publisher на Liferay 6.1.0
После бекпорта фикса с 6.1.1 на 6.1.0, и исправления баги http://issues.liferay.com/browse/LPS-31539 (она же Asset Publisher can't handle the multilevel categories - кто использует 6.1.1 - обратите внимание - она там по прежнему есть) PostgreSQL полегчало несколько - страница стала открываться быстрее (заметно) - но общая скорость работы все равно далека от MySQL

И какие из этого следуют выводы?

По большому счету никаких. Нельзя сказать что MySQL быстрее чем  PostgreSQL только на данном специфическом примере. И нельзя сказать что Liferay быстрее на  MySQL  чем на PostgreSQL.
И понятно что любую базу можно оттюнить так - что она начнет работать значительно быстрее (хотя опять-таки, 25k записей - не та база которую надо тюнить)
И в вашем случае вполне возможно Asset Publsiher-ы вообще не используются, и вам проблема с их производительностью неважна. Или у вас такое железо, на котором  PostgreSQL просто летает.
Но для себя мы выводы сделали - менять основную базу, которую мы используем по умолчанию, с  MySQL на PostgreSQL  смысла нет. По крайней мере используя с настройками по умолчанию мы ничего не выиграем - а глядишь и проиграем.

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

Liferay vs BackBase


Какое-то время назад было необходимо сравнить Liferay  и BackBase.  Возможно результат этого сравнения окажется кому-то полезным.
Сразу оговорюсь - сравнение ни в коем случае не претендует на объективность - все-таки я слишком "заинтересованное" лицо, хотя я честно старался быть максимально объективным :)

Так же данное сравнение ни в коем случае не является официальной позицией компании Liferay  или EmDev -  в данном случае это мое личное, оценочное суждение.

Итак:
В красном углу рынка - портал Liferay: http://www.liferay.com
В синем углу:  портал BackBase: http://backbase.com/

Оба продукта входят в квадрант Гартнера по корпоративным порталам, правда Liferay уже два года как переместился в число лидеров, а BackBase просто ворвался в этот отчет - в 2009 его не было и в помине, в 2010-ом он попал в список нишевых игроков и теперь перешел в разряд в visionaries:
И Liferay  и BackBase входят в gartner quadrant


Основное отличие Liferay и BackBase (из которого вытекают многие отличия по конкретным пунктам):
1. Liferay это портал "широкого профиля" предназначенный для широкого спектра задач
2. BackBase - узкопрофильный портал для решения конкретной задачи (The Lean Portal в терминах самого backbase)

То есть если вам надо только публичный сайт для банка (банки - основная специализация BackBase) - возможно вы сможете выполнить внедрение быстрее и дешевле используя BackBase, если же вам необходимо общее решение ("общий фронт") не только для организации пользовательского портала, но и для организации работы back office  или например обслуживание клиентов через call-center (основные каналы обслуживания клиента - веб-сайта, офис банка, кол-центр) - сделать это средствами BackBase боюсь будет невозможно (ну или тяжело).

Отсутствие орг-структуры

Одно из существенных ограничений которое бросается в глаза при рассмотрении BackBase - это отсутствие возможности отображения орг-структуры компании в рамках портала (я о крайней мере не нашел). Структура пользователей в BackBase -  плоская. Пользователи могут быть только объединены в роли.

При организации просто какого-то публичного сайта - это может быть и достаточно, но если говорить о комплексной информационной системе, где обработка каких-либо запросов пользователя (как и в целом работа сотрудников) возможна только в контексте орг-структуры, данный факт накладывает существенное ограничение на использование BackBase.

Организация  Intranet решений

В whitepapers вся информация посвящена исключительно только построению интернет-сайтов. Описания какой-либо функциональности для построения интранет решения (например для организации совместной работы сотрудников организации по обслуживанию клиентов и выполнения тех или иных действий в рамках бизнес-процессов организации) отсутствуют.

 Liferay в свою очередь представляет решения как для построения интернет порталов, так и интранет решений.


Построение внешних сайтов:

Как мне кажется функциональность Liferay  и  BackBase  тут сравнима:

  • и там и там поддерживается создание мобильных версий;
  • и там и там поддерживается персонализация страниц;
  • и там и там поддерживается remote staging;
  • поддержка мультиязычности...
  • создание страниц, размещение виджетов (портлетов), настройка внешнего вида...
  • ну и вся стандартная функциональность присущая практически любой  CMS  системе.


Однако как мне видится - в данном направлении поддержка мобильных версий и персонализации выполнена в  BackBase лучше:

  1. Стандартные widget-ы BackBase уже поддерживают адаптацию для мобильной платформы. В Liferay такую адаптацию придется программировать (в виде специальной css) самостоятельно - Liferay только дает возможность определить тип платформы и задать некоторые специальные стили. То есть "из коробки" Liferay со стандартной темой не будет красиво адаптироваться под мобильные платформы. Однако как можно посмотреть на примере того же http://www.liferay.com - такое относительно несложно реализуется
  2. Персонализация в Liferay возможно путем задания прав доступа на отображение некоторых portlet-ов (widget-ов) на странице в зависимости от роли пользователя. Это не так удобно как в BackBase.  Мы в принципе продумывали реализации персонализации по группам пользователей (с включением пользователей в группы на основании бизнес-правил) - примерная оценка такой доработки 1-2 человеко-месяца - но опять-таки - в BackBase есть из коробки и удобно - в  Liferayнадо допиливать - ибо то что есть не совсем удобно

Однако тут есть существенное отличие - обе системы поддерживают portal instance - хостинг нескольких логических порталов одним приложением. Однако в BackBase нет понятия "сайта" в рамках одного портала - то есть один портал и есть один сайт - структура портала в данном случае получается "плоская".
В Liferay есть понятие сайта - сайт может быть как сайтом какой-то единицы орг-структуры, так и просто некоторый сайт не привязанный к орг-структуре. Тем самым можно создавать порталы объединяющие в себе различные сайты  и образующие единое информационное пространство. Обычно орг-структурой и сайтами орг-единиц мы отображаем "вертикальную" структуру организации, а сайтами (сообществами, проектами) - горизонтальную - когда например для решения какой-то задачи (проекта) мы организуем отдельный сайт и добавляем туда пользователей из различных элементов орг-структуры.

Так же в  BackBase  я не нашел упоминания шаблонов страниц или шаблонов сайтов (что естественно так как понятия сайтов в нем нет).  Liferay в свою очередь ставит перед собой задачи по упрощению управления порталами с большим числом страниц и контента (с числом страниц например измеряющийся тысячами), с развитой структурой сайтов и подсайтов живущих в рамках одного портала - и в этом существенно помогают шаблоны страниц и сайтов, упрощающих создание и управление однотипных страниц и сайтов (хотя, надо признать тут  Liferay есть куда расти - не всегда эта функциональность работает очевидно и ожидаемо).

Интеграционные возможности:

С точки зрения поддерживаемых API - схожи: REST, SOAP, XML, J2EE, JSP, Spring, JMX and Hibernate, CMIS & WebDav - это все есть и в  BackBase  и в Liferay
Интеграция UI:  HTML5, CSS3, JSON, OpenSocial and various W3C standards   - тут тоже паритет
Package Existing Web Applications as a Widget :   возможность  встраивания внешних приложений в портал - в обоих системах поддерживается и  Server Side rendering (SSR) (в терминах Liferay - WebProxy),  и Client Side rendering (CSR) (в терминах LIferay - iFrame)
   
Интеграция с другими системами - хоть BackBase  и позиционируется как портал для банковских решений - информации о встроенной интеграции с какими либо существующими банковскими системами не указано.
На сайте Backbase есть список банковских партнеров (http://www.backbase.com/company/partners/) - однако насколько решения этих западных компаний применимы к российской действительности - вопрос спорный.

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

В BackBase  встроена функциональность по интеграции внешних сервисов с фильтрацией, трансформацией данных и пр. - однако стандартно такие задач решаются с использованием ESB (причем уверен что функционал любого ESB решения значительно шире и мощней того что встроено в BackBase)

SignleSignOn: Список поддерживаемых решений выглядит одинаково для обоих систем. И там и там он расширяем.
Агрегация публикуемого контента - и там и там поддерживается  CMIS, WebDav, RSS/Atom
Searching & Indexing: и там и там используется Lucene и Solr


Модель безопасности:

В обоих случаях назначение прав доступа происходит через роли.
Однако тут есть ключевое отличие - в BackBase структура пользователей (повторюсь опять) плоская - и как я говорил выше - в  Backbase нельзя отобразить структуру организации.
Тем самым - нельзя выдать какие-то права пользователю в рамках одной организации или сайта. Если пользователь Администратор - то он Администратор всего портала.
Так как в принципе нет сайтов (групп) то нельзя назначить права доступа только в контексте какой-то группы.

Workflow:

В BackBase есть встроенная поддержка Workflow - Backbase forms, однако поддержка Workflow  в  Liferay намного шире, мало того - она гибкая и позволяет подключать собственные решения.
Вместо использования стандартного Workflow Engine - Kaleo можно подключить (как например делаем мы) - Activiti полноценно реализующий стандарт BPMN 2.0.
Есть интеграция и с более серьезными  BPMS решениями -  Intalio & Bonita
В Workflow Liferay можно (в том числе используя онлайн графические редакторы с поддержкой стандартной нотации BPMN ) описать не только бизнес-процесс публикации какого-то контента - но и в принципе любые бизнес-процессы организации как состоящие из задач назначаемых пользователям, так и задач выполняемых автоматически - тем или иным сервисом).


Сообщество и экосистема

Существенное отличие (как мне кажется) между BackBase  и Liferay в том, что BackBase это "закрытая" система  а Liferay - это "открытая".
Приобретая BackBase вы получаете законченный продукт который вы в дальнейшем можете дорабатывать собственными силами или используя услуги партнера - системного интегратора. В какой-то мере вы попадаете в зависимость от них.

В Liferay за годы существования продукта было создано огромное сообщество и экосистема из компаний реализующих свои решения на базе Liferay, или интегрирующие свои продукты с  Liferay. Используя Liferay вы получаете все исходные коды - что позволяет вам в случае необходимости полностью "контролировать" продукт.
Вы можете использовать с Liferay не только решения и дополнения, поставляемые самой компанией Liferay, но и решения третих компаний (которые легко могут быть установлены через Liferay Marketplace - когда они там появятся :) ).

Для Liferay существует большое количество решений по интеграции со сторонними продуктами -  Alfresco, Nuxeo, JasperReports Server, Pentaho, Intalio, Bonita, Activiti, есть решение по организации кол-центра на базе Liferay.

ВЫВОДЫ

Сразу повторюсь - хоть я и старался быть крайне объективным - мое мнение может быть предвзято. К тому же я неплохо знаю Liferay - не сравнить со знанием BackBase.

Основное отличие как я и описывал выше - BackBase - нишевое решение решающее одну конкретную задачу - организацию внешнего сайта.
И тут у него есть ряд преимуществ перед Liferay - более простая сегментация контента под различные группы пользователей.

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

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

суббота, 8 декабря 2012 г.

Google Flight

Увидел сегодня на ленте новость: "Прикольные сообщения в Google Flights", думаю дай попробую - все-таки гугл - поисковый гигант - вдруг он и по дискаунтерам (типа того же RyanAir искать умеет - да еще с коннетами).

Выбираю "From" - Saint-Petersburg - LED - получаю "Sorry, flights from Russia not currently supported".

А жаль - было бы интересно - сможет ли гугл предложить что-либо круче аналогов которых уже много на рынке?

Ну и какие будут "прикольные" сообщения про Россию?
"Якутск" - не забудьте шапку, валенки и 10 литров водки в Duty Free - а то замерзнете нафик.

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

Конец бесплатного Google Apps

Сегодня пришла новость что Google Apps больше не доступен бесплатно.
Честно говоря очень расстроен. Не мне учить Googlу  делать бизнес, но, мне кажется, у них весь бизнес строился с простых бесплатных средств которыми они привлекали массового клиента (начиная с простого, быстрого и естественно бесплатного поисковика который был просто глотком свежего воздуха по сравнению с перегруженным yahoo)
Собственно привлеча на свою сторону кучу "частников" они смогли стать интересными для "бизнеса".

Google Apps  использую давно. С какого-то момента перешел на Premium Account - на самом деле это случилось по недоразумению - для теста включил Premium - но забыл его отключить до окончания trial периода. А потом переход обратно на бесплатную версию стал невозможен, потому что бесплатная версия стала поддерживать только 10 пользователей.

Как по мне - платить 50$  в год за пользователя - жаба душит. Банально потому что я не использую ни одной из "enterprise"  фич - ну ок - использовал одну -  SSO  через SAML между Google Apps и Liferay - когда тестировал поддержку SAML 2.0 в  Liferay EE.

При этом - ограничение в 10 пользователей вполне разумное все-таки - то есть пока компания 2-3 человека - все равно с них много не возьмешь. А уж доросли до 10 - наверное и деньги зарабатывают, можно и платную версию вводить. Хотя я бы был рад увидеть градацию и возможность платить например 10$ за пользователя - не получая при этом доступ к дополнительным фичам (ну типа отдельные версии для  Small Business  и Enterprise )

Google теперь такой возможности не дает - и фиг знает как это отразится. Раньше наличие бесплатной версии было неоспоримым преимуществом по сравнению с Office 365 и LotusLive, а вот теперь фиг знает.

Итак - какие есть альтернативы:

Office 365

Сравнение планов тут: http://www.microsoft.com/en-us/office365/compare-plans.aspx
Hosted Email: 4$ за пользователя в месяц,
Small Business 6$  за пользователя в месяц (по сравнению с Hosted Email добавляется работа с файлами) - по сути дела по набору фич близко к тому что дает Google Apps.

Причем - Microsoft как раз вводит достаточно тонкую градацию - можно хорошо подобрать именно тот план который нужен.
И за Office 365 играет то, что Microsoft очень силен до сих пор на десктопах и Enterprise  мире - большинство рабочих мест по прежнему использует Windows + MS Office - и тесная интеграция с "облаком" играет на руку Microsoft.
Ну и глядишь, мобильники на Windows 8 все-таки подтянутся.

LotusLive

Вернее теперь IBM SmartCloud for SocialBusiness (ух как длинно)
Планы тут: http://www.ibm.com/cloud-computing/social/us/en/planspricing/ - правда без цен (вообще сайт IBM в этом плане какой-то совсем не понятный)
Но опытным путем вычислил что цена за IBM SmartCloud Engage - Advanced (а именно у этого плана стояла поддержка почты) составляет 10$ за пользователя (без скидок при оплате сразу за го - так же 120 и получается).
В прицнипе когда то работали с Lotus-ом и их средствами online meeting-ов - оооочень круто и мощно (по тем временам) - но.... IBM мне кажется как обычно смотрит на больших клиентов - не уверен что "мелким" - типа меня - это вряд ли будет интересно - и по цене и по сложности.

Что-нибудь еще?

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


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

Владивосток - из "не изданного"

Улыбнитесь, ведь кому-то в 100 раз хуже чем вам
Несколько наблюдений о Владивостоке не вошедшие в предыдущие посты

Аэропорт

К саммиту построили новый терминал. Самое полезное - к нему пустили Аэроэкспресс. Штука как и в Москве - дико полезная - одна проблема - ходит не раз в полчаса, а раз в два часа. Потому, если ждать не охота - добро пожаловать на такси.
Такси официально стоит порядка 1500 рублей. Можно с таксистом договорится и за меньшую сумму. Но! Если вы думаете что заплатив 1300 вы сели и поехали - вы ошибаетесь. Таксист посадит вас и пойдет набирать еще таких же как вы за туже 1000 - 1500. От кол-ва людей это не зависит. Потому совет - едите один, хотите на такси? Найдите еще 2-3 таких же и едите за 400-500 рублей с носа. К сожалению других вариантов (разумных) кроме такси (и ожидания два часа Аэроэкспресса) нет. Кстати в аэропорт я уже ехал на нем - все понравилось. Расписание экпресса тут: http://www.vl.ru/transport/local/aeroexpress.html

Проживание

Цена на гостиницы во Владивостоке какая-то конская. Ну скажем так - конечно подешевле чем мы платили в Париже - но на уровне Амстердама - это точно. При том что качество как вы понимаете...
При этом - селиться в гостинице которая далеко от центра - есть свои минусы. Летом мы например заселились в Славянской - "первая речка" не так уж и далеко от центра - но добираться в любом случае было не удобно - пешком гулять не сильно захочется, город (кроме совсем центра) для этого не сильно предназначен, на общественном транспорте можно долго по пробкам стоять, на такси - да в те же пробки встанете.
Ну а в центре - цены. 5000 за номер за одного в Версале... при том что номера и на 3 звезды не тянут - ну это как-то перебор мне кажется.
Потому вариант - квартиры посуточно. Я платил 1900 рублей за квартиру в центре. Квартира не айс конечно - но зато в шаговой доступности от всех место что мне нужны были.
Правда при съеме надо учитывать не только расстояние по "горизонтали" - но и "по вертикали". У меня дом был практически на самом верху - и каждый день я проделывать привычные для местных упражнения - 100 метров вниз, 100 наверх.  И так несколько раз. По началу ноги даже болели - хотя я вроде и стараюсь держать себя в форме.
благодаря "холмистости" легко можно сделать вход на второй этаж
или случайно обнаружить что ваша квартира - в подвале - ниже входа в подъезд
вид с холмов

Город

Город хороший - мне все-таки определенно Владивосток понравился. Самое интересное, он "столичный". Я мог прочувствовать на себе - сразу после Владивостока поехал в Липецк. Сравнимый по размеру, не бедный город с развитой промышленностью и все такое. Но, Липецк и Владик - две большие разницы. Во Владике (ну может потому что я из центра и не вылезал) иногда и забывал что уехал из Питера.
графитти

Погода

Когда были в июле - сначала были дожди и очень влажно (даже по питерским меркам), потом стало солнце и круто - действительно курорт. Мы даже искупались. Говорят сезон в августе - но мы не застали.
В октябре - когда прилетели - вообще сугробы лежали. Потом растаяло. Но было холодно и дикий ветер.

Что смотреть, где гулять

Тут я не советчик, из за работы времени вообще не было  - получилось только в кампус на острове Русском выбраться.
Но уверен, особенно если есть кто знакомый местный - посмотреть много чего можно.
Набережная - пока я там был - открыли новую набережную в бухте "Золотой Рог" - но не могу сказать что мне понравилось - вид практически никакой, а "отреставрированные" заводские корпуса просто обшиты пластиком. Да и попасть на эту набережную - отдельная тема - для меня это было совсем не очевидно.
прям вдоль набережной идет действующая ветка ЖД
прогулка с видом на портовые краны
как из старого кирпичного здания сделать новое? обшить пластиком!
Выбираясь с этой набережной (для непосвященного в городскую географию задача тоже не тривиальная) наткнулся на "Артиллерийский" музей. Вообще-то он был закрыт, но узнав что я из Питера мужчина мне с удовольствием открыл и дал погулять. Экспозиция значительно меньше чем стоит в Питере - зато все экспонаты "боевые"
маленькая подводная лодка
японский танк
боевые раны

Зато набережная на Амурском заливе мне понравилась. Там конечно дует (ну или мне с погодой так повезло) - но хоть какой-то вид
закат над амурским заливом
море волнуется раз...
конечно же я не мог пройти мимо Непала
вид на город с залива

Зонтик я так и не купил, потому думаю у меня еще есть шанс сюда вернуться.
Тем более что я по прежнему остаюсь мэром на four square  в любимой "Корице"
 

Вышел Activiti 5.11

Вчера произошло очень радостное событие (для меня по крайней мере) - вышла новая версия Activiti? под номером 5.11
Радостное - потому что в этой версии сделано ряд вещей, очень интересных для нас, либо даже исправляющих критические для нас ошибки или добавляющие важную функциональность - которую мы только-только обсуждали как сделать.
Итак - что нового:

  • Избавились от дебильного инсталятора. В конце-концов у людей которые работают с Activiti не составит проблем самостоятельно скачать томкат и задеплоить веб-приложение. Это все что надо теперь что бы начать работать с activiti ( пока не посмотрел как настроить на свою базу)
  • В  Explorer встроили Modeler (приложение для рисования бизнес-процессов в web). Теперь можно прям в онлайн рисовать процессы, деплоить их и затем исполнять. Все это не покидая браузера, без переключения в  Eclipse или какие-либо еще desktop приложения
каталог смоделированых ("отрисованых") процессов
рсовать процессы можно теперь прямо в Explorer-е

  • Сам Explorer видимо серьезно доработан - заявлена возможность грузить собственные shape-ы (по крайней мере об этом говорил Tijs когда мы с ним общались по скайпу месяц назад), хранение моделей изменено с тупого хранения в файловой системе (надеюсь что теперь работа с моделями идет через некоторый унифицированный интерфейс), серьезно переработаны наборы атрибутов для shape-ов. То есть если раньше в Modeler-е можно было только рисовать (для исполнения процессы было необходимо допиливать в Eclipse-овом дизайнере), то теперь можно создавать вполне себе выполняемые процессы
  • Исправлено много ошибок. Мы с радостью обнаружили, например, что теперь в истории хранится связка между Call Activiti и созданным в ходе ее выполнения подпроцессом - раньше без этого невозможно было построить полное дерево выполнения процесса (что стало для нас критичным).
Подозреваю что много чего еще вкусного есть, что за первые часы экспериментов с новой версии мы не разведали.
Для тех кому интересно:

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

Liferay и Solr

Зачем SOLR

Liferay использует для поиска (индексации и выполнения запросов) Lucene - это "стандартное" решение для организации поиска в мире java (возможно и не только).
Что такое SOLR? Если очень утрированно - то это тот же lucene - только обернутый серверной оболочкой, позволяющей дернуть его удаленно по http протоколу.
Одна их хороших особенностей Liferay (хотя иногда это вызывает проблемы) - это то, что работа с внешними системами осуществляется через некоторое унифицированное API, что позволяет менять реализацию или используемые системы. Например как раз "подсовывая" свою реализацию Workflow API мы смогли научить Liferay использовать для бизнес-процессов не штатный Kaleo (велосипед еще тот) - а Activiti.
Работа с поиском осуществляется ровно тем же способом: при необходимости что-то проиндексировать или выполнить поисковый запрос Liferay обращается через некоторое унифицированное  API к подсистеме поиска. По умолчанию подсистема поиска использует Lucene, однако можно подсунуть другую реализацию - в частности для Liferay "из коробки" есть поддержка SOLR - реализованная в плагине solr-web.
Итак - в каких ситуациях имеет смысл использовать  SOLR:

  1. Кластеризация. Если у вас Liferay  поднят в кластере - использование Lucene  приведет к ошибкам. Дело в том, что Lucene  по умолчанию хранит свои индексы на файловой системе - при этом лочит их. Если каждая нода будет использовать свою папку для индексации - то поиск будет просто неправильно работать - в одной ноде вы создадите какую-то статью, lucene этой ноды ее проиндексирует,  но в случае выполнения поиска на других нодах вы просто не найдете этой статьи - потому что другие lucene ничего об этом знать не будут. Если же вы попробуете все lucene натравить на одну папку - то одна из них залочив индексы не пустит другие. Штатное решение - вынос поиска на SOLR - в этом случае все ноды обращаются к одному SOLR серверу.
  2. Вынос поисковой нагрузки. Если в вашем случае на поиск ложится большая нагрузка - то можно вынести поиск на отдельный (иногда более мощный) сервер (который в свою очередь тоже может кластеризоваться).
  3. Дополнительные возможности отладки поиска. К SOLR вы сможете обратить в режиме runtime  и сформировав правильные запросы посмотреть - что именно он сохранил и как он ищет. С Lucene это несколько сложнее.
Если один из приведенных случаев - ваш - добро пожаловать к продолжению:

Настройка интеграции Liferay и SOLR

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

  1. Поставить и настроить SOLR  сервер.  Он может быть установлен как на отдельном физическом сервере или отдельном сервере приложений (достаточно обычного томката), так и на том же сервере что и сам Liferay (в его же tomcat)
  2. В Liferay установить (предварительно собрав если это требуется) модуль интеграции с SOLR - solr-web. В случае если у вас кластер - установку надо будет сделать на все ноды кластера.

Установка и настройка  SOLR сервера

  • Скачать и распаковать (в некоторую папку <zip>) дистрибутив SOLR. Для версии Liferay 6.1.0 гарантированно работает версия SOLR 1.4.1, гарантированно не работает 4-ая, и вроде как после танцев с бубном работает SOLR 3.x - но оно вам надо (с бубном танцевать)? В 6.1.1 возможно будет работать SOLR 3.5 -  но надо проверять.
  • Создаем папку где будет жить solr (например /opt/solr)
  • кидаем <zip>/dist/apache-solr-1.4.1.war в /opt/solr
  • копируем <zip>/example/solr/conf в /opt/solr/conf
  • Заменяем /opt/solr/conf/schema.xml на файл docroot/WEB-INF/conf/schema.xml из исходников solr-web (откуда их взять - смотри ниже)
  • Исправляем /opt/solr/conf/solrconf.xml (прописываем где лежит data - что бы не искать ее потом по всему серверу):
<dataDir>${solr.data.dir:/opt/solr/data}</dataDir>
  • Делаем папку /opt/solr доступной для чтения-записи пользователем, под которым запущен tomcat (ну или какой там у вас  app server используется)
  • Кладем в tomcat (например в тот же что используется и для  liferay  - например в /opt/liferay/tomcat-7.0.27) файл /opt/liferay/tomcat-7.0.27/conf/Catalina/localhost/solr.xml с указанием контекста:
<?xml version="1.0" encoding="utf-8"?>
    <Context docBase="/opt/solr/apache-solr-1.4.1.war" debug="0" crossContext="true">
    <Environment name="solr/home" type="java.lang.String" value="/opt/solr" override="true"/>
</Context>
  • В результате должен запуститься solr (смотрим логи)
  • Если все запустилось - то должен появится http://<hostname>/solr - можно даже побаловаться - поделать запросы

Установка и сборка solr-web

Исходники solr-web можно взять из svn liferay тут: http://svn.liferay.com/repos/public/plugins/branches/6.1.x/webs/solr-web/
Только учтите - что тегов для определенной версии Liferay для прагинов нет, потому надо просто смотреть по истории ревизию на дату релиза необходимой версии Liferay (для Liferay 6.1.0 это например 7 января 2012 года) и берите исходники по данное ревизии (для Liferay 6.1.0 это будет ревизия 97229)
Сборка и деплой штатными средствами plugins sdk. Из настроек - требуется только подправить url  показывающий на SOLR сервер - либо в исходниках до сборки в файле docroot/WEB-INF/classes/META-INF/solr-spring.xml либо уже после деплоя (проигнорировав ошибку первого деплоя портлета - так как он не сможет обратиться к SOLR) в файле webapps/solr-web/WEB-INF/classes/META-INF/solr-spring.xml
<bean id="com.liferay.portal.search.solr.server.BasicAuthSolrServer" class="com.liferay.portal.search.solr.server.BasicAuthSolrServer">
<constructor-arg type="java.lang.String" value="http://localhost:8080/solr" />
</bean>
Вот этот localhost и надо поменять на реальный url.

Как проверить что работает

Первое что надо будет сделать после настройки - это вызвать переиндексацию. Control Panel -> Server Administration -> Reindex all indexes
При этом в логах томката где установлен SOLR  сервер должно посыпаться куча логов.
Что бы проверить что  SOLR работает на каждой ноде надо выполнить какое-нибудь действие обращающееся к подсистеме поиска - создать какой-нибудь  веб-контент, просто открыть и сохранить пользователя. Если при этом идут логи в SOLR  сервере - с высокой долей вероятности все работает :)

Важные замечания

У нас в одном из проектов solr  стоял в том же томкате что и первая нода, сторая обращалась к нему. Когда обращение делалось по порту 80 ( и потом прокидывалось nginx-ом) - то на второй ноде плагин solr-web не заводился - команды к  SOLR  вызывали ошибки. Когда поменяли на работу по порту 8080 - стало нормально. Видимо  nginx как-то портил запрос.

Ооооочень желательно что бы /solr не был доступен снаружи для анонимных пользователей. Можно отрубать доступ внешним сервером (apache  или nginx), или разрешать доступ только с определённых ip (что бы доступ был только с нод кластера). Ну и следить что бы по порту 8080 тоже было не достучатся.

Перед тем как перейти на использование SOLR - зайдите на issues.liferay.com -  и посмотрите... дальше сами решайте - надо вам или нет.

Если вы используете solr-web для версии 6.1.0 - обратите внимание на такую замечательную багу  как LPS-25152 - мне больше всего нравится что у нее приоритет minor. На самом желе эта бага о том, что если вы поставили SOLR для Liferay 6.1.0 -  то в панели управления у вас будут показываться пользователи и организации для всех portal instance-ов... вот такой вот минорный косячок :) Бага исправлена в 6.1.1 - для 6.1.1 ее надо бекпортить



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

Как вы боретесь с дебиторской задолежнностью?

Очень в тему вышел вопрос (и комментарии к нему) на smartsourcing: http://smartsourcing.ru/questions/148

Для меня этот вопрос в последние месяцы особенно актуален - хз с чем связано - то ли с надвигающимся мировым кризисом, то ли... но когда даже американцы начинают выкидывать кренделя говоря что "сегодня все платим" - а когда ты через неделю просишь уточнить в банке все ли нормально с платежом  выясняется (причем не после вопроса - а после того как "останавливаешь обслуживание" и ставишь вопрос ребром) что деньги не были отправлены в принципе (я был в шоке - как то привык что у них все-таки за слова в бизнесе отвечают - ну или хотя бы предупреждают что что-то не получилось сделать).

Вообщем наболело.

В ответах ничего нового - но просто окончательно уяснил для себя - пени нафиг - не те размеры заказов что бы они что-то значили. А вот остановка работ - действует. Потому в типовом договоре появится новый обязательный пункт.

Ну и как это не печально - надо быть жестким с клиентами. Пока ты хороший и "входишь в положение" - люди почему-то этим активно пользуются :(