Привет, Хабр!
В этой статье мы хотим поделиться своим опытом работы с программным продуктом Microsoft Dymanics CRM 2013 Online – для чего и как его можно использовать, возможные проблемы типового развертывания, типовой функционал – достоинства, недостатки и пути решения проблем с наименьшими затратами.

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

Привет, Хабр! В этой статье мы делимся опытом по распространению корпоративного приложения для Windows Storе.

Есть у нас клиент. Отличный клиент, для которого мы создали, внедрили и продолжаем развивать большое портальное решение по дистанционному обслуживанию агентов. Примерно год назад было принято решение о создании мобильного рабочего места сотрудника на базе Windows 8 планшетов.
Но создать приложение — это лишь одна задача. Необходимо было продумать следующий шаг: оно должно быть установлено на планшеты компании-заказчика и разойтись по России, потому что конечные пользователи —это представители компании в различных регионах. При этом должен присутствовать механизм обновления приложений, так как без этого, сами понимаете, никуда.

Дорогие Хабролюбители, всем привет! Не откроем Америку если скажем, что существуют сотни плагинов и библиотек, которые облегчают специализированные задачи, связанные с построением современных web интерфейсов. Angular один из них, про его производительность писалось много и в большинстве случаев даются рекомендации чего не нужно делать, чтобы все было хорошо.

Основной аргумент сторонников — медленно работают неправильные приложения, а вот правильные не должны содержать более 2000-3000 элементов. Если содержит больше значит что-то не так. См. например http://iantonov.me/page/angularjs-osnovy.

Аргумент в общем вполне здравый, но всегда есть ситуации, когда нужно написать «неправильное» web приложение потому, что такие требования. В этой статье мы решили рассказать как раз про такую задачу, и как мы ее решили. На наш взгляд статья будет полезна в большей степени профессиональным веб разработчикам. Итак, наша задача была сделать календарь для системы бронирования для одного спортивного клуба. Календарь отображает семь 12–часовых блоков, каждый день из которых разделен на 15 минутные интервалы. В блоке может быть от 2-х до 10 DOM элементов. Вроде ничего не предвещало беды, верхняя граница ~3000.

Одна из самых примечательных задач, которая когда-либо стояла перед QA-отделом EastBanc Technologies, заключается в создании автоматизированной системы тестирования сайта www.washingtonpost.com. Это электронная газета, реализованная в виде информационного и новостного портала.

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

Перед нами не стоит задачи проверить все страницы на соответствие нашим тестам. Наша задача — выявить баги PageBuilder’a, проверить надежность верстки страниц, созданных свежеиспеченным PageBuilder’ом, обратить внимание редакторов Вашингтонпоста на те ньюансы наполнения конкретной страницы контентом, которые могут повлечь за собой потенциальные проблемы в отображении страниц.
Создание системы тестирования находится в стадии активной разработки, но некоторые, интересные на наш взгляд, моменты уже можно представить на суд широкой публики.

Прежде чем мы это сделаем, необходимо отметить одну особенность проекта: все тестирование у нас происходит «снаружи». Т.е. мы, как и любой другой юзер, используем для тестирования боевую версию сайта.

Во время посещения PyConRu 2014 я, с удивлением, узнал, что достаточно большая аудитория python-разработчиков не использует SQLAlchemy в качестве основного инструмента для работы с базой данных. Порассуждав на данную тему после Light Talks с коллегами было принято решение — во чтобы то ни стало написать статью о том, что же можно делать со всей мощью SQLAlchemy.

Обычно в написании сайтов не требуется чего-нибудь этакого от штатного ORM. А если и требуется, то хватает замены на нештатный или прочтения основной части документации. И, как правило, голову ломать над сложными запросами не приходится. Достаточно много различных ORM предлагают классические схемы One-2-Many, One-2-One, Many-2-Many, и т.д. Для обычных запросов и связей этого вполне достаточно. К сожалению, в больших проектах не обходится без частных случаев и программисты при сложных запросах пишут либо raw sql, либо полагаются на то, что им предлагает базовый функционал ORM. Это выглядит не совсем красиво или создает достаточно большую нагрузку на базу данных.

