google protocol buffers: наследование, поиск

Статья состоит из двух частей. В первой части содержится вольный пересказ статьи о статьи о наследовании в protobuf. Вторая часть посвещенна назойливой рекламе самописному «велосипеду» для работы с фреймворком.

Статья не содержит ответа на вопрос «что такое google protocol buffers» и не привязана какому-то конкретному языку програмирования.

Итак, постановка задачи:

• Как имплементировать полиморфизм, при работе с protocol buffers.


• Как искать и находить нужные данные, имея большой файл с сообщениями.

Часть I: Наследование

Предположим, наш протокол содержит три класса объектов: Square, Circle и Polygon. Предположим так же, что все они имеют поле color и поле id. В этом месте у нас появляется несколько причин унаследовать их от общего предка Shape. И, наверное, если бы мы писали на языке с поддержкой полиморфизма, наш код выглядел бы следуюшим образом:

псевдокод

           enum Color { 
                RED, 
                GREEN, 
                BLUE
        }
        
        
        struct Point {
                int x;
                int y;
        }
        
        
        struct Shape  {
                int   id;
                Color color;
        }
        
        struct Square extends Shape {
                Point  corner;
                int    width;
        }
        
        struct Circle  extends Shape {
                Point  center;
                int    radius;
        }
        
        struct Polygon  extends Shape {
                Point [] points;
        }

К сожалению, google protocol buffers не поддерживают иерархий. Jon Parise рассматривает три варианта обхода этого ограничения.

Использование опциональных полей

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

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

Кроме того, такой подход позволяет создать никому не известный квадрато-круг, инициализировав оба (square и circle) поля.

geom-1.proto

        enum Color {
                RED   = 1;
                GREEN = 2;
                BLUE  = 3;
        }

        message Point {
                required fixed32 x = 1;
                required fixed32 y = 2;
        }

        message Square  {
                required Point   corner = 1;
                required fixed32 width  = 2;
        }

        message Circle  {
                required Point   center = 1;
                required fixed32 radius = 2;
        }

        message Polygon  {
                repeated Point   points = 1;
        }

        message Shape  {
                required TYPE    type  = 1;
            required fixed32 id    = 2;
                optional Color color   = 3;

                // наследование
                optional Square  square = 4;
                optional Circle  circle = 5;
                optional Polygon polygon= 6;
        }

Вложеная серилизация

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

Так же не самый удачный вариант, так как «сериализатор» не будет «распаковывать» содержимое поля subclass, и соответственно не будет проведена проверка целостности.

Да и вообще, не красиво как-то.

geom-2.proto

        enum TYPE {
                SQUARE  = 1;
                CIRCLE  = 2;
                POLYGON = 3;
        }

        enum Color {
                RED   = 1;
                GREEN = 2;
                BLUE  = 3;
        }

        message Point {
                required fixed32 x = 1;
                required fixed32 y = 2;
        }

        message Square  {
                required Point   corner = 1;
                required fixed32 width  = 2;
        }

        message Circle  {
                required Point   center = 1;
                required fixed32 radius = 2;
        }

        message Polygon  {
                repeated Point   points = 1;
        }

        message Shape  {
                required TYPE    type  = 1;
            required fixed32 id    = 2;
                optional Color color   = 3;

                // наследование
                required bytes subclass = 4;            
        }

вложеные расширения

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

geom-final.proto

    enum TYPE {
                SQUARE  = 1;
                CIRCLE  = 2;
                POLYGON = 3;
        }

        enum Color {
                RED   = 1;
                GREEN = 2;
                BLUE  = 3;
        }

        message Point {
                required fixed32 x = 1;
                required fixed32 y = 2;
        }

        message Shape  {
                required TYPE    type  = 1;
            required fixed32 id    = 2;
                optional Color color   = 3;

                extensions 4 to max;
        }

        message Square  {
                extend Shape {
                        required Square shape = 5;
                }  

                required Point   corner = 1;
                required fixed32 width  = 2;
        }

        message Circle  {
                extend Shape {
                        required Circle shape = 6;
                }  

                required Point   center = 1;
                required fixed32 radius = 2;
        }

        message Polygon  {
                extend Shape {
                        required Polygon shape = 7;
                }  

                repeated Point   points = 1;
        }

Часть II: Поиск

И так, у нас есть файл с описанием структуры сообщений (geom.proto). Наша програма отработала и создала большой файл с самими сообщениям. Хотелось бы находить в нем нужную информацию, а простым текстовым поиском это не всегда возможно.

Например:

• Найдти окружности пересекаюшие оси координат.


• Найдти полигоны с пустым множеством точек


• Найдти полигоны с больше чем 10-ю точками.

Согласитесь, обычный grep нам здесь не поможет.

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

Вернемся с примерам задач:

• type == "CIRCLE" && ((center.x - radius) < 0 || (center.y - radius) < 0)) // Найдти окружности пересекаюшие оси координат.


• type == "POLYGON" && #points == 0 // Найдти полигоны с пустым множеством точек


• type == "POLYGON" && #points > 10 // Найдти полигоны с больше чем 10-ю точками.

Все это, и многое другое умеет делать самописный велосипед.

А так же, он умеет

