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

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

Впервые квартово-квинтовый круг был описан в книге «Идея грамматики мусикийской» от 1679 года русско-украинского композитора Николая Дилецкого.

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

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

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

Недавно viktorpanasiuk опубликовал задачу о конфетах, которая «зацепила» многих (в частности, koldyr опубликовал на Хабре свое аналитическое решение), в том числе и меня. Задача практическая, от инженера-кондитера, формулировалась так: «Найти максимально допустимое отклонение массы конфеты при ее производстве, чтобы нетто коробки, состоящей из n=12 штук их, не выходило за пределы M=310±7 грамм в 90% случаев. Закон распределения считать нормальным».

Автор решил задачу, исходя из предположения о нормальном распределении конфет по массе, и нашел среднюю массу конфеты (очевидно, равную µ=M/n=25.83 г) и стандартное отклонение σ=1.23 г. Использование метода Монте-Карло, т.е. генерация N*n случайных чисел с гауссовым распределением конфет со средним µ и стандартным отклонением σ, подтверждает правильность решения. Распределение масс коробок является гауссовым, и его параметры близки к найденным аналитически (расчеты в Mathcad Express в форматах MCDX и XPS прилагаются). На левом графике показана гистограмма плотности распределения (по массе) конфет, а на правом — соответственно, распределения коробок.



В финале процитированной статьи автор упоминает о немного измененной (на практике, более актуальной) задаче определения границ массы отдельной конфеты, при выходе за которые эту (чересчур большую или маленькую) конфету нужно отбросить, чтобы коробки удовлетворяли исходным условиям (310±7 г в 90% случаев). На мой взгляд, исходная статья уже содержит решение, надо лишь посмотреть на нее немного с другой точки зрения.

Мы продолжаем наш туториал об использовании кастомных жестов в связке Kinect+Unity. В первой части мы рассмотрели процесс обучения жестов, в результате чего у нас получилась обученная модель в виде .gdb файла. Сегодня мы будем использовать эту модель в Unity.

Это третья статья из цикла о процедурно генерируемых с помощью Unity и C# картах мира. Цикл будет состоять из четырех статей.

Привет, Хабр!



Три недели назад мы (дружная команда образовательного проекта Хекслет) опубликовали пост про наш новый проект — игру для программистов Codebattle. Напомню, идея игры очень простая: вам и сопернику дается задача, вы решаете ее на выбранном вами языке. Вы видите код соперника в реальном времени, результаты запуска тестов и можете общаться с ним и зрителями в чате. Кто первый решит задачу (удовлетворит тестам) — тот победил.

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

Встречайте — обновленный Codebattle! Вкратце:

1. Хабраэффект нам не страшен (тьфу-тьфу-тьфу)
2. Читерить больше не получится (нельзя подогнать решение под тесты)
3. Добавлять языки стало проще (сейчас уже есть clojure, ruby, js, python, php, java, erlang)

Подробности под катом →

Для кого эта статья?

В основном статья для технических лидеров команд разработчиков ПО и тех, кто стремится ими стать. И, конечно, для остальных, кого заинтересовала тема.  Для тех, кому интересно мнение относительно роли технического лидера, и для тех, кто готов делиться собственными соображениями на этот счет.

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

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

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

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

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

Небольшая иллюстрация того, как на языке C# реализовать монаду Maybe и зачем это вообще нужно. Смотреть видео рекоммендуется в разрешении 720p.



Сопутствующую статью можно найти тут (англ. яз.). Комментарии приветствуются!

Трем программистам предложили пересечь поле, и дойти до дома на другой стороне. Программист-новичок посмотрел на короткую дистанцию и сказал, «Это не далеко! Это займет у меня десять минут». Опытный программист посмотрел на поле, немного подумал, и сказал: «Я мог бы добраться туда за день». Новичок посмотрел на него с удивлением. Гуру-программист посмотрел на поле и сказал. «Кажется минут десять, но я думаю пятнадцати будет достаточно». Опытный программист рассмеялся.

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

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

