Добрался до Киева. Тут мороз почище нашего, зато весь город очень нарядно выглядит (может за счет чистого белого снега на улицах)
Квартира досталась отличная, по цене ниже чем я снимал во Владике, но несравненно уютней и комфортней.
Из окна отличный вид, был бы, если бы его, как и во Владивостоке, не портили недостроенные многоэтажки.
А еще выяснилось, что 3G есть только у киевстара и только при заключении контракта на год... как то странно, такое ощущение что продавец меня напарил.
среда, 19 декабря 2012 г.
В Киеве
среда, 12 декабря 2012 г.
Поиск билетов
Не рекламы ради, а просто интересное наблюдение.
Для поиска билетов я чаще всего пользуюсь сайтом Eviterra/ Знаю, таких сервисов много, просто как-то увидел рекламный пост в блоге Темы Лебедева, начал пользоваться и привык. Причем часто просто нахожу Авиакомпанию которая предлагает наиболее низкий перелет и потом смотрю билет уже на ее сайте.
Хотя, иногда Eviterra может делать вещи, которые сайт какой-то одной компании вам не сделает:
Для поиска билетов я чаще всего пользуюсь сайтом 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);
Есть более просто решение - 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 - видимо это тоже внесло свою лепту.
Некоторое последнее время пришлось плотно заниматься нагрузочным тестированием одного из проектов. Там у нас используется 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 лучше:
- Стандартные widget-ы BackBase уже поддерживают адаптацию для мобильной платформы. В Liferay такую адаптацию придется программировать (в виде специальной css) самостоятельно - Liferay только дает возможность определить тип платформы и задать некоторые специальные стили. То есть "из коробки" Liferay со стандартной темой не будет красиво адаптироваться под мобильные платформы. Однако как можно посмотреть на примере того же http://www.liferay.com - такое относительно несложно реализуется
- Персонализация в 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 - а то замерзнете нафик.
Выбираю "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, а вот теперь фиг знает.
Итак - какие есть альтернативы:
Small Business 6$ за пользователя в месяц (по сравнению с Hosted Email добавляется работа с файлами) - по сути дела по набору фич близко к тому что дает Google Apps.
Причем - Microsoft как раз вводит достаточно тонкую градацию - можно хорошо подобрать именно тот план который нужен.
И за Office 365 играет то, что Microsoft очень силен до сих пор на десктопах и Enterprise мире - большинство рабочих мест по прежнему использует Windows + MS Office - и тесная интеграция с "облаком" играет на руку Microsoft.
Ну и глядишь, мобильники на Windows 8 все-таки подтянутся.
Планы тут: http://www.ibm.com/cloud-computing/social/us/en/planspricing/ - правда без цен (вообще сайт IBM в этом плане какой-то совсем не понятный)
Но опытным путем вычислил что цена за IBM SmartCloud Engage - Advanced (а именно у этого плана стояла поддержка почты) составляет 10$ за пользователя (без скидок при оплате сразу за го - так же 120 и получается).
В прицнипе когда то работали с Lotus-ом и их средствами online meeting-ов - оооочень круто и мощно (по тем временам) - но.... IBM мне кажется как обычно смотрит на больших клиентов - не уверен что "мелким" - типа меня - это вряд ли будет интересно - и по цене и по сложности.
Что-нибудь еще?
Итого - фиг знает, фиг знает - но мне кажется они этим шагом сделали большой подарок Microsoft-у, все-таки, при общих равных пользователи с большей долей вероятности выберут решение о Microsoft - просто потому что на компьютерах у них стоит тот же Microsoft.
Честно говоря очень расстроен. Не мне учить 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 в любимой "Корице"
Набережная - пока я там был - открыли новую набережную в бухте "Золотой Рог" - но не могу сказать что мне понравилось - вид практически никакой, а "отреставрированные" заводские корпуса просто обшиты пластиком. Да и попасть на эту набережную - отдельная тема - для меня это было совсем не очевидно.
прям вдоль набережной идет действующая ветка ЖД |
прогулка с видом на портовые краны |
как из старого кирпичного здания сделать новое? обшить пластиком! |
маленькая подводная лодка |
японский танк |
боевые раны |
Зато набережная на Амурском заливе мне понравилась. Там конечно дует (ну или мне с погодой так повезло) - но хоть какой-то вид
закат над амурским заливом |
море волнуется раз... |
конечно же я не мог пройти мимо Непала |
вид на город с залива |
Зонтик я так и не купил, потому думаю у меня еще есть шанс сюда вернуться.
Тем более что я по прежнему остаюсь мэром на four square в любимой "Корице"
Вышел Activiti 5.11
Вчера произошло очень радостное событие (для меня по крайней мере) - вышла новая версия Activiti? под номером 5.11
Радостное - потому что в этой версии сделано ряд вещей, очень интересных для нас, либо даже исправляющих критические для нас ошибки или добавляющие важную функциональность - которую мы только-только обсуждали как сделать.
Итак - что нового:
Радостное - потому что в этой версии сделано ряд вещей, очень интересных для нас, либо даже исправляющих критические для нас ошибки или добавляющие важную функциональность - которую мы только-только обсуждали как сделать.
Итак - что нового:
- Избавились от дебильного инсталятора. В конце-концов у людей которые работают с Activiti не составит проблем самостоятельно скачать томкат и задеплоить веб-приложение. Это все что надо теперь что бы начать работать с activiti ( пока не посмотрел как настроить на свою базу)
- В Explorer встроили Modeler (приложение для рисования бизнес-процессов в web). Теперь можно прям в онлайн рисовать процессы, деплоить их и затем исполнять. Все это не покидая браузера, без переключения в Eclipse или какие-либо еще desktop приложения
каталог смоделированых ("отрисованых") процессов |
рсовать процессы можно теперь прямо в Explorer-е |
- Сам Explorer видимо серьезно доработан - заявлена возможность грузить собственные shape-ы (по крайней мере об этом говорил Tijs когда мы с ним общались по скайпу месяц назад), хранение моделей изменено с тупого хранения в файловой системе (надеюсь что теперь работа с моделями идет через некоторый унифицированный интерфейс), серьезно переработаны наборы атрибутов для shape-ов. То есть если раньше в Modeler-е можно было только рисовать (для исполнения процессы было необходимо допиливать в Eclipse-овом дизайнере), то теперь можно создавать вполне себе выполняемые процессы
- Исправлено много ошибок. Мы с радостью обнаружили, например, что теперь в истории хранится связка между Call Activiti и созданным в ходе ее выполнения подпроцессом - раньше без этого невозможно было построить полное дерево выполнения процесса (что стало для нас критичным).
Подозреваю что много чего еще вкусного есть, что за первые часы экспериментов с новой версии мы не разведали.
Для тех кому интересно:
- Официальный анонс: http://bpmn20inaction.blogspot.ru/2012/12/activiti-511-released.html
- Ссылка на скачивание: http://activiti.org/download.html
вторник, 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:
- Кластеризация. Если у вас Liferay поднят в кластере - использование Lucene приведет к ошибкам. Дело в том, что Lucene по умолчанию хранит свои индексы на файловой системе - при этом лочит их. Если каждая нода будет использовать свою папку для индексации - то поиск будет просто неправильно работать - в одной ноде вы создадите какую-то статью, lucene этой ноды ее проиндексирует, но в случае выполнения поиска на других нодах вы просто не найдете этой статьи - потому что другие lucene ничего об этом знать не будут. Если же вы попробуете все lucene натравить на одну папку - то одна из них залочив индексы не пустит другие. Штатное решение - вынос поиска на SOLR - в этом случае все ноды обращаются к одному SOLR серверу.
- Вынос поисковой нагрузки. Если в вашем случае на поиск ложится большая нагрузка - то можно вынести поиск на отдельный (иногда более мощный) сервер (который в свою очередь тоже может кластеризоваться).
- Дополнительные возможности отладки поиска. К SOLR вы сможете обратить в режиме runtime и сформировав правильные запросы посмотреть - что именно он сохранил и как он ищет. С Lucene это несколько сложнее.
Если один из приведенных случаев - ваш - добро пожаловать к продолжению:
Настройка интеграции Liferay и SOLR
В принципе Liferay Wiki содержит инструкцию, однако она не совсем внятная и к тому же на иностранном языке. Попробую изложить свои рецепты.В целом, для выполнения данной задачи необходимо выполнить следующие шаги:
- Поставить и настроить SOLR сервер. Он может быть установлен как на отдельном физическом сервере или отдельном сервере приложений (достаточно обычного томката), так и на том же сервере что и сам Liferay (в его же tomcat)
- В 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 - что бы не искать ее потом по всему серверу):
- Делаем папку /opt/solr доступной для чтения-записи пользователем, под которым запущен tomcat (ну или какой там у вас app server используется)
- Кладем в tomcat (например в тот же что используется и для liferay - например в /opt/liferay/tomcat-7.0.27) файл /opt/liferay/tomcat-7.0.27/conf/Catalina/localhost/solr.xml с указанием контекста:
<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
Для меня этот вопрос в последние месяцы особенно актуален - хз с чем связано - то ли с надвигающимся мировым кризисом, то ли... но когда даже американцы начинают выкидывать кренделя говоря что "сегодня все платим" - а когда ты через неделю просишь уточнить в банке все ли нормально с платежом выясняется (причем не после вопроса - а после того как "останавливаешь обслуживание" и ставишь вопрос ребром) что деньги не были отправлены в принципе (я был в шоке - как то привык что у них все-таки за слова в бизнесе отвечают - ну или хотя бы предупреждают что что-то не получилось сделать).
Вообщем наболело.
В ответах ничего нового - но просто окончательно уяснил для себя - пени нафиг - не те размеры заказов что бы они что-то значили. А вот остановка работ - действует. Потому в типовом договоре появится новый обязательный пункт.
Ну и как это не печально - надо быть жестким с клиентами. Пока ты хороший и "входишь в положение" - люди почему-то этим активно пользуются :(
Для меня этот вопрос в последние месяцы особенно актуален - хз с чем связано - то ли с надвигающимся мировым кризисом, то ли... но когда даже американцы начинают выкидывать кренделя говоря что "сегодня все платим" - а когда ты через неделю просишь уточнить в банке все ли нормально с платежом выясняется (причем не после вопроса - а после того как "останавливаешь обслуживание" и ставишь вопрос ребром) что деньги не были отправлены в принципе (я был в шоке - как то привык что у них все-таки за слова в бизнесе отвечают - ну или хотя бы предупреждают что что-то не получилось сделать).
Вообщем наболело.
В ответах ничего нового - но просто окончательно уяснил для себя - пени нафиг - не те размеры заказов что бы они что-то значили. А вот остановка работ - действует. Потому в типовом договоре появится новый обязательный пункт.
Ну и как это не печально - надо быть жестким с клиентами. Пока ты хороший и "входишь в положение" - люди почему-то этим активно пользуются :(
Подписаться на:
Сообщения (Atom)