Полгода назад мы рассказывали о том, как реализовали сервис бронирования переговорных комнат у крупного заказчика с территориально разнесенными офисами и штатом несколько тысяч человек. Мы продолжаем работать с SharePoint-порталом этой компании, в рамках его развития специалисты EastBanc Technologies создали еще один модуль — сервис управления заявками на отпуска в интеграции с автоматизированной системой управления персоналом БОСС-Кадровик.

Назначение этого сервиса, как нам кажется, не нуждается в пространном разъяснении: попросту говоря, сервис автоматизирует учет отпусков в компании. Гораздо интересней, какие практические задачи стояли перед нами в данной конкретной компании, об этом — дальше.

В этом топике мы делимся нашим реальным опытом в миграции порталов с 2010 на 2013 SharePoint. Вопрос давно решен, нужно мигрировать, и наверняка руководство уже поставило сроки, когда это должно быть сделано. Вот тут наш материал может оказаться полезным для понимания того, с какой стороны к этому делу подойти. Чтобы не делать огромную статью с кучей специфических вставок технической информации мы сосредоточились на главном — на различиях в миграции с 2007 на 2010 с миграцией 2010 на 2013 и на основных этапах.

Если перед вами стоит еще более сложная задача мигрировать 2007 на 2010, а потом на 2013, почитайте наш прошлогодний материал, там мы уже рассказывали про миграцию портала SharePoint 2007 на SharePoint 2010.

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

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

Например, сейчас у нас в работе есть SharePoint-портал, который используется для дистанционного расчетно-финансового обслуживания контрагентов компании-заказчика. У каждого контрагента имеется несколько пользователей — от 1 до 10. Мы хотели понять, как они обращаются с тем или иным функционалом. Чтобы обрисовать для себя их поведение, мы задействовали средства Google Analytics.

Всем привет!

В этой статье мы решили поделиться своими жизненными наблюдениями за проблемой производительности больших списков в SharePoint.

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

Нередко бизнес-процесс компании включает в себя необходимость обработки документации, содержащей штрих-коды, с последующим занесением их в некую учетную систему. Это актуально, например, для сферы ЖД-перевозок и авиакомпаний: в штрих-код купона, присылаемого на электронную почту агентами компании, зашиты номера билетов. Операционисты вынуждены ежедневно обрабатывать и заносить во внутреннюю учетную систему тысячи таких купонов.

Работа рутинная, человеческий фактор провоцирует ошибки. Как автоматизировать процесс и избавить оператора от необходимости ручной обработки писем и их вложений? Мы нашли простое решение с использованием MS SharePoint. По своему обыкновению, мы постарались по максимуму задействовать имеющийся функционал систем, существующую библиотеку и немного своей программистской магии.

Привет!

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

История и статистика использования Project Server в EastBanc Technologies

Мы используем Project Server c 2005 года для учета рабочего времени и планирования работ в рамках группы компаний, состоящей из двух офисов в разных часовых поясах — в России и США. Также учитываем в системе временно привлекаемых подрядчиков.

Примерная статистика:

Всего проектов в системе — 603,

Сотрудников — 216,

Табелей учета рабочего времени (они же time sheets, они же таймщиты) на проверку еженедельно — 140,

Задач в неделю 260.

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

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

Мы столкнулись с тем, что работа с рекламодателями в печатных СМИ поставлена, как говорится, «по старинке». Все в основном завязано на конкретных менеджеров по рекламе с минимальной автоматизацией – в основном, это таблички в Excel и разложенные по папочкам документы.

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

Данный обзор подготовлен с целью сравнить и показать преимущества одной из платформ (Microsoft Surface 2, Apple iPad). Рассмотрен вариант использования планшета не для развлечений, а в качестве рабочего инструмента. Делается сравнение по всем параметрам устройств: внешний вид, аксессуары, мощность и «живучесть» батареи и, самое главное, операционная система и доступные программные продукты. В конце обзора сделан вывод о том, какое устройство является наиболее удобным корпоративным планшетом.

В декабре 2013 года мы выступили на конференции Mobile Developer&Business Day с докладом «Особенности разработки мобильных приложений для СМИ». В презентации мы обобщили опыт EastBanc Technologies в разработке мобильных приложений для российских и американских СМИ, попытались коснуться всех важных вещей, которые когда-то стали для нас открытием. Мы хотим донести до читателей, как важно понимать, для чего вы делаете приложение: как поддержку бренда или расширение канала сбыта, т.к. по-нашему мнению для разработчика очень важно осознавать, за какую задачу он взялся и адекватно оценить ресурсо- и времязатраты.

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

