Недавно добавил оплату в свой Телеграм‑бот. После некоторых изысканий выбор пал на Тинькофф (ныне Т‑банк). Сам бот работает на php без вспомогательных библиотек. Возможно, кому‑то пригодится мой опыт и код. И бот.

По работе мне часто приходится рисовать разные схемы, диаграммы процессов и графики, в том числе и те, которые потом используются в качестве иллюстраций для сайта, статей и презентаций. Всё бы ничего, но есть у диаграмм и графиков, сделанных в популярных онлайн-сервисах наподобие draw.io или lucidcharts одна беда — они выглядят как-то слишком уныло и «олдскульно», в духе «90-х». Всю эту инфографику хотелось бы сделать более заметной, привлекательной и душевной (и, желательно, без привлечения дизайнера).

Так у меня возникла идея создания инструмента для отрисовки диаграмм и графиков в стиле «нарисовано от руки». Об истории создания сервиса и «подводных камнях» я расскажу в этой заметке.

Это глубокое погружение в управление памятью Java позволит расширить ваши знания о том, как работает куча, ссылочные типы и сборка мусора.

В прошлых двух статьях мы рассказывали об IIoT — индустриальном интернете вещей — строили архитектуру, чтобы принимать данные от сенсоров, паяли сами сенсоры. Краеугольным камнем архитектур IIoT да и вообще любых архитектур работающих с BigData является потоковая обработка данных. В ее основе лежит концепция передачи сообщений и очередей. Стандартом работы с рассылкой сообщений сейчас стала Apache Kafka. Однако, для того, чтобы разобраться в ее преимуществах (и понять ее недостатки) было бы хорошо разобраться в основах работы систем очередей в целом, механизмах их работы, шаблонах использования и основной функциональности.

Мы нашли отличную серию статей, которая сравнивает функциональность Apache Kafka и другого (незаслуженно игнорируемого) гиганта среди систем очередей — RabbitMQ. Эту серию статей мы перевели, снабдили своими комментариями и дополнили. Хотя серия и написана в декабре 2017 года, мир систем обмена сообщениями (и особенно Apache Kafka) меняется так быстро, что уже к лету 2018-го года некоторые вещи изменились.

Снова и снова, после проведения аудита, на мои рекомендации спрятать порты за white-list'ом встречаюсь со стеной непонимания. Даже очень крутые админы/DevOps'ы спрашивают: "Зачем?!?"

Предлагаю рассмотреть риски в порядке убывания вероятности наступления и ущерба.

1. Ошибка конфигурации
2. DDoS по IP
3. Брутфорс
4. Уязвимости сервисов
5. Уязвимости стека ядра
6. Усиление DDoS атак

Встретились Бяка и Бука.
Никто не издал ни звука.
Никто не подал и знака —
Молчали Бука и Бяка.

И Бука
Думал со скукой:
«Чего он так смотрит — букой?»
А Бяка думал:
«Однако
Какой он ужасный
Бяка…»

Разбираемся, что такое софт скилы и как не быть букой в 2022 году, хоть это и не просто

name?.length

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

Хотя люди обычно признают удобства ФП фич, ведь намного приятнее писать:

int Factorial(int n)
{
    Log.Info($"Computing factorial of {n}");
    return Enumerable.Range(1, n).Aggregate((x, y) => x * y);
}

чем ужасные императивные программы вроде

int Factorial(int n)
{
    int result = 1;
    for (int i = 2; i <= n; i++)
    {
        result *= i;
    }
    return result;
}

Так ведь? С одной стороны да. А с другой именно вторая программа в отличие от первой является функциональной.

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

В мире JVM про корутины знают в большей степени благодаря языку Kotlin и Project Loom. Хорошего описания принципа работы котлиновских корутин я не видел, а код библиотеки kotlin-coroutines совершенно не понятен неподготовленному человеку. По моему опыту, большинство людей знает о корутинах только то, что это "облегченные потоки", и что в котлине они работают через умную генерацию байткода. Таким был и я до недавнего времени. И мне пришла в голову идея, что раз корутины могут быть реализованы в байткоде, то почему бы не реализовать их в java. Из этой идеи, впоследствии, появилась небольшая и достаточно простая библиотека, в устройстве которой, я надеюсь, может разобраться практически любой разработчик. Подробности под катом.

В PostgreSQL есть два типа данных: JSON и JSONB. Первый формат является текстовым хранилищем, в котором json хранится "as is",  второй — бинарным, в нем ключи отсортированы  (сначала по длине ключа, а потом по его названию), дубликаты удалены, а пробелы удалены.

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

Однако у постгреса есть серьёзная проблема, которая сказывается и на производительности JSONB  — это TOAST, и о ней я говорил в первой части. Сегодня я расскажу о том, как мы улучшили JSONB для того, чтобы существенно повысить его производительность.

Это такое приятное чувство, когда ты закончил какую-то задачу. А особенно когда твой проект уже готов к релизу. Остался лишь последний шаг.

Публикация проекта в Maven Central, имеено об этом я расскажу в этой статье. Как настроить Gradle, чтобы потом без труда настроить CI.