Всем привет!

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

Большая часть обучающего материала для наглядного и интерактивного представления реализована с использованием Jupyter Notebook. Предполагается, что читатель имеет базовые знания из области высшей математики, а также немного владеет языком программирования Python.

Linux — это операционная система. Как винда (windows), только более защищенная. В винде легко подхватить вирус, в линуксе это практически невозможно. А еще линукс бесплатный, и ты сам себе хозяин: никаких тебе неотключаемых автообновлений системы!

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

Я дам кратенькое описание основных команд с примерами (примеры я все проверяла на cent os, red hat based системе) + ссылки на статьи, где можно почитать подробнее. Если же хочется копнуть еще глубже, то см раздел «Книги и видео по теме». А еще комментарии к статье, там много полезного написали)

Jupyter уже давно зарекомендовал себя как удобную платформу для работы в различных областях на стыке программирования, анализа данных, машинного обучения, математики и других. Вот например очень известная книга по анализу данных, состоящая из Jupyter блокнотов. Поддержка $$, markdown, html дает возможность использовать использовать Jupyter в качестве платформы для удобного оформления научного-технического материала. Преимущество таких блокнотов заключается в интерактивности, возможности сопровождать сухой материал примерами программ, при этом эта интерактивность очень естественна и проста в использовании. В этой статье хотелось бы рассказать про возможность создания в Jupyter анимированных примеров работы различных алгоритмов и привести несколько из них с исходным кодом. В качестве кликбейта алгоритм Дейкстры.

Как написать хороший SLA (Service Level Agreement, оно же Соглашение об уровне сервиса). И какой SLA будет хорошим.

Эта статья является попыткой обобщить имеющийся опыт, а также на неё я собираюсь ссылаться, когда меня будут в дальнейшем спрашивать, как должен выглядеть SLA. Работая в индустрии не первый десяток лет, я к своему удивлению регулярно сталкиваюсь с серьёзным непониманием основ, на которых строится SLA. Наверное, потому что документ довольно экзотический. После прочтения данного текста, я надеюсь, у вдумчивого читателя точечки над ё должны встать на свои места. Целевая аудитория — те, кто пишет SLA, и им сочувствующие.

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

Привет! Меня зовут Иван Смуров, и я возглавляю группу исследований в области NLP в компании ABBYY. О том, чем занимается наша группа, можно почитать здесь. Недавно я читал лекцию про Natural Language Processing (NLP) в Школе глубокого обучения – это кружок при Физтех-школе прикладной математики и информатики МФТИ для старшеклассников, интересующихся программированием и математикой. Возможно, тезисы моей лекции кому-то пригодятся, поэтому поделюсь ими с Хабром.

Поскольку за один раз все объять не получится, разделим статью на две части. Сегодня я расскажу о том, как нейросети (или глубокое обучение) используются в NLP. Во второй части статьи мы сконцентрируемся на одной из самых распространенных задач NLP — задаче извлечения именованных сущностей (Named-entity recognition, NER) и разберем подробно архитектуры ее решений.

Развеиваем страхи, ликвидируем безграмотность и уничтожаем мифы про железнорождённого слона. Под катом обзор экосистемы Hadoop-а, тенденции развития и немного личного мнения.

Jobs-to-be-Done — это подход к созданию продукта на основе анализа работы, которую стремится выполнить клиент с помощью продукта. Появился в 90-х годах и был адаптирован Intercom для IT-продуктов. Подход состоит из теории, почему «вечные» работы, для выполнения которых «нанимают» продукты, важнее свойств личности пользователя, а также фреймворка для практического применения при разработке продуктов.

Вторая часть

Статья написана совместно с ananaskelly.

Введение

Всем привет, хабр! Работая в Центре Речевых Технологий в Санкт-Петербурге, мы накопили немного опыта в решении задач классификации и детектирования акустических событий и решили, что готовы им с вами поделиться. Цель этой статьи — познакомить вас с некоторыми задачами и рассказать о соревновании по автоматической обработке звука “DCASE 2018”. Рассказывая вам о конкурсе, мы обойдемся без сложных формул и определений, связанных с машинным обучением, таким образом общий смысл статьи будет понятен широкой аудитории.

Для тех, кого в названии привлекла именно сборка классификатора, мы подготовили небольшой код на python, и по ссылке на гитхабе вы можете найти notebook, где мы на примере второго трека конкурса DCASE создаем простую сверточную сеть на keras для классификации аудиофайлов. Там мы немного рассказываем о сети и признаках, используемых для обучения, и как с помощью простой архитектуры получить близкий к baseline результат (MAP@3 = 0.6).

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

Хотя второй по счету митап Write the Docs Moscow состоялся уже месяц назад, опубликовать отчет и краткие конспекты докладов никогда не поздно. Мы успели обсудить ну практически все: от документирования RESTful API до профессиональных траекторий техписателя.

Митап, кстати собрал не только «техписательское гетто», но и широкий круг других специалистов, кто так или иначе работает испытывает боль с документацией на проекте: тимлиды, аналитики, тестировщики и даже один технический директор.

Если вы работаете в IT-компании, то, скорее всего, ваши процессы построены вокруг известного продукта Atlassian — Jira. На рынке есть множество таск-трекеров для решения тех же задач, в том числе open-source-решения (Trac, Redmine, Bugzilla), но, пожалуй, именно Jira имеет сегодня самое широкое распространение.

Меня зовут Дмитрий Семенихин, я тимлид в компании Badoo. В небольшом цикле статей я расскажу, как именно мы используем Jira, как настраивали её под свои процессы, что хорошего «прикрутили» сверху и как тем самым превратили issue-трекер в единый центр коммуникаций по задаче и упростили себе жизнь. В этой статье вы увидите наш флоу изнутри, узнаете, как можно «докрутить» свою Jira, и прочтёте о дополнительных возможностях инструмента, о которых могли не знать.

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

Все мы прекрасно знаем о том, как разрабатывается ПО. Подумали 10 минут и сразу пошли кодить. Цикл создания программного обеспечения состоит из многих ключевых моментов. Это такие моменты как планирование, создания архитектуры, создание SRS, создание дизайна и тд и тп.

Введение

Недавно ко мне обратились, чтобы я посоветовал стандарты для написания технического задания (ТЗ) на разработку автоматизированных систем (АС) и программного обеспечения (ПО). Вот думаю, сейчас зайду в Яндекс, найду подходящую статейку и отправлю её. Но не тут-то было! Одной статьи, где перечисляются стандарты для ТЗ, включая шаблоны и примеры готовых документов, я не нашел. Придется сделать такую статейку самому…

И так, основные стандарты, методологии и своды знаний, где упоминается ТЗ или SRS (Software (or System) Requirements Specification):

• ГОСТ 34
• ГОСТ 19
• IEEE STD 830-1998
• ISO/IEC/ IEEE 29148-2011
• RUP
• SWEBOK, BABOK и пр.

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

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



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