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



Обратите внимание, что эта статья является не дословным переводом оригинального документа (PDF), подготовленного Bilgin Ibryam — архитектором из Red Hat, активным участником нескольких проектов Apache и автором книг «Camel Design Patterns» и «Kubernetes Patterns», — а представляет основные его тезисы в довольно свободном изложении.

За последнее десятилетие я реализовал много проектов, связанных с агрегацией и анализом контента. Часто агрегация включает в себя снятие данных со сторонних сайтов, то есть скрапинг. Хотя я стараюсь избегать этого термина. Он превратился в некий ярлык, с которым связано много заблуждений. Основное заблуждение в том, что веб-скрапинг можно заблокировать с помощью X, Y, Z.

tl; dr; Нельзя.

С точки зрения бизнеса

На прошлой неделе я встретился с высокопоставленным руководителем из отрасли, в которой развиваю свой бизнес GO2CINEMA. Без сомнения, это один из самых умных и знающих людей в киноиндустрии.

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

Я посоветовался с этим человеком насчёт поиска инвестиций. Он предложил свою помощь и попросил подготовить анализ всех способов блокировки моего текущего бизнеса, включая скрапинг контента (с технической и юридической точек зрения). Я подготовил необходимые документы и поделился с ним перед нашей встречей. Его реакция была примерно такой:

Да, тщательное исследование. Но всё-таки есть способы, чтобы тебя заблокировать. *ухмыляется*

Нет, парень, нет таких способов.

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

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

Как вам может помочь эта статья

За прошедший год команда Insight приняла участие в работе над несколькими сотнями проектов, объединив знания и опыт ведущих компаний в США. Результаты этой работы они обобщили в статье, перевод которой сейчас перед вами, и вывели подходы к решению наиболее распространенных прикладных задач машинного обучения.

Мы начнем с самого простого метода, который может сработать — и постепенно перейдем к более тонким подходам, таким как feature engineering, векторам слов и глубокому обучению.

После прочтения статьи, вы будете знать, как:

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

Пост написан в формате пошагового руководства; также его можно рассматривать в качестве обзора высокоэффективных стандартных подходов.

Ссылка для скачивания

Последнюю половину года мы подробно обсуждали здесь новшества Java 10 и знаем их наизусть.

Но было бы странно, если самая главная Java-новость за полгода не появилась бы в этом хабе.

Как говорится, просто оставлю это здесь. Вперёд к приключениям!

Всем привет! Меня зовут Лёха, и я работаю бэкенд-разработчиком в FunCorp. Сегодня мы поговорим про реактивное программирование, библиотеку Reactor и немного про веб.

Реактивное программирование часто «подвергается упоминанию», но если вы (как и автор статьи) всё ещё не знаете, что это такое — устраивайтесь поудобнее, попробуем разобраться вместе.

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

Один из моих текущих проектов связан со сбором данных из GitHub-профилей разработчиков. Профили GitHub затруднительно использовать как источник данных, поэтому хочу сразу перечислить проблемы при попытке оценить разработчика только по его вкладу на GitHub.

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

Есть несколько правильных статей, почему нельзя требовать от кандидатов профили GitHub. Особенно рекомендую «Этика неоплачиваемого труда и сообщество Open Source» и «Почему GitHub — не резюме». Обе статьи отлично объясняют причины, почему при найме не следует спрашивать о вкладе в свободные проекты. Но я не о том, что это неэтично или что GitHub не слишком подходит для демонстрации проектов.

Я о том, почему эти профили просто малополезны.

Разреженность данных

Если посмотрите публичный профиль лучшего инженера-программиста, с которым я когда-либо работал, то увидите примерно такое:

Привет, Хабр! Представляю вашему вниманию перевод статьи "REST API Best Practices" автора Krishna Srinivasan.

REST становится общим подходом для представления сервисов окружающему миру. Причина его популярности заключается в его простоте, легкости использования, доступе через HTTP и другие. Существует неправильное представление о том, что все данные, доступные через сеть, считаются REST, но это не так. В этой статье я собираюсь объяснить вам некоторые best practices, которые вы должны всегда помнить при реализации собственного REST приложения. Я бы хотел услышать ваш опыт в REST приложениях, поэтому если вы знаете best practies, которые не упомянуты в этой статье, пожалуйста, поделитесь с нами в комментариях.

Disclamer: все best practies основаны на моем личном опыте. Если вы имеете другое мнение, не стесняйтесь отправлять его мне на email, и мы обсудим его.

Здесь представлен список best practices, которые будут обсуждаться в этой статье:

1. Конечные точки в URL – имя существительное, не глагол
2. Множественное число
3. Документация
4. Версия вашего приложения
5. Пагинация
6. Использование SSL
7. HTTP методы
8. Эффективное использование кодов ответов HTTP

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

— Что ты думаешь об интерфейсах?

— Имеешь в виду интерфейсы в Java или C#?

— Да. Классная фича этих языков?

— Просто великолепная!

— Правда? А что такое интерфейс? Это то же самое что и класс?

— Ну… Не совсем!

Про обратную связь, которая вызывает желание убивать

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

1. “Это непрофессионально...

Последние четыре года я работал разработчиком программного обеспечения в Google, но 1 февраля уволился, потому что они не сделали мне подарок на Рождество.

Шучу, на самом деле всё немного сложнее.

Первые два года

Первые два года я любил Google.

