🐰 Топ-вакансий для Go-разработчиков за неделю

Senior Golang-разработчик — от 300 000 ₽, Офис (Москва)

Golang Developer — от 210 000 ₽, Удаленно/Офис (Питер)

Golang наставник — от 350 000 ₽, Гибрид/Офис (Воронеж)

Hotel Search Team Lead — от 6 400 $, Удаленно

Бустер — удалённо (не только Москва)

➡️ Еще больше топовых вакансий — в нашем канале Go jobs

🔠 Команда Go рассказала о выявленных уязвимостях в криптобиблиотеке

В ходе аудита библиотеки TOB Crypto команда Go обнаружила несколько важных технических уязвимостей, включая ошибки в обработке ключей и недостатки в управлении памятью.

Также выявили места с возможными рисками тайминговых атак из-за недостаточно защищённых операций.

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

➡️ Блог команды разработки Go

🐸Библиотека Go-разработчика #свежак

💻 HTML-санитайзер

Bluemonday — это инструмент для очистки HTML-контента. Его главная задача — защитить веб-приложения от атак типа Cross-Site Scripting (XSS), удаляя из пользовательского ввода потенциально опасные теги и атрибуты.

Bluemonday использует политики на основе allowlist, позволяя контролировать, какие элементы остаются в HTML, а какие — удаляются.

Встроенные политики уже оптимизированы для типичных сценариев, например, для обработки пользовательского контента.

Инструмент интегрируется в Go-проекты и поддерживает разные форматы ввода, от строк до потоков.

Чтобы избежать уязвимостей, важно применять инструмент на последнем этапе обработки и с осторожностью настраивать политики.

Пример очистки пользовательского контента с помощью стандартной политики UGC:

import (
    "fmt"
    "github.com/microcosm-cc/bluemonday"
)

func main() {
    p := bluemonday.UGCPolicy()  // Политика для пользовательского контента
    dirtyHTML := `<a href="http://example.com" onclick="alert('XSS')">Ссылка</a><script>alert('bad')</script>`
    cleanHTML := p.Sanitize(dirtyHTML)
    fmt.Println(cleanHTML)
}

Результат:

<a href="http://example.com" rel="nofollow">Ссылка</a>

Вредоносный <script> и атрибут onclick удалены, добавлен rel="nofollow" для безопасности.

💬 Используете ли вы подобные санитайзеры, фреймворки безопасности или собственные решения? Делитесь тулзами в комментариях 👇

📎 Репозиторий проекта

🐸Библиотека Go-разработчика #буст

🐸Библиотека Go-разработчика #развлекалово

🎮 Игра на Go: от меню до победы

Если вы пишете на Go, но устали от серверного кода и CLI-интерфейсов — то мы нашли для вас видео, в котором с нуля реализован классический «Сапёр».

В основе проекта лежит библиотека Raylib с Go-обвязкой, которая обеспечивает простой API для работы с окнами, текстом, мышью и отрисовкой.

➡️ Смотреть видео

🐸Библиотека Go-разработчика #буст

✏️ Технические решения в команде

Недавно один из подписчиков спросил:

Как вы подходите к принятию технических решений в команде?

Технические решения — это не просто выбор между «правильно» и «неправильно». Это баланс между бизнес-целями, техническими ограничениями, ресурсами и человеческими факторами.

В каждой команде свой стиль, инструменты и методики, но есть общие практики, которые помогают выработать эффективный подход.

1️⃣ Сбор информации и формулирование проблемы

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

2️⃣ Вовлечение команды

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

3️⃣ Структурирование обсуждения

Для упрощения выбора полезно использовать визуализации — схемы, диаграммы, прототипы. Формальные практики, такие как технические или архитектурные ревью, помогают систематизировать процесс и задокументировать принятые решения.

4️⃣ Принятие решения и достижение консенсуса

В идеале — это компромисс, основанный на аргументах и фактах. Иногда необходимо голосование или прототипирование, чтобы проверить гипотезы на практике.

В ситуациях разногласий роль лидера — принять окончательное решение и донести логику до команды.

5️⃣ Анализ и ретроспектива

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

Открытость, структурированность и последующий анализ — вот основные принципы, которые помогают команде работать эффективно и с минимальными конфликтами.

💬 Какие методы принятия технических решений работают в вашей команде? Ждём ваши ответы в комментариях 👇

P.S. Напоминаем, вы можете спросить сообщество библиотеки Go разработчика и не только! Самые интересные вопросы обязательно опубликуем.

🐸Библиотека Go разработчика #междусобойчик

👨‍💻 Сборка только с необходимым

В процессе разработки и деплоя Go-программ в продакшн-среду важно минимизировать зависимости и размер итогового бинарного файла.

Команда, которая компилирует программу с минимальным размером и включает все зависимости статически:

go build -ldflags="-s -w -extldflags '-static'"

-s: удаляет информацию о символах (символьные таблицы и отладочную информацию), что сокращает размер бинарника.

-w: исключает таблицу отладочных данных, еще больше уменьшая размер.

-extldflags '-static': компилирует все внешние зависимости в статически слинкованный бинарник, чтобы он не зависел от библиотек на целевой системе (особенно полезно в контейнерах).

Эта команда полезна для создания приложений, которые должны быть максимально легкими, независимыми и готовыми к деплою в такие среды, как Docker или другие облачные платформы.

🐸Библиотека Go разработчика #буст

🐸Библиотека Go разработчика #развлекалово

👨‍💻 Какой фреймворк выбрать для Go

Go славится своей простотой, скоростью и лаконичностью. Многие разработчики считают, что «чистый net/http — это и есть фреймворк». Но всё больше проектов строятся на готовых решениях: Gin, Fiber, Echo.

Так стоит ли вообще использовать фреймворк в Go — или лучше идти по пути минимализма?

🔧 Когда стоит выбрать фреймворк:

• Нужно быстро MVP. Меньше кода — больше результата. Тогда Gin или Fiber экономят время.

• Команда новичков в Go. Фреймворки помогают с организацией кода, предлагают готовые паттерны.

• Проект типовой: REST API, простая маршрутизация, CRUD. Нет смысла писать всё руками.

• Не хочется собирать инфраструктуру самому. Логгеры, middleware, CORS — всё уже есть.

⚙️ Когда лучше писать на «голом» net/http:

• Долгосрочный проект. Чем меньше зависимостей — тем проще поддерживать.

• Нужен полный контроль. Нет «магии», всё прозрачно и предсказуемо.

• Следуете философии Go. Чем проще и очевиднее — тем лучше.

• Хочется писать идиоматично. Стандартная библиотека Go — это уже почти идеал.

💬 Что думаете вы? Go хорош и без обёрток или фреймворки наше всё? Делитесь рассуждениями в комментариях 👇

🐸Библиотека Go разработчика #междусобойчик