• Перегонять файлы из бинарного формата в текстовый и наоборот


• Вырезать и распечатывать только определенные поля из сообщений


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

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

Спасибо.

This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.

Дайджест интересных материалов из мира веб-разработки и IT за последнюю неделю №113 (8 — 14 июня 2014)

Только зарегистрированные пользователи могут оставлять комментарии.

Войдите, пожалуйста.

Пометьте топик понятными вам метками, если хотите

Метки лучше разделять запятой. Например: общение, социальные сети, myspace.com, подростки, мердок

или закрыть

This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.

Хитрый и китайский рандом или «закон сохранения массы никто не отменял»

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

Все рисунки (рисунок) делал в Paint'e.

Суть

Для примера приведу стандартный float/double рандом в диапозоне от 0 до 1 (в нашем случае 1 не включается в набор, поскольку генерирует дробь). Еще у нас доступен набор целочисленных. Так вот. В математике можно просто растянуть умножением. Но в компьютерной реальности лучше этого не делать, а генерировать плотную последовательность как есть. Как это сделать? Правильно: генерировать как минимум два случайных числа. Суть в том, что мы охватывает все возможные точности при генерации случайных чисел в диапазонах (в нашем случае от 0 до N).

Стандартный рандом. Точность такая, какая есть.

random = random()

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

random = random() * 2.0

Китайский двойной рандом. Не вредит точности, либо вредит не сильно.

random = random() > 0.5 ? random() : random() + 1.0

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

random = floor(random() * some_integer) + random()

В чем дело? Дело в том, что в первом случае мы просто «растягиваем» вероятность (* и /). При этом сохраняется опасность при очень больших значениях сильно повредить точность. В остальных случаях генерируется точность для дробной и целой части. При этом можно просто сместить (операция + и -) и обрезать (max, min, clamp). Также можно попробовать сжать делением. Но растягивать умножением последовательность лучше в крайнем случае.

Иллюстрация

Привел более наглядный рисунок. Два или один рандом: решать вам.

Резюме

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

This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.

Когда они пришли за тобой…

Роскомнадзор заблокировал LostFilm из-за жалобы компании "Амедиа" по решению Мосгорсуда.

По решению Мосгорсуда, Роскомнадзор заблокировал страницы сайта с сериалами «Американская история ужасов», «Игра престолов», «Во все тяжкие», «Отдел новостей», «Преступная империя» и другие.

Если в течение 15 дней заявитель не подаст иск против нарушителя, то блокировка LostFilm будет снята. Кроме того, стороны имеют 15 суток, чтобы обжаловать это решение.

Напомним, компания «Амедиа» обладает эксклюзивными правами на прокат в России ряда зарубежных сериалов, посмотреть которые законно можно лишь на платной основе. Другие студии, вроде LostFilm, которые занимаются любительским переводом зарубежных сериалов, согласно российскому законодательству, нарушают авторские права «Амедиа». При этом создатели популярных сериалов, например телеканал HBO, выступает категорически против такого положения дел.

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

P.S. Готовься %username% скоро у Кирилла и Мефодия тоже могут объявиться наследники в каком то поколении.

This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.

Человек залез на 8-метровую стеклянную стену с помощью устройства, сделанного по образцу лапки геккона

Тропические ящерицы гекконы обладают уникальным строением лапок, которое позволяет им бегать по стенам и потолкам из любого материала так же легко, как по поверхности земли. Цель программы Z-man агентства DARPA — создать альпинистское оборудование, основанное на тех же принципах, по которым работает лапка геккона. 5 июня DARPA доложило о первом значительном успехе этой программы — человек, чья масса вместе с полезным грузом составила 122 кг, поднялся и спустился по отвесной стеклянной стене высотой 7,6 метра. Для военных эта технология ценна тем, что значительно расширяет возможности солдат, особенно в условиях городского боя. В мирной жизни всё разнообразие применений такого «суперскотча», который намертво прилипает к любой поверхности и в то же время легко отрывается, не оставляя следов, трудно даже вообразить.

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



Как работает лапка геккона? Её поверхность покрыта множеством складок, на каждой из которых есть множество тончайших щетинок длиной в 0,1 мм, а на конце каждой щетинки есть несколько сотен ответвлений, каждое из которых заканчивается треугольной лопаточкой всего в 200 нм шириной. Миллиарды этих лопаточек прилегают к поверхности, по которой бежит геккон, настолько близко, что между ними начинают действовать Ван-дер-Ваальсовы силы межмолекулярного притяжения. Они проявляются лишь при близком контакте и в обычных условиях пренебрежимо малы. Уникальное строение лапок геккона на много порядков увеличивает площадь близкого контакта с поверхностью. Щетинки и лопаточки геккона устроены так, что, потянув их под определённым углом, можно легко оторвать их от поверхности. В остальных направлениях они остаются прочно прилипшими к ней.

Попытки создать искусственный аналог лапки геккона предпринимаются довольно давно. Несколько лет назад был разработан робот Stickybot, использующий этот принцип. Так же во многих лабораториях мира разрабатывают "гекконовый скотч", который может нести весьма большой вес. Сложность создания альпинистского оборудования состоит в том, что оно должно одновременно держать большие нагрузки (вес типичного геккона не превышает 100-200 грамм, на два порядка меньше веса альпиниста с грузом) и при этом, в отличие от скотча, выдерживать много циклов прилепления-отлепления без заметного ухудшения характеристик. Именно такого результата удалось добиться учёным из Кембриджской лаборатории Дрейпера, которая ведёт эту разработку по заказу DARPA.

