Мы все хотим ставить перед собой и своей командой четкие и понятные цели (задачи), для этого существует несколько критериев, которые собираются в английскую аббревиатуру SMART (умный):

Буква	Английский термин	Русский термин
S	Specific	Точные и конкретные
M	Measurable	Измеримые
A	Achievable	Достижимые
R	Relevant	Релевантные
T	Time bound/framed	Цели со сроком

Каждая компания на определенном этапе развития становится перед вопросом организации и последующей автоматизации своего документооборота. Хотим поделиться нашим опытом использования решений Google — Drive (Docs), Calendar и Contacts.

Введение

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

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

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

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

В этом посте речь пойдет о вопросах кодирования видео «в промышленных масштабах» с применением видеокодека h264 на GPU, интегрированном в современные процессоры Intel и о том опыте, который приобрела наша компания Inventos в процессе создания и оптимизации медиа сервера для обработки потокового видео.

Наверное, каждый Android программист хотя бы раз задумывался о написание чего-нибудь полезного с использованием компьютерного зрения или дополненной реальности. А некоторые даже написали hello, word при помощи opencv, которую таки портировали и на Android. К сожалению, если мы захотим написать что-то серьезное, мы обнаружим, что набор библиотек с уже реализованными функциями Computer Vision не так велик, особенно это касается платформы Android. Чаще всего для этой цели используют opencv, написанную на C++ либо пишут свои велосипеды, что в общем тоже хорошо, но не так быстро, как хотелось бы в плане реализации. Однако, не все так плохо. Существует такой замечательный проект BoofCV, который представляет из себя библиотеку компьютерного зрения, написанную на чистом Java. Последние две буквы в названии библиотеки означают именно то, о чем вы подумали. А в последнем релизе появилась долгожданная поддержка Android. Ниже мы рассмотрим основные плюшки, предоставляемые библиотекой на конкретном примере.

Всем привет. В этом топике я хотел бы провести обзор относительно нового и довольно мощного метода нелинейной динамики – метода Recurrence plots или рекуррентного анализа в приложении к анализу временных рядов. А, кроме того, поделится кодом короткой программы на языке Matlab, которая реализует все нижеописанное.

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

12 апреля мы запустили большой новый проект — «Битрикс24»: социальный интранет, SaaS-сервис, объединяющий в себе классические инструменты командной работы (календари, задачи, CRM, работа с документами) и социальные коммуникации («лайки», социальный поиск, мгновенные сообщения и многое другое).

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

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

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

* * *

Итак, первый пост — об архитектуре проекта в целом. Поехали!

Кёртис Спенсер (Curtis Spencer) с коллегами из компании Spool разработали легковесный сервер Fake S3, который ведёт себя как настоящий Amazon S3 и помогает тестировать проекты, не гоняя данные в облако и не тратя деньги на трафик. К тому же, для тестирования Fake S3 надёжнее, потому что работает локально. Спенсер говорит, что благодаря Fake S3 они сэкономили около $1000 за последний месяц на одной только оплате трафика.

Установка

gem install fakes3

Для запуска сервера нужно указать хост и порт

fakes3 -r /mnt/fakes3_root -p 4567

Перевод главы «Multithreading» книги David Thomas и Andrew Hunt «Programming Ruby: The Pragmatic Programmers' Guide, Second Edition».

Часто самым простым способом выполнить одновременно две вещи является использование потоков в Ruby. Они являются внутрипроцессными, встроенными в интерпретатор Ruby. Это делает потоки Ruby полностью переносимыми, т.е. независимыми от операционной системы. Но в то же время вы точно не получите выгоду от использования родных, нативных потоков. Что это значит?

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

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

На 111ом вебинаре UX Russia мы с Андреем Сикорским обсуждаем тихий ужас, который творится в Системах Электронного Документооборота. Программисты создают абстрактные системы для абстрактного пользователя. А реальные пользователи отвечают ненавистью, которую легко понять, если посмотреть на эти системы.

