Продолжаю цикл статей про использование Greenmask - инструмента, который написан на Go специально для безопасной работы с данными PostgreSQL: он помогает делать логические бэкапы, восстанавливать таблицы и при необходимости — анонимизировать чувствительную информацию.
В первой части описаны базовые сценарии использования данного инструмента, а в этой части опишу что такое database subsets и как использовать данный функционал для радикального снижения размера дампа базы данных.
Еще раз про gomock и тесты. Практики как можно писать тесты быстро, сохраняя их качество, при этом не лить горючие слезы.
Привет! Я Артур Давыдов, бэкенд разработчик в Здравсити. В этой статье хочу рассмотреть поведение defer более детально. Данную статья пишется в целях "попробовать себя", а так же, надеюсь, помочь кому-то разобраться с defer.
Привет, Хабр!
Сегодня разберём, как устроен reflect.Value изнутри и что на происходит, когда вы вызываете .Field(i).
Go — язык, который ценится за простоту и чёткость. Однако даже при минимальном синтаксисе здесь есть нюансы. Особенно это касается работы с функциями и методами. В этой статье хочу поделиться личными наблюдениями и выводами по нескольким ключевым темам: выбор типа получателя, использование именованных параметров результата, распространённые ошибки при возврате nil, проблемы с файлами в качестве входных данных и поведение defer.
ps. Обложку нейронка сгенерировала. Очень странно, но мне понравилось.
Привет, Хабр!
В статье рассмотрим, как реализовать Template Method-паттерн в Go без наследования, зачем он вообще нужен.
В данной статье представлен авторский подход к унификации и централизации механизма обработки ошибок в HTTP-обработчиках веб-сервисов, разработанных на языке Go. Статья подробно рассматривает ограничения традиционных методов обработки ошибок, ведущие к дублированию кода и снижению поддерживаемости. Предлагается новый архитектурный паттерн, включающий использование специализированной сигнатуры функций-обработчиков, кастомного типа ошибки HTTPError для инкапсуляции статуса ответа, сообщения для клиента и внутренней ошибки для логирования, а также Middleware-адаптера для интеграции с фреймворками net/http и Gin. Данный подход демонстрирует повышение читаемости кода, упрощение отладки и обеспечение консистентности ответов API, что представляет собой значимый вклад в практику разработки бэкенд-сервисов на Go.
Забудьте о том, что Docker — это некий таинственный инструмент исключительно для DevOps-инженеров. В современном мире разработки Docker стал таким же незаменимым швейцарским ножом, как Git или ваш любимый редактор кода. Он позволяет любому разработчику писать код, который будет одинаково работать на машине коллеги, на тестовом стенде и в продакшене, забыв о кошмаре "а у меня на машине все работает". Если вы еще не погрузились в мир контейнеризации или вам нужен удобный источник команд, эта статья — ваш экспресс-билет.
Всем привет! В данной статье я поделюсь своим опытом написания сервиса. Я не являюсь опытным или профессиональным разработчиком, я пишу свой проект и мои решения могут быть не самыми оптимальными. Эта статья состоит в основном из моих решений при написании сервиса, что могут быть не идеальными. Мой путь не является правильным и потому - судите "строго". Так же порекомендую прочитать предыдущие мои статьи.)
В настоящее время резко возрос спрос на контейнеры, используемые в продакшене для эксплуатации больших энтерпрайз-приложений. Как правило, они развёртываются в Docker. Docker де-факто стал основной технологией для работы с контейнеризованными приложениями. Но на основе чего он построен? Как он контейнеризует приложения? В данной статье постараемся ответить на эти вопросы.
Привет, Хабр!
Сегодня разберёмся, зачем Go-проекту слой Application / Use-Case: как он герметично изолирует бизнес-логику, позволяет переключаться между HTTP, gRPC, Cron-джобами и очередями, а заодно экономит тесты и нервные клетки.
Ошибки в приложениях неизбежны, но мы можем их смягчить и упростить отладку. Но как выбрать правильный способ обработки?
В этой статье предлагаю разобраться, как организовать работу с ошибками в Go так, чтобы они не просто сигнализировали о проблеме, но и помогали быстро её локализовать, воспроизвести и устранить. Рассмотрим инструменты и ограничения Go, обсудим подходы к обработке ошибок, а в финале сформулируем регламент, который поможет выбрать оптимальный способ работы с ошибками в разных сценариях.
Я структурировал способы обработки в зависимости от контекста — ситуации и типа программ, в которой возникает ошибка. Типы разделений — условные, в реальных задачах рекомендую опираться на требования к ошибке:
· Библиотека — узкоспециализированная программа, основной потребитель разработчик.
· Command Line Interface — консольные утилиты, где пользователем может быть кто угодно, а даже если это программист, то он не обязан понимать как CLI устроен внутри.
· Сервисы — Worker, WEB/API/RPC-сервисы и др.
Go не признаёт сложных развесистых фреймворков — и это правильно. Любой инструмент должен быть настолько очевидным, чтобы разработчики сразу видели пользу от его применения.
И если вы сталкивались на больших legacy-проектах с хаосом в обработке и логировании ошибок — когда одна и та же ошибка дублируется в логах на каждом уровне, когда непонятно где обрабатывать ошибку, а где передавать дальше, когда тесты превращаются в кромешный ад из-за необходимости мокать каждый возможный путь ошибки — тогда возможно пригодится то, что я хочу предложить.
В этой статье я хочу погрузиться в то, как работают некоторые структуры (далее ниже) в ГО. Хотя я и работаю с ГО уже 3й год, все равно есть вещи, в которые интересно погружаться. Хочу отметить, что я не буду погружаться прям сильно в реализацию того как устроены map и slice, скорее на столько, что бы понимать как они ведут себя и почему. Такое часто могут спрашивать на собеседованиях или это может писать более качественный и безопасный код.
Итак на сколько мы знаем (я надеюсь, что и вы читаете статью уже со знанием ГО) в ГО можно разделить типы переменных глобально на 2 группы
В эпоху становления асинхронного программирования JavaScript-разработчики столкнулись с явлением, получившим название "callback-hell" — бесконечной вложенностью функций обратного вызова. Хотя с точки зрения функционального программирования функции являются полноправными гражданами первого класса, принцип "всё хорошо в меру" никто не отменял. Появление Promise и механизма async/await стало спасительным решением этой проблемы.
В мире Go у нас есть более элегантные инструменты — каналы и горутины. Однако совершенству нет предела, и здесь нас поджидает другая ловушка — "error-hell". Новички в Golang часто приходят в недоумение от того, что идиомы языка требуют обработки ошибок буквально на каждом шагу.
Строки — одна из самых часто используемых структур данных в любом языке программирования. И в Go они повсюду: от простых приветствий вроде "Hello, World!" до сложных парсеров, логгеров и сетевых протоколов. На первый взгляд, с ними всё просто: создал, склеил, обрезал — и пошёл дальше. Но как это часто бывает, под простотой скрываются тонкости, игнорирование которых может привести к ошибкам и снижению производительности.
Go предлагает удобные, но специфичные механизмы работы со строками. Они тесно связаны с понятиями Unicode, UTF-8, рун, неизменяемости и байтовых представлений. Понимание этих механизмов позволяет не только избежать типичных подводных камней, но и писать более эффективный код.
Наверняка вам уже не раз попадалась на глаза статься, в которой рассказывают о том, какие пакеты и файлы нужно создать в вашем проекте, чтобы код получился легко расширяемым и поддерживаемым. Эта еще одна статья такого рода, посвященная декомпозиции проекта go на минимально зависимые друг от друга части. В качестве движущих сил декомпозиции будут использоваться следующие известные практики:
- архитектура слоев;
- предметно-ориентированное проектирование (DDD);
- разделение команд и запросов (CQS);
- архитектура портов и адаптеров.
Также будет затронута тема именования файлов .go и вопросы связности (low coupling/high cohesion).
Всем привет! В данной статье я поделюсь своим опытом написания сервиса. Я не являюсь опытным или профессиональным разработчиком, я пишу свой проект и мои решения могут быть не самыми оптимальными. Эта статья состоит в основном из ошибок, которые я совершил. Мой путь не является правильным и потому - судите "строго".
Go-разработчики часто сталкиваются с парадоксом: изначально простой и понятный проект со временем превращается в сложный для поддержки монолит.
✔️ Бизнес-логика оказывается размазана между слоями?
✔️ Замена базы данных требует переписывания половины кода?
✔️ Новым разработчикам требуется недели, чтобы разобраться в проекте?
В этой статье мы разбираем практическое применение DDD и Clean Architecture в Go. Обсуждаем возможный стандарт структуры микросервиса. Оптимизируем существующие.
🔥 Для разработчиков, которые хотят создавать проекты, остающиеся поддерживаемыми даже через годы развития.
