...

суббота, 30 ноября 2013 г.

Дайджест интересных материалов из мира веб-разработки и IT за последнюю неделю № 85 (24 — 30 ноября 2013)

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




Метки лучше разделять запятой. Например: общение, социальные сети, 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 fivefilters.org/content-only/faq.php#publishers.


DIY-диммер: путеводитель по компонентам


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


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


Краткий ввод в курс для тех, кто первый раз увидел наш проект
Мы разрабатываем полноценную систему Умного дома. «Первая ласточка» нашей системы — DIY-диммер. Вот его основные характеристики:

  • Работа по радиоканалу 2,4Ггц (свой протокол, без лицензионных ограничений)

  • Защищенное шифрованием соединение

  • Установка без изменения стандартной электропроводки обычной квартиры

  • Низкий расход электроэнергии

  • Привычный внешний вид выключателей

  • Возможность самостоятельного расширения как аппаратного, так и программного функционала

  • Открытый исходный код как программной, так и аппаратной части


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






Принципиальная схема устройства





Спецификация используемых компонентов




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













































































































































































































































































ОбозначениеНаименованиеВарианты заменыКорпусФото
U1PBS1.27 10pin x2 Выводной
10-пиновый разъем для радиомодуля с шагом выводов 1.27мм, 2 шт.
U2LNK304D LNK305D, LNK306DSO-8
Преобразователь питания
U3MOC3052SM SDIP6
Оптосиммистор
VO16N139S SDIP8
Оптопара
VD1, VD2TB10S TDI
Диодный мост
T1T835-600G T1635-600GD2PAK
Симмистор
D1LED 0805
Светодиод вашего любимого цвета
D2STTH1R06A ES1JSMA
Диод быстрый
D3GS1J S1JSMA
Диод выпрямительный
C13,3uF x 450V 2,2uF x 450VВыводной
Конденсатор электролитический
C2, C4, C5, C6100n (0.1uF) 0603
Конденсатор керамический SMD
C310n (0.01uF) 0603
Конденсатор керамический SMD
C710uF x 10V 10uF x 16VВыводной
Конденсатор электролитический
C8470uF x 10V 220uF x 10V LOWESR / 220 x 16Выводной
Конденсатор электролитический
R1, R2470k 0,25W Выводной
Резистор выводной
R3, R447R 1W Выводной
Резистор выводной взрывозащитный (flameproof)
R5, R610k 5% 0603
Резистор SMD
R7200R 5% 0603
Резистор SMD
R8, R101,6k 1% 0603
Резистор SMD
R92k 1% 0603
Резистор SMD
R11390R 1W Выводной
Резистор выводной
R121k 5% 0603
Резистор SMD
L13,3uH 1210
Дроссель SMD
L21000uH Выводной
Дроссель выводной силовой
F1250V 2A Выводной
Предохранитель
LINEРазъем 2 пин Выводной
Силовой разъем



Обратите внимание, в продуктовой плате мы постарались минимизировать размеры корпусов элементов и по-максимуму использовать поверхностный монтаж. Все используемые микросхемы — в SMD-корпусах. Выглядят они вот так:


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


Кто может собрать сам?




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

Где купить компоненты?




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

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


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


Анонс следующих постов:



  • Первые фото первого корпуса нашего DIY-диммера + 3D-модель для самостоятельной печати корпуса на 3D-принтере.

  • Модуль подключения к компьютеру по USB: описание, схематика, спецификация компонентов и традиционный комплект gerber-файлов.

  • Где приобрести подходящие радиомодули и что можно еще купить в Китае для использования в самодельном умном доме?

  • Первые шаги по программированию NRF24LE1: мигаем светодиодом

  • Прошивка NRF24LE1 с помощью подручных средств: Raspberry PI & TI MSP430 LaunchPad




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

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 fivefilters.org/content-only/faq.php#publishers.


[Перевод] Магия data-driven design

Примечание от переводчика

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



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


Мысль 1: Основы




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

Мысль 2: Необходимый Минимум




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

Мысль 3: Ничего Не Ограничивайте




Предположим, что измениться может что угодно (скорее всего так и будет). Если игра требует режим разделенного экрана, не надо жестко указывать ровно два. Напишите свою игру, которая может поддерживать любое количество экранов со своей логикой для каждой камеры. Количество работы от этого, при правильном подходе к делу, не сильно увеличится. С помощью магии текстовых файлов вы определите сколько экранов должно быть в игре — один, два, четыре или больше. Файлы также зададут начальные данные для камер: положение, направление, угол охвата и наклон. Самое приятное в том, что ваши гейм-дизайнеры тоже обладают прямым доступом к изменению этих параметров.

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

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

Вы поверили мне, когда я сказал «Ничего»?

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

Мысль 4: Основной Управляющий Сценарий




Сценарий — это просто способ задания поведения за пределами программного кода. Сценарии прекрасно подходят для определения последовательности шагов, которые должны произойти в игре, или для игровых событий, которые должны быть вызваны. Например, сценарий для игровой сцены описывающий простую причинно-следственную логику, вроде «что будет при условии завершения квеста» или «какой триггер сработает для данной окружающей среды». Все эти примеры относятся к парадигме data-driven design.

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

К сожалению, для описания сценариев требуется соответствующий язык. Это означает, что вы должны создать целый синтаксис для определения поведения игры. Язык сценариев включает в себя создание парсера сценариев и, возможно, компилятора для преобразования сценариев в двоичный файл для более быстрого выполнения в дальнейшем. Другой вариант заключается в использовании существующего языка, например Java, но в таком случае может потребоваться большое количество дополнительных компонентов. Чтобы не потратить на язык сценариев много времени, нужно выиграть проектируя системы проще. В целом, наблюдается тенденция придания излишней мощности языку сценариев. Следующая мысль объясняет некоторые подводные камни сложного языка сценариев.

Мысль 5: Когда Хорошие Сценарии Становятся Плохими




Использование сценариев для описания поведения в data-driven design — естественное следствие данной методологии. Однако, не нужно забывать про здравый смысл и помнить ключевую идею: отделение логики от данных. Сложная логика отправляется в программный код, а данные остаются снаружи.

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

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

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

Размытая граница

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