This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.

Ubisoft убирает женские персонажи из двух игр

В совместном режиме игры по 2-4 человека Assassin's Creed Unity (для нового поколения игровых приставок) не будет женских персонажей. Компания Ubisoft объяснила, что сначала планировала создать их, но разработку прекратили из-за нехватки денег. Алекс Амансио (Alex Amancio), креативный директор проекта Unity, объясняет, что присутствие женщин-киллеров удваивает стоимость разработки практически всего: анимации, озвучки, визуальных объектов — особенно потому, что в Assassin's Creed можно настраивать внешний вид персонажей.



Женские персонажи присутствовали во всех предыдущих частях Assassin's Creed, как в роли убийц, так и в других ролях. Новое решение Ubisoft не на шутку взволновало геймерское сообщество.

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

Что ещё более странно, компания решила убрать женские персонажи из совместного режима ещё одной игры — Far Cry 4.

Почему Ubisoft это делает — совершенно непонятно, если только не верить в странную отговорку про экономию бюджета.

А вот почему народ возмущается — вполне можно понять. Здесь вопрос равноправия, да и вообще, многие мужчины любят играть именно за женские персонажи. Например, исследование американских социологов в игре World of Warcraft показало, что поведение мужчин с женскими аватарами сильно отличается от поведения женщин с женскими аватарами. Во-первых, мужчины выбирают более привлекательные женские аватары, чем сами женщины.

Примеры привлекательных и непривлекательных мужских/женских аватар из WoW, определённые авторами научной работы на основании традиционных представлений западной культуры о причёске, лице и фигуре мужчин/женщин

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

Почему мужчины выбирают симпатичные женские аватары — это вообще очень просто. Когда много часов проводишь за игрой, на чьи формы приятнее смотреть? Неудивительно, что игроки Ubisoft возмущены политикой компании.

This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.

Switch to Sketch. Часть 4

Оригинальная версия старинной французской поговорки гласит: Le bon Dieu est dans le détail («Бог в деталях»). Собственно, неприметные на первый взгляд детали и отличают Sketch от многочисленных конкурентов. Давайте поближе взглянем на этот кладезь удивительных мелочей.

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

«Продвинутые детали» встречают вас уже на этапе создания нового документа.

Что вы увидите практически в любом графическом редакторе, выполнив команду File > New?

Скорее всего, то же самое, что в фотошопе — диалоговое окно, в котором необходимо указать размер будущего документа, выбрать цветовую модель и установить прочие параметры:

Разработчики из Bohemian Coding задались вопросом: «А зачем нам нужны дюймы и сантиметры, DPI и CMYK, если мы хотим рисовать интерфейсы и сайты в пикселях и в цветовой схеме RGB?». И попросту убрали такое диалоговое окно.

Нажав Cmd-N, вы получите новое окно документа мгновенно.

«Какого же размера будет созданный документ?» — спросите вы. А никакого.

Дело в том, что в Sketch безразмерный канвас. И, соответственно, бесконечный уровень масштабирования. Цвет фона у канваса по умолчанию белый.

Но как же быть, если есть необходимость как-то ограничить размер своего документа. Например, сделать его под формат iPad Retina Landscape?

Для этого и была введена возможность создания страниц и артбоардов. Нажмите клавишу A (или выполните команду Insert > Artboard) и выберите один из подходящих вариантов в появившемся списке в панели инспектора:

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

После этого артбоард будет создан. Его имя появится в списке слоев, в панели инспектора появятся свойства артбоарда. Пространство за пределами станет серым, а внутри остается белым (цвет фона потом можно поменять в инспекторе). Над артбоардом отображается его имя, которое можно поменять, дважды кликнув на имени в панели слоев:

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

Количество создаваемых артбоардов неограничено, поэтому в пределах одного документа вы можете создать, к примеру, основы для экранов iPhone, iPad, а также для всех основных типоразмеров иконок:

Помимо выбора цвета фона и указания возможности включать фон артбоарда в экспортируемый файл, можно использовать еще две опции для экспорта. Особенно полезной будет Trim Transparent Pixels: если ваш артбоард превышает размер помещенного объекта, то при включении этой опции высота и ширина изображения подгонятся под размеры объекта, а все лишние пиксели будут отсечены.

Кроме того, нажав на плюсик в разделе Export на панели инспектора, вы увидите различные опции для экспорта (об этом поговорим позже) и небольшую миниатюру с содержимым артбоарда. Достаточно нажать и потянуть эту миниатюрку в любое место (Рабочий стол, Finder, Mail.app, Coda и т.п.). В том месте будет создан PNG-файл, содержащий все то, что находилось внутри артбоарда. Очень просто и потрясающе удобно:

Это позволяет обойтись без вызова дополнительных окон вроде Save for Web…

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

