За четыре года работы над онлайн консультантом WebConsult мы накопили достаточно большой опыт, и оказалось, что изначально мы не учли многих вещей, которые потом приходилось переделывать – в итоге это стоило нам массы времени, средств и нервов. Эта статья, а возможно и цикл статей, будут посвящены аспектам, которые необходимо продумать еще до начала разработки, дабы будущие стартаперы изначально закладывали грамотную основу в свои веб-приложения. Этой статьи нам очень не хватало четыре года назад, когда создание системы только начиналось, и мы надеемся, что она поможет вам не повторить наших основных ошибок. Многие приведенные советы кому-то покажутся очевидными, однако часто разработчики их упускают, поэтому мы считаем необходимым еще раз напомнить о простых вещах.
Был как-то проект у меня, который был связан с картой города. И возникла идея, что раз есть карта с маршрутами и соответствующими остановками городского транспорта, то почему бы не сделать поиск пути из пункта А в пункт Б на ней.
Так как железо, где предполагалось размещать софт, имеет крайне узкий канал интернета, то поиск должен был бы полностью осуществляться локально, то есть без привлечения мощностей сервера. Кроме того, конечно же, хотелось не потерять внимание пользователя и выдать ему результат как можно быстрее.
Где-то около часа или двух я сидел и не мог ничего придумать, а потом появилась идея, что я могу рассматривать маршрут, не как множество остановок, а как 1 точку. И если я сверну маршруты в точку, то я получу очень простой граф.
Идея показалось неплохой, и мне понравилась.
Первое что сделал это запарсил с сайтов маршруты транспорта. Далее принялся за граф.
Это оказалась не сложная задача, берем каждую остановку маршрута и смотрим, нет ли остановок любого другого маршрута в заданном нами радиусе. Радиус взял 600м (в последней версии 400м) – предполагаемое расстояние, которое человек может пройти безболезненно пешком от одной остановки до другой в случае необходимости пересадки. Вероятно, это расстояние можно сократить, скажем, до 200м, так как расстояние от одной остановки до другой на перекрестке не превышает эту дистанцию.
Итак, после всех этих манипуляций я получил граф, по которому достаточно быстро можно построить путь от одного маршрута к другому. Таким образом, получился граф, который хранит информацию о переходах с одного маршрута городского транспорта на другой, эдакий, мета-граф.
За несколько месяцев алгоритм переписывался пару раз, далее поподробнее расскажу о последней реализации.
Качество видео ужас, но как сделать получше я так и не обнаружил.
Усредненное время, затрачиваемое на выполнение шагов:
gpt — 0.009с, найти ближайшие остановки к точке клика
grt — 0.001с, найти кратчайший путь от маршрута к маршруту
apt — 0.0001с, добавляем остановки и точки поворота к нашему маршруту
all — 0.01c, суммарное время выполнения поиска пути
В данной статье пойдет речь о методе распознавания рукописного ввода путем анализа всех точек плоскости и перебора всевозможных комбинаций с целью отыскать наилучшее наложение контрольных точек на ранее описанные фигуры. Поясню.
Рукописный ввод — это рисование мыслимым «пером» определенной фигуры. Рисование в компьютерных системах — это сохранение в графической памяти информации обо всех пикселях графического контекста. «Точка на плоскости» в математике — понятие абстрактное. В компьютерной же графике за этим понятием скрывается «пиксель». Данный алгоритм распознавания будет анализировать предоставленный ему набор точек( пикселей ) и пытаться в нем отыскать наиболее возможную и похожую фигуру. Фигура, в свою очередь, это каркас, содержащий лишь основные( контрольные ) точки, делающие фигуру уникальной.
Матчасть
Вообще говоря, сердце алгоритма — всем известная со времен школы Теорема Косинусов, являющаяся обобщенной теоремой Пифагора. Зная координаты трех точек плоскости и их порядок «появления» на ней, мы можем с легкостью определить угол, описанный этими точками( Вершина угла — вторая по счету точка ):
A( x1;y1 )
B( x2;y2 )
C( x3;y3 )
расстояния между точками находятся по теореме Пифагора
Зная косинус, величину угла легко можно вычислить.
Среди набора точек, которые подаются на вход алгоритма, необходимо «подставить» точки во всевозможные каркасы фигур( о них выше ) и выбрать наилучшее решение среди найденных. Делается это следующим образом:
Мы берем первую и последнюю точки каркасов фигур. Уже две есть, осталось отыскать третью ( для нахождения величины угла ).
Поиск третьей осуществляется перебором все последующих точек после первой. Решение включать точку в предполагаемый каркас фигуры принимается на основе двух анализов:
Попытка подставить точку в угол( в качестве третьей, заключительной ) и проверить его на соответствие величине того же угла в каркасе реальной фигуры.
Проверить отношение сторон получившегося угла с тем же отношением сторон угла в каркасе реальной фигуры.
Если эти два условия выполняются, то алгоритм принимает решение о включении точки из набора точек в мыслимый каркас( при этом увеличиваем величину похожести на текущую анализируемую фигуру ).
Если, допустим, у нас есть несколько анализируемых каркасов, например, «8» и «6». И результат алгоритма распознавания: «8»-80%, «6» — 90%, то решение принимается в пользу той фигуры, в каркасе которой присутствует больше контрольных точек, т.е в пользу восьмерки.
Процент сходства набора точек с точками в каркасе высчитывается просто: суммируются все точки, которые сошлись с теми же точками в каркасе и находится отношение. Допустим, если в каркасе N контрольных точек, а у нас сошлось M, то процент сходства — M / N * 100
В то время как область разработки софта растет, мы разработчики постоянно пытаемся ухватиться за новейшие технологии. К счастью, ремесло написания поддерживаемого кода языко-независимо и в этой серии постов мы сфокусируемся на мощном наборе вечных инструментов: паттернах проектирования.
Я настроятельно рекомендую книгу Russ Olsen — Design Patterns in Ruby. Наш цикл постов будет черпать вдохновение оттуда и будет чем-то вроде краткой выжимки. Таким образом, если вам понравится то что вы читаете (а я надеюсь на это!), книга будет отличным продолжением.
Мы рассмотрим различные паттерны проектирования и научимся их применять. Сегодняшняя тема — Шаблоный метод, простейший паттерн проектирования.
На домашней странице Ubuntu снова обратный отсчет. Подпись гласит «The line where / two surfaces meet». Я не знаю, к какому событию он приурочен, но в коментариях на одном сайте здорово шутят — «Canonical выпустит холодильники с Ubuntu». И если речь идет об Ubuntu Phone, то подпись очень даже правдивая. С одной стороны шквал негатива («Еще одна мобильная ОС» и т.д. и т.п.), с другой — искреннее желание как можно скорее увидеть релиз своей любимой ОС на своем смартфоне. Как вы можете помнить, вместе с анонсом Ubuntu Phone так же сообщалось о привлечении волонтеров в разработку 12 базовых приложений для это ОС (core applications). Так вышло, что будучи членом одной из команд, я обладаю некоторой информацией, которая может показаться интересной. Статья не претендует на «взгляд из самых первых рядов», а в формате простого повествования рассказывает о некоторых деталях нашей работы изнутри. К тому же я, помнится, обещал делиться информацией о ходе процесса. С другой стороны, я не могу безэмоционально все рассказывать, так что в статье много нетехнических деталей и художественного повествования. Но если Вы заинтересованы, прошу под кат!
Впервые столкнувшись с MapReduce, я продолжительное время искал реальные примеры применения. Пресловутый поиск слов в тексте, встречающийся в каждой второй статье о MapReduce, искомым примером считать не будем. Наконец, на двух курсах по Big Data на Coursera, я нашёл не только живые примеры, но теоретическую подоплёку для более глубокого понимания происходящего. Возможность применить полученный багаж знаний не заставила себя долго ждать.
В этой небольшой статье я хочу поделиться опытом реализации классической для большинства Интернет-магазинов системы фильтров товаров по критериям применительно к туристическому порталу, где появилась задача поиска и фильтрации по базе в десятки тысяч отелей, каждый из которых описывается рядом параметров и наличием нескольких десятков предоставляемых сервисов из сотен возможных.
Хочу поделиться своими наработками по настройке nginx, которые, возможно, помогут кому-то при старте нового проекта или избавят от необходимости копипастить очередной vhost.
Я отметил две проблемы подавляющего числа конфигов nginx'а, попадавших мне на глаза:
«Всё в одном файле»
Дублирование настроек
С помощью моего подхода, надеюсь, эти и многие другие проблемы будут устранены.
О системе обучения Coursera на хабре писали неоднократно. И даже приводили анонсы некоторых курсов. Я же решил отобрать те из них, которые могут быть интересны и полезны людям, работающим со звуком: музыкантам, композиторам, звукорежиссёрам, как опытным, так и только помышляющим сделать первые шаги. Предлагаемые курсы помогут:
ознакомиться с физическими основами звука и акустики;
получить базовое или расширить понимание теории музыки, психоакустики и т.п.;
познакомиться с цифровой обработкой звука, программными инструментами и механизмами обработки;
научиться писать свои простейшие программы для обработки звука;
наконец, научиться игре на гитаре, джазовой импровизации, управлению репетициями и другим интересным вещам.
Это вторая часть доклада, который я прочитал на Dribbble Meetup 2013 в Москве. В первой части я подробно описал свой процесс интеграции дизайна под платформу Android. Эта часть — про интеграцию дизайна под iOS и Windows Phone, а также я вскользь упомяну про Samsung Bada 2.0. Дальше — много картинок.
«Как автоматизировать сочинение музыки?» — этот вопрос тревожит умы музыкантов еще со времен средневековья. Кеплер превращал траектории движения планет в музыку; Моцарт и его современники изобрели игру в «музыкальные кости» — они броском кубиков выбирали из большой таблицы такты и составляли из них менуэты. Но только с появлением компьютеров алгоритмическая генерация музыки получила настоящее развитие. Теория вероятности, марковские цепи, искусственные нейронные сети — все это стало инструментами создания музыки.
Сделать плавно работающий список с возможностью выделения рядов как кликом на иконку ряда, так и долгим нажатием на него. Также, дабы выделение не пропало даром, мы должны дать возможность пользователю производить некие действия с выделенными объектами.
У нас неплохо получается хранить фотографии, поэтому мы решили упростить жизнь и вам, если вы хотите соорудить свой tumblr, facebook или imgur. Дело на самом деле нехитрое, но есть тонкости, о которых лучше знать заранее. К тому же мы сделали всё на node.js, что не слишком характерно для хранилища с более чем 100 000 000 фотографий.
Я сполна получил п***й за первый пост. Самое время писать продолжение! Итак, чего же мне надо от резюме разработчика?
Все ниже в порядке приоритета.
Код
Я хочу видеть код, которым вы гордитесь. Я хочу знать, как вы называете переменные, как декомпозируете систему, как проверяете входные условия и насколько любите все усложнять. Очень желательно, если будет описание проблемы, иначе понимание кода и решения затруднено.
На днях появился новый веб-сервис, позволяющий в несколько кликов создавать новый проект для андроид со всеми современными вкусностями сторонних библиотек.
Название AndroidKickstartr.com отлично описывает его задачу — максимально быстро и просто сконфигурировать новый проект, добавив туда все самое необходимое.
В этой статье я хочу поделиться с вами своим практическим опытом разработки игры для iOS на основе open-source компонентов. Мы пройдемся по техническим решениям, которые были приняты во время разработки игры.
Разработчиком мобильных приложений под iOS я стал совсем недавно. Все началось с обычного увлечения, когда пришла мысль попробовать свои силы в новых технологиях. После нескольких успешных проектов на фрилансе я решился на разработку своего собственного приложения – визитки для фирмы, в которой на тот момент работал инженером-конструктором. К сожалению, после всех согласований и утверждений, когда проект уже был в рабочем состоянии на моем телефоне, я так и не смог получить добро на публикацию его в App Store. Бюрократическая машина в нашей стране работает исправно.
Сегодня я хочу поделиться с вами несколькими полезными шаблончиками (templates) для IDE Eclipse, которые помогут вам ускорить некоторые рутинные операции при разработке под Android. Я пока что использую Eclipse для разработки, но, я уверен, что Idea позволит создавать совершенно аналогичные шаблоны.
Что такое шаблоны? Это заранее заготовленные кусочки кода, которые IDE может быстро подставлять для вас при нажатии на Ctrl+Space. Например, введите «syso» в eclipse, нажмите Ctrl+Space. Бац, у вас появился System.out.println(), или «fore» — у вас появится готовый шаблон для цикла for each. Более того, данные кусочки параметризированы, и IDE предложит вам ввести имена для нужных переменных.
Это краткий перевод основных тезисов из брошюры «Web API Design. Crafting Interfaces that Developers Love» Брайана Маллоя из компании Apigee Labs. Apigee занимается разработкой различных API-сервисов и консталтингом. Кстати, среди клиентов этой компании засветились такие гиганты, как Best Buy, Cisco, Dell и Ebay.
В тексте попадаются комментарии переводчика, они выделены курсивом.
Собираем API-интерфейсы, которые понравятся другим разработчикам
Понятные URL для вызовов API
Первый принцип хорошего REST-дизайна — делать вещи понятно и просто. Начинать стоит с основных URL адресов для ваших вызовов API.
Ваши адреса вызовов должны быть понятными даже без документации. Для этого возьмите себе за правило описывать любую сущность с помощью коротких и ясных базовых URL адресов, содержащих максимум 2 параметра. Вот отличный пример:
/dogs для работы со списком собак /dogs/12345 для работы с отдельной собакой