Однако, некоторые игры проектировались с возможностью написания игроками собственных AI. Зачастую, это стрелялки от первого лица, позволяющие добавлять ботов. Когда цель именно такая, подобие языка сценариев настоящим языкам программирования просто неизбежно. В качестве примера можно рассмотреть Quake C. Поскольку создание ботов заложено в саму игру, ресурсы и энергия были потрачены на создание языка сценариев на столько удобного, как и язык C. Язык сценариев такого масштаба довольно трудоемкий и не стоит относиться к нему легкомысленно.

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

Мысль 6: Как Избежать Синдром Повторения Данных




Распространенная программистская практика — никогда не дублировать код. Если вам нужно некоторое поведение (например, общая функциональность) в двух разных местах, оно должно существовать только в одном месте. Идея применима и к описанию данных с помощью ссылок на глобальные блоки данных. Кроме того, используя ссылки на наборы данных и изменяя некоторые из их значений, вы, в конечном счёте, приближаетесь к концепции наследования.

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

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


Мысль 7: Сделайте Инструмент Для Работы с Данными




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

Заключение




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

Игра Total Annihilation — хороший пример такого подхода. Дизайнер Крис Тейлор заложил две расы: Arm и Core. Хоть вся игра и сосредоточена на двух расах, они не были жестко запрограммированы в игру. Теоретически, можно было бы добавить данные для добавления третьей расы, даже после выпуска игры. Несмотря на то, что эту возможность не использовали, Total Annihilation остаётся полностью настраиваемая в этом плане. Так как все юниты определяются данными, новые юниты публиковались еженедельно на сайте игры. На самом деле, многие люди создавали собственных юнитов с функциональностью, которая потрясла самих разработчиков игры.

Data-driven design помог Total Annihilation поддерживать верных фанатов игры в и без того переполненном жанре. Идея, реализованная в Total Annihilation, нашла свое дальнейшее применение и в других играх, например в The Sims, которые также распространяют дополнительный игровой контент через веб сайт. Без приверженности разработчиков к философии data-driven design, такие расширения были бы невозможны.

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 fivefilters.org/content-only/faq.php#publishers.


Полезные книги по интернет-торговле и маркетингу

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

image image image


image image image


Интернет-маркетинг на 100% (бумажная, электронная)


Первая отечественная работа, раскрывающая все основные аспекты присутствия компании в Интернете.

Издание ориентировано на директоров и менеджеров по маркетингу, специалистов, отвечающих за поддержку веб-проектов компании.


77 секретов копирайтинга (бумажная, электронная)


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


Удвоение продаж в интернет-магазине (бумажная, электронная)


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


Интернет-магазин без правил (бумажная, электронная)


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


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


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


Интернет-мгазин с нуля


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


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 fivefilters.org/content-only/faq.php#publishers.


OCZ признала себя банкротом…


сегодня в 21:08



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


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


В течение часа будут новые подробности...





Developers, stick with Russians – work in London




Переводы с

карты на карту


Переводы

через QR-Код


Новая функция

«Мой контроль»




Возьми Lumia 925 на тест-драйв сейчас.




Впечатляющие возможности

в стильном тонком корпусе из металла




Boomburum

исследует LTE


Эволюция средств связи

в путешествии по России




Проблемы коммуникации внутри бизнеса?



Смотри бесплатные курсы

и выиграй Xbox



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


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 fivefilters.org/content-only/faq.php#publishers.


Apple скоро откроет Apple Store в Москве


сегодня в 19:51




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



Вот сама вакансия:







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





Developers, stick with Russians – work in London




Переводы с

карты на карту


Переводы

через QR-Код


Новая функция

«Мой контроль»




Возьми Lumia 925 на тест-драйв сейчас.




Впечатляющие возможности

в стильном тонком корпусе из металла




Boomburum

исследует LTE


Эволюция средств связи

в путешествии по России




Проблемы коммуникации внутри бизнеса?



Смотри бесплатные курсы

и выиграй Xbox



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


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 fivefilters.org/content-only/faq.php#publishers.


О форматах электронных книг

<Приветствие>




Этот пост о том, что я думаю о форматах fiction book и electronic publication. А цель — не поделиться чем-то важным и рассказать что-то интересное, а прежде всего вынести что-то для себя.

Краткое вступление. Начал читать книгу по программированию в формате fb2: ни кода, ни картинок. Один голый текст. Да и строки некоторые не на своих местах. Нет, это не формат fb2 кривой, просто такая книга попалась. А в pdf читать на телефоне не очень удобно.

</Приветствие>




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



О хорошем




FictionBook. Замечательный формат для художественной литературы. Хорошая идеология. Логическое форматирование и отсутствие необходимости скроллить вправо-влево на малых устройствах. Автоматическая обработка книг благодаря метаданным. Легкий экспорт в другие популярные форматы и довольно простая спецификация.

ePub. Неплохой формат для визуального форматирования. Простота создания книги без соответствующих программ.

Более подробно описывать форматы не буду.

Теперь о плохом




Недостатков у ePub достаточно. Я считаю, что лучше поговорить о другом. FictionBook — это формат для художественной литературы. Сейчас, конечно, разрабатывается формат fb3, который предположительно решит проблему с форматированием текста. Однако, кое-что мне в нем все равно не нравится. Это использование XML. Сила ePub в том, что текст можно отформатировать, зная только html. Многие из вас знают html-теги? А элементы FictionBook? Все скажут, что для редактирования есть специальные программы. Да, есть. Но, похоже, что не все программисты достаточно хорошо понимают элементы стандарта FIctionBook. Следствие этого — перепутанные строки, которые меня периодически сбивали с толку. На самом деле, всё это пустая болтовня и особых неудобств это не доставляет. Достаточно просто посидеть и конвертировать/отформатировать во что/как душе угодно. Но всё же, хотелось бы не заморачиваться по этому поводу, а скачать и начать читать.

Всё сложно




Тут представлены различные документы по формату FictionBook. Как мне кажется, стандарт FB излишне сложен. Поэтому хочется взять и скрестить. Взять лучшее от ePub и FB.