Помимо этого вы можете создавать любое количество страниц. Каждая страница при этом может иметь произвольное число артбоардов. В палитре слоев нажмите на самую верхнюю полоску, где написано Page 1, и вы увидите всплывающий список созданных страниц (изначально есть одна). Нажав на плюсик, вы создадите новую пустую страницу, которую можно переименовать на свое усмотрение:

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

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

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

Нажмите File > New From Template и выберите один из пяти предустановленных вариантов или из тех шаблонов, которые вы создали с помощью File > Save As Template.

Пока что встроенные шаблоны позволят вам создавать интерфейсы и иконки для Mac OS и iOS, но в планах у разработчиков включить аналогичные наборы для Android, Windows Phone, Windows, Linux, Tizen и других операционных систем. Впрочем, подобные шаблоны уже можно отыскать в сети. Например, вы можете бесплатно скачать набор интерфейсных элементов свежайшей системы OS X 10.10 Yosemite.

Если был выбран предустановленный шаблон iOS UI Design, вы получаете великолепный набор символов от Teehan + Lax.

Нажмите на выбор страниц и вместо Welcome перейдите на страницу Symbols:

Здесь вы найдете все необходимые элементы для создания приложений под iOS8. Просто перетаскивайте нужные объекты на свои артбоарды или создавайте из библиотеки символов:

Разобраться с этим не составит труда, тем более, что Teehan+Lax написали подробное руководство, доступное на первой странице Welcome.

Итак, с созданием документа мы разобрались, что же дальше?

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

С импортом дела обстоят следующим образом. Sketch понимает все основные растровые графические форматы: JPEG, TIFF, PNG, причем для последних двух учитывается альфа-канал. Файлы PSD можно импортировать, но будут проигнорированы слои и каналы, изображение будет помещено как однослойное. То же самое относится и к формату AI. Кроме того, имеется поддержка трех векторных форматов: SVG, EPS и PDF. Наилучшая степень конвертации реализована лишь для SVG (возможны какие-то потери специфических свойств, но чаще всего Sketch импортирует все правильно). В случае с EPS и PDF результат, скорее всего, будет далеко не самый лучший, поэтому предпочтительно сначала перевести эти файлы в SVG при помощи Adobe Illustrator, как я писал в начале обзора.

Макеты записываются в формате .sketch. Размер их получается относительно небольшим, и существенное влияние на эту величину оказывает лишь обилие растровых изображений, помещенных в Sketch. Поскольку, как я уже упоминал ранее, все изображения трактуются как смарт-объекты (вы можете уменьшить изображение до любого размера и потом восстановить до исходных размеров без потери качества), поэтому будьте осторожны и не используйте картинок с высоким разрешением, если в итоге вам нужно небольшое по размеру изображение.

Например, файл с пустым артбоардом для iPhone (640x1136 пикселей) будет занимать всего 5 килобайт против такого же файла .psd, размер которого будет в несколько раз больше — 68 килобайт. Та же тенденция сохраняется и при создании более сложных макетов. Например, одна композиция в формате .sketch у меня получилась на 785 Кб, тогда как аналогичный .psd занял целых 3,2 мегабайта. Нет нужды говорить, что макеты Sketch значительно привлекательнее как с точки зрения экономии пространства, так и с точки зрения скорости открытия и записи.

Будучи Cocoa-приложением, Sketch в полной мере поддерживает такие замечательные функции Mac OS как Full Screen, Auto Save и Versions.

Последняя особенно важна, поскольку вы в любой момент можете откатиться к предыдущему варианту дизайна. Если вы переделали макет, и хотите вернуться к одной из прошлых записанных версий, нажмите File > Revert To > Browse All Versions и выбирайте понравившийся вариант (о работе с Versions можно почитать здесь):

Фотошоп не может пока похвастать подобным функционалом, поэтому пользователи вынуждены прибегать к не особо удобным и далеко не всегда понятным способам вроде History Snapshots или Layer Comps. Лично я так и не смог привыкнуть к ним, поэтому Versions для меня оказался очень полезным методом работы с изменениями в макетах.

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

Но, как показывает практика, создавать эти линейки совершенно необязательно. Ведь в Sketch есть несколько совершенно потрясающих способов контроля за размещением объектов.

Например, вы можете включить режим отображения простой сетки, нажав иконку View на тулбаре и выбрав Show Grid или нажав Ctrl-G:

Там же можно выбрать Grid Settings и настроить сетку под себя:

Но есть способ и получше. В Sketch имеется функция построения сложных разметочных сеток. Вызовите View > Show Layout (Ctrl-L) и по умолчанию будут отображены ставшие стандартом 12 колонок для ширины макета 960 пикселей:

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

При этом, если вам не очень нравятся полупрозрачные закрашенные прямоугольники в качестве основы для сетки, вы можете поменять их на линейки любого цвета. Зайдите в настройки (Sketch > Preferences или Cmd-,) и во вкладке Canvas поменяйте Fill Grid на Stroke Outline, а также настройте предпочтительные цвета:

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

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

При зажатой клавише Shift размеры будут равнозначными, а при зажатой клавише Alt объект создается со вдвое большими значениями высоты и ширины.

