В левой руке Морфеуса лежит 7 синих и 3 красных таблетки, а в правой 5 синих и 8 красных. Вы закрываете глаза и берете таблетку — она оказывается красной, однако вы не знаете из какой руки ее взяли. Какова вероятность, что вы взяли ее из правой руки?

17 апреля 1761 — день смерти Томаса Байеса.
Под катом результаты того, что есть в рунете, помимо стандартных вещей типа Теорема Байеса, Байесовская сеть, Наивный байесовский классификатор , Байесовская фильтрация спама

Ratchet — так называется HTML5-фреймворк для быстрого прототипирования мобильных приложений, который 1,5 года назад создали те же парни, которые когда-то выпустили Bootstrap.

Инструмент позволяет быстро создать красивый интерфейс мобильного приложения — и дает вам красивые стили и замечательные иконки, согласованные с гайдлайном в зависимости от платформы. Можно сделать прототип, а можно завернуть в PhoneGap и без особых усилий получить сравнимый с нативным интерфейс приложения в продакшене.
Фреймворк очень прост в использовании и прекрасно документирован.

Я являюсь поклонником Ratchet с момента выхода первой версии. Тогда он был доступен только под iOS.
Не так давно вышла вторая версия, которая наряду с iOS поддерживает Android. Ура-ура!
(правда, обратной совместимости с первой версией нет)

Кому интересно про новые возможности Ratchet 2.0 — прошу под кат!

Цель этой статьи — рассказать о языке программирования Go (Golang) тем разработчикам, которые смотрят в сторону этого языка, но еще не решились взяться за его изучение. Рассказ будет вестись на примере реального приложения, которое представляет из себя RESTful API веб-сервис.

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

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



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

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

Время от времени я встречаю публикации, где рассказывается о том, какие из значений оператора == эквивалентны (как, например, здесь). Часто при этом оговаривается, что приведённые в таблице данные не очень хорошо организованы.

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



Кошмар, товарищи!.. Как по мне, так здесь бóльший беспорядок в очерёдности строк/столбцов.

В течение минуты думал над заголовком, так ничего и не придумал…
Strace. Наверное нет того человека, который бы не слышал про strace. Если кто не слышал, то strace — это утилита, отслеживающая системные вызовы, которые представляют собой механизм трансляции, обеспечивающий интерфейс между процессом и операционной системой (ядром). Эти вызовы могут быть перехвачены и прочитаны. Это позволяет лучше понять, что процесс пытается сделать в заданное время. Перехватывая эти вызовы, мы можем добиться лучшего понимания поведения процессов, особенно если что-то идет не так. Функциональность операционной системы, позволяющая отслеживать системные вызовы, называется ptrace. Strace вызывает ptrace и читает данные о поведении процесса, возвращая отчет. Детали можно прочитать в вики или официальном man. Собственно вот, ну и речь конечно же о Linux. В других ОС свои аналоги.
Так вот, лично для меня strace это как последняя инстанция. Когда уже все логи просмотрены, все debug и verbose ключи включены, а причина проблем так и не обнаружена, я достаю из широких штанин запускаю strace. Есть одно но, strace это такой инструмент который вовсе не является серебряной пулей, которая тут же все покажет и расскажет. Для работы с strace требуется наличие определенных знаний и чем шире и глубже эти знания тем больше вероятность обнаружения проблемы.
В интернетах полно вводных статей, где описываются примеры запуска strace. Я же в этой статье покажу частные проблемы и их решение с помощью strace.

Всем привет!

Сегодня расскажу, как на боевых серверах во время нагрузки, в пыли и грязи, эффективно отлавливать узкие места в производительности больших веб-приложений на PHP, а также искать и устранять «нестандартные» ошибки. Многие из описанных техник мы с успехом применяем на нашем облачном сервисе «Битрикс24».
Информация, надеюсь, пригодится системным администраторам и разработчикам, обслуживающим сложные веб-проекты, а также менеджерам, которые хотят выстроить эффективный и быстрый процесс поиска и устранения узких мест и ошибок проектов на PHP.

