Я тебя знаю как разработчика Sphinxsearch, но, как показывает твоя краткая биография, которую ты дал в описании доклада, похоже компьютерная графика — твоя главная страсть?

1. Прямоугольник и квадраты
2. Нули и единицы
3. Новая трасса
4. Дерево
5. Варвары

А что если я скажу вам, что новый продукт можно сразу начинать писать на микросервисной архитектуре, а не заниматься распилом монолита? Это вообще нормально? Удобно? Хотите узнать ответ?

Задача: необходимо написать за выходные (время ограниченно 10-15 часами) сферический блог на микросервисах, на php, не используя никаких фреймворков. Можно пользоваться здравым смыслом. А еще забудем о том что такое фронтенд и вспомним что мы жить не можем без виртуализации. Выберем Docker. Интересно? Вперед под кат.

Это вторая статья в цикле про создание и использование скриптов для веб-скрейпинга на Node.js.

1. Web scraping при помощи Node.js
2. Web scraping на Node.js и проблемные сайты
3. Web scraping на Node.js и защита от ботов
4. Web scraping обновляющихся данных при помощи Node.js

В первой статье разбиралась простейшая задача из мира веб-скрейпинга. Именно такие задачи достаются веб-скрейперам в подавляющем большинстве случаев – получение данных с незащищённых HTML-страниц стабильно работающего сайта. Быстрый анализ сайта, HTTP-запросы при помощи needle (организованные при помощи tress), рекурсивный проход по ссылкам, DOM-парсинг при помощи cheerio – вот это вот всё.

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

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

Если вы следите за этим блогом, то помните, что в последнее время я пишу (и говорю) о CDI (Contexts and Dependency Injection). У CDI много аспектов, но до сих пор я акцентировал внимание на том, как начать работу с CDI в вашем окружении и как интегрировать CDI в существующее Java EE 6 приложение, а затем сфокусировался на внедрении зависимостей в CDI. Это уже третий пост про внедрение в CDI: в первом я рассказывал о внедрении по умолчанию и спецификаторах, во второй о всех возможных точках внедрения (поле, конструктор, сеттер). В этом посте я расскажу о продюсерах или "как вы можете типобезопасным способом внедрять что угодно и куда угодно".

Это второй пост о внедрении зависимостей в CDI (Часть 1) после нашего разговора о том, как начать работу с CDI в вашем окружении и как интегрировать CDI в существующее Java EE 6 приложение. В этом посте я хочу рассказать о различных точках внедрения в CDI: поле, конструктор и сеттер. Для этого я буду использовать часть предыдущего примера: внедрение POJO генератора ISBN в сервлет.

После статьи о том, как начать работу с CDI в вашем окружении и нескольких советов о том, как интегрировать CDI в существующее Java EE 6 приложение, я хочу поговорить о внедрении зависимостей. Да, о простом внедрении или о том, как провести внедрение одного бина в другой. Из этой серии трех статей (Часть 2, Часть 3) вы увидите, что есть множество различных способов: давайте начнем с самого простого — обыкновенного внедрения.

Недавно ко мне обратился друг с просьбой написать бота, импортирующего новости из RSS-канала на сайте в Telegram-канал. Огромнейшим плюсом данного способа оповещения являются push-уведомления, которые приходят каждому подписанному пользователю на его устройство. Уже давно хотелось заняться чем-то подобным. Недолго думая, в качестве образца я выбрал канал Хабра telegram.me/habr_ru. В качестве языка программирования был выбран Python.

Скучное вступление

Проблема. Становится интересней