User
Более 10 лет разработчики на Go жаловались на отсутствие структурированного логирования в ядре Golang. Участники сообщества Golang даже создали несколько собственных пакетов, таких как Logrus, Zap и Zerolog. В 2023 году, команда разработчиков Google Go наконец-то представила Slog — высокопроизводительный пакет для структурированного ведения логов в стандартной библиотеке Go. Мы перевели гайд о возможностях slog.
Первая часть шаблона посвящена HTTP серверу.
Вторая часть шаблона посвящена прототипированию REST API.
Третья часть посвящена развертыванию шаблона в Docker, Docker Compose, Kubernetes (kustomize).
Четвертая часть будет посвящена развертыванию в Kubernetes с Helm chart и настройке Horizontal Autoscaler.
Пятая часть посвящена оптимизации Worker pool и особенностям его работы в составе микросервиса, развернутого в Kubernetes.
Для корректного развертывания в Kubernetes, в шаблон пришлось внести изменения:
Ссылка на новый репозиторий.
Шаблон goapp в репозитории полностью готов к развертыванию в Docker, Docker Compose, Kubernetes (kustomize), Kubernetes (helm).
Настоящая статья не содержит детального описание используемых технологий
# Шаблон backend сервера на Golang — часть 5 — оптимизация Worker pool
Пятая часть посвящена оптимизации Worker pool и особенностям его работы в составе микросервиса, развернутого в Kubernetes.
Представленный Worker pool поддерживает работу с двумя типами задач
Накладные расходы Worker pool на добавление в очередь, контроль очереди, запуск обработки task, контроль времени выполнения task:
Для task, которые должны выполняться быстрее 200 ns/op представленный Worker pool использовать не эффективно
Собираются следующие метрики prometheus:
Ссылка на репозиторий проекта.
Шаблон goapp в репозитории полностью готов к развертыванию в Docker, Docker Compose, Kubernetes (kustomize), Kubernetes (helm).
Ссылки на предыдущие части:
Представленный ниже шаблон сервера на Golang был подготовлен для передачи знаний внутри нашей команды. Основная цель шаблона, кроме обучения — это снизить время на прототипирование небольших серверных задач на Go.
Шаблон включает:
Вторая часть посвящена прототипированию REST API.
Третья часть посвящена развертыванию шаблона в Docker, Docker Compose, Kubernetes (kustomize).
Пятая часть посвящена оптимизации Worker pool и особенностям его работы в составе микросервиса, развернутого в Kubernetes.
Ссылка на репозиторий проекта.
Представленный ниже шаблон сервера на Golang был подготовлен для передачи знаний внутри нашей команды. Основная цель шаблона, кроме обучения — это снизить время на прототипирование небольших серверных задач на Go.
Первая часть шаблона посвящена HTTP серверу:
Вторая часть шаблона посвящена прототипированию REST API.
Ссылка на репозиторий проекта осталась прежней.
Третья часть посвящена развертыванию шаблона в Docker, Docker Compose, Kubernetes (kustomize).
Пятая часть посвящена оптимизации Worker pool и особенностям его работы в составе микросервиса, развернутого в Kubernetes.
В ходе тестирования шаблона на стенде были получены следующие результаты.
Итак, моя задача: подключение рулевой рейки тигуана на столе без подключения к машине. Для этого требуется имитация активности в CAN шине. Для этого требуется адаптер, позволяющий работать с программой CanHacker и, собственно, трейс CAN пакетов с автомобиля.
Привет, Хабр!
Протокол CAN сейчас широко распространён не только в автомобильной сфере, но и на предприятиях, в различных самоделках, и даже в Средствах Индивидуальной Мобильности (контроллеры VESC, например). В ноябре прошлого года я сделал для себя удобный инструмент для анализа CAN и отправки фреймов, сейчас же хочется сделать код опенсорсным и рассказать о самом проекте.
Для тех, кто только подключился -- я рассказываю про платформу для VR игр, как с ней интегрироваться и как добраться до ее сенсоров напрямую.
Я уже заметил некоторые глюки и проблемы с сенсорами -- значит, неплохо было бы их поправить. Но чтобы их поправить, надо понять что они за зверь, и можно ли их как-то поменять. Из-за огромного размера статьи, пришлось разделить и без того маленький рефератик на еще более маленькие кусочки -- поэтому сегодня мы просто заглянем внутрь сенсора и научимся менять ему прошивку в простом и удобном виде.
"Что б они ни делали -- не идут дела. Видимо в прошивке багов дофига". Как я напомнил в прошлой статье (где я подготовил утилиты для перепрошивки сенсоров) -- я рассказываю про платформу для VR игр, как с ней интегрироваться и как добраться до ее сенсоров напрямую.
Её исходный ресивер обновляет сенсоры с частотой в 86Гц, тогда как технически возможно разогнать до 133 Гц, получив ощутимо ниже задержки, но связь была нестабильной.
Давайте начнём погружение в сенсоры -- посмотрим, что за игра ghidra_11.0_PUBLIC установлена у меня в C:\Games, заглянем одним глазком в саму прошивку и поковыряемся там грязными патчиками, да исправим race condition плюс выкинем немного отладочных глюков. В общем, готовимся к погружению. В этот раз -- всё серьёзно.
Итак, мы познакомились с платформой как пользователи. Посмотрели на связь игр с софтом. Софта с платформой. Пришла пора посмотреть как платформа общается со своими сенсорами: нужен ли нам провод до платформы вообще?
Теперь познакомимся с Bluetooth LE и узнаем, почему приходится писать свой приёмник а не просто полагаться на операционную систему.
В прошлой статье я рассказал что это за платформа, и показал как можно получить данные с неё и как встроить код в стороннее приложение.
Однако, получение данных требует постоянно висящего приложения (на C#), и надо понять что же конкретно оно делает.
Давайте разберёмся как общаться с железом и избавимся от балласта!.. Переписав на Kotlin. Почему Kotlin? Потому что я на нем никогда еще не писал.
У меня есть дурная привычка: я играю в игры. Впрочем, понятие "играю в игры" довольно своеобразное.
Уже несколько лет как я обзавелся VR платформой от KAT VR. Согласно её внутренней статистики, я прошел на ней около 30 километров и сделал 40к шагов. Статистика, конечно, врёт и сильно, было гораздо, гораздо больше. Однако же да, на ней я играл гораздо меньше времени чем с ней.
Уже не первый десяток лет газоразрядные цифровые индикаторы переживают свой ренессанс. Одни собирают часы и метеостанции на широко распространённых ИН-12, другие уходят в тему с головой и пытаются наладить своё производство ламп немыслимых доселе форм и размеров.
Большинство конструкций на газоразрядниках, которые мне попадались в категории «для начинающих», использовали давно снятые с производства микросхемы по типу К155ИД1 или SN74141. Также многие встреченные схемы экономили на оных, используя один дешифратор для всех ламп сразу, коммутируя аноды через оптопары.
Поставить же две ИН-12, валявшихся в ящике уже десяток лет, хотелось в свой проект CD-плеера — отображать номер трека или радиостанции. Поэтому хотелось иметь такой же модуль, как и любой другой дисплей — не сильно крупнее геометрически, чем сами лампы, подключающийся по какой-нибудь стандартной шине и не требующий от процессора никаких заморочек с обновлением динамической индикации и всего такого, да и на производящихся по сей день компонентах до кучи.
Кто же знал, чем это всё для меня обернётся!
Привет, меня зовут Артем. Не так давно я спросил Артёма о том, почему бы нам не рассказать о своём проекте, думаю многие смогут подчеркнуть в нашей истории, что-то своё.
Проект ещё начинался, когда я был в 9 классе школы. В университете к разработке присоединился мой друг Артём. Сейчас я закончил университет и темой моей работы стал данный проект.
