Что может проще логирования??? Хочется сказать: автотесты! :-) Но автотесты регулярно запускаются. Некачественный подход в автотестировании проявляет себя в виде нестабильных тестов. А логирование - настоящая "серая лошадка". Проблемы в логе можно заметить, только при поддержке более-менее нагруженного проекта. В этой статье сравниваются разные подходы логирования, обращается внимание на тонкости, которые делают лог удобным для анализа работы системы.

Описаны различные способы получения профиля CPU. Объясняется смысл значений в профиле. Приводится пример анализа графа профиля CPU. На конкретных примерах обращается внимание на качественную природу профиля.

В Мире нет панацеи - лекарства от всех болезней. Так и в разработке нет идеальных решений. Многопоточность в некоторых случаях может значительно ускорить вычисления программы, но в то же время может превратиться в настоящий кошмар для разработчика. Не имеет смысла писать многопоточный код без умения пользоваться трассировкой. О способах её получения написано много материала. Более того, есть много статей, где анализ кода сопровождается с анализом трассировки. К сожалению, обычно этот инструмент используется под конкретную задачу, это приводит к тому, что обычно не подсвечиваются некоторые его особенности. В статье на простых очевидных примерах объясняются неочевидные результаты трассировки.

Эта статья посвящена каналам. Поднимается вопрос необходимости закрытия каналов. Приводится множество примеров, на escape-анализе и трассировке которых объясняются особенности сохранения каналов в памяти, взаимодействие с GC, горутинами. Также поднимается вопрос уместности закрытия каналов. Подсвечивается практическая польза использования однонаправленных каналов.

Доброго времени суток!

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

В этой статье хочется немного поговорить о паттернах, которые применяются в Go. Поэтому рассмотрим, так называемый, fan-in: попишем немного код и unit-тест.

Доброго времени суток!

Хочу предложить вниманию читателей немного поговорить о такой немодной теме, как REST API. Если не углубляться в различия между REST API и REST-подобным API, то с такой вещью имел дело каждый: от junior до senior. Более того, проходя собеседование, можно услышать вполне естественный вопрос: что такое REST API? Если сильно не задумываться, а лишь вспомнить, с чем имел дело, проектируя API очередного сервиса, то можно ответить: ну, там используется http 1.1. Также есть глаголы GET, PUT, POST, DELETE, PATCH и ещё некоторые. Каждый глагол отвечает за что-то одно: создание, изменение, удаление, чтение и т.д. В ответе используются коды ошибок: 200, 301, 401, 404, 500 и т.д. Каждый код обозначает, что всё прошло успешно, или возникли некоторые проблемы: нет прав, страница не найдена, внутренняя ошибка сервера и т.д. И в принципе, такой ответ нельзя назвать некорректным. Всё так, но он поверхностный - не отражает сути REST API. Без понимания сути сложно не допустить ошибку при проектировании. А для понимания необходимо осознать название REST API, то есть дать корректное определение.