Чтобы лучше понять, что нужно брать от FB, а что от ePub, следует взглянуть на следующее. Контент в ePub представлен в виде html-файлов, оформление — css. Плохо в этом то, что для книг множество HTML избыточно, а пользовательские настройки пересекаются с css. В FB же есть несколько интересных элементов для форматирования, значение которых важно. Например, элемент poem, epigraph. Или stanza. На мой взгляд, в этих элементах нет нужды. Для представления контента достаточно определить необходимое подмножество HTML и CSS. Такое, которое не будет убивать удобство ради выразительности. Если определить необходимое подмножество HMTL и CSS(атрибуты которых не будут пересекаться с пользовательскими настройками), то представится возможность куда более гибкого оформления, нежели элементами poem и epigraph.

Теперь о структуре. Моё мнение, что упаковка в zip-архив — удачное решение. Это залог быстрого доступа как к самой книге, так и к её элементам, а также меньшей нагрузке на устройство. Недостаток — создание временных файлов(хотя в недостатке памяти сейчас мало кто страдает). Разбивать контент по отдельным файлам следует на логические единицы. Например, на главы. Изображения хранить в отдельной папке «img», а стили в «style». Во всем остальном я согласен со структурой будущего fb3.

Заключение




У меня всё. На месте разработчиков FB и ePub я бы сделал именно так, как я описал чуть выше. Такая структура мне кажется логичной и очевидной. Но не смотря на это, она не такая. Почему? Очень жду вашим критических замечаний и комментарий по поводу изложенного.

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 fivefilters.org/content-only/faq.php#publishers.


Как правильно использовать пиратов в своих интересах


сегодня в 16:09



image



Польское книжное издательство недавно выпустило перевод книги Девида Каплана «Homeland.Carrie's Run» — приквел известного шпионского сериала «Родина» (в версии Lostfilm). Поскольку тема довольно специфична (2006-й год, Бейрут, Керри Метисон) и рассчитана на аудиторию, знакомую со событиями оригинального ТВ-шоу, издательство поступило оригинально.

Распространением нелегальных эпизодов «Родины» в Польше занимается некая группа "Хатак", которая одновременно занимается и польской локализацией субтитров сериала. По грубым оценкам еженедельно аудитория шоу, предпочитающая слышать настоящие голоса актёров и не дожидаться озвучки, составляет примерно 4000 человек. Именно их директор по менеджементу издательства Мацей Мигда (Maciej Migda) и решил использовать для продвижения книги.



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



«Как всё начиналось. Вы узнаете из книги...»



(польск.)
image

В релиз-группе говорят, что такое сотрудничество — даже не совсем реклама, а просто желание познакомить фанов «Родины» с событиями, предшествующими освобождению сержанта Броуди и его разоблачению ЦРУ. При этом обе стороны оказались в выигрыше — издательство получило прямой доступ к своей аудитории (более заинтересованных людей, чем которые скачивают еще не озвученное шоу, не найдёшь), а с другой стороны — релиз-группа получила возможность получить ещё один источник финансирования при минимальных затратах со своей стороны.


[Источник]





Developers, stick with Russians – work in London




Переводы с

карты на карту


Переводы

через QR-Код


Новая функция

«Мой контроль»




Возьми Lumia 925 на тест-драйв сейчас.




Впечатляющие возможности

в стильном тонком корпусе из металла




Boomburum

исследует LTE


Эволюция средств связи

в путешествии по России




Проблемы коммуникации внутри бизнеса?



Смотри бесплатные курсы

и выиграй Xbox



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


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 fivefilters.org/content-only/faq.php#publishers.


STM32+Visual Studio

Не так давно я вновь занялся поиском IDE для STM. Keil, IAR — это, конечно, прекрасно, но да простят меня любители данных сред, они ужасны. CooCox — единственная вещь, которая напоминает о том, что мы живем в 21 веке. Но CooCoх даже рядом не стоял с моей любимой средой разработки — Visual Studio. И мне удалось найти проект, который позволит мне работать с STM в VS.

Зовут сие чудо VisualGDB. Плагин платный, 64 еврика, имеет триалку в 30 дней. В принципе, по сравнению с другими проектами, достаточно дешево. Плюс к тому — скидка для студентов в размере 50%.


Процесс установки предельно прост. Далее-далее, скачивание нескольких тулзов для работы ST-Link и импорт списка контроллеров (интотал около 40 Мб) — и вуаля. Быстрый старт (создание и запуск проекта) описан тут.


На текущий момент я не писал на нем ничего сверхсложного, джентельменский «Hello, World» из мира МК — поморгал светодиодиком. Но первые впечатления таковы:


Плюсы:


1. Простота установки. 10 минут, прозрачно и интуитивно понятно. Проверялось на Win7 64x + VS2010 Ultimate + VS2012 Ultimate

2. Простота запуска. F5 деплоит прошивку, одновременно запуская отладчик. На ST-Link бряки работают

3. Наличие библиотек. По аналогии с CooCox подтягиваются обертки для переферии для указанного контроллера.


Минусы:

1. IntelliSense. Ну да, оно вроде как работает, но при этом скорее Sense, чем Intelli. Автозавершение не работает. Выборки по типу нет. Общее впечатление — достаточно кутцо, особенно если кодил час назад под десктоп на шарпе.

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

3. Нет примеров. Опять же, CooCox — почти все библиотеки снабжены семплами по использованию, тут этого не хватает.


Как итог — хотелось бы услышать мнение сообщества по данной разработке (особенно ввиду того, что есть триалка и можно спокойно пощупать). Для себя же — она чуть удобнее по сравнению с кокосом, и единственный вопрос — стоит ли это удобство 64 евро?..


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 fivefilters.org/content-only/faq.php#publishers.


[Из песочницы] Magento. Процесс загрузки конфигурационных файлов

Добрый день, хабрасообщество.

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

Кому интересно, добро пожаловать под кат.



Любое обращение к страницам в интернет магазине на базе Magento начинается с обработки index.php. В данном файле производится первичная проверка, в том числе версии PHP, объявляются константы и подключается файл Mage.php с базовым классом Mage. Данный класс реализует множество интересных методов, которые будут рассмотрены в дальнейших статья, а на данный момент нас интересует метод

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

self::$_app = new Mage_Core_Model_App();
if (isset($options['request'])) {
self::$_app->setRequest($options['request']);
}
if (isset($options['response'])) {
self::$_app->setResponse($options['response']);
}
self::$_events = new Varien_Event_Collection();
self::_setIsInstalled($options);
self::_setConfigModel($options);
self::$_app->run(array(
'scope_code' => $code,
'scope_type' => $type,
'options' => $options,
));