Гуру программист пустился в путь, и пошел прямо через поле. Целеустремленно и прямо. Он достиг цели всего за десять минут.
«Как тебе это удалось?» — спросили двое других — «Как ты умудрился не зацепить ни одной мины?»
«Легко» — ответил он. «Я не закладывал мины на своем пути».

Как ни прискорбно, придется признать – мы сами закладываем себе мины. В первой части я подробно разобрал основные риски в разработке ПО и описал технологические и методологические способы ослабления этих рисков. За прошедший год я получил множество комментариев, основной смысл которых сводился к следующему: «все круто, но с чего начать и как все это будет выглядеть в реальном мире». Действительно, первый текст носит скорее теоретический характер и представляет собой каталог ссылок. В этой статье я постараюсь привести как можно больше примеров.

Пару месяцев назад мне захотелось поэкспериментировать с нейроинтерфейсом. Никогда этой темой не занимался, но вдруг стало любопытно. Вроде как лет 5-10 назад обещали бум нейроустройств, а всё что мы сейчас имеем на рынке — устройство чтобы махать ушами, устройство чтобы светить камешком, да устройство чтобы левитировать шаром. Где-то на подходе устройство чтобы будить вовремя. Вот тут есть неплохая статья про всё это дело. В то же время регулярно появляются какие-то исследования, где рассказывают, что люди могут научиться двигать роботическими руками-ногами или писать тексты (1, 2, 3, вот тут есть подборка). Но это всё опытное, в единственном экземпляре, со стоимостью аппаратуры как хорошее авто.

А где что-то посередине? Что-то полезное обычному пользователю? Пусть даже не везде, а в каких-то отдельных применениях. Ведь даже навскидку придумывается несколько вещей: детектор засыпания для водителя, повышение работоспособности (например через выбор музыки, или управление перерывами!). Можно выбрать что-то более специфическое. Например смотреть и анализировать своё состояние в киберспорте. Для этого же даже трекеры зрачков выпускают и используют. Почему нет таких применений? Этот вопрос мучил меня. В итоге решил почитать куда наука движется, а так же купить простенькую нейрогарнитуру и затестить. В статье — попытка разобраться в теме, немного исходников и много анализа текущих достижений потребительской электроники.

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

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

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



Я начинал с создания карт для Counter-Strike: сделал карту с автобусной остановкой из своего города, пытался сделать школу. Круто же постреляться в родной школе? Это дало мне базовое понимание из чего состоит виртуальный мир.

Несколько позже я начал проходить туториалы по OpenGL на Android. Радовался как ребенок, когда впервые на экране телефона появился заветный треугольник!


*Картинка взята отсюда

Затем получился кубик с наложенной текстурой камня и появились мысли о создании своей простейшей игры. Перенос игры Portal на Android казался вполне достижимой задачей для новичка. Я сильно недооценивал предстоящий объем работ. Хорошо, что на то время уже существовал Portal в Google Play, и я успел создать только одну комнату.

Тогда я решил сделать что-то попроще и, увидев в Футураме бильярд без гравитации, решил его по-быстрому воплотить (пока другие не успели). Оказалось, что я по-прежнему недооценивал объем работ. И, кстати, бильярд без гравитации таки успели сделать раньше меня.

В своем первом материале, опубликованном в середине декабря, я писал о приятном процессе сборки, начале эксплуатации и небольших доработках 3D принтера MC2 от компании Мастер Кит.

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



Итак, по-порядку.

В этом цикле статей мы научимся создавать процедурно генерируемые карты мира с помощью Unity и C#. Цикл будет состоять из четырех статей.

Это вторая статья из цикла о процедурно генерируемых с помощью Unity и C# картах мира. Цикл будет состоять из четырех статей.

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

1. Установка

Итак, работа начинается с покупки и установки самого плагина с Asset Store:

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