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

Я Александр Парфенов, бэкенд-разработчик в Тинькофф Инвестициях и автор InvestAPI SDK для языка Go. Расскажу о том, как автоматизировать торговые стратегии при помощи Tinkoff INVEST API и языка Go.

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

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

Подробный туториал по процессам записи и чтения данных в мапах Go. Объясняем проблемы переполнения, эвакуации элементов; важность передачи количества элементов при создании мапы. Рассказываем, почему в Go нельзя обращаться к ключу или значению по адресу.

В Go ввели generics и он потерял одно из своих основных преимуществ: легкую читаемость.

Как же обходились без шаблонов в Go 13 лет? Это не помешало выпустить отличные библиотеки и сделать хорошую стандартную библиотеку! При этом сохранялась лаконичность и легкость языка. А теперь...

Рост генеративного ИИ, API OpenAI и локальные LLM, влияют на то, как мы разрабатываем приложения. У разработчиков на Python и JavaScript есть много инструментов, особо популярен LangChain. Однако, у гошников вариантов меньше. LangChainGo, порт оригинального LangChain, пытается маппить питонячие концепции на го, получается не слишком идеоматично. К тому же, есть ощущение, что LangChain сам по себе переусложнен.

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

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

Каждая миллисекунда имеет значение, микрооптимизация это must have, особенно на языке Go.

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

Эта заметка о том, зачем нам нужен пакет coroutine для Go и как он будет выглядеть. Но прежде всего, что такое корутины?

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

В отличие от подпрограмм, корутины выполняются конкурентно на разных стеках, но все равно верно, что одновременно выполняется только одна функция, а ее вызывающая сторона ждет. F запускает G, но G не выполняется немедленно. Вместо этого F должен явно возобновить (resume) выполнение G, который затем начинает выполняться. В любой момент G может развернуться и вернуться (yield) назад к F. Это приостановит G и продолжит F операцию возобновления. В конце концов F снова вызывает resume, который приостанавливает F и продолжает G после выхода. И так далее, туда-сюда, пока G не вернется, что приведет к очистке G и продолжению F с последней операции возобновления, с некоторым сигналом для F, что G закончена и F больше не должна пытаться возобновить G. В этом паттерне одновременно выполняется только одна корутина, а ее вызывающая сторона ждет на другом стеке. Они выполняются по очереди в четко определенном, скоординированном порядке.

Это несколько абстрактно. Давайте посмотрим на реальные программы.

В этой статье мы научимся писать полноценный gRPC сервис на Go на примере сервера авторизации с полноценной архитектурой, готовой к продакшену. Мы напишем как серверную часть, так и клиентскую. В качестве клиента мы возьмём мой сервис — URL Shortener, о котором у меня также есть статья и видео-гайд на ютубе. Попутно мы познакомимся с базовыми подходами к работе с авторизацией. И в конце настроим автоматический деплой сервиса с помощью GitHub Actions на удалённый сервер.

Видео-версия этого гайда с более подробными объяснениями

Исходный код проекта: https://github.com/GolangLessons/sso

Итого, наш план:

• Напишем простой, но полноценный gRPC-сервис
• Разберемся с базовыми принципами работы авторизации — чтобы не было скучно
• Настроим автоматический деплой в прод — потому что руками деплоить лень
• Подружим его с уже готовым сервисом URL Shortener — чтобы был практический смысл
• Напишем полноценные функциональные тесты

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

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

Несколько лет назад я прочитал статью о параллелизации в GO и ничего не понял – я тогда только начинал программировать на этом языке. Но размышления автора мне очень понравились – они подкреплялись бэнчмарками, что было довольно убедительно. Автор игрался c параметром GOMAXPROCS и показал, что увеличение этого параметра не всегда приводит к увеличению производительности. Под конец статьи он подобрал такое значение, которое будет максимально эффективным для его функции, на мое удивление, это значение оказалось равно единице! Т.е. его код работал максимально эффективно, если работал всего на одном ядре процессора! Однако, в одном из комментариев под той статьей я прочел, что все эти изыскания нелепы, поскольку та же самая функция из статьи запущенная всего в один поток оказывается эффективнее любой ее параллельной реализации.

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

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