Видно, что в методе создается новый класс Mage_Core_Model_App и для него вызывается метод run, где и происходит вызов методов первоначальной загрузки конфигурационных файлов.

Рассмотрим данный метод:



public function run($params)
{
$options = isset($params['options']) ? $params['options'] : array();
$this->baseInit($options);
Mage::register('application_params', $params);


if ($this->_cache->processRequest()) {
$this->getResponse()->sendResponse();
} else {
$this->_initModules();
$this->loadAreaPart(Mage_Core_Model_App_Area::AREA_GLOBAL, Mage_Core_Model_App_Area::PART_EVENTS);


if ($this->_config->isLocalConfigLoaded()) {
$scopeCode = isset($params['scope_code']) ? $params['scope_code'] : '';
$scopeType = isset($params['scope_type']) ? $params['scope_type'] : 'store';
$this->_initCurrentStore($scopeCode, $scopeType);
$this->_initRequest();
Mage_Core_Model_Resource_Setup::applyAllDataUpdates();
}


$this->getFrontController()->dispatch();
}
return $this;
}


Метод baseInit отвечает за инициализацию свойства _config и загрузку базовых конфигураций. Базовая конфигурация загружается в методе _initBaseConfig, который в дальнейшем вызывает loadBase метод из класса Mage_Core_Model_Config.

Метод loadBase парсит и сохраняет в свойство _xml объекта Mage_Core_Model_Config данные из файлов app/etc/local.xml и app/etc/config.xml. В данных файлах содержатся доступы к БД и базовые настройки интернет магазина.

После чего происходит загрузка конфигурационных файлов модулей. За это отвечает метод _initModules, который, в свою очередь, вызывает метод loadModules из класса Mage_Core_Model_Config.

Для загрузки конфигурационных файлов модулей сначала загружается список всех файлов из папки app/etc/modules и производится разбор этих файлов. За это отвечает метод _loadDeclaredModules. В методе loadModules производится обработка только трех типов файлов из папки etc в директории модуля:



  • 1. confix.xml

  • 2. config.{resource_name}.xml (в нашем случае config.mysql4.xml)

  • 3. local.xml




Для загрузки первых двух типов вызывается метод loadModulesConfiguration, которому в качестве $fileName передается массив с именами файлов (config.xml и config.mysql4.xml)

image

Далее производится парсинг и загрузка данных в свойство _xml для всех активных модулей:

$modules = $this->getNode('modules')->children();
foreach ($modules as $modName=>$module) {
if ($module->is('active')) {
if ($disableLocalModules && ('local' === (string)$module->codePool)) {
continue;
}
if (!is_array($fileName)) {
$fileName = array($fileName);
}
foreach ($fileName as $configFile) {
$configFile = $this->getModuleDir('etc', $modName).DS.$configFile;
if ($mergeModel->loadFile($configFile)) {
$mergeToObject->extend($mergeModel, true);
}
}
}
}




С помощью файла local.xml можно вносить свои изменения в базовую конфигурацию интернет магазина.

На этом загрузка конфигурации завершается, и запускаются соответствующие процессы, в зависимости от роутера страницы на которую вы перешли.

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


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 fivefilters.org/content-only/faq.php#publishers.


10 месяцев бесплатных облаков на DigitalOcean


сегодня в 00:16


imageОдин из лучших облачных сервисов DigitalOcean дарит новым пользователям $50 на Чёрную пятницу.

Данной суммы должно хватить на 10 месяцев использования самого дешёвого тарифа (512Мб памяти, 1 ядро, 20Гб SSD, 1Тб трафика).


Сервис можно отнести к модели обслуживания «Инфраструктура как услуга». Как это использовать? Можно почитать в статьях. Сервис неоднократно упоминался на Хабрахабре, к примеру:




Для получения кредита нужно:


  1. Создать аккаунт

  2. Зайти в Billing

  3. Внизу страницы ввести Code: BLACK50

  4. Внести через Paypal $5 (может быть опционально)

  5. Создать Droplet с тарифом $5 в месяц

  6. 10 месяцев VPS за $5 (11 если внесли платёж через Paypal)

  7. ???????

  8. PROFIT!


Найдено на Hacker News.


Изображение лицензировано Creative Commons Attribution-Share Alike 2.0 Generic license.





Developers, stick with Russians – work in London




Переводы с

карты на карту


Переводы

через QR-Код


Новая функция

«Мой контроль»




Возьми Lumia 925 на тест-драйв сейчас.




Впечатляющие возможности

в стильном тонком корпусе из металла




Boomburum

исследует LTE


Эволюция средств связи

в путешествии по России




Проблемы коммуникации внутри бизнеса?



Смотри бесплатные курсы

и выиграй Xbox



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


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 fivefilters.org/content-only/faq.php#publishers.


Сервисный робот Tod. Первые шаги вместе с ROS



Добрый день, Хабр. Наша команда занимается разработкой сервисного робота Tod. Мы стремимся к созданию многофункционального робота, который в своих возможностях сможет потягаться с такими флагманами в мобильной робототехники как PR2 Willow Garage. Мы начинаем с малого, но с каждым днем наш робот приобретает новые навыки, оснащается новыми сенсорами. О том, что вообще из себя представляют сервисные роботы, вы можете узнать в нашей предыдущей статье, а сегодня речь пойдет о реализации навигационной системы Tod. Сегодня мы расскажем как научить робота выполнять навигационную задачу определения собственного местоположения на базе колесной одометрии и получать сенсорные данные с ультразвуковых сонаров. Всё это дело будет управляться под операционной системой для роботов ROS (Robot Operating System), которая хорошо зарекомендовала себя в различных робототехнических проектах. Добро пожаловать под кат.



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

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

В основе качественных навигационных алгоритмов лежит сложная математика, поэтому у многих начинающих робототехников пропадает энтузиазм после столкновения с расчетами якобианов и квантерионов, построением кинематической модели и применением вероятностных алгоритмов. К счастью, на сегодняшний день существует множество робототехнических фреймворков таких, как ROS, Player и Microsoft Robotics Studio, с помощью которых даже новички, обладающие необходимой настойчивостью, смогут использовать в своих проектах сложные навигационные и ИИ алгоритмы.

ROS и навигационный стек




