В далёком 2009 году я загорелся идеей постройки собственного промышленного робота, который мог бы делать что-то полезное (а именно — сортировать мелкие детали на конвейере). Сразу скажу, что робота я построил (результат вы видите на заглавном фото), а заодно, в качестве побочного продукта, написал небольшую статью о кинематике дельта-роботов на форуме TrossenRobotics — американского продавца наборов из деталей для роботов. Они как раз проводили в то время какой-то конкурс для авторов. Конкурс я, разумеется, не выиграл, но статья на английском осталась. Несколько раз я порывался перевести её на родной язык, однако завершить начатое удалось только сейчас.

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

Предисловие

Команда, в которой я сделала свои первые шаги на поприще написания промышленного кода, занималась разработкой удобного API к функциональности программного продукта на C# (для удобства назовем его, скажем, буквой E), существовавшего уже много лет и зарекомендовавшего себя на рынке с весьма положительной стороны. И здесь вроде бы у юного падавана пока не должно возникать вопросов, однако же представим себе, что ранее вы, скорей всего, конечно, писали собственные web-API, но вряд ли для широкой аудитории, а значит жили по принципу «Сам создал – сам пользуюсь», и если вдруг кого-то бы заинтересовала функциональность вашего API, то вы, наверное, кинули бы ему pdf-файл с подробной инструкцией (по крайней мере я бы сделала именно так). «Где посмотреть функционал апи» — спросила я тимлида ожидая получить ссылку на текстовый документ. «Загляни в Swagger» — ответил он.

О чём эта статья

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

В этой статье я напишу как устроен алгоритм шифрования AES (которого иногда называют Rijndael) и напишу его на JavaScript. Почему на JavaScript? Чтобы запустить программу на этом языке, нужен только браузер в котором вы читаете эту статью. Чтобы запустить программу, скажем, на C, нужен компилятор и найдётся совсем мало желающих, готовых потратить время на компиляцию кода из какой то статьи. В конце есть ссылка по которой можно скачать архив с html страницей и несколькими js файлами — это пример реализации AES на JavaScript.

Этот материал — тот самый Vantablack 2, который не поддаётся измерению спектрометром



Еще два года назад компания Surrey NanoSystems создала из нанотрубок самый черный материал на Земле, который получил название Vantablack (Vertically Aligned NanoTube Arrays). У этого материала был зафиксирован самый низкий коэффициент отражения среди всех прочих известных темных материалов — всего 0,036%. Для демонстрации свойств Vantablack его создатели сняли ролик с лазерной указкой. Пятно света, которое проходит по поверхности этого материала, просто пропадает. Все это похоже на черную дыру в миниатюре.

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

Прошло около года, с момента успешного подключения музыкального синтезатора YM2149F к LPT порту компьютера. LPT это конечно хорошо, однако время не стоит на месте, и найти компьютер или ноутбук с LPT портом становится все сложнее и сложнее. Да и сам автор (то есть я) устал лазить каждый раз под стол, где стоит системник, и перетыкать LPT плату на что-то другое, например программатор (у меня LPT-программатор Willem, ну да не суть). Поэтому на сей раз подключать чип YM2149F будем к USB. Ну и конечно, чтобы соотвествовать эпохе, будем это делать на копеечном древнем микроконтроллере PIC16F628.



Вкратце, YM2149F (или ее функциональный аналог AY-3-8910) — микросхема звукового трехголосного синтезатора, применялась в старых компьютерах типа Atari ST, Amstrad CPC, ZX Spectrum, MSX и некоторых других для проигрывания музыки. В России чип приобрел определенную известность благодаря установки в различные клоны ZX Spectrum'а. За время шествования ZX Spectrum по бывшему СССР музыкантами были написаны тысячи мелодий под этот звуковой программируемый генератор. Да и сейчас можно вполне найти людей, создающих музыку именно под этот чип. В конце статьи будут приведены ссылки на огромнейший архив чип-тюнов для YM/AY на сотни часов непрерывного прослушивания.

Это продолжение серии из трех статей (первая статья, третья статья) об автоматизированном тестировании программных продуктов в Openshift Origin. В данной статье будут описаны основные объекты Openshift, а также описаны принципы работы кластера. Я осознано не делаю попытку описать все возможные объекты и их особенности, так как это очень трудоемкая задача, которая выходит за рамки данной статьи.

Кластер:

Здравствуйте, уважаемые участники ИТ сообщества. Данный материал является незапланированным продолжением серии статей (первая статья, вторая статья, третья статья), которые посвящены тестированию ПО в Openshift Origin. В данной статье будут рассмотрены аспекты интеграции контейнеров и виртуальных машин посредством Openshift и Openstack.

Какие цели я преследовал интегрируя Openshift с Openstack:

1. Добавить возможность запускать контейнеры и виртуальные машины в единой сети (L2, отсутствие вложенных сетей).
2. Добавить возможность использования опубликованных в Openshift сервисов виртуальными машинами.
3. Добавить возможность интеграции физического сегмента сети с сетью контейнеров/виртуальных машин.
4. Иметь возможность обоюдного разрешения FQDN для контейнеров и виртуальных машин.
5. Иметь возможность встроить процесс развертывания гибридных окружений (контейнеры, виртуальные машины) в существующий CI/CD.

Примечание: в данной статье не пойдет речи об автоматическом масштабировании кластера и предоставлении хранилищ данных.

Юдель Пэн. Часовщик. 1924

