UPD. Ссылка на новый репозиторий проекта с поддержкой развертывания в Kubernetes

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

Первая часть шаблона посвящена HTTP серверу:

• настройка HTTP сервера через командную строку и конфигурационный файл
• настройка параметров TLS HTTP сервера
• настройка роутера и регистрация HTTP и prof-обработчиков
• настройка логирования HTTP трафика, логирования ошибок в HTTP
• HTTP Basic и MS AD аутентификация, JSON Web Token
• запуск сервера с ожиданием возврата в канал ошибок
• использование контекста для корректной остановки сервера и связанных сервисов
• настройка кастомной обработки ошибок и кастомного логирования
• сборка кода с внедрением версии, даты сборки и commit

Вторая часть шаблона посвящена прототипированию 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 классе школы. В университете к разработке присоединился мой друг Артём. Сейчас я закончил университет и темой моей работы стал данный проект.

Как всё начиналось