Наша команда неслучайно решила использовать для робота Tod опенсорсный фреймворк Robot Operating System. ROS на сегодняшний день находит применение в робототехнических проектах многих исследовательских групп и компаний. Этот фреймворк предоставляет возможности, сравнимые с функциями целой ОС, включая аппаратные абстракции, управление устройствами на низком уровне, реализацию базовых функций и алгоритмов, передачу сообщений между процессами и менеджер пакетов. Исполняемая в ROS программа представляет собой набор узлов, которые могут обмениваться между собой сообщениями, подписавшись на общую тему. Такие узлы можно независимо реализовывать на языках C++ и Python. ROS полноценно работает под управлением Ubuntu, в частности, мы используем для Tod Ubuntu 12.40 и ROS Groovy. Более подробную информацию о ROS, документацию и хорошие пошаговые руководства можно найти на ros.org.

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

— Робот по форме должен быть круглым или прямоугольным, а его колеса должны быть голономными, т.е. движение робота должно осуществляться только вдоль направления вращения колес. Например, колеса автомобиля или велосипеда — голономные.

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

— Робот должен посылать сообщения для управления перемещением в формате линейной и угловой скорости.

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



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

— Узлы, помещенные в белый прямоугольник предоставляются ROS

— Узлы, помещенные в серые прямоугольники тоже предоставляются ROS, но их использование в стеке не является обязательным

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

Теперь, когда требования к использованию навигационного стека ROS известны, можно приступить к его адаптации к нашем роботу Tod.

Base controller и управление перемещением




Base controller — это узел навигационного стека, отвечающий за управление перемещением робота. ROS не предоставляет стандартного base controller'а, поэтому для своего робота необходимо писать собственный узел или брать за основу сторонние опенсорсные решения. Команды управления перемещением робота передаются к base controller в теме cmd_vel в сообщениях типа geometry_msgs/Twist.

geometry_msgs/Vector3 linear
float64 x
float64 y
float64 z
geometry_msgs/Vector3 angular
float64 x
float64 y
float64 z




Вектор linear задает линейную скорость перемещения робота по осям x, y, z, а вектор angular — угловую скорость перемещения по осям x, y, z. Далее эти команды преобразуются в команды управления вращением двигателей, и робот осуществляет перемещение в заданном направлении.

Порядок задания векторов скоростей зависит от кинематики робота. Наш робот Tod оснащен двухколесным дифференциальным приводом на базе двигателей постоянного тока, который позволяет ему перемещаться вперед, назад, по дуге или вращаться на месте. Это означает, что в сообщении geometry_msgs/Twist будет задаваться только линейная скорость по оси x (соответствует движению вперед-назад) и угловая скорость z (соответствует вращению на месте или перемещению по дуге при задании ненулевой линейной скорости).



3-х колесный робот с дифференциальным приводом. Рулевое колесо или шаровая опора обеспечивает роботу устойчивость.

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

Низкоуровневую задачу управления вращением двигателем мы поручили Arduino Uno в связке с драйвером Pololu Dual MC33926 Motor Driver Shield, выдающего небходимую мощность для наших 12-ти вольтовых двигателей. После реализации base controller'a можно покататься роботом с помощью клавиатуры и ROS-вского узла turtlebot_teleop, посылающего сообщения geometry_msgs/Twist base controller'у.


Одометрия




Одометрия – самый распространенный метод счисления пути. Суть этого метода заключается в определении позиции робота на основании подсчета инкрементальных оборотов колес относительно любой фиксированной точки на карте. Обычно измерения одометрии производятся оптическими цифровыми энкодерами, закрепленными на колеса или непосредственно на двигатели робота. Tod оснащен цифровыми энкодерами c разрешением 64 импульса на каждый оборот вала двигателя, что соответствует 8384 импульсов на один оборот колеса.



Геометрия одометрии. При заданной позиции робота (x, y, theta) и ширины колесной базы dbaseline требуется рассчитать новую позицию (x', y', theta').

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

std_msgs/Header header
uint32 seq
time stamp
string frame_id
string child_frame_id
geometry_msgs/PoseWithCovariance pose
geometry_msgs/Pose pose
geometry_msgs/Point position
float64 x
float64 y
float64 z
geometry_msgs/Quaternion orientation
float64 x
float64 y
float64 z
float64 w
float64[36] covariance
geometry_msgs/TwistWithCovariance twist
geometry_msgs/Twist twist
geometry_msgs/Vector3 linear
float64 x
float64 y
float64 z
geometry_msgs/Vector3 angular
float64 x
float64 y
float64 z
float64[36] covariance




Сообщение geometry_msgs/Pose определяет текущую позицию робота в трехмерном пространстве и ориентацию, которую в случае вращения объекта в трехмерном пространстве будет удобно рассчитывать кватернионами. Уже знакомое нам сообщение geometry_msgs/Twist определяет линейную скорость x и угловую скорость z.

Так как при выполнении вычислений мы имеем дело с несколькими системами координат, то нам понадобится узел tf. Узел tf работая с URDF-моделью робота, берет на себя заботу по выполнению громоздких вычислений преобразования позиции из локальной системы координат робота в глобальную систему координат карты.



Визуализация URDF-модел робота Tod с данными одометрии в симуляторе Rviz.

Сонары




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

Используя ультразвуковые сонары можно измерять расстояние от объекта до робота. Сонары работают по технологии TOF (time-of-flight). Они испускают звуковой сигнал, который отражается от ближайшего на пути объекта и возвращается в виде эха. Время «полета» сигнала фиксируется, и на его основе рассчитывается расстояние до объекта.



Сонар испускает звуковой сигнал и «слушает» эхо.

Tod использует сонары HC-SR04, поддерживающий диапазон измерения от 0.2 до 5 м с заявленной точностью 0.03 м. Угол обзора одного HC-SR04 составляет 30 градусов, и если разместить несколько сонаров рядом, то можно получить больший угол обзора. 3 сонара, размещенные на передней стороне Tod обеспечивают угол обзора 90 градусов.

Навигационный стек ROS может использовать данные различных видов сенсоров для получения одометрии, построения карты помещения или объезда препятствий. Теоретически есть возможность использовать сонары для построения карты помещения, ведь 12 или более сонаров дают угол обзора в 360 градусов и представляют более дешевую замену дорогостоящим лазерным дальномерам. Tod для построения карты использует Kinect, который по многим сенсорным характеристиками превосходит сонары. Однако, это не повод сбрасывать сонары со счета. Kinect закреплен на роботе достаточно высоко, что не позволяет видеть происходящего прямо под колесами. Сонары захватывают эту слепую зону, тем самым оказываясь полезными в решении задач планирования пути и объезда препятствий.

Как было сказано раннее, навигационный стек поддерживает работу только с лазерным сенсором и 3-D сканером. Это ограничение можно обойти, представив систему сонаров в виде фейкового 3-D сканера. 3-D сканер использует сообщение sensor_msgs/PointCloud, описывающее облако точек в трехмерном пространстве.

std_msgs/Header header
uint32 seq
time stamp
string frame_id
geometry_msgs/Point32[] points
float32 x
float32 y
float32 z
sensor_msgs/ChannelFloat32[] channels
string name
float32[] values




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



Визуализация сенсорных данных сонара в Rviz.

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

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 fivefilters.org/content-only/faq.php#publishers.


пятница, 29 ноября 2013 г.

Простая публикация геоданных на собственной карте на базе 2ГИС

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

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


Для реализации задумки была выбрана связка Google Docs и API картографического сервиса 2ГИС. Решение получилось действительно простым, в духе знаменитых «30 строк» :)



