Go *

Привет, на связи Лука.

Знаете, есть такая поговорка: «тише едешь — дальше будешь». Работая с LLM, я пришёл к выводу, что аккуратность и точность в подаче контекста — это один из самых важных ключиков к хорошему результату. Иначе получится как в другой поговорке — про дурака и стеклянный орган.

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

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

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

Как-то раз я допустил в своем коде дедлок и пока выкатывал пул реквест с его фиксом думал “ах как бы было хорошо, если дедлоки определялись на этапе компиляции”. Я решил немного разобраться в этом вопросе и вот что выяснил…

Заранее оговорюсь, всё что будет описано в данной статье, будет касаться runtime (децентрализованного) кеша и применимо не только к Gо приложениям.
Зачем нам нужен такой кеш? По нескольким причинам.

Вообще, я менеджер.

Но когда-то писал код и всегда любил это занятие. Серьезно прогал мобильные приложения, и даже заработал за один из ответов на SO больше 100 звездочек.

Но с тех пор прошла куча времени.

И последнее время меня вновь увлекла эта тема. А как она может увлечь современного человека, измученного миллиардом фреймворков и отставшего от прогресса лет на 15?
Конечно-же курсором и вайб-кодингом.

И я начал кодить.

Собрал несколько ботов, потом замахнулся на CMS. Сейчас даже делаю свою тулзу для запуска LLM-пайплайнов с импортом их из n8n.

Но в процессе всего этого неизменно сталкивался с двумя проблемами

1) Cursor (и брат его Windsurf) паршивейшим образом обходится с нетипизированными и слабо-типизированными языками. Изобретает названия переменных, меняет их по ходу, и вообще, забивает на это огромный и толстый... За пределами этого кодит он неплохо. Но данная штука лично у меня порождает 90% багов.
2)...

Я больше не мог смотреть на то, как сканеры уязвимостей просто генерируют атаки из словарей и кидают в стену тысячи запросов. Это напоминало мне детский рисунок, где ребёнок мечется кистью по холсту, надеясь случайно изобразить Ван Гога.

Я хотел сканер, который понимает. Сканер, который учится. Сканер, который адаптируется.

Так начался проект AI-Scanner — не как плагин к существующему решению, а как попытка вырастить нечто живое: обучаемую систему, способную эволюционировать, предсказывать, ошибаться и исправляться.

Greenmask — это кроссплатформенный инструмент, разработанный на Go специально для безопасной работы с данными PostgreSQL: он помогает делать логические бэкапы, восстанавливать таблицы и при необходимости — анонимизировать чувствительную информацию. Главное преимущество Greenmask — полная совместимость с pg_dump и pg_restore. То есть, если вы уже работаете с этими инструментами, интеграция Greenmask не потребует пересмотра всей инфраструктуры.

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

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

Официальный сайт: https://greenmask.io

Документация: https://docs.greenmask.io/latest/

GitHub-репозиторий: https://github.com/GreenmaskIO/greenmask (уже 1308 звезд)

Telegram-канал: https://t.me/greenmask_ru

Когда мы только начинали работу над платформой, тестирование напоминало ручное управление парусником в шторм — много усилий, но результат непредсказуем. Разработчики вручную создавали тестовые среды, QA проверяли функционал через Postman, а о стабильности релизов можно было только мечтать. Каждый новый релиз был как лотерея: либо всё работает, либо начинается долгий процесс поиска причины багов в production.

После каждой новой статьи с заголовком «ООП — это обман» хочется напомнить: ООП — это не набор шаблонов из книжек, а инженерный подход. Если проект страдает от наследования и DI, возможно, проблема не в ООП. А в том, как вы его применяете.

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

## Парадигма и инструменты языка

Я несколько раз встречал мнение, что го не ООП-язык. И поэтому прежде всего договоримся о том, что такое ООП.

ООП как парадигма — это идея оформить код таким образом, чтобы он отражал в себе образы, которыми мы мыслим. Если я пишу программу для живописи, то я буду объяснять её функционал словами: холст, кисть, цвет, закрашивать... Если эти же слова возникают в моём коде, то я использую ООП. Читая такой код, легко восстановить в голове смысл, который закладывался в программу. Так как в нашем мышлении присутствуют абстракции, для которых свойственны полиморфизм и сокрытие подробностей, то мы переносим их и в код.

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

