Записки программиста

Недавно по работе я занимался проработкой небольшой tech story. Сторя распалась на несколько задач, связанных отношением «задача А блокирует задачу Б». Стало интересно, как это будет смотреться на диаграмме Ганта, или хотя бы в виде простого графа. Но оказалось, что из коробки Jira такой возможности не предоставляет. Опрос знакомых на предмет готового решения результатов не дал. Тогда было решено написать небольшой скрипт на Python.

Ранее мы научились писать модульные тесты на языке 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 решений, и по данному вопросу я имею сказать следующее.