Шаг 1. Заводим таблицу для данных.



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

Вот ссылка на нее: docs.google.com/spreadsheet/ccc?key=0AvdXWIJtCGnndG0tODY5MzRsVFhnbkJseFk0aWJkaUE&usp=sharing


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


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


Теперь таблицу нужно опубликовать. Для этого идем в меню «Файл — Опубликовать в интернете». В появившемся окне выбираем «Начать публикацию», в нижней части — выбираем «CSV (значения, разделенные запятыми)» и получаем ссылку на наш лист таблицы в виде CSV.


Получается вот такая ссылка: docs.google.com/spreadsheet/pub?key=0AvdXWIJtCGnndG0tODY5MzRsVFhnbkJseFk0aWJkaUE&single=true&gid=0&output=csv


Шаг 2. Готовим данные для карты.



Напишем несложный скрипт на PHP и назовем его getMapData.php:

define('CSV_DATA_URL', 'https://docs.google.com/spreadsheet/pub?key=0AvdXWIJtCGnndG0tODY5MzRsVFhnbkJseFk0aWJkaUE&single=true&gid=0&output=csv');
define('DEFAULT_CITY', 'Кострома');

$points = array();
$csvDataHandle = fopen(CSV_DATA_URL, 'r');
$i = 0;
while ( false !== ($line = fgetcsv($csvDataHandle, null, ',', '"')) ) {
// Пропускаем первую строку в файле
if ( !$i++ ) continue;
// Считываем номер участка
if ( !empty($line[0]) )
$zone = $line[0];
$points[] = array(
'zone' => $zone,
'address' => DEFAULT_CITY . ', ' . $line[1] . ', ' . $line[2],
'data' => $line[3],
);
}




Тут нужно заметить, что скорее всего при первом запуске вы получите ошибку «Warning: fopen(): Unable to find the wrapper „https“». Это связано с тем, что в дефолтной установке PHP не включен модуль OpenSSL. Найдите в файле php.ini строчку

;extension=php_openssl.so и раскомментируйте ее, убрав точку с запятой. Обычного этого достаточно.

Разумеется, массив $points нужно куда-то закешировать, чтобы не «дергать» Google Docs при каждой отрисовке карты.


Теперь перед нами стоит следующая задача. Нужно адреса геообъектов каким-то образом перевести в координаты на карте. Для этого у 2ГИС есть соответствующее API: api.2gis.ru/doc/geo/search/


Вот простейший код для работы с API геокодера:



define('DGIS_API_KEY', 'XXXXXX'); // Ваш ключ
define('DGIS_API_URL', 'http://catalog.api.2gis.ru/geo/search?version=1.3&key=' . DGIS_API_KEY . '&q=%s');

function getGeoObjectInfo($address) {
$url = sprintf(DGIS_API_URL, $address);
$response = json_decode(file_get_contents($url));
if ( $response->response_code == 200 ) {
// Координаты центра геообъекта
$coords = $response->result[0]->centroid;
// Немного магии, чтобы привести их в нужный вид
$coords = explode(',', preg_replace('/^POINT\(([\S]+)([\s]+)([\S]+)\)$/', '$1,$3', $coords));
} else
$coords = array();
return $coords;
}




Ну и наконец пробежимся по массиву $points нашим «геокодером» и выведем результат в формате JSON:

foreach ( $points as &$address ) {
$address['coords'] = getGeoObjectInfo($address['address']);
sleep(1);
}

echo json_encode($points);




Обратите внимание на странную строчку sleep(1); в коде. Дело в том, что я пользуюсь тестовым доступом к API 2GIS, а при нем частота запросов ограничена одним в секунду. После получения полного доступа эту строчку нужно, разумеется, убрать.

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


Шаг 3. Показываем карту.



Тут я приведу полный код страницы. Ничего сложного в нем нет, тем более что у 2ГИС есть неплохая документация, ее можно прочитать по адресу api.2gis.ru/doc/maps/info/

<!DOCTYPE html>
<html>
<head>
<script type="text/javascript" src="//ajax.googleapis.com/ajax/libs/jquery/1.10.2/jquery.min.js"></script>
<script type="text/javascript" src="http://maps.api.2gis.ru/1.0?loadByRequire=1"></script>
<title>Тестовая карта с объектами</title>
</head>
<body>
<div id="DGMap" style="width:100%; height:600px"></div>

<script type="text/javascript">

$(DG.load(function() {

// Создаем карту
var map = new DG.Map('DGMap');
map.setCenter(new DG.GeoPoint(40.95,57.76),12);
map.controls.add(new DG.Controls.Zoom());

// Получаем данные
$.get('getMapData.php', function (data) {
var objects = JSON.parse(data);
for ( i in objects ) {
var marker = new DG.Markers.MarkerWithBalloon({
geoPoint: new DG.GeoPoint(objects[i].coords[0], objects[i].coords[1]),
balloonOptions: {
headerContentHtml: '<b>Участок №'+objects[i].zone+'</b>',
contentHtml: 'Адрес:'+objects[i].address+'<br />Число квартир:'+objects[i].data
}
});
map.markers.add(marker);
}
// Получаем границы добавленных на карту маркеров:
var markersBounds = map.markers.getBounds();
// Устанавливаем карте новые границы по маркерам:
map.setBounds(markersBounds);
});

}));