В этой статье разбирается решение задачи «Гистограммы» с контеста Route 256 от Ozon с помощью SIMD.

Условие задачи

Гистограммой является массив, каждый элемент которого указывает высоту столбика на соответствующей позиции. Две гистограммы считаются совпадающими, если при совмещении одной гистограммы с другой гистограммой, повёрнутой на угол 180°, получается ровный прямоугольник без наложений и пропусков.

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

Задачи на собеседованиях. Денежные переводы в SQL. Обновление счетов и уровни изоляций

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

В очередной раз листая озон я наткнулся на девайс который привлек мое внимание, самоочищающийся лоток для котов Petkit Pura Max, вещь весьма интересная, особенно если у тебя три кота. Пушистые бандиты у меня крупные, потребляют много калорий и соответственно часто ходят в лоток.

В первой части статьи мы рассмотрели, как можно вручную ускорить Go-код с помощью векторизации и SIMD-инструкций, реализованных через Go-ассемблер. Написали простую, но показательно быструю реализацию sliceContains и увидели, что даже базовая векторизация может дать ускорение в 10–14 раз по сравнению со стандартной реализацией.

Во второй части статьи погрузились в практическое применение SIMD в Go-ассемблере, реализовали функцию SliceContainsV1 и изучили, как с помощью VADD, VDUP и других инструкций можно добиться 10–14-кратного ускорения простых задач.

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

Привет, Хабр! Меня зовут Игорь Панасюк, я работаю в Яндекс, преподаю в ИТМО, а также в свободное время выступаю на конференциях, делюсь опытом в соцсетях и помогаю развитию Go-сообщества, веду телеграм-канал и youtube-канал. Если вы уже знакомы с базовыми техниками векторизации, эта часть поможет глубже понять, как устроены продвинутые способы ускорения Go-кода и на что стоит обратить внимание при работе с архитектурно-зависимыми оптимизациями.

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

Ускорить простые задачи, вроде поиска в массиве и сравнения слайсов, поможет мощь SIMD. Эти векторные инструкции, которые обрабатывают десятки байт данных за один такт процессора, отличная замена традиционным циклам. Во второй части статьи мы погружаемся глубже в практическое применение SIMD в Go-ассемблере, реализуем функцию SliceContainsV1 и изучим, как с помощью VADD, VDUP и других инструкций можно добиться 10–14-кратного ускорения простых задач.

Из этой статьи вы узнаете:

• Как устроено сравнение массивов с помощью SIMD-инструкций;

• Почему векторизация быстрее бинарного поиска;

• Как правильно работать с регистрами, фреймами и указателями в Go-ассемблере;

• Что нужно учесть при переносимости и поддержке низкоуровневого кода;

• Когда ассемблер оправдан и безопасен в реальных проектах на Go.

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

В первой части статьи мы разобрали саму идею ускорения кода на Go с помощью ассемблера. А в этой разберём её практическое применение.

Привет! Сегодня мы создадим бота-переводчика для Telegram. Для этого будем использовать библиотеку telego и нейросеть Mistral через платформу n8n.

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

Ассемблер может показаться сложным и пугающим, но он открывает большие возможности для работы с низкоуровневыми оптимизациями. Готовы разобраться, как это работает? Тогда погнали!

Привет, Хабр! Меня зовут Игорь Панасюк, я работаю в Яндекс, преподаю в ИТМО, а также в свободное время выступаю на конференциях, делюсь опытом в соцсетях и помогаю развитию Go-сообщества.

Приветствую тебя, дорогой Разработчик! Хочу поделиться своим опытом о том, как реализовать вход с помощью кошелька Metamask (расширение для браузера) в твой проект. В этой статье я пропускаю весь код архитектуры приложения и покажу тебе только сервисный код (нижний уровень кода. Взгляни на DDD архитектуру, также известную как «Чистый код»). Я использую GO с распространенными библиотеками для веб‑разработки, такими как Gin, jwt, sqlc и другие.

Для начала давай представим, как должен работать наш процесс входа. Как мы все знаем, стратегия «разделяй и властвуй» очень эффективна для чего угодно. Поэтому здесь мы можем разделить наш процесс на 2 логических шага. Назовем их «Начало» и «Завершение». Теперь давай посмотрим на схему нашего процесса, потому что мы, как инженеры, должны максимально упростить свою работу. Итак, схема — отличный способ достичь этого.