«Компьютер — это конечный автомат. Потоковое программирование нужно тем, кто не умеет программировать конечные автоматы» 
Алан Кокс, прим. Википедия

“Знай свой инструмент” — твердят все вокруг и все равно доверяют. Доверяют модулю, доверяют фреймворку, доверяют чужому примеру.

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

Разработчики из GitHub на прошлой неделе выложили в открытый доступ исходники своего балансировщика нагрузки — GLB Director. Команда трудилась над этим проектом несколько лет.

Чем примечательно их решение, как оно устроено, и кто еще передавал системы распределения нагрузки в open source, рассказываем далее.

Мне по работе часто приходится сталкиваться с высоконагруженными многопоточными или многопроцессными сервисами (application-, web-, index-server).
Достаточно интересная, но иногда неблагодарная работа — оптимизировать все это хозяйство.
Растущие потребности клиентов часто упираются в невозможность просто заменить железную составляющую системы на более современную, т.к. производительность компьютеров, скорость чтения-записи жестких дисков и сети растут много медленнее запросов клиентов.
Редко помогает увеличение количества нодов кластера (система как правило распределенная).
Чаще приходится запустив профайлер, искать узкие места, лезть в source code и править ляпы, которые оставили коллеги, а иногда и сам, чего греха таить, много лет назад.
Некоторые из проблем, связаных с синхронизацией, я попытаюсь изложить здесь. Это не будет вводный курс по многопоточному программированию — предпологается, что читатель знаком с понятием thread и context switch, и знает для чего нужны mutex, semaphore и т.д.

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

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

Предисловие

Пост является кратким конспектом Wiki, TechNet'а, FreeBSD'шного handbook'a, Serverfault'a, множества RFC и документов IANA, а также курсов от Специалист.Ру для сотрудников Яндекса.

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

Неделю назад разработчики Rancher представили предварительный релиз своей будущей крупной версии — 2.0, — попутно объявив о переходе на Kubernetes в качестве единой основы для оркестровки контейнеров. Что побудило разработчиков пойти таким путём?

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

последняя редакция статьи доступна на сайте makeloft.xyz

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

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

Однажды мне понадобилось решить простенькую (как мне тогда казалось) задачу – в PHP-скрипте узнать длительность mp3-файла. Я слышал о ID3 тегах и сразу подумал, что информация о длительности хранится либо в тегах, либо в заголовках mp3-файла. Поверхностные поиски в интернете показали что за пару-тройку минут решить эту задачу не получится. Поскольку от природы я довольно любопытен а время не поджимало — решил не использовать сторонние инструменты а разобраться в одном из самых популярных форматов самостоятельно.

Если Вам интересно, что там внутри – добро пожаловать под кат (трафик).

Девять лет назад я посещал курс физики в колледже, и мой профессор рассказал одну вещь, которая поразила меня. Я думаю, не будет преувеличением сказать, что это одно из наиболее широко используемых математических открытий — от оптики до квантовой физики, радиоастрономии, сжатия MP3 и JPEG, рентгеновской кристаллографии, распознавания голоса и МРТ. Этот математический инструмент называется преобразование Фурье, в честь французского физика и математика 18-го века Жозефа Фурье. Им пользовались даже Джеймс Уотсон и Фрэнсис Крик, чтобы декодировать структуру двойной спирали ДНК из рентгенограмм, произведенных Розалиндой Франклин. (Крик был экспертом по преобразованиям Фурье, он в шутку назвал свою книгу «Преобразования Фурье для орнитологов», чтобы объяснить суть Уотсону, заядлому любителю птиц).

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



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

P.S.
Добавил дополнительные ссылки на первоисточники

Предисловие

OpenSIPS — это сигнальный SIP-коммутатор. Если вы хотите обрабатывать реально много SIP-звонков, то, скорее всего, мимо OpenSIPS не пройдете.
Система реально «mature», проверенная в бою и, со временем, обросшая множеством полезных (и не очень) модулей.

Вместе с этим, очевидно, что архитектура, заложеннная еще в 2001 году не отвечает современным требованиям.
Поэтому разработчики OpenSIPS заявили, что версия 2.0 будет вестись «с чистого листа».

Ниже приведен перевод документа OpenSIPS 2.0 Design. Интересно, что думает хабрасообщество по этому поводу.

Комментарии по существу я постараюсь передать разработчикам.

Зачем нужна новая архитектура

Текущая архитектура OpenSIPS (до версии 2.0) основана на концепциях, которым более 7 лет. В то время требования были простыми (простой stateless SIP-прокси, только UDP) и решения принимались в соответствии с этими требованиями. Но со всеми дополнениями, как в SIP так и функционале (таком как TCP/TLS, манипуляции в скрипте, поддержка диалогов, интеграция с внешними системами и т.д.), существующая архитектура больше не может удовлетворять требованиям и реальным сценариям использования.

Внимание! Внутри большой и структурированный текст с картинками.

Приветствую, хаброжители!
В этой статье я хочу поделиться опытом развертывания кластера Master-slave на СУБД PostgreSQL. Отказоустойчивость достигается с помощью возможностей pgpool-II (failover, online recovery).
pgpool — это прекрасное средство для масштабирования и распределения нагрузки между серверами и, думаю, немногие знают о возможностях автоматического создания failover на ведомом сервере при отказе ведущего и как добавить новые мощности в уже работающий кластер без отключения всего кластера.