Если вы захотите изменить размер созданного объекта, необязательно обращаться к панели инспектора (хотя очень удобно корректировать эти значения именно там, поскольку возможность оперировать не на глазок, а с точными числами невероятно дисциплинирует). Можно при нажатой клавише Cmd нажимать стрелки на клавиатуре и видеть, как динамически меняется размер в инспекторе с шагом в один пиксел. При нажатии клавиши Shift эти изменения будут с шагом в 10 пикселей. Потрясающе удобная функция.

Когда вы перемещаете объекты, они прилипают не только к сеткам и направляющим, но и к смарт-гайдам, которые появляются, когда перетаскиваемый объект соприкасается с границами или центральными осями других объектов:

Но даже это еще не все!

Дизайнеры из Bohemian Coding придумали очень мощный и эффективный способ отслеживания расстояний.

Выделите один объект и, нажав клавишу Alt, подведите мышку к любому другому объекту (он подсветится голубой обводкой), и вы увидите расстояния до границ того объекта:

Вы можете, не отпуская клавишу Alt, переместить мышку на любой другой объект, и расстояния отобразятся до него.

Но это еще не все! Не отпуская Alt и не уводя курсор мыши со невыбранного объекта, до которого вам важно видеть расстояния, нажимайте стрелки на клавиатуре и передвигайте выделенный объект, наблюдая, как динамически меняются показываемые значения. Клавиша Shift также включает шаг в 10 пикселей.

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

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

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

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

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

Удачного фотошопинга скетчинга!

---

---

This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.

Внутренняя USB зарядка

У каждого из нас есть несколько девейсов с USB зарядкой. Рядом с кроватью у меня удлинитель с 5 розетками, 3 розетки заняты под USB зарядки. Такой вариант зарядки телефонов мне довно не нравился из за своих габаритов и не эстетичного вида, хотелось гармонии.

Озадачившись этой проблемой я стал искать внутренние USB розетки. У Gira и Legrand есть варианты с 1 USB розеткой и блоком питания на 1 А и с 2 USB розетками и блоком питания на 1.5 А, но с 4 USB розетками нет ни у кого. Поняв, что это все мне не подходит, да и цены на внутренние USB розетки конские, я решил сам изготовить розетку с 4 USB портами и блоком питания. В качестве блока питания использовал зарядку от iPad 2.4 А как самую компактную и мощную.



Итак, для изготовления встраиваемой USB розетки на 4 порта нам потребуется:

1. Блок питания от iPad 2.4А (avito.ru — 100р, apple.ru — 800р)


2. USBA-2J розетка двойная на плату 2 шт. (voltmaster.ru — 23р x2)


3. USB-A вилка на кабель (voltmaster.ru — 13р)


4. Кусочек макетной платы для пайки (найден в закромах)


5. Встраиваемая Ethernet розтека (на маркете нашел по акции за 15р, средняя цена в магазинах — 300р)

Подготовил набор для сборки

Разобрал зарядку и напаял USB розекти на макетную плату

Расточил отверстие под размер USB портов и подпаял 4 USB розетки к одной USB вилки. При зарядки используются не только +5 и GND, но и DATA -, DATA +. iPhone без подключенных D+ и D- к зарядке не заряжается.

Супер клеем приклеил 4 USB розетки к расточенному отверстию Ethernet, и сверху еще все залил клеевым пистолетом. Подключил блок питания и примерил все это дело в подрозетник глубиной 40 мм. Даже немного места осталось.

Осталось дело за мылам, установить это в стену. Вам предлагаю посмотреть на готовый вариант

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

Пока что, я заряжаю 3 телефона и 2.4 А зарядки от iPad хватает, тем более телефоны редко заряжаются одновременно. Но если брать с расчетом на будущее и учитывать, что здесь же будет заряжаться iPad, то нужно использовать две зарядки вместо одной, 4.8 А на 4 USB порта хватит всем с головой.

This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.

Компания Gecko продала патентный портфель (LED)

Информация для разработчиков, производителей и иных игроков на рынке LED-освещения.

Компания Gecko Alliance Group, Inc. (Gecko) продала свой портфель патентов, относящихся к удаленному диммированию светодиодных источников света. Покупателем стал консорциум Allied Security Trust (AST). Брокером Gecko выступила компания Tangible IP, LLC. Финансовые подробности сделки не раскрываются. Кто из участников AST инициировал сделку, также не сообщается. По условиям контракта сама Gecko сможет продолжать использовать эти изобретения для собственных нужд.

This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.

Завершилась битва в CodeCombat между 545 программистами

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

Во время соревнования 545 участников написали более 126 000 строк кода. Каждый потратил в среднем 10 часов на подготовку заданий, что соответствует 7,5 человеко-месяцам разработки. Обсчёт итога происходил на 673-ядерном кластере, который за один час просчитал результат всех 153 439 игр. Победители заберут призов на сумму более $40 000.



Абсолютный чемпион Wizard Duke показал и вовсе уникальный результат: 363 победы, 0 поражений, 14 ничьих. В интервью организаторам 23-летний английский программист Майкл Хиселл (Michael Heasell) объяснил свою стратегию сбора монет. Вектор движения игрока вычислялся как сумма векторов, генерируемых окружающими монетами, в зависимости от их ценности, и векторов противоположного направления от границ игровой зоны и коллег-сборщиков монет. Результат сложения всех векторов показывал, в какую сторону сборщику совершить очередной ход.

