Go *

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

В предыдущей статье я попросил — «Расскажите, зачем вам DI‑контейнер в golang». Большое спасибо всем, кто оставил коммент и проголосовал. Общий вывод такой: используем контейнер, потому что с ним удобно писать тесты. Тесты — весомый аргумент, особенно в контексте того, что тест — это часть кода. Получается, мы все таки «тащим» Di‑контейнер в проект. Ну, хорошо....

Вероятно, это будет uber‑fx, ведь у него хорошая документация, самое простое и понятное API по сравнению с другими..., или нет — не «тащим»?

Мой ответ — нет, uber‑fx не «тащим», потому что можно еще проще и понятнее.

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

Чаще всего я настраивал это все на уровне кода, но, некоторый период назад наткнулся на Modelfile и решил изучить и попробовать его, в ходе экспериментов наткнулся на реально большое число неожиданностей и решил таки написать о нем тут подробнее :)

Modelfile позволяет упаковывать модели и формировать готовых агентов. В нем оказалось много реально неожиданного поведения, и одновременно с этим есть сложности и странности. Однако с его помощью можно взять множество разных моделей из того же Hugging Face и запустить под Ollama, а самое важное, удобства в тюнинге (или же наоборот отупливании модели :D ).

Привет, Хабр! Меня зовут Дмитрий Гурьянов, я руковожу командой Manuls в VK HR Tek (система ведения кадрового электронного документооборота). Сегодня расскажу о нюансах оптимизации на разных уровнях исполнения кода на Go.

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

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

Свою первую работу программистом на языке PHP я нашёл в далёком 2011 году, имел опыт с разными версиями языка от 5.0 до 8.1 в коммерческих разработках. C тех пор иногда приходилось выходить в смежные области: Python, NodeJS, 1С, VBA и вот наконец Go. Для любого опытного профессионала не станет откровением, что одну и ту же вещь можно сделать разными средствами, и что для каждой задачи есть свой наиболее подходящий инструмент. В середине 2010-х особое распространение начинают получать такие направления, как High Load, микросервисная архитектура, и конечно модное тогда распиливание монолитов. Многие из проектов-монолитов были написаны на языке PHP, и из тех, кто стал делать первые шаги в Go в то время стали в том числе те самые программисты, которые с блеском в глазах могли, как мантру повторять «распилить монолит» и мечтать написать микросервис на Go под каждую задачу, требующей всего того, на что привычный PHP был не способен: неэффективный расход памяти, отсутствие асинхронности.

И в принципе, до выхода версии 7.4 с ее возможностью FFI (Foreign Function Interface) решить озвученные выше проблемы мог совсем не каждый программист, занимающийся разработкой "коробочной" CMS (WordPress, Drupal, Joomla! или Битрикс). В конце концов, мало кому хотелось, вспоминать полузабытый после университета язык C, браться за разработку собственного расширения для PHP (pecl).

Сказанное выше является моим субъективным мнением, единственным выводом из которых хотелось выделить одну простую мысль - есть некая аудитория программистов, которые знают и Go, и PHP. Если вы набрели на эту статью, вбив в поисковике слова "PHP FFI Go", то эта статья для вас, тех кто ищет нетривиальные пути, тех кто пытается взять лучшее от каждой из технологий.

В данной статье представлен пошаговый процесс разработки легковесного веб-фреймворка на языке программирования Go. Основываясь на стандартной библиотеке net/http, мы исследуем ключевые концепции, лежащие в основе современных Go-фреймворков, таких как Gin, Echo и тд.

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

Ниже поделюсь личным опытом изучения языка — и да, я еще продолжаю его осваивать. Расскажу, какие встретил различия между Python и Go в типах данных, преобразовании типов данных, подходах к обработке ошибок. А еще обсудим, какой ЯП быстрее и можно ли импортировать и выполнить код Go в Python. Надеюсь, этот пост будет интересен тем, кто тоже собирается освоить второй ЯП. Ну, let’s Go!

Я старый фуллстек-разработчик и не знаю слов любви, но около полугода назад при очередной итерации сервера почувствовал себя утомленным путником, который узрел нежную красоту wr-обработчика нативного net/http! Вот раньше всё было ужасно - а теперь красиво, приятно читать и интересно показать! За несколько месяцев я переделал свои сотни обработчиков на новый стиль - и всё еще доволен! Почистил авгиевы конюшни слоев логики - теперь там царит запах фиалок! Также у меня была возможность посмотреть как пилят http профессионалы бэкенда - далеко не как фуллстеки, о чем тоже хочется рассказать!
Для ленивых читать - пора вернуть логику в обработчики! Но я расскажу подробно о той красоте, которая скрывается за этими многими восклицательными знаками, и о том, как её можно испортить. Структура такова:
- сначала чем фуллстек отличается от нативного бэкенда,
- потом пройдемся по API-стилю а-ля РЕСТ,
- прочтем оду нативному http-модулю, расковыряем пару болячек фреймворков,
- почитаем мои слова, почему wr-обработчик хорош сразу из коробки,
- и посмотрим пример того, как превратить обработчик в простой вид "задача-дано-решение-ответ".

