Go *

Всем привет! Меня всё так же зовут Сергей, я разработчик в Ozon. 

Прошло полгода с тех пор, как я не могу найти носки выхода моей первой статьи про тестирование HTTP-сервисов на Go, уже почти год библиотеке CUTE, поэтому я горю желанием рассказать вам, как нынче можно тестировать HTTP-сервисы на Go .

В этой статье речь пойдёт про новые возможности CUTE:

- Построение multistep-тестов.
Рассмотрим, как можно сделать тест, состоящий из нескольких шагов, как достать данные из одного теста и перенести их в другой и как это всё выглядит в Allure.

- Загрузка файлов и построение multipart-тесты.
Один из популярных кейсов — когда при проверке ручки регистрации нужно убедиться, что API может принимать картинки и информацию о пользователе в одном запросе. Рассмотрим, как такое тестировать.

- Написание табличных тестов.
Рассмотрим возможность создавать массивы тестов с проверками, параметризацией и Allure-отчётами.

И много других фич. Готовы? Let's read it again!

Свежая подборка новостей и материалов.

Интересное в этом выпуске

Выпущены Go 1.20.3 и 1.19.8, поиск пути на 2D-полигональных картах, golang предложение log/slog structured, leveled logging принято.

Привет, Хабр! Этот пост — отчёт с митапа Moscow Python x YADRO. Мы обсуждали отличия языков Python и Go, подробно разобрали работу с протоколом syslog и почти написали свой Docker. Если вам интересны эти темы — заходите под кат, там вы найдёте видеозаписи докладов, презентации спикеров и небольшой фотоотчёт. 

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

С некоторыми ошибками мы пишем в лог стек вызовов. Используемая нами IDE (Idea, GoLand) позволяет по скопированному стеку вызовов получить комфортную навигацию по файлам (Analyze external stack traces). К сожалению, эта возможность хорошо работает только в том случае, если бинарый файл собран на том же хосте, на котором запущена IDE.

Этот пост посвящён тому, как мы пытались подружить формат стека вызовов и IDE.

Среди программистов не утихают споры о том, надо ли знать "алгосики" для реальной работы, или же это просто некий странный ритуал для прохождения воронки собеседований в компании а-ля FAANG (MANGA). У нас в Каруне в разных командах есть разные мнения на этот счёт. Я, например, как тимлид Go-команды считаю, что некую элементарную базу знать точно бы не помешало, но всё же главное, чтоб человек был хороший.

Мнения могут различаться, но одно я знаю точно: разгадывать загадки бывает очень интересно. Я как-то из любопытства прорешивал задачки на hackerrank, и, если для решения простых задач тупо достаточно догадаться отсортировать данные или построить map (даже не надо ничего особо знать), то для некоторых придумать решение довольно проблематично.

Одна из таких задач — нахождение самой длинной общей подпоследовательности (longest common subsequence). Подобный алгоритм используется в реальной жизни, в таких программах как diff. Скажу сразу: я не смог решить задачу самостоятельно за разумное время (т.е. пока не надоело решать) и посмотрел алгоритм в Википедии.

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

Disclaimer: я точно не олимпиадник и не гуру алгоритмов, просто любопытствующий.

Всем привет!

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

Сегодня я хочу рассказать вам о волшебном алгоритме, который стоит за безопасным общением в интернете, и, в частности, в нашем любимом мессенджере - Telegram. Этот алгоритм называется алгоритмом Диффи-Хеллмана, и его история начинается в далеком 1976 году. На этом с историей закончим ?

В настоящее время существует огромное количество всеразличного рода анонимных (скрытых) сетей, начиная с теоретически доказуемых (DC-сети, Queue-сети, Entropy-сети) и заканчивая практически используемыми (Tor, I2P, Mixminion). При таком количестве реализаций было бы очень удобно обобщить структуру всех таковых систем и привести их к общим составляющим. В результате подобных действий, мы сможем не только лучше понять то, как строятся современные анонимные сети, но и то, как их можно улучшать.

Возможно эта статья покажется Вам странной, ведь вопрос одного из самых популярных мультиплееров для игры GTA: San Andreas давно решён, так или иначе поддержка неофициального фреймворка, если его можно так назвать, для языка GO всё ещё идёт.

Ответ на один из возможных вопросов читателей:
- Зачем писать статью о никому неизвестном фреймворке для SAMP-мультиплеера?
Вопрос вполне корректный, честно я и сам пока что не нашёл правильного ответа. Но думаю что кому-то это и потребуется. Когда-то я и сам начинал программировать, а моё начало было с написания игрового мода для сервера SAMP, впрочем, это другая история.

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

В этой статье я расскажу, что делать при обнаружении утечки в Go-приложении: чем могут быть вызваны утечки и с чего начать поиск источника проблемы.

