RMarkdown, R и ggplot

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

Преамбула

Конференция это прежде всего доклады, и далеко не последнее место занимает то, как оформлены слайды доклада.

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

Пожалуй известные средства для создания слайдов это:

• PowerPoint, и вариации в лице LibreOffice Impress, Apple KeyNote
• облачные вариации с тем же подходом — Google Slides
• LaTeX
• и относительно новый (для меня) RMarkdown

• Сервер на Java в стиле микросервиса на основе Netty и JAX-RS (в реализации Resteasy) для обработки web-запросов, с возможностью запуска в Docker.
• Dependency Injection с использованием библиотеки CDI (в реализации Weld SE).
• Сборка javascript бандла с помощью Webpack 2.
• Настройка редеринга HTML на сервере с помощью React.
• Запуск отладки с поддержкой «горячей» перезагрузки страниц и стилей с использованием Webpack dev server.

При переходе к распределённым системам с большим количеством инстансов сервисов в полный рост встают проблемы их обнаружения (service discovery) и балансировки запросов (load balancing) между ними. Как правило, для их решения используются такие специализированные инструменты как Consul, Eureka или старый добрый Zookeeper, в сочетании с Nginx, HAProxy и некоторым мостом между ними (см. registrator).

Основная проблема в подобном подходе это большое количество интеграций, и, как следствие, точек где что-то может пойти не так. Ведь помимо вышеупомянутых решений наверняка будет использоваться локальный маленький PaaS (например Mesosphere Marathon или Kubernetes). Последние, к слову, уже хранят необходимую конфигурацию об окружении (ведь через них идёт весь деплоймент). И встаёт вопрос, а можем ли мы отказаться от специализированных инструментов для service discovery и переиспользовать тот же Marathon для этой задачи?

Краткий ответ — можем. Если интересно как — читайте дальше.

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

Люди часто спрашивают меня:
Зачем мне вообще использовать RxJava или Reactor, если то же самое можно сделать с помощью Streams, CompletableFutures и Optionals?

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

Давайте определим 8 критериев, которые помогут нам понять разницу между этими библиотеками и стандартными возможностями Java:

Ненадёжные тесты в Google

Вступление

Привет, хабраюзеры! Решил поведать вам о мини-библиотеке Jerminal. Я сейчас работаю над большим коммерческим проектом на Groovy/Java. Ну и мне пришло задание — написать консольку для приложения. К сожалению, было поставлено условие: никаких сторонних решений, все только свое. Недолго думая, я сел и написал ее. Подробнее — под катом.

Основной принцип программирования гласит: не изобретать велосипед. Но иногда, чтобы понять, что происходит и как использовать инструмент правильно, нам необходимо это делать. Сегодня изобретаем ConcrurrentHashMap.

Сперва нам понадобятся 2 вещи. Начнем с 2х тестов — первый скажет, что у нашей реализации нет data races (на самом деле нам нужно проверить, правилен ли наш тест также путем тестирования заведомо некорректной реализации), второй тест мы будем использовать для тестирования производительности с точки зрения throughput.

Больше изоленты!

Предлагаю читателям "Хабрахабра" перевод (возможно лучшей) статьи Kyle Kingsbury, a.k.a "Aphyr".

Давным-давно, на Шпицбергене, когда ты была юной ведьмочкой всего сорока трех лет, мама взяла в свои ладони твои еще не покрытые шрамами руки, и сказала:

Видрун, зачатая от морских ветров в верхушках елей,
Видрун, зелень моих ветвей, радость и ноша моих дней,
Видрун, всех вдохновенней и умней, да станет мудрость нашего клана твоей:
Никогда не читай Hacker News

В статьях про PVS-Studio всё чаще говорят об уязвимостях и дефектах безопасности, которые можно найти с помощью статического анализа. Авторов этих статей критикуют (и я в том числе), что не каждая ошибка является дефектом безопасности. Возникает однако интересный вопрос, можно ли пройти весь путь от сообщения статического анализатора до эксплуатации найденной проблемы и получения какой-то выгоды. В моём случае выгода всё же осталась теоретической, но эксплуатировать ошибку удалось, не особо вникая в код проекта.

Задачи

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

Представим, что у вас которая вызывает большую загрузку процессора:

public class Counter {

    public Double count(double a) {
        for (int i = 0; i < 1000000; i++) {
            a = a + Math.tan(a);
        }

        return a;
    }
}