Внимание, это мнение. В статье поднимаю холиварные темы, при этом я могу быть не прав, но буду настаивать! И фотка из личного фотоархива на тему "Люблю лето!", потому что уже надоели сгенерированные картинки.

Пару дней назад я опубликовал статью про ХрюХрюКар - телегам-бот для борьбы со стоянкой автомобилей на зелёных зонах. Проект с открытым исходным кодом.

За два дня ко мне обратилось несколько сторонников с просьбой добавить их города. Но вот незадача: у меня была возможность через админ-панель Django править данные в базе, но об этом кеш сервера не узнает (основной бекэнд на Go). В результате приходилось добавлять данные и перезагружать контейнеры с go-бекэндом вручную.

Основные серверы ХХК уже имели сторы, которые получают и обрабатывают апдейты, прилетающие через redis.

По сути, оставалось внести правки в часть django-бэкенда, чтобы обрабатывать сигналы pre_save и pre_delete, сериализовать данные и отправлять их в нужный канал редиса.

Решил поручить эту задачу Codex CLI, которую вчера OpenAI представили нам с вами. 

Привет, Хабр!

Сегодня я хочу поговорить о том, как мы все иногда очарованы показателями тестового покрытия в Go — и как же часто эти проценты лукаво нам подмигивают. Казалось бы, влепили go test -cover, получили любимые цифры, приближающиеся к 100%, и можно выдохнуть. Но, увы, не всё так радужно, как хочется. На самом деле заветная сотка покрытия далеко не всегда означает, что ваш код действительно покрыт тестами.

Привет, Хабр. Меня зовут Иван Добряев, я разработчик программного обеспечения в Центре технологий VK. Сегодня хочу поделиться опытом по одной достаточно прикладной, но весьма увлекательной теме — разработке командной строки (CLI) на Go.

Платформа для инференса ML-моделей (inference platform) у нас молодая, ей всего лишь полгода, и мы активно расширяем команду. Так что, если вы хотите писать сервисы на Go с нуля, то приходите к нам, у нас найдутся задачи на любой вкус.

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

В этой статье мы рассмотрим внутреннее устройство срезов, длину, емкость и связь с базовыми массивами, а также разберем распространенные ошибки и оптимальные практики их использования. Мы изучим особенности работы с функциями append и copy, узнаем, как предотвращать утечки памяти при работе с большими срезами, и обсудим различия между нулевыми и пустыми срезами. Также уделим внимание вопросам производительности, включая правильную инициализацию срезов и работу с указателями, чтобы помочь вам писать более эффективный и безопасный код.

Привет, Хабр!

В этой статье рассмотрим //go:linkname — неофициальной, но невероятно мощной фиче Go, которая позволяет вызывать приватные функции и обращаться к закрытым переменным других пакетов.

Хеш-таблица(мапа) — одна из самых популярных структур данных, потому что поиск по ключу происходит за O(1). Причем ключ может быть любым любым типом, элементы которого можно сравнивать (Comparable Trait).

Я столкнулся с тем, что мапа не такая быстрая по бенчмаркам на языке GO, хотя теоретическая сложность алгоритма О(1).

Давайте рассмотрим следующую задачу и способы ее решения.

Как реализовать подходы Mutex и lock-free и какой из них выбрать для решения вашей задачи? Как подружиться с пакетами unsafe и использовать их для эффективной разработки? И, наконец, куда движется Go после в релизе 1.24?

На эти и другие вопросы нашли ответы Go-разработчики из YADRO, Avito Tech и Yandex, а мы принесли вам записи и презентации их обсуждений. Из докладов вы узнаете о работе с критической секцией и подводных камнях unsafe. А после просмотра дискуссии поймете, какие фичи из нового релиза сделают вашу жизнь лучше.

Ранее, я уже писал статью о различных способах, которые мне приходилось использовать для чтения логов, и к какому решению в итоге пришел. Хотя прошло не так много времени, с тех пор приложение не переставало развиваться. Узнав о том, что на Хабре проходит сезон Open source, мне показалось это отличным поводом подчеркнуть, что именно стало причиной для создания данного инструмента, а также рассказать немного подробнее про основные и новые функции.

Всем привет! Сегодня хочется поговорить про механизм распространения контекста трассировки в OpenTelemetry. Разберем, как он работает, и посмотрим простой пример на Go. Всё — коротко и по делу!

Меня зовут Носорев Константин, я backend-разработчик в Яндекс Пей, автор канала "Константин про IT" и просто любознательный инженер.

Привет, Хабр!  На связи Артём Петров, я занимаюсь разработкой ПО в центре технологий VK. Хочу рассказать о важной задаче обработки больших объёмов данных с использованием нескольких экземпляров одной и той же модели машинного обучения. Этот процесс называется batch inference («пакетный инференс») и позволяет значительно повысить производительность системы, особенно когда речь идёт о таблицах большого размера.

Почти год назад я писал про ХрюХрюКар. Это экспериментальный проект, который проработал 7 месяцев в городе Балаково Саратовской области. За это время мы «поймали» около тысячи автомобилистов, разместивших свои авто на зеленых зонах, детских/спортивных площадках и тротуарах.

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