Причины утечек

Для начала перечислим возможные причины утечки памяти:

1) Утечка горутин

При утечки горутины утекают также переменные, которые находятся в области ее видимости. Кроме того, стек горутины выделяется в куче

2) Бесконечная запись в глобальные переменные

Приложение может бесконечно писать в какую-нибудь глобальную мапу, в результате чего память будет утекать. Один раз я пытался найти утечку у приложения, которое использовало gorilla context. Особенность этой библиотеки в том, что при обработке http запроса она сохраняет указатель на запрос в глобальную мапу и не удаляет ключ мапы без явного указания в пользовательском коде. Начиная с Go 1.7, разработчики gorilla рекомендуют использовать http.Request.Context()

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

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

Привет! Меня зовут Владислав Попов, я автор курса «Go-разработчик» Яндекс Практикума. Когда-то я сам был студентом — хотел учиться Go, но такого курса в Практикуме не было, поступил на Python. Прошёл вводную часть — и тут стартовал желанный курс по Go. В тот же вечер оформил возврат и перепоступил. Попал в первый поток, прошёл его, и после сдачи итогового проекта мне предложили стать тестером курса «Продвинутый Go-разработчик».

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

За время работы с Go я понял, что сам язык не очень сложный и подходит даже в качестве первого, но нужно выучить синтаксис и погрузиться в некоторые особенности, которые отличают Go от других языков: например, интерфейсы и особенности встраивания. А ещё важно на старте хорошо знать Git и ориентироваться в работе SQL (причём любого).

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

Это небольшой гайд о том, как обеспечить наблюдаемость в вашей событийно-ориентированной облачной системе.

Инструменты покрытия кода помогают понять, какая часть кодовой базы выполняется (или, как еще говорят, покрывается) при выполнении данного набора тестов. Какое-то время Go поддерживал измерение покрытия кода на уровне пакета, введенное в Go 1.2, она включалась флагом команды go test -cover.

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

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

Двоичные файлы интеграционных тестов создаются командой go build, а не go test, поэтому инструментарий Go до сих пор не предоставлял простого способа сбора профиля покрытия этих тестов.

С версии Go 1.20 программы с инструментированием покрытия можно создавать командой go build -cover, а затем, чтобы расширить область покрытия, передавать эти инструментированные двоичные файлы в интеграционный тест.

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

Параллельное программирование — одна из самых интересных фич, которые может предложить вам Golang. Идея, лежащая в основе параллелизма, заключается в одновременной работе над несколькими разными процессами, что помогает избежать застревания в задачах, выполнение которых занимает много времени.

Привет!

Меня зовут Петр Коробейников, я техлид команды DBaaS for Redis в #CloudMTS.
Некоторое время назад я озадачился созданием общего набора инструментов для наших команд разработки. Цель была проста: разработчик не тратит время на погружение в логику работы конкретного инструмента, берет готовую инструкцию и просто делает свое дело — пишет код. Типовое окружение поможет переходить ребятам из команды в команду и быстро адаптироваться, а новичку — проще приступить к работе.

Сегодня я хочу рассказать про один из элементов такого типового окружения, который позволяет быстро начать работу с брокерами сообщений. Даже если разработчик Kafka и прочие брокеры до этого в глаза не видел. Речь пойдет о шине данных или событий (EventBus) и про то, как мы настроили ее кодогенерацию.

Бюрократия семимильными шагами внедряется в процесс разработки. Людей в пиджаках интересуют лишь цифры, и это же относится к test coverage сервисов. Однако, покрытие зачастую (в том числе, благодаря создателям языка) не отображает полной картины мира. Так ли все плохо на самом деле?

В данной статье описал схему маршрутизации и получения данных в hashicorp vault(это зашифированное хранилище секретов с доступом по политикам). Возможно будет полезно тем, кто думает над архитектурой сервера или слоем(‑ми) доступа к данным.

Всем привет! Меня зовут Денис Колпаков, я бэкенд-инженер в юните Core Services Авито. Долгое время я был овнером критически значимого для бизнеса сервиса форм, а последний год занимаюсь каталогами и каталогизацией. 

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

В Bazel есть любопытная фича, позволяющая добавить данные, которые не инвалидируют кэш сборки.

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

Разберемся, как stamping использовать...

Первая Часть

Предыдущая часть закончилась неудачной балансировкой, которая не решает практически никаких проблем. В комментариях кто-то спросил, почему я не использовал балансировку на уровне DNS. Так вот, я ее использовал. Оказалось, что c помощью DNS записей можно организовать балансировку Round Robin. Для этого в конфигурации Wireguard всего лишь нужно использовать доменное имя вместо IP адреса.