Статья будет интересна всем, кто хочет узнать значение страшного термина «Active Directory Federation Services» на примере из реальной жизни, а также всем, кто занимается разработкой кастомных систем на базе SharePoint и находится в процессе принятия решения, какую модель авторизации и аутентификации выбрать, либо собирается переключить существующее решение на ADFS.

А самое главное, она пригодится тем, кому важны потребительские качества IT-продукта, его значение и удобство для конечного пользователя.

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

Это система лояльности для кассиров, которые продают услуги нашего заказчика. Выполнена на MS SharePoint. Через портал кассиры копят бонусы и получают за них подарки (сувенирку, турпутевки, подарочные карты и т.п.) Компания таким образом может гибко управлять продажами нужных «позиций», анализировать работу кассиров и агентств и много еще чего полезного.

Мы разрабатывали программу лояльности с самого начала. Первый релиз состоялся в феврале 2013 года. Развитие системы продолжается. Например, только что мы провели полный редизайн портала. Но этому предшествовала миграция на ADFS, как важнейший этап модернизации. Об этом — дальше речь.

The major difference between a thing that might go wrong and a thing that cannot possibly go wrong is that when a thing that cannot possibly go wrong goes wrong it usually turns out to be impossible to get at or repair.
— Douglas Adams

Objective C существует уже с 1983 года и является ровесником C++. Однако, в отличие от последнего он начал приобретать популярность только в 2008 году, после выхода iOS 2.0 — новой версии операционной системы для революционного iPhone, включавшей приложение AppStore, позволяющее пользователям приобретать приложения, создаваемые сторонними разработчиками.
Дальнейший успех Objective C обеспечивался не только популярность устройств на базе iOS и относительной легкостью продаж через AppStore, но и значительными усилиями компании Apple по совершенствованию как стандартных библиотек, так и самого языка.
Согласно рейтингу TIOBE к началу 2013 года Objective C обогнал по популярности C++ и занял третье место, уступая только C и Java.

На сегодняшний день Objective C включает и такие относительно старые функции как KVC и KVO, существовавшие еще за 4 года до выхода первого iPhone, и такие новые возможности как блоки (blocks, появившиеся в Mac OS 10.6 и iOS 4) и автоматический подсчет ссылок (ARC, доступный в Mac OS 10.7 и iOS 5), которые позволяют с легкостью решать задачи, вызывавшие серьезные трудности ранее.

KVO — это технология, позволяющая незамедлительно реагировать в одном объекте (наблюдателе) на изменения состояния другого объекта (наблюдаемого), без внесения знаний о типе наблюдателя в реализации наблюдаемого объекта. В Objective C, наряду с KVO, существует несколько способов решения этой задачи:

Несколько недель назад от наших заказчиков мы получили задачу на создание сервиса бронирования переговорных комнат. Компания заказчика довольна крупная и весьма продвинутая в плане ИТ. У заказчика много филиалов по всей России и в каждом по 5-6 переговорных комнат, сотрудники часто летают проводить совещания из одного филиала в другой, а найти свободную аудиторию «на месте» — это реальная проблема. Поэтому сотруднику было бы неплохо прямо со своего рабочего места в Москве «застолбить» переговорку, например, в Туле и со спокойной совестью лететь в командировку. Опытом создания подобного сервиса мы хотим поделится с хабросообществом.

1. Предыстория

Не смотря на то, что функция централизованного входа (Single Sign On, SSO) существует, обсуждается и применяется уже давно, на практике ее внедрение зачастую сопровождается преодолением самых различных проблем. Целью данной статьи будет показать, как реализовать простейший собственный Service Provider ¹ (SP) для SAML 2.0 identity provider (idP) и с его помощью осуществить интеграции SSO в Java Web приложение.

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

1. Liferay version 6.1.20-ee-ga2.
2. Простое java web-приложение.
3. Google apps.

Со стороны заказчика были выдвинуты основные требования построения SSO:

1. Для построения SSO должен использоваться протокол SAML 2.0.
2. Требуется интеграция с Jasig CAS для поддержания работы уже существующих систем.
3. LDAP используется для проверки аутентификации пользователей.