Середина 2000-х годов ознаменовалась бурным ростом числа колоночных СУБД. Vertica, ParAccel, Kognito, Infobright, SAND и другие пополнили клуб колоночных СУБД и разбавили гордое одиночество Sybase IQ, основавшей его в 90х годах. В этой статье я расскажу о причинах популярности идеи по-колоночного хранения данных, принцип действия и область использования колоночных СУБД.

Начнем с того, что популярные в наше время реляционные СУБД — Oracle, SQL Server, MySQL, DB2, Postgre и др. базируются на архитектуре, отсчитывающей свою историю еще c 1970-х годов, когда радиоприемники были транзисторными, бакенбарды длинными, брюки расклешенными, а в мире СУБД преобладали иерархические и сетевые системы управления данными. Главная задача баз данных тогда заключалась в том, чтобы поддержать начавшийся в 1960-х годах массовый переход от бумажного учета хозяйственной деятельности к компьютерному. Огромное количество информации из бумажных документов переносилось в БД учетных систем, которые должны были надежно хранить все входящие сведения и, при необходимости, быстро находить их. Такие требования обусловили архитектурные особенности реляционных СУБД, оставшиеся до настоящего времени практически неизменными: построчное хранение данных, индексирование записей и журналирование операций.

В рамках проекта для одного из наших заказчиков в очередной раз встала задача построить систему конвертации/ хранения/ доставки видео в интернет. Типичная такая задача создания своего маленького (или не очень маленького) “Тьюба” только с профессиональным, а не UGC-контентом.

С момента создания первых “Тьюбов” технологии видео в интернете прошли некоторый путь развития, позволяют сейчас делать намного больше, да и требования к современному видео-сайту стали несколько иными.

Наиболее интересными трендами последнего времени, на наш взгляд, являются:

• возможность смотреть один видео-сайт с разных устройств,
• технология адаптивного HTTP стриминга

Последним и завершающим разделом бизнес-анализа, после выполненного описания предметной области, является анализ проблем заинтересованных лиц, анализ зависимостей и описание бизнес-возможностей сторон.

V. Анализ бизнес-проблем

Проблемы, их владельцы и причины

Описание проблем удобно описывать с помощью таблицы, чтобы структурировать информацию по следующим пунктам.

1. Проблема.
2. На кого воздействует.
3. Результатом чего является.
4. Выигрыш от новой системы.
5. Приоритет.

После описания всех проблем необходимо сортировать в порядке убывания по приоритету, чтобы выделить наиболее значимые.

Перевод статьи Vincent Driessen: A successful Git branching model

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



В качестве инструмента управления версиями всего исходного кода она использует Git.

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



Итак, хочется исправить эти проблемы. А именно, написать корректор коротких фраз или запросов, который:

• умел бы выявлять три (и более) ошибки в запросе;
• умел бы проверять «разорванные» или «слипшиеся» фразы, например expertsexchange — experts_exchange, ma na ger — manager
• не требовал много кода для реализации
• мог бы достраиваться до исправления ошибок на других языках и других типов" ошибок

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

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

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

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



Мы решили посмотреть, как в такую жару работают в аэропортах операторы связи.

Раньше для редактирования обычных русскоязычных текстов, я обычно откладывал Vim в сторонку и прибегал к помощи других редакторов. Причиной этому была парочка очень неприятных косяков:

1. На каждый чих приходилось сто раз переключать раскладку, чтобы корректно ввести пару команд и вернуться обратно. Например, замена буквы-опечатки в только что написанном слове, выливалось в: switch → добраться до буквы, нажать r → switch → [нужная буква] → switch → A → [пишем дальше]. Ад!
2. Штатный spell checker букву «ё» не любил и любое слово с её участием предлагал заменить на аналог через «е». А я ё люблю, меня это расстраивало.

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

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