В этом году я успел уже рассказать о том, как выбирал мини-квадрокоптер за 20$ и о том, как нашёл для себя мини-квадрокоптер с камерой за 40$ и даже рассказал о том, как устроил мини-соревнования на коптерах в парке-музее «Коломенское». Но после каждой публикации ко мне поступало много вопросов именно о выборе бюджетного квадрокоптера, который умеет транслировать видео на пульт. Понятно, что многих людей интересует именно бюджетный вариант первого квадрокоптера, так как после моей статьи «Купить квадрокоптер и попрощаться с ним» многие стали свидетелями того, как за несколько минут я попрощался квадрокоптером за 500$, подвесом за 300$ и камерой за 600$, что в современной России очень не бюджетно.

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

В прошлой статье РОБОТ на базе: android, arduino, bluetooth. Начало была предложена общая схема робота и представлена технология передачи и приема данных между андроидом и ардуино. А в ее завершении приведен список заказанных деталей и модулей. Детали получены (рис.1), комментарии учтены, приступим к созданию первого робота – рефлексного робота.

Рисунок 1

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

Это — статья-roadmap-cheatsheet для изучающих Ruby. Вместо того, чтобы рассказывать очередной how-to я постараюсь расписать все те вещи, которые, на мой взгляд, можно изложить кратко и емко, с упором на то, что программисту пришедшему с других языков и платформ может показаться не очевидным, антипоисковым и просто затратным по времени на изучение без подсказок — на остальное просто дам ссылки. Не смотря на то, что в природе существует множество туториалов/кастов/книг/чего угодно по чему угодно — именно такого формата мне самому всегда не хватает. И по сути, это те вещи, которые чаще всего рассказываю при вопросах «а как оно вообще?», «с чего начать?», «а как делается такая вот штука?», «а какой gem лучше?». Кстати, пока работал над этой статьей на Хабре появилась похожая про Python — видимо, идея витает в воздухе.

От переводчика: MeteorJS — открытый (MIT) фулстек JavaScript фреймворк (и клиент и сервер). Текущая версия 0.7.0 — в начале 2014 планируется выход версии 1.0. Публикации на хабре: 1, 2, 3.

Подготовка к масштабированию

Диаграмма компонентов:

Здесь три сервера Метеор, один MongoDb-сервер и HaProxy-сервер, как балансировщик нагрузки. Для поддержки SSL поставим Stud перед HaProxy.

Давайте обсудим компоненты и их настройку.

Здравствуй, Хабр!

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

• Раздача на Рутрекере (видео+слайды)
• Прямые ссылки на видеофайлы: первая лекция, вторая, третья, четвертая, пятая, шестая и седьмая
• Прямая ссылка на слайды (zip-архив pdf-файлов)
• Подкаст в iTunes
• Плейлист на YouTube
• Форум курса

Первая лекция: Введение в JavaScript, немного истории, числа (тут есть ошибка: функция toFixed округляет значения).



Остальное – под катом.

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



Пример и код в jsFiddle.

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

Этот пост о том, как я пытался прикрутить анимацию и сортировку к известному примеру todos.

Мобильные приложения, это не будущее разработки, это уже настоящее. В настоящее время пользователей мобильных приложений уже 1.2 млрд. человек, и это количество постоянно растет (Wikipedia). Вскоре количество мобильных устройств превзойдет количество людей на планете. Если скорость роста количества мобильных устройств останется неизменной, то к 2017 году ими будут пользоваться 5.1 млрд. человек.
Для нас, как для разработчиков приложений, важно разрабатывать свои приложение с учетом мобильных пользователей, если мы хотим чтобы они были востребованы. В AngularJS реализована поддержка мобильных устройств, написанная как командой AngularJS, так и сообществом.
В этой статье мы будем работать с двумя различными способами, чтобы дать читателям опыт в разработке мобильных приложений.

Как я перетащил пакет Tastypie на Pony ORM и что из этого получилось.

Данная статья продолжает историю моей борьбы за производительность приложений на python и django.

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

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

Предисловие

Хабралюди проявили некоторый интерес к Unity, поэтому открываю этим постом цикл туториалов, освещающих основные моменты работы с объектом (цикл неопределённой пока длительности — если кому окажется полезным продолжу).

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

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

Как я могу судить, для людей, которые на практике не столкнулись с некоторыми специфическими проблемами, эти 2 понятия являются довольно трудными для понимания. И не потому, что понятия Promise и Deferred являются с чем-то сложным, а потому, что довольно непросто сходу выдумать подходящую задачу, чтобы попробовать Deferred objects (в JQuery и не только) в действии.

Да, вероятно для тех, кто знаком с этим вопросом он покажется пустяковым и не стоящим и выеденного яйца. Кроме того, вопрос уже многократно обсуждался. Однако, я наберусь смелости еще раз его затронуть и вот почему: 1) Мне кажется, что для некоторых читателей этот пост может оказаться интересным. 2) Я пойду от практики, а не от теории. Моя задача — продемонстрировать работу инструмента. Теорию и другие варианты применения при необходимости вы найдете в ссылках к посту.

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

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

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

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

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

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

Мы в Alconost предоставляем услуги создания и ведения контекстной рекламы и, по долгу службы, иногда занимаемся разработкой посадочных страниц (landing pages). Мы были очень рады найти и перевести статью, в которой автор изложил все требования, которым такая страница должна соответствовать. Но есть в этой статье и большой минус. Пунктов аж 50, каждый можно отметить в чеклисте, но после доступен лишь результат в баллах, которым можно разве что похвастаться перед друзьями.

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

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

Эта маленькая библиотека позволяет очень просто создать пошаговое введение для сайта или приложения. Достаточно добавить атрибуты data-intro и data-step с описанием и номером шага соответственно к нужным элементам страницы. Вот так:

<a href='http://google.com/' data-intro='Hello step one!' data-step='1'></a>

Бен Кэменс обнаружил, что в выпадающем списке Shop by Department на сайте «Амазон» ховер-эффект происходит очень быстро, абсолютно без какой-либо задержки. Тем самым происходит нарушение старого, выработанного ещё в 90-х годах прошлого века правила: перед отображением пункта подменю необходим так называемый гистерезис, запаздывание.



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

Появилась у меня как-то идея (или расcчётка по мобильным платформам) написать приложения под android на своём любимом ruby. И тут я вспомнил про проект который несколько раз упоминался в RubyNoName подкасте, собственно речь пойдёт о Ruboto.

Как известно, в Django предусмотрен очень лёгкий и простой механизм уведомления разработчиков о возникающих проблемах. Когда проект развёрнут на локальном компьютере и в настройках DEBUG имеет значение True, то отчёты об ошибках просто выводятся в виде HTTP-ответа, в виде удобной страницы с возможностью копирования traceback'а.

Если же это production-сервер, и DEBUG имеет значение False, то отчёты по умолчанию отправляются по электронной почте всем, кто указан в настройке ADMINS (кстати, если вы используете SMTP-сервер, то письма могут не приходить, так как SMTP-сервер не принимает адрес root@localhost — в этом случае просто укажите любой другой адрес, который будет принимать ваш SMTP-сервер, с помощью настройки SERVER_EMAIL).

Разумеется, ничего не мешает также написать свой logging handler (обработчик журналирования) и сохранять отчёты об ошибках в любом нужном виде — создавать задачу в баг-трекере, например.

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