Когда при ежегодном опросе сотрудников мне задавали вопрос, вижу ли я себя в Google через пять лет, я отвечал «разумеется, без вариантов».

Ну конечно я буду в Google через пять лет. Я окружён лучшими инженерами в мире, использую самые продвинутые инструменты разработки в мире и кушаю самую бесплатную в мире еду.


Мой обычный день в Google.
— Ещё тортика, господин Программист? Он бесплатен в любом количестве.
— Не сегодня, Пьер. Я опаздываю на массаж, он тоже бесплатный.

Есть три типа наследования.

1. Онтологическое наследование указывает на специализацию: вот эта штука — специфическая разновидность той штуки (футбольный мяч — это сфера и у неё такой-то радиус).
2. Наследование абстрактного типа данных указывает на замещение: у этой штуки такие же свойства, как у той штуки, и такое-то поведение (это принцип подстановки Барбары Лисков).
3. Наследование реализации связано с совместным использованием кода: эта штука принимает некоторые свойства той штуки и переопределяет или дополняет их таким-то образом. Наследование в моей статье «О наследовании» именно такого и только такого типа.

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

Часто для наследования в ООП приводят контрпример отношений между квадратом и прямоугольником. Геометрически квадрат — это специализация прямоугольника: все квадраты — прямоугольники, но не все прямоугольники — квадраты. Все s в классе «Квадрат» являются прямоугольниками s, у которых длина равна ширине. Но в иерархии типов это отношение обратное: вы можете использовать прямоугольник везде, где используется квадрат (указав прямоугольник с одинаковой шириной и высотой), но нельзя использовать квадрат везде, где используется прямоугольник (например, вы не можете изменить длину и ширину).

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

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

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

В этой статье — истории реальных программистов и их профессиональных фобий, которые мешали им жить и работать в свое удовольствие. Люди реальные, имена вымышленные.

Это выступление состоялась 12 октября 2017 года на конференции Mirror Conf в Браге (Португалия) и ещё раз 9 февраля 2018 года на Awwwards Conference в Берлине.

Этим летом после лекции на веб-конференции у меня состоялась увлекательная беседа с молодой студенткой, которая изучает цифровой дизайн. Было интересно сравнить наши карьерные пути. У меня пятнадцать лет опыта дизайна для веб-клиентов, у неё — один год, но каким-то образом мы оказались в одинаковой ситуации: мы наслаждались работой, но были совершенно дезориентированы и обескуражены быстро растущей сложностью всего вокруг. Что за ерунда произошла? (Конечно, это риторический вопрос).

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

В 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-парсера.

Существует несколько парсеров, подходящих для русского языка. Некоторые из них могут даже выполнять синтаксический анализ, как SyntaxNet, MaltParser и AOT:

… или выявлять факты, как Tomita.

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

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

Когда-то мы уже рассказывали о том, как появился и развивался машинный перевод. С тех пор произошло ещё одно историческое событие – его наконец-то покорили нейронные сети и глубокое обучение. Среди задач обработки естественного языка (Natural Language Processing, NLP) машинный перевод одним из первых получил строгое статистическое основание — еще в начале 1990-х. Но в сфере глубокого обучения он оказался относительно запоздавшим участником. В этом посте мы — команда Яндекса по машинному переводу — обсуждаем, почему это заняло так много времени и какие новые возможности открыл машинный перевод на основе нейросетей.

Мы также будем рады ответить на вопросы на встрече «Яндекс изнутри: от алгоритмов до измерений — в Переводчике, Алисе и Поиске» 1 марта (можно зарегистрироваться или задать вопрос в чате трансляции).

Фразовый машинный перевод

Всего три года назад почти все серьезные промышленные и исследовательские системы машинного перевода были построены с использованием конвейера статистических моделей («фразовый машинный перевод», ФМП), в котором нейронные сети не участвовали. Фразовый машинный перевод впервые сделал машинный перевод доступным для массового пользователя в начале 2000-х годов. При наличии достаточного количества данных и достаточных вычислительных ресурсов ФМП позволял разработчикам создавать системы перевода, которые в основном давали представление о смысле текста, но изобиловали грамматическими, а иногда и семантическими ошибками.

В мире существует множество клёвых маленьких библиотек, которые как бы и не знаменитые, но очень полезные. Идея в том, чтобы потихоньку знакомить Хабр с такими вещами. Сегодня расскажу о JavaParser.

JavaParser — это набор инструментов для парсинга, анализа, трансформации и генерации Java-кода. Иначе говоря, если нужно взять кусок джавакода и как-то его покорёжить подручными методами и без необходимости в особых знаниях, эта либа — самое то.

Где-то посреди статьи вы ВНЕЗАПНО можете осознать, какой кошмар и ужас можно сотворить этой либой, и никак не дождётесь дочитать текст и полить меня гневными комментариями. Не сдерживайтесь, не стоит — сразу скрольте до самого низу и изливайте душу :)

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

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

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

На написание этой статьи меня сподвигла некоторая разрозненность источников информации по такой
важной, на мой взгляд, теме, как публикация своих артефактов в Maven Central. Конечно, следует
отдать должное сотрудникам Sonatype: их официальный гайд (ссылка в конце статьи) достаточно полно
описывает весь процесс. Но в нём нет некоторых неочевидных тонкостей (вроде проблемы хранения
паролей), и он сам выглядит немного неряшливо. На русском же языке на эту тему ресурсов я не нашёл в
принципе. Лично для меня это не страшно, но многих это может остановить.