</script>

</body>
</html>


На этом, собственно, всё. Мы получили простейшую, но вполне функциональную систему, которая показывает на карте объекты согласно списку, ведущемуся в Google Docs. Вот такой mash-up :)


P.S.



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


P.P.S.



Собственно, ничто не мешает сделать такой же «трюк» с картами, например, от Яндекса. Получится даже красивее, за счет множества встроенных стилей и технологии кластеризации маркеров на карте. Изначально я пошел именно этим путем, но тесты показали, что геокодер 2ГИС все-таки гораздо точнее. Яндекс справляется с получением координат примерно от 95% адресов при условии их тщательной подготовки, 2ГИС — почти все 100%.

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 fivefilters.org/content-only/faq.php#publishers.


MNP — что имеем на сегодняшний день?

Осталось пару дней до начала внедрения услуги MNP (MobileNumber Portability). MNP – это возможность сохранить свой телефонный номер после смены оператора связи.


Активное обсуждение введения MNP началось еще в декабре 2012 года, но только более чем через полгода в июле 2013 было подписано постановление, касающееся внесения изменений и поправок в закон «О связи», позволяющий с 1 декабря 2013 года россиянам сохранять свой номер при переходе от одного оператора мобильной связи к другому. Заветная дата наступит уже в предстоящее воскресенье…



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


Если Вам нужно сменить оператора XXX на YYY, то заявление Вы идёт писать именно в YYY, а не к своему текущему. Заявление можно написать с 1 декабря 2013 года.


В заявлении о перенесении абонентского номера указываются сведения:



  • о переносимом абонентском номере;

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

  • о дате подачи абонентом заявления о перенесении абонентского номера;

  • о сроке начала оказания услуг оператором-реципиентом;

  • о решении абонента об одностороннем отказе от исполнения и о расторжении договора с оператором-донором;

  • о согласии абонента погасить задолженность за услуги, оказанные по договору с оператором-донором в отношении переносимого абонентского номера;

  • о согласии абонента перейти на авансовую систему оплаты услуг подвижной связи




К заявлению о перенесении абонентского номера прилагается договор, предусматривающий использование перенесенного абонентского номера. В этом договоре следует указать свой новый тариф.

Оператор подвижной связи, в сеть связи которого осуществляется перенесение абонентского номера, вправе самостоятельно определить дату и время (час) начала оказания услуг подвижной связи с использованием перенесенного абонентского номера, которые указываются в договоре об оказании услуг подвижной связи. Указанная дата начала оказания услуг подвижной связи с использованием перенесенного абонентского номера не может быть определена позднее 15 апреля 2014 г.


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



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


Информирование о статусе переноса номера осуществляется путем направления абоненту короткого текстового сообщения с 9 часов 00 минут до 18 часов 00 минут.


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



  • 30 минут — для предоставления исходящих соединений по сети подвижной связи и направления коротких текстовых сообщений;

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




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


  • до момента технической готовности других операторов связи не будут приниматься входящие вызовы и SMS/MMS с их сетей

  • возможность подключения и/или использования дополнительных услуг не гарантируется

  • пополнение лицевого счета перенесенного абонентского номера возможно в салонах, оплата другими способами не гарантируется




Что нужно знать при переходе к новому оператору?


  • Стоимость предоставления услуги: 100 рублей за каждый переносимый номер

  • Вы подключили текущие номера в том же регионе, где работает новый оператор

  • Ваши номера являются федеральными, а не городскими

  • У вас есть все документы, необходимые для заключения договора об оказании услуг связи

  • Необходимо подать заявление на перенос номеров новому оператору связи

  • Баланс и бонусы не переносятся. Остаток на балансе можно получить у оператора-донора

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

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

  • Потребуется подключение новых SIM-карт

  • В момент оказания услуг новым оператором связи возможно ограничение связи: до 30 минут для исходящих звонков и до 6-ти часов для входящих




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

Попробуем узнать статистику на Хабре, проголосуйте пожалуйста в опросе!


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 fivefilters.org/content-only/faq.php#publishers.


[Перевод] Как умирают софтовые компании, или Как правильно выращивать программистов

imageОкружение, которое выращивает творческих программистов, убивает менеджмент и маркетинг. И обратное тоже верно.

Программирование — это великая Игра. Она поглощает тебя целиком, тело и душу. Когда ты весь погружён в него — для тебя более ничего не существует. Когда ты выныриваешь на свет, ты можешь с удивлением обнаружить, что прибавил 50 кг, возраст твоего исподнего приближается к возрасту первоклашки, и судя по количеству коробок из-под пиццы, уже пришла весна.

Но тебе всё равно, потому что программа работает, код красив, изящен и быстр.



Ты победил.

Ты знаешь, что некоторые считают тебя нердом. И что? Они ведь не Игроки. Они никогда не созтязались с Windows, не выходили один на один с DOS. Для них C++ — это неплохая оценка, почти B (по американской системе оценок) — но не язык. Их почти не видно. Как солдат или художник, тебе всё равно, что там думают эти гражданские. Ты творишь нечто замысловатое и прекрасное. Им не понять.


Пасека.

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


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


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


«Вот он — Игрок!», думает начинающий кодер. «Он на мой код посмотрел!» Больше ничего и не надо.


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


Выход из-под контроля.

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


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

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


Выкуривание.

А для программиста шок ещё больше. Он вдруг обнаруживает, что его контролируют инопланетяне. Митинги, Графики, Отчёты…

И кто-то теперь вдруг требует от него ПЛАНИРОВАТЬ свою деятельность, и потом придерживаться плана! Не улучшать. Не подправлять. Никогда, ни за что не трогать чужого кода.

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


Улей обречён. Лучшие программисты улетают уходят. Маркетологи чувствуют себя комфортно в окружении людей в ярких галстуках, и у них всё под контролем. Правда, они сбиты с толку — почему-то каждая новая версия программы теряет долю рынка, разрастается и обрастает багами.


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


