Уважаемые айфоноводы, бывает ли с вами такое, что вы скачали приложение, а там… всё не то и не так и не на своих местах? Когда ваш юзер-экспириенс подсказывает вам, что приложение устроено неправильно: нажимаете вы, например, кнопку, которая всегда в iOS означала «Поделиться», а вам вместо этого вываливается какое-нибудь «левое» меню… Возникает неприятная фрустрация, и вы, скорее всего, сносите приложение со своего смартфона.
Мы в EastBanc Technologies часто сталкиваемся с необходимостью снять демо- или промо-ролик о мобильных приложениях, которые разрабатываем. Цели могут быть разные — иногда мы делаем это для наших клиентов в качестве инструкции по применению приложения, иногда снимаем для широкой аудитории и выкладываем на свой Youtube-канал. Главное, что всегда хочется сделать это быстро и в приличном качестве.
В этом топике мы хотим поделиться нашим опытом создания мобильных приложений на платформе для разработки кроссплатформенных приложений Titanium. Примерно с 2011 мы начали работы с кроссплатформенными фреймворками. Сначала это был PhoneGap, потом Titanium. Сделали десяток приложений, работающих и по сей день, как в России, так и в США. Мы сознательно хотим отойти от оценок — плохо это или хорошо разрабатывать кроссплатформенные приложения, а сосредоточиться на тех трудностях, с которыми предстоит столкнуться с точки зрения разработки и сопровождения этих приложений.
На наш взгляд, топик будет полезен как читателям, которые собираются заказать приложение, чтобы они могли сделать выбор между native-разработкой на каждую платформу и кроссплатформенностью, так и разработчикам, которые принимают решение, куда идти.
Итак, начнем со списка проблем, с которыми вам придётся столкнуться.
Проблемы:
Примеры, на которых мы столкнулись с этими проблемами.
Полгода назад мы рассказывали о том, как реализовали сервис бронирования переговорных комнат у крупного заказчика с территориально разнесенными офисами и штатом несколько тысяч человек. Мы продолжаем работать с 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 c 2005 года для учета рабочего времени и планирования работ в рамках группы компаний, состоящей из двух офисов в разных часовых поясах — в России и США. Также учитываем в системе временно привлекаемых подрядчиков.
Всего проектов в системе — 603,
Сотрудников — 216,
Табелей учета рабочего времени (они же time sheets, они же таймщиты) на проверку еженедельно — 140,
Задач в неделю 260.
