Продолжаем вкусно готовить asyncio

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

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

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

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

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

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

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

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

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

Всем привет меня зовут Максим, я SRE инженер в группе компаний Тинькофф.
Но сегодня я здесь по другой причине.

Я уже давно собираю и публикую подборки видео, от которых есть толк, с разных каналов SRE направленности в телеграмм канале https://t.me/sre_pub и спасибо им большое за то что позволяют мне это делать.

Но я не видел подобных подборок на хабре и для меня до сих пор загадка почему.
Лично для меня Хабр является основной площадкой для получения информации.
Вы можете это понять по 1500+ моих закладок в профиле.

Так вот я просмотрел все доклады с SREcon23 составил для вас подборку из докладов вырезав все доклады в которых было больше болтовни или рекламы чем пользы.

Привет! Меня зовут Владимир, я разработчик команды продукта «Сервис персонализации» в SM Lab. В этом посте я хотел бы рассказать (а в комментариях — обсудить) один очень важный и полезный инструмент разработчика — юнит-тесты.

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

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

Эта статья для всех – кто слышал про них, но не видел, кто приступает к написанию юнит-тестов, и кто их пишет уже давно. Надеюсь, каждый из вас найдет что-то полезное для себя.

При подготовке материала очень помогла книга Владимира Хорикова (@vkhorikov ) «Принципы юнит-тестирования». Рекомендую ее всем, кто хочет еще глубже погрузиться в эту тему.

Итак, поехали.

Скрам  –  это легкая методология, которая помогает людям, командам и организациям создавать ценности. Это простая и намеренно неполная система, которая позволяет пользователям полностью раскрыть свой потенциал и работать в режиме Agile. 

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

Итак, погружайтесь и узнайте все об основных принципах Скрама... и все это менее чем за 10 минут.

Scrum Alliance

Привет, меня зовут Мария, когда-то я работала на шахте, потом на заводе, а 3.5 года назад пришла в Ozon Tech. Сейчас я старший Golang-разработчик в команде product-facade. Это самый высоконагруженный сервис маркетплейса, но так было не всегда.

Хотите узнать, что скрывается под витриной маркетплейса? Что держит нагрузку в 1 миллион запросов в секунду? Толстые кэши или нечто большее? Про то, как устроено наше кэширование и как мы к этому пришли, — рассказываю в статье.

Меня зовут Настя, я руководитель службы инструментов репозитория в Yandex Infrastructure. Больше 15 лет я проработала в IT-индустрии: сначала как разработчик, потом тимлид, техлид, менеджер проектов и руководитель службы. За это время несколько сотен человек рассказали мне о своём карьерном пути: кто-то собеседовался со мной как с нанимающим менеджером, кто-то приходил ко мне на менторинг, кто-то расширял свой нетворк, как теперь модно говорить. Из этих разговоров можно выделить причины недовольства работой, которые я вижу у людей чаще остальных. Одна из главных причин — ошибка выбора вакансии.  

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

Привет! Меня зовут Петр и мы в компании Nixys очень любим Redis. Эта база используется, если не на каждом нашем проекте, то на подавляющем большинстве. Мы работали как с разными инсталляциями Redis, так и с разными версиями, вплоть до самых дремучих, вроде 2.2. Несмотря на то, что в Интернете очень много статей и докладов по этой БД, мы в своей практике достаточно часто встречаемся с непониманием некоторых основных концепций Redis и со стороны разработчиков, и со стороны системных администраторов.

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

Добиться, чтобы приложение в равной степени могло управляться пользователями, программами, автоматизированными тестовыми или пакетными сценариями, а также разрабатываться и тестироваться в изоляции от устройств и баз данных, на которых оно впоследствии будет выполняться. — Алистер Кокберн, 2005 г.

Двухтрубные системы отопления тупикового и попутного типа. В чём разница и что об этом говорят современные строительные нормы.

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

Теперь настала очередь рассмотреть особенности проектирования и эксплуатации двухтрубных систем, которые крайне популярны у частных домовладельцев в ИЖС.

Так же двухтрубные вертикально-стояковые системы отопления пытаются применять и в многоквартирных домах.

Далее мы рассмотрим гидравлический расчёт систем для одного этажа частного дома с периметром в те же 50м для дом 10х15м по внутренним стенам (150м.кв на этаж).

А позже попытаемся применить те же подходы для максимальной высоты 50м в стояковой системе высотного дома.

Тупиковая система

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

В статье расскажу про свой путь разработки DIY железок для работы с Home Assistant с целью автоматизации отопления в частном доме.

Глава 0: предыстория

Захотелось построить дом. Дом построили, встал вопрос с отоплением и управлением, а так как в доме иногда отсутствовали по несколько месяцев, то переплачивать за газ не очень-то и хотелось. Газа ведь магистрального нет, но «мы скоро проведем». До этого «скоро» закопали газгольдер, а газ там в +-10 раз дороже магистрального. Пытливый ум решил: будем поддерживать в доме температуру 15 градусов, когда там никого нет. Как это сделать? Повесить контроллер/термостат для котла.

Порой простое и очевидное решение может потянуть за собой хвост проблем в будущем. Например, добавление ретраев.

Меня зовут Денис Исаев, и я работаю в Яндекс Go. Сегодня я поделюсь опытом решения проблем с отказоустойчивостью из-за ретраев. Основано на реальных инцидентах в системе из 800 микросервисов.

Этот пост — продолжение вымышленных историй о разработчике Васе, который несколько лет назад разбирался с идемпотентностью в распределённых системах. Теперь перед ним новые задачи — получится ли справиться с ними в этот раз? Давайте узнаем.

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

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

Эта статья — заключительная (наконец‑то!) из моего огромного цикла про недетектируемые инструменты для обхода блокировок. В предыдущих публикациях я упоминал, что клиенты и серверы XRay (форк V2Ray) и Sing‑box при использовании протоколов VLESS/VMess/Trojan могут работать через веб‑сокеты и gRPC, что позволяет подключаться к даже заблокированным Роскомнадзором прокси‑серверам через CDN (content delivery или content distribution network) и дает дополнительные преимущества. Сегодня мы поговорим об этом поподробнее.

Всем привет! Меня зовут Кира Калимулина, я руководитель группы UX-редактуры в Ozon. Я занимаюсь всеми интерфейсными текстами в приложении и на сайте. 

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

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

Не так давно опубликовал статью об экспресс-создании бота для Telegram на фреймворке SKitLs.Bots.Telegram. С тех пор внутренний состав фреймворка солидно изменился, вместе с тем были выпущены предварительные версии *.BotProcesses и *.DataBases и вторая версия ядра фреймворка.

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

Всем здравствуйте, меня зовут Антон, и этой статьей я открываю новый цикл публикаций про Unicode. Сразу может возникнуть вопрос — зачем? Их же и так море?

На Хабре, как и вообще в русскоязычном сегменте Интернета, в‑основном можно найти обзорные статьи, дающие лишь общее представление о Юникоде, но о том, как с ним работать — информации крайне мало. Сами же его разработчики, Unicode Consortium, предоставляют довольно подробную… но очень объемную документацию, которую при этом мало просто прочитать — для полного понимания много чего в ней стоит прокодить.

Этой весной в чатах и сообществах dotnet (не забываем #DropTheDot) обострились анти-медиаторные настроения. Поначалу меня это забавляло, потом удивляло: люди подхватывают лозунги, не пытаясь разобраться в вопросе. Квинтэссенцией обострения стал доклад Андрея Парамонова "MediatR не нужен”, шокирующий своей категоричностью аргументов. В докладе были зерна истины, но они к концу так и не проросли.

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