Привет, Хабр!

Работаю на большом интеграционном проекте (IBM WAS, WebSphere MQ, Oracle) и оплетаю наш кровавый энтерпрайз паутиной функциональных тестов в JMeter, который крутится на тестовом стенде и пробуждается по зову Jenkins после деплоя нового билда. По мере увеличения количества тестов столкнулся с проблемой поддержания тестовой документации в актуальном виде.

Конечные автоматы (finite-state machine)

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

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

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

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


Текущее состояние — множество состояний в котором автомат может находиться в данный момент времени.

Стартовое состояние — состояние откуда КА начинает свою работу.

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

Сдача проекта в опытную эксплуатацию. Комиссия наблюдает, как система распознаёт информацию из сообщений, поступающих в в режиме реального времени. Приходит первое сообщение: “Тихо.”

Комиссия. Что значит “Тихо”? Они там в филиале пьяные что ли?
Система. "Тихо" = Сила ветра в пределах нормы.
Комиссия. Так это они о погоде. Система сдана в опытную эксплуатацию!

Все события в статье вымышлены. Любые совпадения с реальностью случайны.

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

RegExp Unicode Property Escapes перешли на 4-ю ступень и будут включены в ES2018.

В V8 они доступны без флага начиная с v6.4, поэтому готовы к использованию во всех текущих каналах Google Chrome от стабильного до Canary.

В Node.js они будут доступны без флага уже в v10 (выходит в апреле). В других версиях требуется флаг --harmony_regexp_property (Node.js v6–v9) или --harmony (Node.js v8–v9). Сейчас без флага их можно испробовать или в ночных сборках, или в ветке v8-canary.

При этом нужно иметь в виду, что сборки Node.js, скомпилированные без поддержки ICU, будут лишены возможности использовать этот класс регулярных выражений (подробнее см. Internationalization Support). Например, это касается популярной сборки под Android от сообщества Termux.

Подробнее о поддержке в других движках и средах см. в известной таблице (после перехода проскрольте чуть выше).

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

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

Решил я давеча моим школьникам дать задачек на регулярные выражения для изучения. А к задачкам нужна какая-нибудь теория. И стал я искать хорошие тексты на русском. Пяток сносных нашёл, но всё не то. Что-то смято, что-то упущено. У этих текстов был не только фатальный недостаток. Мало картинок, мало примеров. И почти нет разумных задач. Ну неужели поиск IP-адреса — это самая частая задача для регулярных выражений? Вот и я думаю, что нет.
Про разницу (?:...) / (...) фиг найдёшь, а без этого знания в некоторых случаях можно только страдать.

Плюс в питоне есть немало регулярных плюшек. Например, re.split может добавлять тот кусок текста, по которому был разрез, в список частей. А в re.sub можно вместо шаблона для замены передать функцию. Это — реальные вещи, которые прямо очень нужны, но никто про это не пишет.
Так и родился этот достаточно многобуквенный материал с подробностями, тонкостями, картинками и задачами.

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

Код этого поста, как и сам пост, выложен на github.

До недавнего времени регулярные выражения казались мне какой-то магией. Я никак не мог понять, как можно определить, соответствует ли строка заданному регулярному выражению. А теперь я это понял! Ниже представлена реализация простого движка регулярных выражений менее чем в 200 строках кода.

Часть 1: Парсинг

Спецификация

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

• . — соответствие любому символу
• | — соответствие abc или cde
• + — соответствие одному или более предыдущего паттерна
• * — соответствие 0 или более предыдущего паттерна
• ( и ) — для группировки

Хотя набор опций невелик, с его помощью можно создать интересные regex-ы, например, m (t|n| ) | b позволяющий найти субтитры к Star Wars без субтитров к Star Trek, или (..)* для нахождения множества всех строк чётной длины.

План атаки

Мы будем анализировать регулярные выражения в три этапа:

1. Парсинг (синтаксический анализ) регулярного выражения в синтаксическое дерево
2. Преобразование синтаксического дерева в конечный автомат
3. Анализ конечного автомата для нашей строки

Для анализа регулярных выражений (подробнее об этом ниже) мы будем использовать конечный автомат под названием NFA. На высоком уровне NFA будет представлять наш regex. При получении входных данных мы будем перемещаться в NFA от состояния к состоянию. Если мы придём в точку, из которой невозможно совершить допустимого перехода, то регулярное выражение не соответствует строке.

От переводчика

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

