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

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

Проект безопасности OWASP API Security Top 10 предназначен подчеркнуть потенциальные риски в небезопасных API и предложить меры снижения таких рисков.

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



Автор статьи, перевод которой мы сегодня публикуем, работает в Wix. Он хочет рассказать о том, как смог уменьшить размер одного бандла примерно на 80%, используя Webpack Analyzer и React Lazy/Suspense.

Моё имя Азат Разетдинов, я в Яндексе уже 12 лет, руковожу службой разработки интерфейсов в Я.Недвижимости. Сегодня я хотел бы поговорить про монорепозиторий. Если у вас всего один репозиторий в работе — поздравляю, вы уже живете в монорепозитории. Теперь о том, зачем он нужен другим.

Как сказала руководитель службы разработки API Яндекс.Карт Марина Перескокова — посадил дед монорепу, выросла монорепа большая-пребольшая.

Чё, зачем, почему

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

Совсем недавно мы опубликовали статью с описанием проблем одной из самых популярных технологий, используемых в IT, и на наше удивление она вызвала достаточно живой интерес (во всяком случае для технической статьи). Поэтому мы решили на этом не останавливаться, и сегодня мы «идем в гости» к одному из самых популярных продуктов на российском рынке разработки бизнес-приложений — платформе 1С.

Так сложилось, что на хабре многие 1С не любят, но порой складывается впечатление, что немногие из этих людей хорошо понимают, за что они его не любят. Этой статьей мы восполним этот пробел и убьем сразу двух зайцев: с одной стороны, расскажем, как в 1С все устроено изнутри, а с другой стороны — почему это все работает не так как нужно / хотелось бы. Надо сказать, что 1С многими своими решениями смог реально нас удивить, впрочем, не будем забегать вперед.

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

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

Статистика – вещь упрямая. И согласно аналитике за последние пять лет 65% случаев утечки информации в компаниях произошли из-за действий инсайдеров. Более 95% записей скомпрометированы по неосторожности — от незнания правил по обращению с данными или из-за сбоя в системе. Процент утечки персональных данных от общего количества инцидентов все пять лет не опускался ниже 60%.

В лидерах по утечкам — B2C-компании, имеющие большую клиентскую базу: это розничные банки, МФО и операторы связи. От самых громких утечек за последние пару лет пострадало более полумиллиарда учетных записей – напомню некоторые из них, чтобы не быть голословным.

Прим. перев.: То, что сегодня принято называть SRE (Site Reliability Engineering — «обеспечение надежности информационных систем»), включает в себя большой спектр мероприятий по эксплуатации программных продуктов, направленных на достижение ими необходимого уровня надежности. Мониторинг — одно из ключевых мероприятий, а «золотые сигналы» образуют главные метрики, которые должны в нём учитываться. Не найдя на Хабре ни одного материала про них, мы решили перевести небольшую заметку от авторов платформы для управления инцидентами (VictorOps), дающую представление общее представление об этом подходе.



Эффективный site reliability engineering (SRE) опирается на глубокое понимание базовой инфраструктуры сервиса и архитектуры. Повышение прозрачности состояния приложения и инфраструктуры — это только начало проактивной работы над созданием надежных систем. При этом наилучшей отправной точкой для мониторинга состояния систем считаются так называемые «четыре золотых сигнала» (four golden signals) SRE. Наладив эти четыре базовых метода мониторинга, можно переходить к дальнейшему повышению прозрачности системы.

Итак, хабровчане, уже в этот четверг в OTUS стартует курс «Fullstack разработчик JavaScript». И сегодня мы делимся с вами еще одной авторской публикацией в преддверии старта курса.



Автор статьи: Павел Якупов

---

В этой статье мы поговорим о самых простых и распространенных паттернах проектирования в языке Javascript — и постараемся объяснить, какие из них когда нужно применять.
Что такое вообще паттерны проектирования? Паттерны проектирования это термин, который используется для общих, часто используемых решений для общих проблем в создании программ.

Говоря проще, паттерны проектирования — это удачные решения, которые используются достаточно часто. Паттерны проектирования как понятие сформировались еще в то время, когда языка программирования JavaScript не было в помине, в сфере software engineering паттерны проектирования были подробно описаны еще в 1994 году «Большой четверкой». Однако мы в нашей статье обратимся к реализации некоторых несложных паттернов именно на языке программирования JavaScript.

Вашему вниманию предлагается перевод поста Гергелия Ороса, занимающего должность Engineering Manager в Uber. В нем он делится своим взглядом на проектирование крупномасштабных систем, основанном на собственном практическом опыте работы в Uber и Microsoft. В сочетании с комментариями на Hacker News, которые добавляют весомые контр-аргументы и дополняют точку зрения автора, его статья стала одним из самых интересных постов недели. В статье используется термин «дизайн кода» для сравнения с традиционной «архитектурой» — о нем подробнее можно прочитать здесь.

