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

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

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

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

TL;DR: Да, можно программно изменить датчик для работы в сети Zigbee, достаточно по воздуху перезаписать прошивку.

Многим пользователям умного дома известен квадратный датчик температуры и влажности от Xiaomi LYWSD03MMC. Его очевидные плюсы — это LCD экран, подключение к системе умного дома MiHome и конечно же цена. Его без преувеличения можно назвать если не самым, то точно одним из самых дешевых "умных" датчиков, которые имеют интерфесы для подключения к умному дому. В данном случае это популярный bluetooth, который позволяет подключиться к датчику со смартфона и увидеть показания. Поэтому он завоевал своё место в сердцах строителей умных домов как дешевое и надёжное решение.

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

На самом деле мы просто решили писать тесты не на отдельные классы/методы, а на интерфейс api, которым пользуются клиенты - на сервисы этого API. Тестируя их, мы убиваем двух зайцев: проверяем логику работы сервисов api + форматирование результата.

А такое тестирование сопряжено с несколькими проблемами.

Обычно мы подключаем сбор метрик в prometheus к нашим web‑приложениям с помощью каких‑то клиентских библиотек, которые отдают метрики на /metrics. В этой статье я хочу рассказать как визуализировать Latency с помощью Histogram метрики.

Будет полезно тем, кто еще не строил метрики из Prometheus, а так же тем, кто хочет понять как их интерпретировать.

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

Причины утечек

Для начала перечислим возможные причины утечки памяти:

1) Утечка горутин

При утечки горутины утекают также переменные, которые находятся в области ее видимости. Кроме того, стек горутины выделяется в куче

2) Бесконечная запись в глобальные переменные

Приложение может бесконечно писать в какую-нибудь глобальную мапу, в результате чего память будет утекать. Один раз я пытался найти утечку у приложения, которое использовало gorilla context. Особенность этой библиотеки в том, что при обработке http запроса она сохраняет указатель на запрос в глобальную мапу и не удаляет ключ мапы без явного указания в пользовательском коде. Начиная с Go 1.7, разработчики gorilla рекомендуют использовать http.Request.Context()

Подробный рассказ о том, как я свой дом и сад сделал умными. С фото, техническими деталями, стоимостями и выводами на будущее.

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

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

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

В эпоху быстрорастущих приложений важно иметь возможность контролировать состояние системы в любой момент времени. Одними из требований для достижения этого являются логи и метрики, которые помогают нам следить за многими параметрами, такими как количество запросов в секунду (RPS), потребление памяти, cache git и т.д. Однако, есть ещё один полезный инструмент - трейсинг. В этой статье мы ознакомимся со стандартом OpenTelemetry в языке Go и инструментом Jaeger

С наступающим Хабровчане! Есть мнение что, устройство без корпуса нельзя считать законченным и без него оно будет лежать в разобранном виде, собирая пыль. Поэтому в этой финальной части смоделируем и напечатаем на 3D принтере свой корпус.

И наконец – подведём итоги по проекту, сколько было затрачено финансов, допущено ошибок, а также поделюсь с вами своими планами на Хабр и не только

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

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

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

Частая проблема при разработке распределённых систем состоит в следующем. Предположим, вы отправили системе запрос, и этот запрос обрабатывается очень долго. При этом внутри системы он распадается на запросы к нескольким внутренним микросервисам, которые могут превратиться в несколько подзапросов и выполняться параллельно. Как в этом случае определить, что тормозит систему? На помощь приходит Jaeger — сервис для сбора и отображения трейсов в распределённых системах. 

Последнюю пару лет я живу с приточной вентиляцией в городской квартире — и очень рад этому факту.

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

Коротко о главном:
• наружное расположение компонентов ради минимального уровня шума;
• минимум ручного труда в изготовлении и монтаже;
• общий ценник существенно ниже 50 тысяч рублей (ниже 30 тысяч — на момент изготовления два года назад).

И важное. Если вы — адепт систем рекуперации, долгих инженерных расчётов и полугода проектирования, эта статья не для вас. Я — адепт золотой середины между «я сделяль» и «я задолбался».

Постоянно откладываешь дела на потом и не видишь в этом проблемы? Мне это знакомо. Расскажу как не повторить моих ошибок и почему пора это прекращать. Не откладывай эту статью на потом!

Введение

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

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

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

Для хранения потоковой информации использовать структуру под названием log. Название вам знакомо, и не случайно вы с ней сталкиваетесь, читая консольный вывод приложений. Суть в том, что log – это просто упорядоченная во времени последовательность объектов. Когда происходит событие, мы можем просто добавлять его в конец лога с небольшим описанием происшедшего. Это скажет нам о том, что это событие произошло в определённое время относительно других событий. Всё это выглядит достаточно просто.

Привет, мы команда СберМегаМаркета, и это обзорная статья о нашей площадке, пробный камень для блога Хабре. За нашими плечами спешный переезд с PHP на GO, ребрендинг и решение таких задач, с которыми большинство разработчиков не сталкивается. Например, мы сделали высоконагруженную платформу для управления заказами на 1С. А вам слабо?

Мы пришли поделиться опытом, и для начала расскажем, как превратились из локального маркетплейса в высоконагруженный e-commerce сервис, и что интересного входит в IT-инфраструктуру современного маркетплейса.