Привет! Я Александр Пищулин, перфоманс-инженер в компании YADRO. Сегодня расскажу об одном интересном случае траблшутинга в работе с системой хранения данных — он касается выброса времени отклика. Поиск причин сбоев, наверное, одно из самых увлекательных занятий в моей работе. Зачастую у подобных задач минимальная формализация подхода к решению, каждый раз может быть своего рода открытием или, если угодно, челленджем.

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

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

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

Рабочая частота BLE составляет 2,4 ГГц. Он использует частотную модуляцию GFSK и использует механизм скачкообразной смены частоты для решения проблемы перегрузки канала.

Существует три схемы реализации для физического уровня BLE 5, а именно некодированный физический уровень со скоростью 1 Мb/s, некодированный физический уровень со скоростью 2 Мb/с и кодированный физический уровень со скоростью 1 Мb/s. Среди них некодированный физический уровень со скоростью 1 Mb/s совместим с физическим уровнем протокола серии BLE v4, в то время как два других физических уровня увеличивают скорость связи и расстояние связи соответственно.

Недавно компания Valve объявила о том, что Counter-Strike 2 не будет поддерживать macOS. Я инди-разработчик, в одиночку выпустивший игру с поддержкой macOS, поэтому поначалу меня удивило это решение Valve. Но вспомнив о своём собственном опыте поддержки шести платформ, я начал понимать точку зрения компании.

Думаю, будет полезно написать пост с перечислением полученных мной уроков. Надеюсь, он поможет другим инди-разработчикам в выборе поддерживаемых платформ. Небольшое предисловие: моя собственная игра Industry Idle в основном основана на веб-технологиях (WebGL + TypeScript). Это означает, что поддержка разных платформ — относительно простая задача, мне не приходится иметь дело с платформенными графическими API (DirectX, OpenGL, Vulkan, Metal) и в основном игра существует в браузерной «песочнице». Это практически идеальная ситуация для кросс-платформенной поддержки. Тем не менее, меня постоянно удивляют и одолевают проблемы, связанные с отдельными платформами.

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

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

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

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

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

Структура прибора

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

Всем привет, меня зовут Женя Колесников, я из команды Yandex Infrastructure. Сегодня я расскажу, как мы пришли к написанию документации в концепции Docs as Code, придумали для этого набор инструментов, назвали его красивым именем Diplodoc и выложили в опенсорс — теперь вы тоже можете им воспользоваться.

Если вкратце, Docs as Code — это подход к написанию технической документации, который рассматривает её не как набор текстов, а как код. Исходя из этой концепции, к документации могут применяться все те же принципы, инструменты и процессы, что и к самому коду. Расскажу, как это происходит на примере Diplodoc — и чем он может облегчить вам жизнь.

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

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

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

Статья была написана мной в 2020 году, после запуска в прод очередной платформы, построенной на микросервисной архитектуре с целью зафиксировать выученные уроки с точки зрения технического руководителя проекта. В проектах участвовало со стороны подрядчика более 300 человек технических специалистов - разработчиков, тестировщиков, аналитиков и др. Поэтому можно сказать, что проекты были достаточно крупными и значимыми.. Теперь уже многие компании - участники проекта либо свернули бизнес в РФ, либо поменяли бренд, а разработанные системы находятся в эксплуатации. Микросервисная архитектура давно не является новой архитектурной парадигмой. Но я думаю, что статья все еще актуальна, как и многие выученные уроки . 

Представьте, что есть 19 предикторов (параметров предсказания) по которым можно узнать, как долго будущий сотрудник проработает в компании. Для компании это передовая технология, которая экономит миллионы, для кандидатов — это инструкция по поиску идеальной работы. Предсказание будущего — это не сюжет антиутопии, а аналитика больших данных, результаты которой вы уже можете использовать. Я расскажу про эти параметры, дам чек-лист, который поможет вам это повторить. Моя история о том, как мы воспроизвели систему предсказаний у себя в компании, используя Excel и палки, и за три квартала 2023 года сэкономили 1.4М рублей.

Все любители кодокопания заканчивают либо хорошо, либо плохо. Мне повезло. Поэтому я решила написать свою первую статью на хабре.

Эта статья о том, каким странным бывает легаси - и куда же всё-таки копать, чтобы понять, что происходит. stdlibc++ опровергает даже стандартные математические понятия. Как хорошо, что это хотя бы опенсорс....

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

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

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

От умного риска до победы близко. Кто не рискует, тот не пьет шампанского. Без риска и жизнь пресна.

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

• Функция деления с остатком не непрерывна
• Способ слишком сложен: он требует трёх переменных и определения @property для каждого случайного значения, которое мы хотим сгенерировать
• Требует применения @property, которое пока поддерживается не очень широко

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

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

Какие выводы мы в итоге получаем:

В задачах на креативность, где нужно было что-то придумать и концептуализировать (в этом кейсе необходимо было разработать идеи для новых продуктов и стратегию выхода на рынок), 90% консультантов показали рост производительности. Они были на 40% производительнее тех, кто не использовал GPT в этих задачах.

Но когда участники эксперимента использовали GPT для задач, связанных с бизнес-анализом, они показали результаты на 23% хуже, чем те, кто выполнял задачу без GPT.

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

Насколько я понимаю, чем более высокая экспертиза и перфоманс специалиста, тем меньше эффекты от использования GPT.

Привет! Меня зовут Глеб, я разработчик команды продукта «Сервис персонализации» в SM Lab. В цикле из трех постов я расскажу про основы полнотекстового поиска в Elasticsearch.

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

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

Итак, начнём с самых базовых понятий.