Яркие примеры таких приложений: YouTube или Google. Естественно, на одной машине такие сервисы не развернуть, поэтому в архитектуре используются тысячи компьютеров, именуемых Нодами (worker node). Однако эти Ноды, как части общего механизма, могут выходить из строя, и тогда их нужно заново поднимать, более того, хорошо бы вообще постоянно мониторить каждый Нод и считывать его состояние. Выполнять такие задачи становится очень сложно вручную. И, возможно, именно для этих площадок, а может быть и нет, но Google разработала технологию Kubernetes, которая выполняет роль оркестрации контейнеров. Kubernetes следит за Нодами и поднимает те, что выходят из строя, но это не единственная ее задача. Технология также может отключать неиспользуемые Ноды, оптимизируя расход ресурсов.

Привет! Меня зовут Антон Жуков, я руковожу группой разработки в Сбермаркете. В профессии я уже более 12 лет, с Golang работаю с 2016 года, а с Kubernetes — с 2018 года.

В этой статье расскажу об основах Kubernetes, возможных проблемах и решениях, а также о том, как грамотно использовать ресурсы этой платформы, чтобы выжать максимум из Go-приложений. Кроме того, в конце статьи я опишу кейс настройки GOMAXPROCS на примере нашего приложения и расскажу, как нам удалось повысить его производительность на 20-50%.

Изящное завершение работы (Graceful Shutdown) важно для любого длительного процесса, особенно для того, который обрабатывает состояние. Например, что если вы хотите завершить работу базы данных, поддерживающей ваше приложение, а процесс db не сбрасывает текущее состояние на диск, или что если вы хотите завершить работу веб-сервера с тысячами соединений, но не дожидаетесь окончания запросов. Изящное завершение работы не только положительно сказывается на пользовательском опыте, но и облегчает внутренние операции, что приводит к более счастливым инженерам и менее напряженным SRE.

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

Небольшие правки в первой части и программа для связки пары ключей для подписи и домена(имени).

Использование обратного резолвинга(хеш на домен) в смарт-контракте ENS для привязки пары ключей для подписи с доменом(или именем).

Разделяй и влавствуй, или как провести клининг легаси-кода GoLang.

Этот пост является частью большого цикла статей, в которых мы демонстрируем, как создавать приложения на Go, которые легко разрабатывать, поддерживать и с которыми приятно работать в долгосрочной перспективе. Мы делаем это, делясь проверенными методами, основанными на множестве экспериментов с командами, которыми мы руководили, и научных исследованиях («при съёмках фильма ни одно животное не пострадало»).

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

Что касается подхода к «чистой» архитектуре, описываемого далее, то это симбиоз двух идей: разделение Ports и Adapters, а также контроль за тем, как пакеты ссылаются друг на друга...

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

Сразу скажу: велосипедостроение в коммерческой разработке — зло. Создавать что-то, что уже существует и было отлажено многократно – это бессмысленно. И учитывая время, необходимое для выхода на рынок (Time To Market), это еще и опасно. Кроме того, новый код — это новые ошибки. Именно поэтому часто проще взять готовое и дополнить его до нужного уровня при работе в реальных продуктовых проектах.

Тем не менее, я противоречу сам себе, опровергая то, что сказал ранее. Я разработал на языке GO свой собственный easyjson в рамках именно продуктовой разработки, за что мне бесконечно стыдно. Если кто-то скажет, что я потратил деньги бизнес-заказчика в угоду своим амбициям, я не буду с ним спорить, но у меня были определенные причины, а главное теперь у меня есть интересный опыт. Об этом опыте я и расскажу.

В этой статье мы рассмотрим, почему API-шлюзы стали ключевым элементом экосистемы современных облачных вычислений и как появление Kubernetes API Gateway упростило и стандартизировало работу с ними. 

Статья составлена на основе сразу двух англоязычных материалов. В первом (его мы поместили в самое начало) авторы на примере профессий объясняют роль различных компонентов облачных приложений, а во втором — проводят глубокий анализ все возрастающей значимости API-шлюзов для экосистемы облачных приложений, их места в рамках концепции «Kubernetes — облачная операционная система» и того, как повлияет на дальнейшее развитие API-шлюзов появление Kubernetes API Gateway. 

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

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

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

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

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

В этой статье я расскажу о паре способов увеличить пропускную способность системы с помощью партиций kafka и каналов go. В качестве библиотеки-клиента kafka буду использовать segmentio/kafka-go. Статья будет полезна начинающим go-разработчикам, которые уже знакомы с основными концепциями Apache Kafka (producer, consumer, consumer group, offset, топик, партиция), но еще не задумывались о масштабировании. Все рассуждения будут опираться на игрушечный пример, который, я надеюсь, хотя бы немного напоминает реальные системы.

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

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

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

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

gRPC – высокопроизводительный и мощный инструмент для построения микросервисных систем.