Реализация

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

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

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

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

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

Реализация

Реализация этого проекта была нам очень интересна и потребовала решения ряда технических и вычислительных задач.

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

Пользователь загружает 3D модель в редактор и сразу видит, как будет выглядеть воплощённый объект с учётом выбранного масштаба. Исходная модель может иметь особенности, не позволяющие её корректно напечатать, например, недостаточная для веса модели толщина стенки или основания, формируемого из горячего материала, не замкнутые до конца поверхности объекта, слишком мелкие детали и т.п. Нами был разработан алгоритм, который выявляет и заполняет проблемные участки модели полигонами и сглаживает мелкие детали в случае невозможности их печати. Это позволяет получать модель, пригодную для максимально точного воспроизведена на данном принтере и проводить верный расчет объема необходимого материала. Произведенные редактором изменения выделяются цветом, и пользователь может легко оценить конечный результат.

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

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

Реализация

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

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

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

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

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

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

Реализация

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

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

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

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

Реализация

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

Главная особенность данной системы заключается в том, что она ориентирована на “крупных” владельцев доменных имён, работающих одновременно с более 1000 доменов. Это удалось реализовать с помощью так называемой “пакетной обработки” - владелец доменов формирует свой запрос сразу для большого числа доменных имен в виде “пакета”. Например, когда происходит изменение контактных данных владельца имен, пользователь в программе выбирает доменные имена, которых коснутся изменения. Затем он указывает, какая информация будет изменена, после этого в системе формируется пакет состоящий из списка изменений для каждого имени и отравляет его на обработку. По окончании обработки, владелец получает отчет сразу по всем именам из пакета о проведенных изменениях или о невозможности выполнения операции по какой-то причине. Данная технология позволила избежать проблем связанных с ограничением по количеству единовременных операций от одного пользователя, проблем с длительной обработкой, требующей постоянного интернет-соединения, удалось разрешить конфликты, связанные с очередностью действий пользователей - через пакеты все запросы корректно обрабатывались в поступившем порядке.

Все популярные системы, позволяющие производить различные типы операций с доменными именами являются так называемыми “посредниками” между клиентами и истинными регистраторами в любой из зон (.ru, .com, .net, и т.п.). Для предоставления вышеописанных услуг, таким компаниям приходится интегрировать их систему с API каждого из регистраторов в отдельности. В связи с тем, что отсутствует единая спецификация, одни и те же ситуации могут обрабатываться системой по-разному - это является основной проблемой.

С доменным именем может производиться множество типов операций (до 20), а для каждого типа операции предусмотрены свои типы ошибок, которые нужно отловить, заранее продумать и составить модель поведения системы для каждой возможной ситуации, реализовать эту модель и после многократно протестировать всю систему.

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

Реализация

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

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

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

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

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

Реализация

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

Первая версия сайта была успешно реализована и введена в эксплуатацию. Сайт быстро набирал популярность, собрав несколько сотен пользователей. Наша компания осуществляла поддержку системы.

На первоначальном этапе сайт выставлял на торги по одному элитному доменному имени в день. Каждое доменное имя сопровождалось большим количеством информации: кто владел именем, какие сайты существовали не нём, какие маркетинговые возможности доменное имя имеет. Участники делали ставки, и шло активное обсуждение в чате.

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

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

Реализация

Этот проект не был региональным, решение должно было быть реализуемым в любом населённом пункте. Пользователь может делать метки на карте в любых местах, которые ему необходимо посетить.

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

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

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

Реализация

Задача нашей компании состояла в полной переработке текущего сайта заказчика, который был написан крайне некорректно ранее фрилансером (пропадали товары из БД, терялись заказы и т.д.).

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

Мы сделали для магазина специфическую систему фильтрации для поиска товаров по различным пораметрам (цвет, мощность, световой поток, и т.д).

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

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

Некоторые из товаров продавались только кратным количеством, в связи с этим приходилось корректно рассчитывать стоимость с учетом этой кратности, фильтровать товары и т.д.

Реализован заказ “в один клик”.