Недавно добавил оплату в свой Телеграм‑бот. После некоторых изысканий выбор пал на Тинькофф (ныне Т‑банк). Сам бот работает на php без вспомогательных библиотек. Возможно, кому‑то пригодится мой опыт и код. И бот.
Software Engineer
Как я «напрограммировал» себе скилл рисования диаграмм в скетч-стиле
По работе мне часто приходится рисовать разные схемы, диаграммы процессов и графики, в том числе и те, которые потом используются в качестве иллюстраций для сайта, статей и презентаций. Всё бы ничего, но есть у диаграмм и графиков, сделанных в популярных онлайн-сервисах наподобие draw.io или lucidcharts одна беда — они выглядят как-то слишком уныло и «олдскульно», в духе «90-х». Всю эту инфографику хотелось бы сделать более заметной, привлекательной и душевной (и, желательно, без привлечения дизайнера).
Так у меня возникла идея создания инструмента для отрисовки диаграмм и графиков в стиле «нарисовано от руки». Об истории создания сервиса и «подводных камнях» я расскажу в этой заметке.
Управление памятью Java
Это глубокое погружение в управление памятью Java позволит расширить ваши знания о том, как работает куча, ссылочные типы и сборка мусора.
Вопросы для собеседования бэкенд-разработчика
Я не большой любитель задавать технические вопросы на собеседованиях: по мне так лучше посидеть с кандидатом (или кандидаткой) за клавиатурой над каким-то реальным кодом, реальной проблемой — и целый день заниматься парным программированием, желательно поочерёдно с остальными членами команды. Но я считаю, что некоторые технические вопросы могут быть хорошей отправной точкой для начала увлекательного и приятного разговора и позволят глубже узнать друг друга.
В этом репозитории собран ряд вопросов, связанных с серверной частью, которые можно использовать при проверке потенциальных кандидатов. Ни в коем случае не рекомендуется задавать все вопросы одному кандидату: это займет несколько часов и вообще не имеет смысла, потому что они охватывают слишком широкий спектр тем. Никто не может знать всего. Выберите наиболее актуальный раздел и самые интересные вопросы, чтобы развернуть беседу.
RabbitMQ против Kafka: отказоустойчивость и высокая доступность в кластерах
Отказоустойчивость и высокая доступность — большие темы, так что посвятим RabbitMQ и Kafka отдельные статьи. Данная статья о RabbitMQ, а следующая — о Kafka, в сравнении с RabbitMQ. Статья длинная, так что устраивайтесь поудобнее.
Рассмотрим стратегии отказоустойчивости, согласованности и высокой доступности (HA), а также компромиссы, на которые приходится идти в каждой стратегии. RabbitMQ может работать на кластере узлов — и тогда классифицируется как распределенная система. Когда речь заходит о распределенных системах, мы часто говорим о согласованности и доступности.
Эти понятия описывают, как система ведет себя при сбое. Сбой сетевого соединения, сбой сервера, сбой жесткого диска, временная недоступность сервера из-за сборки мусора, потеря пакетов или замедление сетевого соединения. Все это может привести к потере данных или конфликтам. Оказывается, практически невозможно поднять систему, одновременно и полностью непротиворечивую (без потери данных, без расхождения данных), и доступную (будет принимать операции чтения и записи) для всех вариантов сбоя.
Почему Event Sourcing — это антипаттерн для взаимодействия микросервисов
Последнее время получают распространение событийно-ориентированные архитектуры (event-driven architectures) и, в частности, Event Sourcing (порождение событий). Эта вызвано стремлением к созданию устойчивых и масштабируемых модульных систем. В этом контексте довольно часто используется термин “микросервисы”. На мой взгляд, микросервисы — это всего лишь один из способов реализации “ограниченного контекста” (Bounded Context). Очень важно правильно определить границы модулей и в этом помогает стратегическое проектирование (Strategic Design), описанное Эриком Эвансом в Domain Driven Design. Оно помогает вам идентифицировать / обнаружить модули, границы (“ограниченный контекст”) и описать, как эти контексты связаны друг с другом (карта контекстов, ContextMap).
RabbitMQ против Kafka: два разных подхода к обмену сообщениями
В прошлых двух статьях мы рассказывали об IIoT — индустриальном интернете вещей — строили архитектуру, чтобы принимать данные от сенсоров, паяли сами сенсоры. Краеугольным камнем архитектур IIoT да и вообще любых архитектур работающих с BigData является потоковая обработка данных. В ее основе лежит концепция передачи сообщений и очередей. Стандартом работы с рассылкой сообщений сейчас стала Apache Kafka. Однако, для того, чтобы разобраться в ее преимуществах (и понять ее недостатки) было бы хорошо разобраться в основах работы систем очередей в целом, механизмах их работы, шаблонах использования и основной функциональности.
Мы нашли отличную серию статей, которая сравнивает функциональность Apache Kafka и другого (незаслуженно игнорируемого) гиганта среди систем очередей — RabbitMQ. Эту серию статей мы перевели, снабдили своими комментариями и дополнили. Хотя серия и написана в декабре 2017 года, мир систем обмена сообщениями (и особенно Apache Kafka) меняется так быстро, что уже к лету 2018-го года некоторые вещи изменились.
Не открывайте порты в мир — вас поломают (риски)
Снова и снова, после проведения аудита, на мои рекомендации спрятать порты за white-list'ом встречаюсь со стеной непонимания. Даже очень крутые админы/DevOps'ы спрашивают: "Зачем?!?"
Предлагаю рассмотреть риски в порядке убывания вероятности наступления и ущерба.
- Ошибка конфигурации
- DDoS по IP
- Брутфорс
- Уязвимости сервисов
- Уязвимости стека ядра
- Усиление DDoS атак
Софт скилы или как не быть бякой и букой
Встретились Бяка и Бука.
Никто не издал ни звука.
Никто не подал и знака —
Молчали Бука и Бяка.
И Бука
Думал со скукой:
«Чего он так смотрит — букой?»
А Бяка думал:
«Однако
Какой он ужасный
Бяка…»
Разбираемся, что такое софт скилы и как не быть букой в 2022 году, хоть это и не просто
NoSQL базы данных: понимаем суть
Kotlin и autoboxing
А зря, т.к. недавно общаясь с одним из своих коллег, который как раз прочитал одну из статей по Котлину с обзором основных фич, доказывал мне что null-safety зло и реализовано через обработку исключения, т.е. выполняя код:
name?.length
компилятор просто оборачивает вызов в try-catch, пытаясь поймать NullPointerException.
Аналогично другой товарищ после очередного обзора считал, что раз var есть в Kotline, как и в JS, то типизация и там и там динамическая, да и вообще «все эти ваши var/val зло, ничего не понятно, хорошо, что их в Java нет». Say hello, JEP286!
Еще один неудачный пример популяризации языка случился недавно, когда на одной из презентаций по Котлину сам автор доклада не совсем корректно описал работу языка, связанную с примитивами из Java, рассказывая о том, что в Котлине всегда будут использоваться ссылочные типы. Об этом и хотелось бы рассказать поподробней.
Функциональное программирование — это не то, что нам рассказывают
Функциональное программирование — это очень забавная парадигма. С одной стороны, про неё все знают, и все любят пользоваться всякими паттерн матчингами и лямбдами, с другой на чистом ФП языке обычно мало кто пишет. Поэтому понимание о том, что же это такое восходит больше к мифам и городским легендам, которые весьма далеко ушли от истины, а у людей складывается мнение, что "ФП подходит для всяких оторванных от жизни программок расчетов фракталов, а для настоящих задач есть зарекомендовавший себя в бою проверенный временем ООП".
Хотя люди обычно признают удобства ФП фич, ведь намного приятнее писать:
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;
}
Так ведь? С одной стороны да. А с другой именно вторая программа в отличие от первой является функциональной.
Как же так, разве не наоборот? Красивый флюент интерфейс, трансформация данных и лямбды это функционально, а грязные циклы которые мутируют локальные переменные — наследие прошлого? Так вот, оказывается, что нет.
DIY Корутины. Часть 1. Ленивые генераторы
В мире JVM про корутины знают в большей степени благодаря языку Kotlin и Project Loom. Хорошего описания принципа работы котлиновских корутин я не видел, а код библиотеки kotlin-coroutines совершенно не понятен неподготовленному человеку. По моему опыту, большинство людей знает о корутинах только то, что это "облегченные потоки", и что в котлине они работают через умную генерацию байткода. Таким был и я до недавнего времени. И мне пришла в голову идея, что раз корутины могут быть реализованы в байткоде, то почему бы не реализовать их в java. Из этой идеи, впоследствии, появилась небольшая и достаточно простая библиотека, в устройстве которой, я надеюсь, может разобраться практически любой разработчик. Подробности под катом.
Борьба с TOAST или будущее JSONB в PostgreSQL
В PostgreSQL есть два типа данных: JSON и JSONB. Первый формат является текстовым хранилищем, в котором json хранится "as is", второй — бинарным, в нем ключи отсортированы (сначала по длине ключа, а потом по его названию), дубликаты удалены, а пробелы удалены.
Тип JSONB имеет богатую поддержку, облегчающую работу разработчиков приложений, для него есть встроенные индексы, кроме того, существует расширение Jsquery, в котором реализован язык запросов к JSONB и дополнительные индексы. Когда у меня спрашивают, чем пользоваться, я всегда советую JSONB, так как он позволяет работать очень эффективно.
Однако у постгреса есть серьёзная проблема, которая сказывается и на производительности JSONB — это TOAST, и о ней я говорил в первой части. Сегодня я расскажу о том, как мы улучшили JSONB для того, чтобы существенно повысить его производительность.
Как устроены базы данных
Эта статья родилась не от хорошей жизни. Часто даже не то что начинающие разработчики, но и вполне продвинутые, не знают каких-то базовых вещей — может быть, давно учились в университете и с тех пор забыли, или им не приходилось углубляться в теорию, поскольку и так работалось нормально.
Тем не менее, теоретические знания иногда полезно освежить. Этим мы, в том числе, и займемся.
О спикере: Илья Космодемьянский CEO и консультант в компании Data Egret, специалист по базам данных PostgreSQL, Oracle, DB2. А кроме того, отвечает за продвижение Postgres-технологий, выступает на конференциях и рассказывает людям, как с ними работать.
Ниже материал по докладу Ильи на РИТ++ 2017, который не был связан с какой-то конкретной базой данных, но охватывал многие основные аспекты.
Юнит-тестирование для чайников
То что вы делаете, называется интеграционным тестированием. Современные приложения достаточно сложны и содержат множество зависимостей. Интеграционное тестирование проверяет, что несколько компонентов системы работают вместе правильно.
Оно выполняет свою задачу, но сложно для автоматизации. Как правило, тесты требуют, чтобы вся или почти вся система была развернута и сконфигурирована на машине, на которой они выполняются. Предположим, что вы разрабатываете web-приложение с UI и веб-сервисами. Минимальная комплектация, которая вам потребуется: браузер, веб-сервер, правильно настроенные веб-сервисы и база данных. На практике все еще сложнее. Разворачивать всё это на билд-сервере и всех машинах разработчиков?
Публикуем проект с помощью Gradle и Sonatype в Maven Central без рук
Это такое приятное чувство, когда ты закончил какую-то задачу. А особенно когда твой проект уже готов к релизу. Остался лишь последний шаг.
Публикация проекта в Maven Central, имеено об этом я расскажу в этой статье. Как настроить Gradle, чтобы потом без труда настроить CI.
Information
- Rating
- Does not participate
- Location
- Минск, Минская обл., Беларусь
- Date of birth
- Registered
- Activity