Понятно, что в погоне за скоростью выполнения сценариев, можно пожертвовать красотой кода, но что если скоростью можно пренебречь, а вот кроссплатформенностью — нет? Да и не хочется в python коде видеть что-то кроме python кода. А что если хочется на полную катушку использовать любимый ORM (для меня SQLAlchemy) и не писать raw sql запросы?

С удовольствием представляем хабрасообществу мобильное приложение для гражданских журналистов «Спецкор», с помощью которого можно снимать фото- и видеорепортажи и продвигать их под эгидой «Комсомолки». Главный создатель — ИД «Комсомольская правда», IT-приспешники и разработчики — мы, компания EastBanc Technologies. Проект анонсирован «Комсомолкой» в конце апреля 2014 года, тогда же запущены первые конкурсы. Мы же со своей стороны решили поделиться техническими деталями реализации приложения. На наш взгляд, это будет интересным для читателей, потому что редко в одном проекте возникает столько нетривиальных технологических и бизнес-задач одновременно.

«Спецкор» относится к многоплатформенным клиент-серверным приложениям с административным интерфейсом. Клиентская часть реализована на мобильных платформах iOS и Android и содержит следующий функционал:

Уважаемые айфоноводы, бывает ли с вами такое, что вы скачали приложение, а там… всё не то и не так и не на своих местах? Когда ваш юзер-экспириенс подсказывает вам, что приложение устроено неправильно: нажимаете вы, например, кнопку, которая всегда в iOS означала «Поделиться», а вам вместо этого вываливается какое-нибудь «левое» меню… Возникает неприятная фрустрация, и вы, скорее всего, сносите приложение со своего смартфона.

Мы хотим поделиться своим опытом доработки Microsoft Project Server 2010 под специфические требования заказчика.

Данная статья может быть интересна как бизнес-пользователям, которые могут узнать о новых возможностях платформы применительно к собственной компании, так и техническим специалистам, которые могут подчерпнуть из статьи новые знания о методах доработки Microsoft Project Server 2010.

Небольшое введение

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

Информационная система управления проектной деятельностью в идеальном случае должна обеспечивать следующий функционал (далеко не полный, но, в общем, достаточный):

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



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

То, что мы увидели на сканах талонов, сильно напоминало штрих-код Codabar, с которым нам уже приходилось сталкиваться на других проектах.

В этом топике мы хотим поделиться нашим опытом создания мобильных приложений на платформе для разработки кроссплатформенных приложений Titanium. Примерно с 2011 мы начали работы с кроссплатформенными фреймворками. Сначала это был PhoneGap, потом Titanium. Сделали десяток приложений, работающих и по сей день, как в России, так и в США. Мы сознательно хотим отойти от оценок — плохо это или хорошо разрабатывать кроссплатформенные приложения, а сосредоточиться на тех трудностях, с которыми предстоит столкнуться с точки зрения разработки и сопровождения этих приложений.

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

Итак, начнем со списка проблем, с которыми вам придётся столкнуться.

Проблемы:

1. Проблема дабл-кликов.
2. If’ный код.
3. Управление памятью на Android.
4. Недостаточная реализация отдельных функций, в том числе стандартных.
5. Javascript — отсутствие типизации замедляет процесс написания кода и усложняет сопровождение.
6. Отсутствие InterfaceBuilder — замедляет процесс написания приложения, весь UI пишется в коде.
7. Titanium SDK обновляется позже SDK операционных систем.
8. Каждая версия SDK содержит исправление старых ошибок и привносит новые ошибки.

Примеры, на которых мы столкнулись с этими проблемами.

Полгода назад мы рассказывали о том, как реализовали сервис бронирования переговорных комнат у крупного заказчика с территориально разнесенными офисами и штатом несколько тысяч человек. Мы продолжаем работать с 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 в разработке мобильных приложений для российских и американских СМИ, попытались коснуться всех важных вещей, которые когда-то стали для нас открытием. Мы хотим донести до читателей, как важно понимать, для чего вы делаете приложение: как поддержку бренда или расширение канала сбыта, т.к. по-нашему мнению для разработчика очень важно осознавать, за какую задачу он взялся и адекватно оценить ресурсо- и времязатраты.

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