Таким образом, сборщики Wizard Duke двигались в направлении наиболее плотных кластеров с ценными монетами, равномерно распределяясь по территории.

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

Его стратегия производства юнитов тоже довольно сложная. Майкл задействовал продвинутую архитектуру категоризации для распределения приоритетов между типами и подтипами автономного поведения ботов. Например, один из типов поведения — зондирование. Некоторые игроки строят большую армию в ответ на появление любого агрессора. Для проверки противника Wizard Duke отправлял в середине игры единственного солдата к базе врага.

Запись напряжённой битвы между игроком Wizard Duke и канадским кланом Bellardia см. здесь. Интересно, что с середины игровой сессии сборщики монет с противоположных сторон двигаются почти синхронно парами, что указывает на схожесть стратегий, которые использовали Wizard Duke и Bellardia.

This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.

Vessyl: умная чашка, которая знает, сколько и чего вы пьете

Автор проекта Vessyl еще несколько лет назад, будучи выпускником Королевского университета по специальности «biomedical computing», задумал создать собственный гаджет с «интернетом вещей». Перебирая в уме вещи и устройства, которые стоило бы сделать умными, так сказать, автор решил выбрать неожиданный вариант — чашку.

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

Как уже говорилось выше, эта кружка — не просто дизайнерская идея, которая никогда не будет реализована. Уже есть прототип, попавший в руки журналиста издания Theverge.

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

Vessyl определил напитки от Crush, Vitamin Water XXX, напиток от Tropicana, Gatorade Cool Blue, обычную воду и некоторые другие жидкости.

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

Если пользоваться Vessyl постоянно, в течение дня, то чашка показывает, как часто вы пьете, предсказывая уровень гидратации организма владельца. Многие из нас потребляют меньше жидкости, чем нужно, поэтому Vessyl может следить за потреблением воды, приучая человека принимать нужное количество жидкости в день. Конечно, тут есть некоторые сложности — ведь не будешь же в кафе/баре (чашка, кстати, «знает» и определяет многие сорта пива) пользоваться своей кружкой. Тем не менее, идея достаточно интересная.

Интересно еще и то, что сенсор в чашке, по словам разработчика, бесконтактный.

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

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

Автор собирает предзаказы на свое творение, по цене в 99 долларов США. Отгрузка заказов планируется в начале 2015 года. После завершения первого периода, будет открыта возможность прямых заказов, но уже по цене в 199 долларов США.

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

This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.

Аналоговое становится все более цифровым

Только что я оказался достаточно сильно удивлен, подключив к своему Dell Latitude E6440 весьма аналогововые с виду наушники Scullcandy.

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

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

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

Встает вопрос, для чего? Просто для того чтобы выводить название производителя и класс наушников? На что это влияет? Когда это стало стандартом?

По запросам типа «How laptop recognize my headphones vendor» ничего внятного найти не удалось.

Простите мне эти вопросы в формате топика, но это кажется весьма занятным.

Если в комментариях появится информация, проливающая свет на этот вопрос, я бы с удовольствием дооформил топик.

This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.

Получение снимков с цифровой зеркальной камеры (Nikon) из программного кода на c#

Здравствуйте.

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

Как оказалось, у производителей цифровых зеркальных фотокамер есть специальный SDK, через который можно программным путем к этой самой камере обратиться и поуправлять ею. У меня камера Nikon D5200, хотя для Sony и Canon вроде бы тоже видел подобный SDK.

Цель статьи рассказать о возможности и показать короткий пример. Как известно, если вы знаете что что-то можно сделать, то узнать, как это сделать – пара пустяков.



Итак, что нам понадобиться:

Во-первых, вам нужно скачать сам SDK с сайта Никона: http://ift.tt/1oYGIrG

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

Во-вторых, для простоты, рекомендую воспользоваться уже написанным NikonCSWrapper’ом: http://ift.tt/1iuKT8I

Далее создаете свой проект (в Visual Studio), подключаете ссылку на никоновский враппер, и, внимание: копируете в директорию с бинарниками файлы: NkdPTP.dll и Type0009.md3 (вот тут цифры могут отличаться в зависимости от камеры), которые можно отыскать в скачанном SDK.

Теперь небольшой пример о том, как фотографировать:

Сначала определяем менеджер устройств:

NikonManager manager = new NikonManager("Type0009.md3");

Затем привязываем к менеджеру обработчик события добавления устройства:

manager.DeviceAdded += manager_DeviceAdded;

в коде обработчика у меня вот такой текст:

void manager_DeviceAdded(NikonManager sender, NikonDevice device) { _device = device; this.Text = _device.Name; _device.ImageReady += _device_ImageReady; }

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

Обработчик события фотографирования у меня выглядит так:

void _device_ImageReady(NikonDevice sender, NikonImage image) { MemoryStream ms = new MemoryStream(image.Buffer); Image img = Image.FromStream(ms); ms.Close(); pictureBox1.Image = img; }

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

Чтобы сфоткать камерой из программного кода, нужно вызвать метод Capture():

_device.Capture();

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

manager.Shutdown();

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

На этом у меня все, надеюсь, кому-нибудь эта информация пригодиться, Спасибо за внимание.