Несколько недель назад вышла замечательная англоязычная статься об open-source python-библиотеки FlashText. Эта библиотека предоставляла быстрое работающее решение задачи поиска и замены ключевых слов в тексте.

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

Привет, Хабр.

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

Некоторые из них для наглядности будут показаны на примере языков программирования PHP или JavaScript, но в целом они работают независимо от ЯП.

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

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

Поехали!

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

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

В начале сентября было открыто 2 вакансии: стажер-исследователь и стажер-разработчик.

В ECMAScript 6 представлены два новых флага для регулярных выражений:

1. y включает режим «липкого» сопоставления.
2. u включает различные связанные с Unicode опции.

В данной статье объясняется влияние флага u. Эта статья будет Вам полезна, если Вы знакомы с Unicode-проблемами в Javascript.

Расскажу, как классификация текста помогла мне в поиске квартиры, а также почему я отказался от регулярных выражений и нейронных сетей и стал использовать лексический анализатор.

Работа с регулярными выражениями в iOS 10

Всем привет! В этой статье мы разберем как работать с NSRegularExpression и NSDataDetector,
всех неравнодушных приглашают под кат.

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

Хитрость в том, чтобы сразу определить значение слова «действительный».

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


^{en.wikipedia.org/wiki/Email_address#Valid_email_addresses}

Итак, эта статья посвящается тем, кто любит решать нестандартные задачи на не предназначенных для этого инструментах. Здесь я опишу основные проблемы, с которыми столкнулся во время создания аналога игры Gravity defied с использованием потокового текстового редактора (sed).

Далее предполагается, что читатель хотя бы немного знаком с синтаксисом sed'а и и написанием скриптов под bash.

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

Большинство из нас, впервые столкнувшись с данной проблемой, начинают забивать в поисковых системах что-то типа: «regexp online generator» и к своему великому сожалению осознают что гугл сломался все результаты в поиске являются сервисами для проверки корректности уже составленного регулярного выражения (или я плохо гуглил).

А как же составить это самое регулярное выражение?

До недавнего времени существовало 2 ответа на этот вопрос:

1. Изучить документацию по регулярным выражениям и составить регулярку самому
2. Попросить кого-то более опытного сделать это за вас

Теперь, после нескольких месяцев разработки, рад представить и 3-й ответ:

» Генератор регулярных выражений

История

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

Всем привет!

Эта статья про реализацию одного конкретного DSL (domain specific language, предметно-ориентированный язык) для регулярных выражений средствами Kotlin, но при этом она вполне может дать общее представление, о том, как написать свой DSL на Kotlin и что обычно будет делать "под капотом" любой другой DSL, использующий те же возможности языка.

Многие уже используют Kotlin или хотя бы пробовали это делать, да и остальные вполне могли слышать о том, что Kotlin располагает к написанию изящных DSL, чему есть блестящие примеры — Anko и kotlinx.html.

Конечно же, для регулярных выражений подобное уже делали (и ещё: на Java, на Scala, на C# — реализаций много, похоже, это распространённое развлечение). Но если хочется попрактиковаться или попробовать DSL-ориентированные языковые возможности Kotlin, то добро пожаловать под кат.

Плюнь тому в глаза, кто скажет, что можно обнять необъятное!
…
Усердие всё превозмогает!
 
                          Козьма Прутков "Мысли и афоризмы" 

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

Классический сухой регекс:

/^(?:[0-9]|[a-z]|[\._%\+-])+(?:@)(?:[0-9]|[a-z]|[\.-])+(?:\.)[a-z]{2,}$/i

С новым вкусом SLR:

Любые благородные начинания UI-дизайнера и верстальщика хоть как-то навести порядок в списках названий организаций разбивается о копи/паст неграмотного пользователя. Так ли всё плохо и можем ли мы чем-нибудь им помочь? Попробуем разобраться…

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

После перехода от Perl к JavaScript много лет тому назад, я всё испытывал за свой новый язык некоторый комплекс неполноценности из-за недостаточной поддержки Юникода. За всё то время, пока JavaScript совершал в этом направлении свой большой скачок (при переходе от ES5 к ES6), у меня в закладках осталось несколько хороших статей.

The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!)
JavaScript has a Unicode problem
Unicode-aware regular expressions in ECMAScript 6
ES6 Strings (and Unicode, ) in Depth

В последней из них предлагался рецепт разбиения строки на символы с учётом Юникода при помощи нового оператора ...