В 2020 году библиотека Natasha значительно обновилась, на Хабре опубликована статья про актуальную версию. Чтобы использовать инструменты, описанные в этом тексте, установите старую версию библиотеки pip install natasha<1 yargy<0.13.

Раздел про Yargy-парсер актуален и сейчас.

Есть стандартная задача извлечения именованных сущностей из текста (NER). На входе текст, на выходе структурированные, нормализованные объекты, например, с именами, адресами, датами:



Задача старая и хорошо изученная, для английского языка существует масса коммерческих и открытых решений: Spacy, Stanford NER, OpenNLP, NLTK, MITIE, Google Natural Language API, ParallelDots, Aylien, Rosette, TextRazor. Для русского тоже есть хорошие решения, но они в основном закрытые: DaData, Pullenti, Abbyy Infoextractor, Dictum, Eureka, Promt, RCO, AOT, Ahunter. Из открытого мне известен только Томита-парсер и свежий Deepmipt NER.

Я занимаюсь анализом данных, задача обработки текстов одна из самых частых. На практике оказывается, что, например, извлечь имена из русского текста совсем непросто. Есть готовое решение в Томита-парсере, но там неудобная интеграция с Python. Недавно появилось решение от ребят из iPavlov, но там имена не приводятся к нормальной форме. Для извлечения, например, адресов («ул. 8 Марта, д.4», «Ленинский проезд, 15») открытых решений мне не известно, есть pypostal, но он чтобы парсить адреса, а не искать их в тексте. C нестандартными задачами типа извлечения ссылок на нормативные акты («ст. 11 ГК РФ», «п. 1 ст. 6 Закона № 122-ФЗ») вообще непонятно, что делать.

Год назад Дима Веселов начал проект Natasha. С тех пор код был значительно доработан. Natasha была использована в нескольких крупных проектах. Сейчас мы готовы рассказать о ней пользователям Хабра.

Natasha — это аналог Томита-парсера для Python (Yargy-парсер) плюс набор готовых правил для извлечения имён, адресов, дат, сумм денег и других сущностей.

В статье показано, как использовать готовые правила из Natasha и, самое главное, как добавлять свои с помощью Yargy-парсера.

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



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

Привет всем!

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

А будем мы творить модальные окна. Да опять они. Но не такие простые, как описаны в первой моей (не моей) публикации.

Много уже их создано для Vue. Пользовался всякими. И видимо, когда достигаешь какого-то определенного уровня владения инструментом (в данном случае Vue), сразу хочется сделать велосипед, но конечно со своими прибамбасами, типа, чтобы круче всех и т.д. И я не стал исключением из правил.

Из всех доступных модальных компонентов, использовал в основном этот — Vuedals.
Но решил я его проапгрейдить. В принципе от основы остался только EventBus и взаимодействие событий связанных с открытием-закрытием окон. Основной компонент переписан и стал оберткой-контейнером и добавлен новый компонент — само модальное окно.
Но обо всем по порядку. И статья получится очень немаленькая, кто осилит, тот красавчик :)

Еще одна небольшая статейка попроще вдогонку. Расскажу, как я рисую таблицы во Vue.

Компонентов-таблиц для Vue наделано немало. С различными возможностями. И везде по-разному таблица собирается в template страницы или какого-то компонента.

В основном происходит это как-то так:

<template>
  <cmp-table :items="items" :columns="columns"/>
</template>

<script>
export default {
  name: 'page',
  data() {
    return {
      items: [ 
        { id: 1, name: 'Sony' } , 
        { id: 2, name: 'Apple' }, 
        { id: 3, name: 'Samsung' } ],
      columns: [ 
        { prop: 'id', title: 'ID' }, 
        { prop: 'name', title: 'Name' } ]
    }
  }
}
</script>

upd2: Вот и статья: https://habrahabr.ru/post/350290/
upd: Прием вопросов закончен, спасибо всем! Мы постараемся опубликовать ответы на следующей неделею

Vue (vuejs.org) — JavaScript фреймворк для разработки веб-приложений на JavaScript, созданный Эваном Ю (Evan You) в 2013 году.

Vue нашел золотую середину между React и Angular и испытал взрывной рост в последние два года, попав в тройку лидирующих JS фреймворков.

В отличии от Angular/Google и React/Facebook Vue разрабатывается сообществом и финансируется через пожертвования на Patreon. В результате Эван оставил работу в Google и полностью посвятить себя разработке Vue.

Vue набирает популярность и в России:

• В русском Vue чате в Telegram уже более 2200 человек!
• С предыдущими статьями о Vue можно ознакомиться в хабе VueJS
• 22 Марта состоится первый VueMoscow , не пропустите!