This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.

Пороговый декодер

Друзья, всем привет!

Пару месяцев назад, я уже начал рассказывать про методы помехоустойчивого кодирования. Первая статья была посвящена алгоритму Чейза. Она вот тут. Многих заинтересовало данное направление, поэтому я решил продолжить. На очереди весьма любопытный, перспективный, и что важно простой для понимания пороговый декодер. Давайте начнём!

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

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

Можно сказать, что представленный кодер, задан с помощью «образующего полинома» g(x)=1+ x+x^4+x^6.

Таким образом, с процессе кодирования будет получены две части зашифрованного сообщения, которые в последствие будут объединены и переданы в канал, как единый вектор. Первая — информационная (u) будет содержать биты, исходного сообщения, переданные на прямую из нулевой ячейки регистра, кодируемого сообщения. Вторая – проверочная (v) будет содержать биты полученные путем сложения бит из ячеек регистра с индексами, соответствующим ненулевым степеням «образующего полинома» g(x).

Пусть нам нужно зашифровать следующее сообщение: 0111011011011. Информационная ветвь (u) будет полностью соответствовать исходному сообщению, т.е. будет равна «1101101101110».

Проверочная ветвь (v) будет состоять из бит полученных за счёт сложения «по модулю два» бит, из 0-ой, 1-ой, 4-ой и 6-ой ячеек регистра.

Пример:

1. В регистре: 1 0 1 1 1 0 1 1 0 1 1 0 1

V = 1 ⊕ 0 ⊕ 1 ⊕ 1 = 1;

2. В регистре: 1 1 0 1 1 1 0 1 1 0 1 1 0

V = 1 ⊕ 1 ⊕ 1 ⊕ 0 = 1;

......

13. В регистре: 0 1 1 1 0 0 1 0 1 1 0 1 1

V = 0 ⊕ 1 ⊕ 0 ⊕ 1 = 0;

После «круга» работы кодера, проверочная часть будет представлять собой вектор: «111000000010».

Следовательно, в канал будет отправлен вектор «10111011011011110000000010».

Стоит отметить что формат вектора [ u | v ] не является единственно верным. И может быть с легкостью заменен на любой другой формат, к примеру: [u1 | v1 | u2 | v2…un | vn].

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



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

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

Пусть в исходное сообщение «10111011011011110000000010» будет внесена ошибка «1011111101101 1110000000010».

Синдромный регистр будет содержать следующие значения: «00000011001010» (самый первый бит — ячейка «0» синдромного регистра на картинке)

1. В синдромном регистре: «0000011001010» → «0000011001010»

В пороге: 1, 1

2. В синдромном регистре: «0000110010100» → «0000110010100»

В пороге 1, 1

......

6 В синдромном регистре: «1100101000000» → «0000000000000».

В пороге 4, 4 > 2 → изменение есть. В результат идёт значение «0», вносятся изменения в синдром;

В результате после декодирования мы получим сообщение «1 1 0 1 1 0 1 1 0 1 1 1 0». Ошибка была исправлена. И после инверсии позиций всех бит мы получим исходное сообщение «0 1 1 1 0 1 1 0 1 1 0 1 1».

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

Спасибо, всем кто прочёл. Буду рад конструктивным замечаниям/комментариям. Старался быть доходчивым :)

This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.

Первые официальные видео Samsung GALAXY Tab S

сегодня в 19:56

Доброй пятницы, Хабр!

Пока в наших чертогах готовится пост с развернутым описанием главной новинки лета от Samsung — планшета с Super AMOLED экраном GALAXY Tab S, предлагаем вам ознакомиться с видео роликами, которые демонстрируют новый гаджет во всей красе и раскрывают его основные технические характеристики и возможности. Желаем вам хороших праздников и выходных!

Только зарегистрированные пользователи могут оставлять комментарии.

Войдите, пожалуйста.

This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.

История создания синематика «Несокрушимые». Часть первая

Привет, Хабр! Сегодня у нас есть немного свежезапеченного CG, и мы хотим рассказать тебе о разработке синематика «Несокрушимые» для стратегии «Спарта: Война империй». В первой части статьи о создании этого видео, руководитель Plarium Cinematics Team Вячеслав Лисовский расскажет о работе над анимацией и VFX.

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

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

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

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

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

Еще одним сложным моментом был финальный massive shot. Его мы делали параллельно с остальными сценами на протяжении всего проекта; реализацией занимался наш аниматор Александр Варжаинов. Первостепенной задачей здесь было создать масштабную и впечатляющую сцену с участием двух армий. Для этого Александр написал скрипт, который отвечал как за движения солдат, так и за их внешний вид. Что касается ландшафта финальной сцены, то растительность создавалась при помощи V-Ray Multiscatter, а все большие элементы, такие как скалы, камни и даже корабли на заднем плане, – это полноценные 3D-модели.

«Несокрушимые» – это второй ролик, созданный нашей командой. Оглядываясь назад, я понимаю, что смена тематики ролика и попытка реализовать какие-то новые для нас сцены помогли всей команде вырасти в профессиональном плане. Если в нашем прошлом синематике «Победа достойна смерти» мы еще могли «закрыть ядерным взрывом» какую-недоработку, то здесь нам пришлось показывать бой настоящих живых людей и каждая мелочь была важна. Мы поставили себе высокую планку, но очень многому научились за эти три месяца. Любите свое дело, не бойтесь больших и сложных задач, и у вас всё получится!