В качестве idP решили использовать Shibboleth (http://shibboleth.net/about/index.html) как open source-систему, реализующую в полном объеме протоколы SAML 1.0 && SAML 2.0.

Сложные моменты, с которыми мы столкнулись при решении данной задачи:

1. Отсутствие экспертизы по работе с протоколом SAML 2.0 и продуктом Shibboleth.
2. Сырая и еще не достаточно хорошо структурированная документация по Shibboleth от производителя.
3. Отсутствие качественных примеров по реализации Service Provider’а для интеграции SSO в свое Java Web-приложение.

Преодоление этих барьеров и стало мотивацией для публикации данной статьи. Мы хотим поделиться приобретенными знаниями, помочь разработчикам решать подобные задачи, а также облегчить знакомство с протоколом SAML 2.0.

2. Для кого предназначена статья?

Данная статья ориентирована на следующую аудиторию:

1. Разработчики, интегрирующие функцию SSO в своих проектах средствами SAML 2.0.
2. Java-Разработчики, которым нужен практический пример интеграции в свое приложение функции SSO средствами SAML 2.0.
3. Java-Разработчики, которые хотят опробовать в качестве SSO Identity Provider’а (idP) компонент Shibboleth.

Для понимания статьи рекомендуется иметь минимальные знания по протоколу SAML 2.0.

О реализации многопоточности при разработки Android-приложений уже написано немало. В этой же статье хочется провести сравнение нескольких распространенных на сегодня способов скачать/прочитать/сохранить/посчитать, при этом не дав пользователю повода для раздражения. Постараться понять, когда то или иное решение будет уместным, а чего лучше не делать вовсе. Попытаемся показать, почему привычных вещей, таких как класс Thread и пакет java.util.concurrent оказывается недостаточно, когда речь заходит об Android-приложении.

Если к вам уже приходили с вопросом «Где можно получить свежую сборку?», то вы прекрасно понимаете, зачем нужна автоматизация сборки и распространения. Никто не хочет тратить лишнее время на рутинную работу. Раньше мы пользовались утилитой под названием iOSBetaBuilder (http://www.hanchorllc.com/betabuilder-for-ios/). Это приложение предназначено для упрощения распространения AdHoc сборок iOS-приложения: нужно только ввести название и версию проекта, адрес (URL), где хочется выложить сборку, и получаются сгенерированные index.html и manifest.plist. На первое время этого достаточно.

Но когда проект достигает стадии багфиксинга, тратить лишние 5 минут на сборку и перепубликацию для QA – неохота и некогда. А когда проектов становится много, а их сборки становятся дольше… В рамках компании затраты времени помноженные на количество проектов становятся слишком существенными, и приходит время автоматизации.

В этой статье мы расскажем как настроить автоматическую сборку iOS приложений, рассылку уведомлений по почте и публикацию приложения на FTP-сервере для тестирования и демонстрации заказчику.

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

Всем привет.

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

Речь пойдет, конечно, о коде.

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

Да и давайте признаемся — все мы любим писать “фреймворки”, которыми пользуемся потом сами и которыми пользуются другие. Это добавляет немного куража нашей повседневной деятельности.

И тут автор ловит себя на том, что поступает неправильно, начиная описывать ситуации — все и так понимают, о чем речь. А описать нужно технологии и процесс. Поэтому давайте просто остановимся на абстрактной мысли, что внезапно нашлось много кода, который может быть полезен коллегам и его хорошо бы сделать легкодоступным. Также примем во внимание вторую, куда менее приятную, мысль, что в “зрелых” проектах можно найти большое количество copy-paste кода, значительно понижающего сопровождаемость. Да и работу над такими проектами приятной назвать трудно. И с этим надо что-то делать.

И мы решили с этим что-то делать.

Привет!

У нас есть корпоративный сайт на Liferay, и он требует довольно кропотливой работы на этапе создания layout. Мы решили посмотреть, чем отличается создание кастомного раздела в Liferay от того же процесса в Orchard CMS в рамках такой небольшой задачки как создание корпоративных новостей.



Что у нас из этого вышло:

Привет!

В июле мы анонсировали публикацию мобильных приложений для делового информационного портала BFM.ru — iOS и Windows 8-версии. Для нашего отдела мобильной разработки этот проект стал еще одним приложением для новостных ресурсов, среди которых — Newsweek, Slate, Engadget и другие. Чтобы обобщить опыт и поделиться им с читателями, для которых актуальны вопросы дизайна новостных приложений, мы решили сделать небольшую ретроспективную зарисовку, посвященную дизайну линейки мобильных приложений портала BFM.ru.

Привет!

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

Что важно: это не очередной агрегатор соцсетей, ключевое слово тут «корпоративный»!