Эван любезно согласился ответить на вопросы пользователей Хабрахабра.

Задавайте свои вопросы в комментариях до четверга. Подробности и немного о Vue под катом.

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

          

Всем доброго!

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

Вступление

В последнее время кажется, что все и каждый говорят о машинном обучении. Ваши ленты в социальных сетях забиты сообщениями об ML, Python, TensorFlow, Spark, Scala, Go и т. д .; и если у нас с вами есть что-то общее, то вы можете поинтересоваться, а что насчет PHP?

Да, как насчет машинного обучения и PHP? К счастью, кто-то был достаточно сумасшедшим, чтобы не только задать этот вопрос, но и разработать универсальную библиотеку машинного обучения, которую мы можем использовать в нашем следующем проекте. В этом посте мы рассмотрим PHP-ML — библиотеку для машинного обучения на PHP — и мы напишем класс анализа тональности, который мы сможем позже использовать для нашего собственного чата или твит-бота. Основными задачами этого поста являются:

• Изучение общих понятия, касающиеся машинного обучения и анализа тональности текста
• Обзор возможностей и недостатков PHP-ML
• Определение задачи, которую мы будем решать.
• Доказательство того, что попытка машинного обучения на PHP не является абсолютно безумной целью (опционально)

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

React — это один из ведущих фронтенд-фреймворков не только потому, что за ним стоит Facebook, но и благодаря его высокой производительности. Виртуальный DOM React известен благодаря эффективному рендерингу компонентов. Но как быть, если эти компоненты внезапно становятся не такими уж и быстрыми? Куда стоит посмотреть? Как это исправить?

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

Webpack фактически стал стандартом для сборки крупных приложений на JS. Его используют практически все. Для разработчика webpack выглядит как магический черный ящик: если забросить в него файлы и небольшой конфиг, на выходе автоматически появится бандл.

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


В основе материала — доклад Алексея Иванова на конференции HolyJS 2017, проходившей в Санкт-Петербурге 2-3 июня.

Знаменитый советский и российский математик Владимир Иосифович Левенштейн (кстати, ушедший из жизни два с небольшим месяца назад) в начале второй половины прошлого века ввёл понятие дистанции редактирования, которым мы пользуемся по сей день в различных сферах — от поисковых систем до биоинформатики. В этой статье мы применим его принцип для нечёткого поиска в MySQL (поскольку MySQL на данный момент пока не предлагает встроенного решения), вычислив самый эффективный (т.е. быстрый) способ из нескольких найденных в интернете, построим алгоритм такого поиска и реализуем его на PHP.

Вместе с iOS 11 появился новый iPhone X, айфон с самой большой диагональю экрана, который фактически не имеет границ. 5.8 дюймовый OLED экран даже больше чем экран 5.5 дюймов iPhone 8 Plus, в то время как размер самого корпуса примерно такой же как у iPhone 8. Для дизайнеров это означает большую свободу в макетах.

Свежая подборка со ссылками на новости и материалы. В выпуске: PHP 7.2.0 RC 1, Laravel 5.5 LTS, чистый код на PHP, предложения из PHP Internals, видео с конференций и митапов, и многое другое.
Приятного чтения!

Честно говоря, когда мы приступили к работе над перезапуском Яндекс.Карт, я и представить себе не мог, сколько проблем нам в итоге доставит Swift. Если вы начали писать на Swift совсем недавно, то, поверьте, вы пропустили все самое интересное. Каких-то два года назад не было инкрементной компиляции в принципе (даже пробел в любом файле приводил к полной пересборке), сам компилятор постоянно вылетал с Segmentation Fault на вполне безобидных вещах вроде тройной вложенности типов или наследования от Generic, индексация проекта длилась невообразимо долго, автодополнение работало через раз и так далее и тому подобное, всех бед не счесть. Подобные моменты несомненно усложняют жизнь программистам, но постепенно решаются с каждым обновлением Xcode. Однако есть более существенные проблемы, влияющие не только на разработку, но и на качество приложения: запрет компиляции статических библиотек из свифтового кода, а также отсутствие поддержки Swift на уровне iOS.


Изначально не было очевидно, что использование Swift и динамических библиотек приводит к росту времени запуска. Мы не сравнивали время запуска с предыдущей версией и воспринимали долгую загрузку как данность. Да и средств диагностики того, что же на самом деле происходит на этапе загрузки приложения, в общем-то не было. Но в один прекрасный день разработчики Apple добавили возможность профилирования работы системного загрузчика. Оказалось, что загрузка динамических библиотек занимает очень много времени по сравнению с другими этапами. Конечно, с нашим кодом тоже не все было идеально, но, пожалуй, это частные особенности отдельного приложения и не всем будет интересно о них читать. А вот борьба с динамическими библиотеками — общая тема для всех разработчиков, использующих Swift. Именно об этой проблеме и пойдет речь.

