В нашей прошлой статье про синтез речи мы дали много обещаний: убрать детские болячки, радикально ускорить синтез еще в 10 раз, добавить новые "фишечки", радикально улучшить качество.

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

• Снизили размер модели в 2 раза;
• Научили наши модели делать паузы;
• Добавили один высококачественный голос (и бесконечное число случайных);
• Ускорили наши модели где-то примерно в 10 раз (!);
• Упаковали всех спикеров одного языка в одну модель;
• Наши модели теперь могут принимать на вход даже целые абзацы текста;
• Добавили функции контроля скорости и высоты речи через SSML;
• Наш синтез работает сразу в трех частотах дискретизации на выбор — 8, 24 и 48 килогерц;
• Решили детские проблемы наших моделей: нестабильность и пропуск слов, и добавили флаги для контроля ударения;

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

Попробовать модель как обычно можно в нашем репозитории и в колабе.

Введение

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

Введение

Bottle — это мини-фреймворк для Python, позволяющий писать веб-приложения с высокой скоростью.

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

Если вам надо написать handler, который будет принимать ссылку на файл, а потом скачивать его в s3 с какой-то обработкой, то для проверки функционала bottle отлично подойдет.

Для работы с bottle достаточно описывать сами обработчики, например:

from bottle import route, run, template
@route('/hello/<name>')
def index(name):
    return template('<b>Hello {{name}}</b>!', name=name)
run(host='localhost', port=8080)

(Пример из документации.)

При написании более смысловых функций (например, телефонная книга с сохранением в БД), очень быстро возникает необходимость работы то с БД, то с кэшем, то с сессиями. Это порождает необходимость пихать функционал работы с БД в сам обработчик, затем выносить в отдельные модули, чтобы не дублировать код. А после этого код CRUDL для разных объектов переписываем в виде что-то типа мета-функций.

Но можно пойти и по другому пути: начать использовать bottle plugin. О механизме плагинов и пойдет речь в этой публикации.

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

Зачем нужны индикаторы прогресса?

Индикаторы прогресса (progress bar) — визуальное отображение процесса работы. Они избавляют нас от необходимости беспокоиться о том, не завис ли скрипт, дают интуитивное представление о скорости его выполнения и подсказывают, сколько времени осталось до завершения.

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

Для начала повторим основные горячие клавиши. Если вы их ещё не используете — начните обязательно. В долгосрочной перспективе время на изучение окупится многократно.

0. Основные горячие клавиши

• Esc: Переключение между режимом выполнения и редактирования
• A: Добавление пустой ячейки сверху
• B: Добавление пустой ячейки снизу
• DD: Удаления ячейки
• C: Копирование ячеек
• X: Вырезание ячеек
• V: Вставка ячеек

1. Перезапуск блокнота

Для рестарта просто нажмите ESC + 00.

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


Улучшения в количестве ошибочно распознанных слов. Тестовый голосовой набор был собран на телефонном коммутаторе в 2000 году из 40 случайных разговоров двух человек, чей родной язык – английский

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

Предполагалось, что когда компьютер научится понимать человеческую речь, мы быстро сможем создать искусственный интеллект. Но точность систем распознавания речи достигла своего пика в 1999 году и с тех пор застыла на месте. Академические тесты 2006 года констатируют факт: системы общего профиля так и не преодолели уровень 80%, тогда как у человека этот показатель составляет 96-98%.

Профессор Роберт Фортнер из Media Research Institute считает, что создатели систем распознавания речи окончательно зашли в тупик. Программисты сделали всё что смогли, и у них не получилось. Спустя несколько десятилетий они поняли, что человеческая речь — не просто набор звуков. Акустический сигнал не несёт достаточно информации для распознавания текста.

Часто нужно узнать всю информацию о какой-нибудь уязвимости: насколько найденный баг критичен, есть ли готовые сплоиты, какие вендоры уже выпустили патчи, каким сканером проверить наличие бага в системе. Раньше приходилось искать вручную по десятку источников (CVEDetails, SecurityFocus, Rapid7 DB, Exploit-DB, базы уязвимостей CVE от MITRE/NIST, вендорские бюллетени) и анализировать собранные данные. Сегодня эту рутину можно (и нужно!) автоматизировать с помощью специализированных сервисов. Один из таких — Vulners, крутейший поисковик по багам, причем бесплатный и с открытым API. Посмотрим, чем он может быть нам полезен.

Начать свое присутствие на Хабре мы решили с материала, подготовленного для Конференции уральских веб-разработчиков, в котором описаны проверенные на собственной практике и оказавшиеся вполне успешными методы борьбы с DDoS-атаками. Целевая аудитория данной статьи — это программисты, имеющие в распоряжении vds или dedicated. Статья не претендует на полноценное руководство и многие сисадминские нюансы в ней намеренно опущены. Мы рассматриваем только DDoS типа http flood как наиболее распространенный тип DDoS и наиболее дешевый для заказчика.

