четверг, 23 мая 2019 г.

Небольшой опыт с разработкой под Kotlin и Android 4

Недавно попробовал сделать нативное приложение по Android 4 на Kotlin.
В принципе, всё получилось и даже вышло скучнее чем ожидал. 95% времени заняло не ковыряние самого Kotlin - он-то оказался на редкость удобным и, по сравнению с разработкой на Java, - просто сверхскоростным. Производительность проца и памяти тоже не стала особой проблемой, как я ожидал (хотя приложение внутри юзало рекурсивный обход с отсечением, что довольно нагружало его).

воскресенье, 14 апреля 2019 г.

По следам мануала: RabbitMQ + cluster

RabbitMQ поддерживает полноценную сборку кластера. Однако, при её настройке стоит учитывать несколько особенностей.

пятница, 12 апреля 2019 г.

По следам мануала: RabbitMQ + federation

Ещё один мануал, по которому настраивал недавно - это мануал по обмену RabbitMQ через federation plugin. Задача та же - обмен сообщениями между хостом на Windows 10 и Ubuntu.

Полезные ссылки: E3PC

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

Ссылка.

Для удобства чтения лучше сразу сконвертировать в PDF.

четверг, 11 апреля 2019 г.

По следам мануала: Kafka

Решил  пройтись по мануалу по настройке Kafka, попробовав решив по сути хелловорлдную задачу: сделать передачу сообщений по сети, между двумя нодами (Windows 10  и Ubuntu 18.10).

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

суббота, 6 апреля 2019 г.

Flutter + Android = Awesome


Я довольно редко радуюсь какой-то хорошей либе, новому SDK, т.к. во многом опыт, в том числе и негативный, даёт о себе знать. Но иногда всё же появляются вещи, которые сначала вызывают скепсис, а потом начинают нравиться. Одной из таких вещей стал для меня Flutter.

суббота, 2 марта 2019 г.

Сетевая бессвязность или мысли о локалочках


Иногда, я думаю о том, что несмотря на сложившееся мнение о том, что открытое лучше закрытого, иногда гораздо проще и дешевле будет держать свою физическую локалку (даже не VPN, а именно физическую) и аккуратно давать к ней доступ, таким образом сохраняя "security by obscurity" и забив на большинство проблем, возникающих при открытой инфраструктуре (DDoS и иже с ним). К этому, временами, примешивается ещё и ностальгия по временам расцвета локалок и DC++.
Мысль довольно нубская и на мой взгляд, странная, поэтому решил подумать, разобраться и написать сей пост.