Мне приходилось писать расширения для того, чтобы воспользоваться функциями C++ библиотек в коде PHP. Ещё, одно тяжёлое расширение портировал с 5й версии на 7ю.

Если загуглить документацию на тему написания расширений для PHP, то, в основном, это будут тексты до 2014 года, актуальные для версии 5. Сам сайт php.net предоставляет обрывчатые и устаревшие сведения, а то, что удаётся найти в их wiki, опять про 5ю версию. Максимум, что удалось найти на офф сайте, это скудный ман по миграции уже написанных расширений.

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

Однажды техдепу в HeadHunter сделали толстовки с принтом на спине «hh и в продакшн». Вроде бы и забавно, но меня всё время смущала эта надпись, т.к. в оригинале это не то, чем стоит гордиться. Это натолкнуло меня написать пост, что же на самом деле означают буквы hh.

Я хочу рассказать о том, как рождается фича в HeadHunter на примере команды API, в которой я тружусь. Какой путь ей предстоит пройти от идеи до выхода в продакшн. Затрону как технические, так и менеджерские аспекты.

Много раз (с коллегами и без) изучал рынок e-commerce & онлайн-экономики в целом в России: и всякий раз поражался, на сколько же он переполнен артефактами (в значении — близком к этому).

И вот на прошлой-позапрошлой неделе стало известно сразу несколько важных вестей:

1. ФАС дала «добро» на объединение «Техносилы» и «Эльдорадо»
2. При этом сама Техносила опровергла перед этим слухи о своём (возможном) банкростве
3. А СберБанк факторинг высудил у Юлмарта круглую сумму

Как связаны эти события?

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

Мы рады сообщить, что подготовка к PG Day'17 Russia идет полным ходом! Мы опубликовали полное расписание предстоящего мероприятия. Приглашаем всех желающих прийти и похоливарить с Антоном лично

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

Почему вообще возникла идея такого доклада? Дело в том, что PostgreSQL сейчас явно хайповая технология, и многие переходят на эту СУБД. Иногда — по объективным причинам, иногда — просто потому что это модно.

Но сплошь и рядом складывается такая ситуация, когда какой-нибудь условный программист Вася вчера писал на MySQL, а сегодня вдруг начал писать на Посгресе. Как он будет писать? Да в целом также, как и раньше, используя лишь самый минимальный набор возможностей новой базы. Практика показывает, что проходят годы, прежде чем СУБД начинает использоваться более менее полноценно.

Чуть больше месяца назад мы выпустили iOS-приложение «Тинькофф Инвестиции». Приложение полностью написано на языке Swift, но имеет некоторые Objective-C-зависимости. Продукт быстро начал обрастать новой функциональностью, а вместе с тем время сборки проекта существенно увеличивалось. Когда мы пришли к тому, что после clean или значительных правок проект собирался дольше шести минут, мы осознали, что перемены необходимы.


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

И в чем же проблема?

Я начал изучать React и Redux не так давно, но он уже успел изрядно потрепать мне нервы. Буквально над каждым действием приходится задумываться — почти никакие изменения в коде невозможны без того, чтоб что-то оторвать. Чтоб просто получить список постов по API и вывести их, надо, пожалуй, написать не меньше сотни строк кода — создать корневой контейнер, создать store, добавить action для запроса к API, для успешного результата запроса, для неудачного результата запроса, создать action-creators, сматчить action-creators и props, сматчить dispatch и props, написать reducer на каждый action… Ух, продолжать не хочется. И все это мы должны делать заново для каждого веб-приложения — крайне нерациональная трата сил программиста.

Да, можно сказать новичку: "Смотри, тут десяток пакетов, которые могут сделать каждое действие из этого списка вместо тебя. Выбирай и пользуйся!" Но проблема в том, что надо разобраться в настройке и воспользоваться десятком пакетов, позаботившись о том, чтоб они совпадали с версией, которая описана в документации и не вступали друг с другом в конфликты… Слишком сложно. Хочется чего-то проще, такого же простого, как в мире Django, из которого я пришел. Какой-то один пакет, после установки которого в store сами по волшебству складываются все нужные данные — бери и пользуйся.

Ну, я и решил — если такого решения нет, напишу-ка я его сам.

Постановка задачи

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

1. Делать асинхронный GET-запрос к REST API.
2. Анализировать полученные данные и данные, лежащие в store, и, если там не хватает связанных по foreign key данных, делать еще запросы.
3. Складывать полученные данные в store и следить за актуальностью хранящихся данных.

По описанию выходит, что состоять пакет будет из action creator'а, middleware и reducer'а.