Наш умозрительный провайдер linkmeup взрослеет и обрастает по-тихоньку всеми услугами обычных операторов связи. Теперь мы доросли до IPTV.
Отсюда вытекает необходимость настройки мультикастовой маршрутизации и в первую очередь понимание того, что вообще такое мультикаст.
Это первое отклонение от привычных нам принципов работы IP-сетей. Всё-таки парадигма многоадресной рассылки в корне отличается от тёплого лампового юникаста.
Можно даже сказать, это в некоторой степени бросает вызов гибкости вашего разума в понимании новых подходов.

В этой статье сосредоточимся на следующем:

• Общее понимание Multicast
• Протокол IGMP
• Протокол PIM
• >>>PIM Dense Mode
• >>>Pim Sparse Mode
• >>>SPT Switchover — переключение RPT-SPT
• >>>DR, Assert, Forwarder
• >>>Автоматический выбор RP
• >>>SSM
• >>>BIDIR PIM
• Мультикаст на канальном уровне
• >>>IGMP-Snooping
• >>>MVR

Хочу просто поделиться недавно найденным сервисом для работы с регулярными выражениями. Да, это еще один сервис. Но у него есть особенность — он позволяет не только составлять регулярные выражения, но и помогает разбирать уже написанные — эдакий regexp-декомпилятор.
Сервис называется Regex101.

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

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

Также мы немного обозначили задачи, которые фактически решает наше подразделение в компании i-Free. Закончена предыдущая статья была «громким» обещанием описать модели представления речевого сигнала и показать, как данные модели возможно использовать для изменения голоса диктора.

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

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

WARNING!



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

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



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

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

В одно прекрасное утро я просматривал логи и задал себе ряд вопросов:

1. А жду ли я письма из Юго-Восточной Азии? (когда смотрел логи почты)
2. И с какого перепугу ко мне стучатся ssh брутфорсеры из Штатов?
3. Мне надо терпеть сетевые сканеры из Австралии?
4. Кто мне звонит из Африки? (когда разглядывал логи asterisk)
5. С какой стати к моему POP-серверу обращаются из Латинской Америки?

Почему бы не забанить по континентам? Оставив только нужный континент(ы)?

Что происходит с кодом после того, как он написан? Во многих областях разработки ПО его жизнь только начинается. Например, в разработке для веба, приложение исполняется где-то на сервере. Значит, после написания кода встаёт задача интегрировать его в приложение и доставить на конечную машину. Именно этот процесс мы сегодня обсудим.

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

Статья написана на основе материалов внутреннего семинара компании Аори, и рассказывает о принципах деплоймента на примере процесса, построенного у нас.

Собственно, изучая данную тему, было перерыто много сайтов, но нигде толком ничего не объяснялось, либо информация была по устаревшим ныне протоколам. Это и послужило своеобразным пинком для создания этого HowTo. Это будет не детальный разбор всех возможных проблем, но немного теории и описание некоторых вещей которые для кого-то являются банальщиной, а у кого-то (вроде меня) вызвали трудности и потерю времени на поиск решения. Сразу предупрежу — здесь не рассматривается как поднять сокет-сервер на PHP, подобной информации в интернете навалом. Буду исходить из того, что сокет-сервер уже существует и надо лишь научить его общаться через вебсокеты.
Итак, хватит лирики, теперь к делу!

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

Как обычно, в конце статьи ссылки на демонстрационную игру и исходный код на гитхабе.

Содержание:

• Поддержка вебсокетов браузерами
• Разработка онлайн-игры
• Благодарности
• Демка и исходный код

После написания моей предыдущей статьи Делаем вебсокеты на PHP с нуля я понял, что у сообщества есть некоторый интерес к поднятой мною теме.

В прошлой статье я обещал, что опишу:

