В прошлом посте я делился своими скромными успехами в электронике, которые не тот момент ограничивались сборкой электронных схем на макетной плате без какой-либо пайки. Теперь же я буду хвастаться тем, как осилил делать что-то паяльником. Как, пожалуй, и в любом деле, при наличии правильной методички, коей, напомню, в моем случае является книга Чарльза Платта «Электроника для начинающих», дело это оказалось не таким уж и сложным.

Иногда бывает нужно синтегрироваться со Slack, Gitter, или подобного рода веб-чатом. Например, посылать в него сообщение при происшествии определенного события. К сожалению, подобные сервисы имеют сильно разные и иногда не слишком удобные для этих целей API. Зато многие, включая тот же Slack и Gitter, позволяют ходить в них по IRC. Более того, с помощью программы bitlbee по IRC можно ходить еще и в Skype, Jabber, Twitter и многое другое. Грех этим не воспользоваться.

Изучаю электронику по книжке Чарльза Платта Электроника для начинающих (в оригинале «Make: Electronics»). Это потрясающая книга, объясняющая, как делать свои электрические цепи из резисторов, диодов, конденсаторов и вот этого всего по принципу от простого к сложному. Что намного важнее, на Амперке, линк на который я привел выше, продаются готовые наборы к книге со всем необходимым. На момент написания этих строк я провел за книгой менее двух дней, и вот чего мне уже удалось собрать.

Данная статья представляет собой краткое руководство по использованию GnuPG (он же GPG). В ней вы найдете основные команды, примеры использования, а также инструкции по прикручиванию GPG к почтовым клиентам. Далее предполагается, что вы знакомы с принципом работы GPG и объяснять, например, что такое ассиметричная криптография, открытый и закрытый ключ, цифровая подпись и так далее, не требуется. За несколько десятилетий существования GPG никто особо не преуспел в его взломе, что как мы намекает нам, что это довольно надежное решение как для обмена зашифрованными сообщениями, так и просто шифрования файлов.

При разработке нового проекта в качестве основной СУБД нередко выбираются реляционные базы данных, такие, как PostgreSQL или MySQL. В этом действительно есть смысл. Первое время у проекта мало пользователей, и потому все данные помещаются в один сервер. При этом проект активно развивается. Нельзя заранее сказать, какой функционал в нем станет основным, а какой будет выкинут. Есть много историй о том, как мобильный дейтинг в итоге превращался в криптомессанджер, и подобного рода. РСУБД удобны на ранних этапах, потому что они универсальны. Так, PostgreSQL из коробки имеет встроенный полнотекстовый поиск, пространственные индексы, а также подходит для хранения очередей и рассылки уведомлений. По мере развития проекта и роста нагрузки часть данных может быть перенесена в специализированные NoSQL решения. Также нагрузку можно распределить, поделив базу на несколько совершенно не связанных между собой баз, а также при помощи потоковой репликации. Но что делать в случае, если все это не помогло? В этом посте я постараюсь ответить на данный вопрос.

Многие ошибочно полагают, что сеть Tor — это такой набор бесплатных (и очень медленных) прокси-серверов в обычный интернет. Такой вариант использования Tor, конечно же, возможен, но куда большая ценность «даркнета», на мой взгляд, заключается в его внутренних .onion ресурсах. Из этой статьи вы узнаете не только об обоих вариантах использования Tor, но и о том, как поднять собственный .onion ресурс, или как установить TCP-соединение через Tor, даже если клиент и сервер находятся за NAT.

Такие решения, как LXC и KVM, не всегда удобны, потому что они работают только под Linux. Используя их, вы не можете передать виртуалки пользователям каких-нибудь MacOS или Windows. По этой причине, а также потому что на практике у меня еще не возникало необходимости запускать больше пяти ВМ одновременно, я все еще предпочитаю VirtualBox. Им можно управлять из консоли при помощи Vagrant, но Vagrant всегда делал чуть-чуть не то, что мне на самом деле было нужно. Например, я хочу, чтобы по дэфолту все виртуалки всегда были в одной NAT-сети, без какой-либо правки Vagrantfile’ов. Все это сподвигло меня к изучению «родных» утилит VirtualBox, в частности, vboxmanage.

Рассмотрим типичную задачу. Есть программа на C или C++ с исходниками. Известно, что при выполнении определенных условий программа начинает отжирать слишком много памяти. Нужно понять, почему это происходит, и по возможности исправить. Инструменты, которые мы рассматривали до этого, например, в заметке Профилирование кода на C/C++ в Linux и FreeBSD, для этого явно не подходят. Спрашивается, что же тогда делать? На помощь приходит Heaptrack!

Сегодня мы поговорим об основах управления пакетами в Arch Linux. В общем и целом, идея напоминает ports и packages из мира FreeBSD. То есть, можно как компилировать софт из исходников, так и ставить бинарные пакеты. Но есть ряд существенных отличий. Итак, давайте же во всем разберемся!

Для PostgreSQL существует множество так называемых high availability решений, наиболее известными из которых, пожалуй, являются repmgr и patroni. Согласно некоторым отзывам, они не слишком удобны в использовании и иногда могут терять данные. Поэтому сегодня мне хотелось бы рассказать о более новом решении под названием Stolon. Разработка Stolon ведется с сентября 2015-го года. Он написан на языке Go, активно паразитирует на Consul или etcd (на выбор пользователя) и из коробки имеет интеграцию с Kubernetes. Но самое главное — он сравнительно прост в использовании и выглядит очень правильно с точки зрения дизайна системы. При правильном использовании Stolon переживает нетсплиты и не теряет данные.