ВНИМАНИЕ, статья устарела, но её всё еще можно использовать в ознакомительных целях
Захотелось внезапно рассказать подробнее об открытом и свободном проекте для управления различными летательными аппаратами (ЛА). Вообще до недавнего времени он был рассчитан только на мультиротороные системы (коптеры), стабилизацию подвеса камеры и в бета версии была стабилизация для летающего крыла, но судя по dev прошивкам в скором времени будут официально добавлены самолеты и вертолеты, а стабилизация полета летающего крыла уже вышла из стадии бета тестирования.

Идея создания книги собственными руками поселилась в голове изрядно давно. Изучив практическую сторону вопроса, я лишь укрепился в этом желании, но руки никак не доходили даже до выбора книги. И вот некоторое время назад судьба распорядилась за меня. В силу обстоятельств непреодолимой силы во мне появилось желание подарить уникальную вещь, а, как известно, лучше книги подарка нет. Выбор пал на любимое произведение объекта моего неконтролируемого интереса, невероятно мудрое и емкое, смыслом, а не словами, творение Экзюпери — «Маленький принц». Желание творить подстегивала и моя личная любовь к этой книге. Решение было принято, время неумолимо приближало момент вручения, и я приступил к работе.

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

^{Один из тестовых полётов нашего коптера}

Оглавление

1. Уравнения динамики

Введение

Давным-давно я написал следующий комментарий: Всё.
После такой новости сажусь делать свой квадрокоптер. А то вон все делают, а я нет. Не, ну а что.
Всегда хотел, чтобы у меня была какая-нибудь летающая штука. Были 2 вертолета радиоуправляемых. Но кончилось это плохо.
Я решил делать свой квадрокоптер. Как это кончится — посмотрим. Я не буду использовать какие-либо готовые полетные контроллеры, все запрограммирую самостоятельно. И постараюсь этот процесс описать в цикле статей. Сейчас представляю вашему вниманию первую часть. В ней будет бегло показано то, какие уравнения динамики скрываются внутри квадрокоптера.
Итак, поехали.

Добрый день!
Хотелось бы немного рассказать о проекте AeroQuad Open Source и о своем опыте сборки квадрокоптера.

Проект AeroQuad поддерживает:
1. В перспективе возможность подключения gps, полета по путевым точкам, которые можно загрузить через AeroQuad Configurator.
2. Стабилизация камеры. Для компенсации движений квадрокоптера можно использовать 3 сервопривода.
3. On-Screen-Display. Наложение графики на видеопоток.
4. Помимо подключения гироскопа акселерометра и магнитометра есть возможность подключения других датчиков, таких как ультразвуковой дальномер и барометр.

Задача

Настройка удобного средства для обработки и получения логов.

Условия

1. Лицензия MIT или Apache 2.0
2. Возможность приема и обработки многострочных сообщений
3. Простота в настройке и использовании
4. Возможность работы с логами из Log4j

Решение

Logstash + ElasticSearch + Kibana 3.

Последнее время ни один пост от нашей компании не обходился без традиционного вопроса от читателей, «А когда же выйдет ваша кросс-платформенная C/C++ IDE?». И вот сегодня, наконец, мы готовы сказать: Public Early Access Program началась!



Если коротко: тут — скачать, здесь — почитать ознакомительную инструкцию, а под катом — подробности.

Добрый день, Хабрахабр. Это еще один пост в рамках моей программы по обогащению базы данных крупнейшего IT-ресурса информацией по алгоритмам и структурам данных. Как показывает практика, этой информации многим не хватает, а необходимость встречается в самых разнообразных сферах программистской жизни.
Я продолжаю преимущественно выбирать те алгоритмы/структуры, которые легко понимаются и для которых не требуется много кода — а вот практическое значение сложно недооценить. В прошлый раз это было декартово дерево. В этот раз — система непересекающихся множеств. Она же известна под названиями disjoint set union (DSU) или Union-Find.

Условие

Поставим перед собой следующую задачу. Пускай мы оперируем элементами N видов (для простоты, здесь и далее — числами от 0 до N-1). Некоторые группы чисел объединены в множества. Также мы можем добавить в структуру новый элемент, он тем самым образует множество размера 1 из самого себя. И наконец, периодически некоторые два множества нам потребуется сливать в одно.

Формализируем задачу: создать быструю структуру, которая поддерживает следующие операции:

MakeSet(X) — внести в структуру новый элемент X, создать для него множество размера 1 из самого себя.
Find(X) — возвратить идентификатор множества, которому принадлежит элемент X. В качестве идентификатора мы будем выбирать один элемент из этого множества — представителя множества. Гарантируется, что для одного и того же множества представитель будет возвращаться один и тот же, иначе невозможно будет работать со структурой: не будет корректной даже проверка принадлежности двух элементов одному множеству if (Find(X) == Find(Y)).
Unite(X, Y) — объединить два множества, в которых лежат элементы X и Y, в одно новое.

На рисунке я продемонстрирую работу такой гипотетической структуры.

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

Под катом истории таких компаний, как Dropbox, Reddit, Quora, Foursquare, Groupon, Tinder и Airbnb.

Вид на City, сердце деловой Великобритании

Перед тем как перейти «на контракт» я работал в постоянным сотрудником в Лондоне в небольшой (700 серверов / 8 коллег) компании. Моя специализация — Wintel engineer, то есть я могу работать к в суппорте так и в техподдержке проектов. Все что связано с продуктами Microsoft. Я подумывал об уходе с постоянной работы, однако волею судеб пришлось уйти совершенно неподготовленным. Именно отсюда начинается мой рассказ о контрактниках в Великобритании.

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

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

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

