На Хабре в свое время была статья о том, как вызвать Rust код из Go. Статья неплохая, но довольно сложная для понимания и на самом деле отталкивающая новичков от желания смотреть в сторону обоих языков. Цель этого поста не столько залезть в «кишки» кросс-языковых вызовов, сколько показать насколько просто это можно сделать.

Если кратко описать, что такое лексикографический порядок — это сортировка в алфавитном порядке. Т.е. последовательность символов — AAA → AAB → AAC → AAD → ……… → WWW — является отсортированной в алфавитном (или в нашем случае лексикографическом) порядке.

Представьте, что у Вас есть конечная последовательность символов, например 0, 1, 2, 5, 3, 3, 0 и Вам необходимо найти все возможные перестановки этих символов. Наиболее интуитивным, но и наибольшим по сложности, является рекурсивный алгоритм, когда мы выбираем первый символ из последовательности, далее рекурсивно выбираем второй, третий итд, до тех пор, пока все символы из последовательности не будет выбраны. Понятно, что сложность такого алгоритма — O(n!).

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

Если вы используете микро-сервисную архитектуру, то скорее всего знаете, что накладные расходы на коммуникацию между сервисами часто становятся значительной проблемой и если Вы сталкивались с этой проблемой, то скорее всего начали использовать один из RPC фреймворков поверх Protobuf, например, gRPC от Google или Go-Kit от Peter Bourgon или что-то другое. Пересказывать что это и как этим пользоваться нет смысла, все достаточно хорошо описано до меня. Я сам активно использую gRPC в своих проектах, но тут Twich решил выпустить свою реализацию protobuf Twirp. Если Вам интересно, зачем им это было нужно или чем она отличается проходите под кат.

При прохождения очередного собеседования мне задали небольшое тестовое задание, написать на Go сетевой сканер открытых портов. Задание в принципе не сложное, но одним из условий было, что в качестве параметра может быть передан как IP-адрес, так и диапазон сетевых адресов в виде сетевой маски: 192.168.8.0/21.

Тема скорее всего очень тривиальная для сетевых инженеров и администраторов и, наверно, даже скучная. Моя цель просто изложить тут алгоритм перевод диапазона IP в сетевую маску (дальше по тексту CIDR) и обратно из CIDR в диапазон адресов.

Docker начиная с версии 17.05 и выше стал поддерживать многоэтапные сборки (multi-stage builds). С удивлением обнаружил, что никто еще не написал об этом на хабре. Поэтому давайте исправим этот пробел.

Паттерн (CQRS — Command and Query Responsibility Segregation) разделяющей в своей основе команды по чтению данных от команд по их модификации или добавлению. Это позволяет достичь максимальную производительность, масштабируемость и безопасность, а также позволяет увеличить гибкость системы к модификациям с течением времени и снизить количество ошибок при усложнении логики системы, причиной которых обычно является обработка данных на доменном уровне.