На мою долю выпало достаточно опыта в проектировании и создании крупномасштабных систем. Я принимал участие в переписывании распределенной системы платежей в Uber, проектировании и релизе Skype на Xbox One и выпуске в открытый доступ RIBs — мобильного архитектурного фреймворка, созданного в Uber. Все эти системы имели тщательно продуманный дизайн, прошли через несколько итераций, с ними связано множество совещаний, проведенных у маркерной доски, и других обсуждений. Затем придуманный дизайн сводился к дизайн-документу, который распространялся среди других разработчиков для сбора дополнительной обратной связи, который продолжался до тех пор, пока мы не переходили к разработке.

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

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

Собственно, что делать руководителю и команде, достаточно хорошо написано в «Сгоревшие сотрудники: есть ли выход» (uyga) и «Гори, гори ясно, пока не погасло» (Lisichkina). Краткий спойлер от меня: достаточно быть внимательным руководителем и заботиться о сотрудниках, остальное — разные по степени эффективности инструменты.

Но я убеждена, что ≈80% причин выгорания лежат в личностных особенностях сотрудника. Вывод основан на моём опыте, но думаю, это справедливо и для других выгоревших. Более того, мне кажется, что более ответственные, переживающие за своё дело и внешне перспективные, покладистые работники выгорают чаще, чем остальные.


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

Во первых словах:

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

Сейчас я обосную этот тезис с научной точки зрения.

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

Весной мы добавили в API DaData.ru фичу «Обратное геокодирование», она же «Адрес по координатам». Название намекает: метод принимает геокоординаты и отдает данные об адресе.

Солидный продукт с той же функциональностью предлагает «Яндекс» — он называется «Геокодер». Но сервис «Яндекса» бесплатен только для открытых некоммерческих проектов. Стандартный же тариф — от 120 000 ₽ в год — подходит не всем.

Мы подумали — если сделать бесплатную или недорогую альтернативу «Геокодеру», разработчики наверняка скажут спасибо. И сделали. В статье расскажу, как устроен «Адрес по координатам»: как мы наладили поиск, собрали справочник и упаковали в готовый метод.

Содержание

• Описание метода
• Применение тестировщиками
  
  • Строка данных
  • Файл
• Применение разработчиками
• Резюме

Иногда баги сами нас находят. Вот мы впихали большую строку данных — и система подвисла. Это она из-за 1 млн символов упала? Или ей какой-то конкретный не понравился?

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

Если найти минимальные данные для воспроизведения, то:

• Вы сэкономите время разработчику — ему не придется подключаться к тестовому стенду, самому грузить файл и дебажить
• Менеджер сможет легко оценить приоритет задачи — это нужно срочно исправлять, или баг может подождать? Пока название «некоторые файлы падают, хз почему» — это сделать сложно...
• Описание бага от понимания причины падения тоже только выиграет.

Как найти минимальные данные для воспроизведения бага? Если есть какие-то подсказки в логах, применяем их. Если подсказок нет, то самый оптимальный метод — метод бисекционного деления (также известный как метод «деления пополам» или «дихотомия»).

Описание метода

Метод применяется для поиска точного места падения:

1. Взять падающую пачку данных.
2. Разбить пополам.
3. Проверить половину 1
   
   
   • Если упало — значит, проблема там. Работаем дальше с ней.
   • Если не упало → проверяем половину 2.
4. Повторяем шаги 1-3 до тех пор, пока не останется одно падающее значение.

Метод позволяет довольно быстро локализовать проблему, особенно если это делается программно. Разработчики встраивают такие механизмы в обработку данных. А если не встраивают, то сами и страдают потом, когда к ним приходит тестировщик и говорит «Вот на этом файле падает, а точную причину я не смог найти».

Вступление

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

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

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

Интернет-магазин, здесь злоумышленник также может сильно навредить, отменив покупку, которая уже оплачена.

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

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

Они помогут вам:

• глубже продумать свой макет
• избежать лишних вопросов
• получить более качественный результат
• остаться друзьями с frontend-разработчиком

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

Я в общих чертах расскажу о перекрестной репликации между PostgreSQL и MySQL, а еще о методах настройки перекрестной репликации между этими двумя серверами базы данных. Обычно базы данных в перекрестной репликации называются однородными, и это удобный метод перехода с одного сервера реляционной СУБД на другой.

Базы данных PostgreSQL и MySQL принято считать реляционными, но с дополнительными расширениями они предлагают возможности NoSQL. Здесь мы обсудим репликацию между PostgreSQL и MySQL, с точки зрения реляционных СУБД.

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

Привет, Хабр. Это статья о том как написать Hello world по последнему слову техники.

В конце мы получим hello world библиотеку которая:

• Использует typescript
• Заботится о codestyle
• Генерирует доку
• Проводит тесты