Ранее мы научились писать модульные тесты на языке Go и измерять степень покрытия кода тестами. Также недавно мы познакомились с GitHub Actions и узнали, как с его помощью автоматически собирать и тестировать проект. Казалось бы, проверять code coverage при помощи GitHub Actions должно быть проще простого. Используем материалы двух предыдущих статей, и готово! Но если бы все было так банально, вы бы сейчас не читали эти строки.

GitHub Actions — это CI/CD система, интегрированная с GitHub. В первом приближении можно думать о ней, как об аналоге TeamCity или Jenkins, предоставляемом в виде сервиса. Сервис бесплатен для открытых проектов, и даже для закрытых, если ваши билды собираются не слишком долго и/или не слишком часто.

Большинство современных приложений представляют собой распределенные системы. Допустим, ваша компания делает «просто» приложение для мобильных устройств. Но помимо самого приложения, с которым работает пользователь, наверняка есть и какой-то сервер-сайд. Он состоит из балансировщиков нагрузки (например, Nginx), некоторого количества микросервисов, а те в свою очередь ходят в некие СУБД (PostgreSQL), кэши (Redis, Memcached) и service discovery (Consul). СУБД скорее всего крутится не на одном сервере, а имеет энное количество реплик — для распределения нагрузки, аналитики и снятия бэкапов. По моему скромному опыту, многие люди не сильно задумываются над проблемами, которые могут возникать в подобных системах. Давайте же выясним, что это за проблемы.

Время от времени возникает задача нарисовать картинку с некой математической формулой. Есть больше одного решения этой проблемы. Сегодня мне хотелось бы рассказать о решении, которое мне лично кажется наиболее простым и при этом достаточно универсальным. Оно заключается в использовании штуки под названием AsciiMath.

PlantUML — это открытый (GPL) кроссплатформенный (написан на Java) инструмент для построения UML-диаграмм из текстового описания. Можно думать о нем, как о Graphviz, только для UML, а не для графов. Помимо UML-диаграмм PlantUML поддерживает и некоторые другие виды диаграмм, например, диаграммы Гантта. В целом, это довольно полезный инструмент, когда нужно по-быстрому нарисовать картинку для какой-нибудь документации или чего-то такого. Давайте рассмотрим использование PlantUML на нескольких примерах.

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

Определение степени покрытия кода тестами — это очень-очень важно как минимум по двум причинам. Во-первых, с его помощью вы проверяете, что тесты выполняют каждую из написанных вами строк кода хотя бы один раз. Если это не так, скорее всего, у вас довольно фиговые тесты. Во-вторых, вы можете найти «мертвый» код, который на самом деле никогда не выполняется, и выкинуть его. Сегодня мы выясним, как посмотреть code coverage в программах, написанных на языке C или C++.

При написании кода на C и C++ люди допускают ошибки. Многие из этих ошибок находятся благодаря -Wall, ассертам, тестам, дотошному code review, предупреждениям со стороны IDE, сборкой проекта разными компиляторами под разные ОС, работающие на разном железе, и так далее. Но даже при использовании всех этих мер ошибки часто остаются незамеченными. Немного улучшить положение дел позволяет статический анализ кода. В этой заметке мы познакомимся с некоторыми инструментами для произведения этого самого статического анализа.

Многие скажут, что сегодня я выступаю в роли Капитана Очевидности, и будут совершенно правы. Тем не менее, в разных мейлинг листах и чятиках то и дело появляются люди с вопросами типа «посоветуйте мне идеальную базу данных, а то у меня SQL тормозит и вообще все говорят, что MongoDB сейчас в моде». C 2007-го года я успел поработать со многими СУБД, не исключая ряда NoSQL решений, и по данному вопросу я имею сказать следующее.

Не могу сказать, что я большой фанат Subversion. По-моему, Git прекрасен, и никакие другие системы контроля версий не нужны. Тем не менее, работать с Subversion время от времени приходится, потому что нужно сделать checkout какого-то древнего полумертвого проекта или еще почему-то. Так что, в этой заметке мы рассмотрим основы работы с Subversion, ну и заодно почему он иногда может быть даже интереснее, чем Git. Заметка рассчитана на тех, кто уже имеет опыт использования Git или хотя бы Mercurial.