Вторая часть — https://habr.com/ru/post/563484/

Вокруг темы синтеза речи сейчас много движения: на рынке есть огромное число тулкитов для синтеза, большое число закрытых коммерческих решений за АПИ (как на современных технологиях, так и на более старых, т.е. "говорилки") от условных GAFA компаний, большое количество американских стартапов, пытающихся сделать очередные аудио дипфейки (voice transfer).

Но мы не видели открытых решений, которые бы удовлетворяли одновременно следующим критериям:

• Приемлемый уровень естественности речи;
• Большая библиотека готовых голосов на разных языках;
• Поддержка синтеза как в 16kHz так и в 8kHz из коробки;
• Наличие своих собственных голосов у авторов решения, не нарушающих чужие права и лицензии;
• Высокая скорость работы на "слабом" железе. Достаточная скорость работы на 1 потоке / ядре процессора;
• Не требует GPU, команды ML инженеров или какой-либо дополнительной тренировки или для использования;
• Минимализм и отсутствие зависимостей / использование в 1 строчку / не надо ничего собирать или чинить;
• Позиционируется именно как готовое решение, а не очередной фреймворк / компиляция чужих скриптов / тулкитов для сбора плюсиков;
• Решение никак не связано и не аффилировано с закрытыми экосистемами и продуктами Гугла / Сбера / Яндекса / вставить нужное;

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

Общепринятые мировые практики против проведения нескольких трансформаций в компании одновременно. И все же они возможны, при соответствующей подготовке, привлечении необходимых ресурсов и правильном мониторинге результатов. Плюсами и минусами одновременных трансформаций на конференции DevOps Live 2020 поделился лидер трайба IT4IT в ОТП Банке Максим Ефимов. 

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

• «Проблема»
• «Не работает»
• «Сломанный»
• «Сбой»
• «Ошибка»
• «Баг»
• «Не работает»
• «Поломка»
• «Не могу выстроить»
• «Не удалось установить»
• «Не работает»
• «Помощь»
• «Не компилируется»
• «Ошибка»
• «Не подключается»
• «Проблема»

Главная сложность в разработке приложения – накодить его функционал. Например, сделать редактирование текста для приложения-блокнота. Так я полагал, когда был моложе и наивнее.

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

Хочу поделиться краткой выжимкой из своего опыта: какие неожиданные сложности вас ждут, если вы делаете мобильное приложение впервые.

На днях у меня появилась довольно интересная идея для статьи, основанная на следующей предпосылке: на Хабре ни разу не рассказывали об организации энтерпрайз разработки "от и до". В плане совсем с нуля и хотя бы до комфортного минимума. За отправную точку я буду брать ситуацию полнейшего хаоса, когда какой-то код существует на машине единственного разработчика, нет системы контроля версий, нет тестовых сред, код объектов БД существует только внутри эталонной продуктивной базы данных, нет никаких процессов сборки и установки, контроля качества кода и так далее. Возможно читатель задастся вопросом "Такое бывает в 2020 году? Разве кто-то еще так разрабатывает?" и будете только отчасти правы. Предлагаю обсудить детали под катом.

Вам нужны наблюдаемые микросервисы, но вы еще не знаете, как их реализовать с помощью Kubernetes? Ну что ж… возможно это именно та статья, которую вы искали.

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

Выяснить, что вы не совпадаете с компанией по целям и ценностям иногда удаётся не сразу: что-то вскрывается уже спустя несколько месяцев, как случилось у нашего героя Антона, Python-разработчика, на прошлом месте работы. Казалось бы, почему? Вы — хороший инженер, нанимающий менеджер — человек с большим опытом собеседований за плечами. У двух умных людей не должно возникнуть проблем при общении друг с другом. Но времени мало, а на подробные расспросы не всегда есть силы. К тому же иногда люди склонны — как, впрочем, и на свидании — показывать при первой встрече только лучшее.

Мы опросили знакомых IT-специалистов, разработчиков и тимлидов, как проверить компанию во время собеседования. Собрали каверзные вопросы, на которые нельзя отделаться стандартной отговоркой — надеемся, они вам пригодятся. Список не может быть полным: каждый ищет свою работу мечты, к тому же удалёнка вносит коррективы :) Поэтому добавляйте свои варианты в комментарии! Кстати, есть хорошая идея — задавать эти вопросы разным интервьюерам и сравнивать ответы.

Как вырасти внутри компании уровня FAANG? Какие для этого нужны навыки, что придется делать и почему быстро получить повышение не получится? Мы спросили про это у Алины — она работает в Uber и недавно получила повышение до Senior Software Engineer. Сейчас расскажет, через что ей для этого пришлось пройти.

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

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

По мотивам своих собеседований, а также собеседований коллег и mentee, составил список вопросов от тимлида к компании, что стоит прояснить на собеседовании — что спросить собеседующего.

Вопросы подойдут, возможно, не только тимлиду, но были придуманы для него.

Каковы финансовые показатели компании?

Является ли компания прибыльной или тратит деньги инвесторов? Или даже до инвесторов ещё не дошло, и основатели пока платят из своего кармана? Как выглядит бизнесовый план развития?

Если компания имеет представительство в РФ, официальное ли (по ТК РФ) трудоустройство и полностью ли "белая" зарплата?

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

Расскажите про ваше понимание «хорошего тимлида»

У собеседника должно быть четкое и непротиворечивое понимание, что он вкладывает в понятие «тимлид» и какие критерии используются для оценки работы тимлида.

Возможно, это понимание даже прописано в должностных инструкциях.

Где-то тимлид должен быть разработчиком (то есть, писать код) с минимальной общественной нагрузкой, где-то руководителем, где-то пытаться совместить.

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

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

Иногда вещи находят себе применение неожиданно и не в том, для чего их задумывали. 

В 1960-е годы Кен Томпсон — легенда программирования — написал компьютерную игру Space Travel для операционной системы Multics. Система была проектом компании Bell Lab, где он работал вместе с Денисом Ритчи. Позже проект закрыли, и чтобы продолжать играть в свою Space Travel, Томпсон решил портировать ее на компьютер PDP-7. Инструменты, которые он создал для порта, затем легли в основу операционной системы Unix. 

Томпсон написал в одиночку первые три версии. Для Unix был нужен системный язык — так появился B. Позже Денис Ритчи, коллега и друг Томпсона, подхватил разработку и написал язык C. Вот так в основе почти всего, на чем построены современные технологии, лежало желание поиграть в компьютерную игру и пет-проекты для забавы.

Кен Томпсон построил блестящую карьеру исследователя в области computer science. В середине 2000-х он устроился в Google, где вместе с Робом Пайком и Робертом Грейсмером создал Golang — один из самых популярных языков последнего времени.

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

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

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