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

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

- мощности и производительности

- безопасности, соответствию стандартам и законодательству

- переносимости и совместимости.

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

• При работе с WYSIWYG-решениями (напр., PowerPoint) требуется выполнять вручную массу монотонной работы, они не слишком хорошо поддерживают подсветку синтаксиса, не предоставляют качественных инструментов для точной отрисовки сложных фигур и анимации, а также их не так просто интегрировать с контролем исходников.
• Декларативные инструменты (напр., Beamer или reveal.js) гораздо лучше. В них серьёзно поддерживается подсветка синтаксиса, они позволяют рисовать сложные фигуры и анимацию (в особенности Beamer) и, кроме того, с лёгкостью версионируются. Правда, ни один из используемых с ними декларативных языков (ни LaTeX, ни HTML) не дают достаточной гибкости для создания по-настоящему сложных слайдов.

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

Меня зовут Щемелинин Вадим, я четыре года работаю в сфере цифровизации промышленности в компании «СИБУР Диджитал». Моя основная задача — развитие Индустрии 4.0 в холдинге. Одним из продуктов моего направления является видеоаналитика. Сегодня я расскажу про сложности, с которым сталкиваются Python-разработчики, внедряя машинное зрение в нефтехимическую индустрию.

В материале, переводом которого мы решили поделиться к старту курса о машинном и глубоком обучении, простым языком рассказывается о семантическом поиске, статья охватывает шесть его методов; начиная с простых сходства по Жаккару, алгоритма шинглов и расстояния Левенштейна, автор переходит к поиску с разреженными векторами — TF-IDF и BM25 и заканчивает современными представлениями плотных векторов и Sentence-BERT. Простые примеры сопровождаются кодом и иллюстрациями, а в конце вы найдёте ссылки на соответствующие блокноты Jupyter.

Регулярные выражения в Python от простого к сложному

1. Модули и краткая история C++.
2. Операция «космический корабль».
3. Концепты.
4. Ranges.
5. Корутины.
6. Другие фичи ядра и стандартной библиотеки. Заключение.

Мотивация

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

Меня зовут Кирилл Богатов, я дизайнер разговорных продуктов в KODE. Я нашёл способ упрощать сложные схемы при помощи языка ДРАКОН. В статье расскажу о том, как я к нему пришёл, чем он так хорош и как с его помощью мы стали тратить на проектирование почти вдвое меньше времени.

Статья содержит анализ и критику стандарта ГОСТ 19.701-90 в части схем алгоритмов. Предлагается для записи алгоритмов создать новый стандарт, основанный на эргономичном визуальном алгоритмическом языке ДРАКОН. Дается сравнительный анализ блок-схем алгоритмов по ГОСТ 19.701-90 и дракон-схем.

В предыдущих статьях я рассказал об этапах выполнения запросов и о статистике.

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

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

QQ Хабр! В этом гайде мы пройдемся по каждому шагу создания ботов в Telegram - от регистрации бота до публикации репозитория на GitHub. Некоторым может показаться, что все разжевано и слишком много элементарной информации, но этот гайд создан для новичков, хотя будет интересен и для тех, кто уже занимался разработкой в Telegram. Сегодня мы будем делать бота, который отвечает на заданные вопросы.

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

В этой статье будут рассмотрены методы чистки данных – noise reduction – и результаты тестирования алгоритмов.

Чистка данных – значение и применение

Чистка данных – это процесс удаления шума из датасетов, который появляется в результате неправильно размеченных примеров. Источники такого шума могут быть разными: случайные ошибки аннотатора – человека или машины, которые размечают данные в соответствии с задачей, – неслучайные ошибки из-за плохого понимания задачи или двусмысленного примера, ошибки автоматической разметки. 

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

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

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