После успешного перехода c MongoDB полнотекстового поиска на ElasticSearch, мы успели запустить несколько новых сервисов работающих на Elastic'е, расширение для браузера и в общем и целом, я был крайне доволен миграцией.

Но в бочке меда, оказалась одна ложка дегтя — примерно через месяц после конфигурации и успешной работы, LogEntries / NewRelic в один голос закричали о том, что сервер поиска не отвечает. После логина на дешбоард Digital Ocean'a, я увидел письмо от поддержки, что сервер был приостановлен в связи с большим исходящим UDP трафиком, что скорее всего свидетельствовало о том, что сервер скомрометирован.

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

2. «Сам дурак»
Большая проблема — нежелание слушать мнение окружающих. Когда половина проекта готова и внезапно становится понятно, что проект нежизнеспособен, есть два варианта: резко меняться или сворачиваться. Знаете, что часто делают руководители IT-стартапов? Перестают слушать людей снаружи, превращают команду в секту и упорно допиливают продукт. Потому что полработы уже сделано.

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

Перевод статьи «Building robust web apps with React: Part 4, server-side rendering», Matt Hinchliffe

От переводчика: это перевод четвертой части цикла статей «Building robust web apps with React»
Переводы:

• Построение надежных веб-приложений на React: Часть 1, браузерные прототипы
• Построение надежных веб-приложений на React: Часть 2, оптимизация с Browserify
• Построение надежных веб-приложений на React: Часть 3, тестирование с Jasmine
• Построение надежных веб-приложений на React: Часть 4, серверная генерация

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

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

Перевод статьи «Building robust web apps with React: Part 3, testing with Jasmine», Matt Hinchliffe

От переводчика: это перевод третьей части цикла статей «Building robust web apps with React»
Переводы:

• Построение надежных веб-приложений на React: Часть 1, браузерные прототипы
• Построение надежных веб-приложений на React: Часть 2, оптимизация с Browserify
• Построение надежных веб-приложений на React: Часть 3, тестирование с Jasmine
• Построение надежных веб-приложений на React: Часть 4, серверная генерация

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

Перевод статьи «Building robust web apps with React: Part 2, optimising with Browserify», Matt Hinchliffe

От переводчика: это перевод второй части цикла статей «Building robust web apps with React».
Переводы:

• Построение надежных веб-приложений на React: Часть 1, браузерные прототипы
• Построение надежных веб-приложений на React: Часть 2, оптимизация с Browserify
• Построение надежных веб-приложений на React: Часть 3, тестирование с Jasmine
• Построение надежных веб-приложений на React: Часть 4, серверная генерация

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

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

Перевод статьи «Building robust web apps with React: Part 1, in-browser prototypes», Matt Hinchliffe

От переводчика: это первая статья из цикла «Building robust web apps with React».
Переводы:

• Построение надежных веб-приложений на React: Часть 1, браузерные прототипы
• Построение надежных веб-приложений на React: Часть 2, оптимизация с Browserify
• Построение надежных веб-приложений на React: Часть 3, тестирование с Jasmine
• Построение надежных веб-приложений на React: Часть 4, серверная генерация

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


404PageFound содержит до сих пор работающие сайты, созданные еще в 1993 году.

За последнее время у меня накопилось достаточно материалов по разработке плагинов для IntelliJ IDEA, чем и собираюсь поделиться с хабрасообществом.

Среда разработки и инфраструктура

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

Для разработки плагинов подойдет любая современная версия Intellij IDEA – она уже включает в себя полный набор необходимого инструментария.

Привет Хабр! Пару месяцев назад я захотел провести тестирование производительности некоторых сетевых фреймворков, c целью понять насколько большая разбежка между ними. Надо ли использовать Node.js там, где хотелось бы Python с Gevent или нужен Ruby с его EventMachine.



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

Дуглас Крокфорд

2007-02-21

Введение

В 1973 году на первом ежегодном симпозиуме «Принципы языков программирования» (Principles of Programming Languages Symposium) Вон Пратт представил статью «Нисходящий парсер с операторным предшествованием» (Top Down Operator Precedence). В этой статье Пратт описал метод синтаксического разбора, который объединяет лучшие стороны рекурсивного спуска и метода операторного предшествования Флойда. Метод Пратта очень похож на рекурсивный спуск, но требует меньше кода и работает гораздо быстрее. Пратт заявил, что его метод прост в освоении, реализации и использовании, необычайно эффективен и очень гибок. Благодаря своей динамичности он может использоваться для расширяемых языков.

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

Есть и другое объяснение: этот метод наиболее эффективен для динамических, функциональных языков программирования и использовать его в статическом, процедурном языке куда сложнее. Свою статью Пратт иллюстрирует на примере Lisp и играючи строит синтаксические деревья по потоку лексем. Но методы синтаксического разбора не особо ценятся в сообществе Lisp-программистов, которые проповедуют спартанский отказ от синтаксиса. С момента создания Lisp предпринималось немало попыток придать этому языку богатый синтаксис в стиле ALGOL: CGOL Пратта, Lisp-2, MLISP, Dylan, Interlisp's Clisp, оригинальные М-выражения Маккарти и так далее. Но все они провалились. Для Lisp-сообщества согласованность программ и данных оказалась важнее выразительного синтаксиса. С другой стороны, подавляющее большинство программистов любит синтаксис, поэтому сам Lisp так и не стал популярен. Методу Пратта нужен динамический язык, но сообщество динамических языков исторически не пользовалось синтаксисом, который так удобно реализуется методом Пратта.