Целевая аудитория данной статьи – это программисты, имеющие в распоряжении VDS или Dedicated.

Вступление

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

Сам Unity Engine (далее Unity), как и многие другие игровые движки, наиболее приспособлен к компонентно-ориентированному программированию (далее КОП), так как Behavioral Pattern — один из базовых паттернов архитектуры движков, наряду с паттерном «Component» из классификации Decoupling Patterns. Потому именно компонент является базовой единицей для реализации бизнес-логики в Unity. В этой статье я расскажу о том, как применять КОП в Unity.

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

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

В публикации рассматриваются следующие темы:

• Наследование VS компоненты
• Сложные иерархии классов юнитов, предметов и прочего
• Машины состояний, деревья поведений
• Абстракции игровых объектов
• Упрощение доступа к другим компонентам в объекте, сцене
• Сложные составные игровые объекты
• Характеристики объектов в игре
• Модификаторы (баффы/дебаффы)
• Сериализация данных

Специально для Хабра мы взяли интервью с представителем “темной стороны” рынка мобильного трафика.
“Вы считаете, что работая с CPA агентствами вы приобретаете хоть сколько нибудь живой трафик? Вы верите в модель CPI? Угадаете долю живого трафика в подобных сетях? На самом деле, доля “серого” трафика намного больше, чем Вы могли подумать."
Интересно?

Несмотря на то, что один из крупнейших игроков компьютерного рынка IBM в 1981 году выпустила персональный компьютер IBM PC, британская компания Sinclair Research, возглавляемая Клайвом Синклером, 23 апреля 1982 года выпустила на рынок дешёвую модель компьютера Sinclair ZX Spectrum, число продаж которого за 17 месяцев превысило один миллион штук.

картинку можно потыцать

Каталог:
Один
Два
Три

Менеджер памяти (и связанные с ним вопросы контроллера кеша, менеджера ввода/вывода и пр) — одна из вещей, в которой (наряду с медициной и политикой) «разбираются все». Но даже люди «изучившие винду досконально» нет-нет, да и начинают писать чепуху вроде (не говоря уже о другой чепухе, написанной там же):

Грамотная работа с памятью!!! За все время использования у меня своп файл не увеличился ни на Килобайт. По этому Фаерфокс с 10-20 окнами сворачивается / разворачивается в/из трея как пуля. Такого эффекта я на винде добивался с отключенным свопом и с переносом tmp файлов на RAM диск.

Или к примеру μTorrent — у меня нет никаких оснований сомневаться в компетентности его авторов, но вот про работу памяти в Windows они со всей очевидностью знают мало. Не забываем и товарищей, производящих софт для слежения за производительностью и не имеющих ни малейшего понятия об управлении памятью в Windows (и поднявших по этому поводу истерику на пол интернета, на Ars-е даже был разбор полетов). Но самое потрясающее, что я видел всвязи с управлением памятью — это совет переместить pagefile на RAM-диск:

Из моих трех гигабайт под RAM disk был выделен один (на тот момент, когда на лаптопе еще была установлена XP), на котором я создал своп на 768МБ ...

Цель данной статьи — не полное описание работы менеджера памяти (не хватит ни места ни опыта), а попытка пролить хоть немного света на темное царство мифов и суеверий, окружающих вопросы управления памятью в Windows.

Разработка Xenonauts заняла пять лет. На нее ушло в десять раз больше времени и в двадцать раз больше денег, чем я ожидал, но она стала настолько важной частью моей жизни, что мне даже немного жаль, что это путешествие завершилось. С разработкой было связано немало личных рисков. Когда она началась в 2009 году, мне было 22 года и я ничего не знал о разработке игр. Я потратил на этот проект все свои сбережения, значительную часть которых составляло наследство. Моим офисом была моя спальня, я работал над Xenonauts по вечерам и на выходных, после полноценной рабочей недели консультанта в KPMG, включавшей в себя три года экзаменов по бухучету (провал каждого из них привел бы к моему увольнению). К счастью, все закончилось хорошо. Эта статья представляет собой обещанный на Кикстартере дневник, в котором оцениваются все стороны разработки — правильно я поступал или нет. Надеюсь это будет интересно и возможно поможет кому-то избежать моих ошибок.

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

Сегодня я решил опубликовать свои шпаргалки, на самые часто встречающиеся ошибки при работе с MySQL.

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

Первая публикация в этом цикле будет посвящено сравнительному анализу генераторов статических сайтов.