• запуск нескольких процессов для обработки соединений
• межпроцессное взаимодействие
• разделение процессов мастер-воркер
• проксирование вебсокетов с помощью nginx
• запуск из консоли
• интеграция с вашим фреймворком на примере yii
• демонстрация

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

Некоторое время назад я выбирал библиотеку для работы с вебсокетами. На просторах интернета я натыкался на статьи по интеграции node.js с yii, а почти все статьи о вебсокетах на хабре ограничивались инструкциями к тому, как использовать phpdaemon.

Я изучал библиотеки phpdaemon и ratchet, они достаточно монструозны (причём используя ratchet для отправки сообщения конкретному пользователю рекомендовано дополнительно использовать wamp). Мне не совсем было понятно для чего использовать таких монстров, которые требуют установку других монстров. Почитав исходники этих, а также других библиотек, я разобрался как всё устроено и мне захотелось написать простой вебсокет-сервер на php самостоятельно. Это помогло мне закрепить изученный материал и наткнуться на некоторые подводные камни, о которых я не имел представления.

Так я решил написать необходимый для меня функционал с нуля.

Получившийся код и ссылка на демонстрационный чат в конце статьи.

От переводчика: Sam Altman, успешный предприниматель из Калифорнии, делится своими наблюдениями по поводу того, что общего у самых успешных компаний. Сам Sam Altman, основавший компанию Loopt, которой удалось привлечь $30 миллионов венчурного капитала, входит в число партнеров Y Combinator. BusinessWeek назвал его одним из «Лучших технологических предпринимателей».

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

* Они одержимы качеством продукта/опыта. Почти слишком одержимы, они тратят много времени на детали, которые на первый взгляд не очень важны. Учредители этих компаний реагируют так, будто они чувствуют физическую боль, когда что-то идет не так с продуктом или пользователю оказывают плохую поддержку. Хотя они верят в ранний запуск и циклы, эти люди не собираются размениваться на плохой продукт. (Это не повод откладывать запуск. Вы, наверное, и так с ним медлите).

Из-за этого они стараются не ставить никого между собой и пользователями. Учредители таких компаний также занимаются продажей и поддержкой самих клиентов.

До появления HTML5 единственное, что мы не могли контролировать и управлять (без перезагрузки контента или хаков с location.hash) — это история одного таба. С появлением HTML5 history API все изменилось — теперь мы можем гулять по истории (раньше тоже могли), добавлять элементы в историю, реагировать на переходы по истории и другие полезности. В этой статье мы рассмотрим HTML5 History API и напишем простой пример, иллюстрирующий его возможности.

Основные понятия и синтаксис

History API опирается на один DOM интерфейс — объект History. Каждый таб имеет уникальный объект History, который находится в window.history. History имеет несколько методов, событий и свойств, которыми мы можем управлять из JavaScript. Каждая страница таба(Document object) представляет собой объект коллекции History. Каждый элемент истории состоит из URL и/или объекта состояния (state object), может иметь заголовок (title), Document object, данные форм, позиция скролла и другую информацию, связанную со страницей.

Основные методы объекта History:

1. window.history.length: Количество записей в текущей сессии истории
2. window.history.state: Возвращает текущий объект истории
3. window.history.go(n): Метод, позволяющий гулять по истории. В качестве аргумента передается смещение, относительно текущей позиции. Если передан 0, то будет обновлена текущая страница. Если индекс выходит за пределы истории, то ничего не произойдет.
4. window.history.back(): Метод, идентичный вызову go(-1)
5. window.history.forward(): Метод, идентичный вызову go(1)
6. window.history.pushState(data, title [, url]): Добавляет элемент истории.
7. window.history.replaceState(data, title [, url]): Обновляет текущий элемент истории

Автовставка точек с запятой (";") — одна из наиболее спорных особенностей яваскрипта, вокруг которой скопилось много непонимания.

Некоторые программисты ставят ";" в конце каждого оператора, некоторые — только там, где строго необходимо. Большинство же где-то посередине, хотя есть и такие, которые добавляют лишние ";" из стилистических соображений.

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