PS: Это перевод статьи Орсона Скотта Карда, автора серий книг «Вселенная Эндера», «Сказание об Элвине Созидателе», «Возвращение домой».


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 fivefilters.org/content-only/faq.php#publishers.


OpenVX: стандарт компьютерного зрения

Автор: Виктор Ерухимов, исполнительный директор Itseez, председатель рабочей группы OpenVX

The Khronos Group 18 ноября 2013 года представила предварительную спецификацию стандарта OpenVX 1.0 для компьютерного зрения. Поскольку Itseez был одним из инициаторов этой деятельности и активно участвовал в создании спецификации, мы решили рассказать про этот стандарт аудитории Хабрахабра.




Когда несколько лет назад инженеры Itseez начали заниматься компьютерным зрением на мобильных платформах, они были поражены тем, как медленно работают алгоритмы на процессорах мобильных телефонах по сравнению с настольными компьютерами, к которым тогда все привыкли. Простая функция изменения разрешения изображения (cv::resize) могла работать дольше 20 миллисекунд, почти не оставляя времени для обработки видео в реальном времени (функция, обрабатывающая 30 кадров в секунду, должна работать примерно 33 мс на кадр). Например, используя NEON оптимизацию, cv::resize можно ускорить более чем в 7 раз на ARM (см [1]). Стало очевидно, что необходимо более эффективное взаимодействие кода с SoC, причем не только с центральным процессором, а со всеми доступными ускорителями, включая GPU, DSP, ASIC, FPGA. Ни одна компания не будет решать такую задачу в одиночку, поэтому Itseez совместно с NVIDIA обратилась в Khronos Group с предложением создать стандарт для компьютерного зрения, представляющий из себя Hardware Abstraction Layer (HAL), то есть интерфейс, функции которого будут вызываться высокоуровневыми алгоритмами, а релизация будет оптимизирована под вычислительную архитектуру. Примеры стандартов от Khronos — OpenGL и OpenCL, — решают эту задачу для графики и общих вычислений соответственно. Предложение было поддержано большим количеством компаний, и была создана рабочая группа, председателем которой был избран сотрудник Itseez. В разработке стандарта принимают участие лидеры индустрии (см. ниже). С такой мощной поддержкой, которую получила идея OpenVX, можно действительно изменить индустрию, сделав разработку приложений компьютерного зрения как никогда простой!


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





OpenVX представляет из себя C API двух уровней: immediate mode и graph mode. Первый – это отдельные функции, по структуре очень похожие на примитивы из OpenCV. У всех функций есть эквивалент в OpenCV, по большей части в модуле imgproc.


Верхний уровень позволяет описать алгоритм компьютерного зрения в виде ориентированного графа, где каждый узел соответствует функции. Для каждой функции immediate mode существует эквивалентный узел графа. Граф полностью задается перед выполнением. Пользователь может определить свою функцию через C API callback и включить ее в граф (пользовательские узлы, см. user nodes в примере Stereo Machine Vision ниже). Оба уровня API работают с контейнерами для изображений, внутренняя структура которых не специфицирована, – пользователь оперирует с идентификаторами:



typedef uintptr_t vx_reference;
typedef vx_reference vx_image;




Таким образом, данные контейнеры являются непрозрачными (opaque), что дает большую свободу реализации. Распределение изображений и узлов графа по потокам и ускорителям почти никак не управляется стандартом, и, соответственно, остается на усмотрение разработчика, реализующего стандарт. В рамках этой архитектуры можно хранить изображения и исполнять функции OpenVX на ускорителях, что может сильно ускорить алгоритм или сделать его более энергоэффективным. Вообще, Graph API открывает большой простор для оптимизаций. Например, можно выполнять несколько операций паралелльно на разных ядрах или разных ускорителях. При определенных условиях можно исполнять два последовательных узла графа одновременно в одном потоке, выполняя вычисления на лету, или обрабатывать изображение по кускам (tiling), для того, чтобы повысить кэш-эффективность. Поддержка tiling для пользовательских узлов реализована при помощи расширения стандарта OpenVX 1.0 Tiling Extension — интерфейс, утвержденный группой OpenVX, но не обязательный к реализации для OpenVX 1.0. В дальнейшем, возможно, Tiling API станет обязательной частью следующих версий стандарта.




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


В течение работы над OpenVX мы получали много вопросов по поводу взаимодействия OpenVX и OpenCL. Например, почему OpenVX не может быть просто набором ядер (kernels) OpenCL? Мы решили сделать OpenVX не требующим зависимости от OpenCL, потому что есть ускорители, не поддерживающие OpenCL, но способные выполнять часть функций OpenVX. Тем не менее, OpenVX спроектирован так, чтобы сделать возможной реализацию OpenVX на OpenCL.





Очень многие разработчики технологий компьютерного зрения сейчас при работе ориентируются на одну платформу, выбирая алгоритм и оптимизируя его реализацию для одной системы. При условии широкой поддержки OpenVX для разных платформ, усилия по адаптации алгоритма для другой платформы будут минимальными. В ближайшем будущем это приведет к росту классных приложений компьютерного зрения для мобильных телефонов и планшетов. В более далекой перспективе OpenVX будет стимулировать производителей чипов к созданию ускорителей, ориентированных на OpenVX. Это приведет к радикальному ускорению технологий компьютерного зрения и создаст условия для более умных приложений, о которых сейчас никто даже не мечтает — такие, как измененная реальность на носимых устройствах (augmented reality on wearable devices) и функции безопасного вождения, доступные на автомобилях эконом-класса.

В настоящий момент опубликована предварительная версия спецификации (прямая ссылка на документ). Её цель – собрать отзывы сообщества и, по возможности, учесть их в финальной спецификации OpenVX 1.0, выпуск которой ожидается не позднее середины 2014 года. Сейчас можно оставить сообщения на форуме, в будущем откроется доступ к bugzilla. Мы призываем всех будущих пользователей OpenVX посмотреть на стандарт! И, конечно, всех энтузиастов компьютерного зрения мы приглашаем прислать свое резюме нам на адрес jobs@itseez.com!

Всем удачи и быстрых алгоритмов!




[1] Kari Pulli, Anatoly Baksheev, Kirill Kornyakov, Victor Eruhimov: Real-time computer vision with OpenCV. Commun. ACM (CACM) 55(6):61-69 (2012).

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 fivefilters.org/content-only/faq.php#publishers.