This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.

Как я выбирал Zend Framework для проектов веб-студии

Начну с того, что Zend Framework (далее ZF) меня заинтересовал четыре года назад. Около года я присматривался к этому фреймворку, после чего наконец решился переписать самописный движок одной из веб-студий, где я тогда работал старшим программистом. С тех пор меня постоянно преследует вопрос «А почему вы выбрали ZF?». Этот вопрос мне задавали программисты, с которыми я вместе тогда работал в веб-студии; задавали партнеры веб-студии, с которыми мы делали общие проекты; спустя несколько лет мне продолжают задавать этот вопрос потенциальные работодатели на собеседованиях. В этом посте я постараюсь объяснить, зачем выбирался фреймворк взамен самописному движку и почему выбрался конкретный фреймворк.

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

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

В третьих, определить проекты, которые будут разрабатываться на базе фреймворка. Основной критерий: ожидаемая длительность поддержки проекта. Разрабатывается ли проект на пару недель. как промо-сайт, или проект достаточно крупный с поддержкой на несколько лет. Лично мне пришлось столкнуться с доработкой проектов, которые были разработаны еще во времена PHP3, когда использовались глобальные переменные. Уверены ли вы, что выбранный фреймворк будет развиваться в течение ближайших пяти-десяти лет? Какая стратегия развития фреймворка у разработчиков? Как часто разработчик выпускает новые версии фреймворка, которые несовместимы? Все эти вопросы очень важны для веб-студии, у которой может быть несколько сотен разработанных проектов при весьма ограниченном штате сотрудников, т.к. неправильный выбор приведет к значительным трудозатрадам при дальнейшей поддержке проектов.

В четвертых, нужно определить, что вы ждете от фреймворка? Гибкость, стабильность, безопасность? Наличие профессионального сообщества, огромное количество готовых примеров? Хорошая документация, вебинары, семинары и сертификаты? Может что то еще?

Итак, основные вопросы для выбора фреймворка были составлены (нужен ли вообще фреймворк, какому фреймворку отдается предпочтение, какие проекты, что ожидается от фреймворка). Теперь оставалось найти ответы на эти вопросы… Кроме всего прочего, команда программистов была довольна небольшая с разным уровнем знаний и подготовки. Это тоже необходимо было учитывать.

Нужен ли вообще фреймворк?

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

Какому фреймворку отдается предпочтение?

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

Какие проекты?

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

Первый проект:

— поддерживается с 2006 года, ожидается длительная поддержка

— включает несколько языковых версий сайта

— включает несколько сайтов с общим административным интерфейсом

— проект на виртуальном хостинге

Второй проект:

— поддерживается с 2011 года, ожидается длительная поддержка

— включает API для внешних взаимодействий

— включает несколько административных интерфейсов

— важен быстрый старт проекта

— важны безопасность, стабильность, скорость отклика

— проект на выделенном сервере

Что ожидается от фреймворка?

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

Но какой же проект соответствует всем этим ожиданиям?

Т.к. ожидается длительная поддержка проектов, то стоит опираться на ветеранов, которые уже давно существуют, но все еще регулярно выпускают стабильные релизы. Таковых к сожалению не много, например: CakePHP, CodeIgniter, Symfony, Zend Framework.

Далее изучаем changelog's:

Далее изучаем документацию:

Кроме этого, у ZF и Symfony имеются dev — порталы: http://ift.tt/SGa4OA и devzone.zend.com/. а также видео-курсы: www.screenfony.com/ и www.zendcasts.com/ (т.е. проще изучить фреймворки на профессиональном уровне). Также, в России регулярно проводятся конференции ZF.

На данном этапе лидируют ZF и Symfony по уровню документации с примерами и развитому профессиональному сообществу, а CodeIgniter явно проигрывает по уровню безопасности.

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

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

This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.

Московская встреча по Corona SDK в это воскресенье

Приглашаю на неформальную встречу разработчиков, использующих Corona SDK.

Будем знакомиться, делиться опытом, показывать свои проекты и просто весело проводить время!

С собой приносите вопросы и свои проекты на телефонах/планшетах или компьютерах.

Встреча состоится в воскресенье 15 числа во второй половине дня.

Регистрация по ссылке

http://ift.tt/1xUeLW6

Точное время и место проведения будет выслано на email.

This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.

Spintires доступна на Steam

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

Начавшийся в 2009-м году как демо возможностей движка Havok для конкурса Intel Havok Physics Innovation Contest, год назад проект начал сбор денег на Kickstarter для финансирования разработки полноценной версии. При начальной цели в 40 тысяч фунтов, разработчик, британская студия Oovee Game Studios (судя по всему, основанная выходцами из СССР), собрал более 60 тысяч, что и дало возможность выпустить «взрослый релиз».

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

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

Единственное на данный момент ведро дёгтя в бочке мёда — это цена релиза, 799 рублей.

Затариться счастьем и бессонницей на Steam Store.

This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.