Пост для тех, кто любит радиосвязь, но не радиолюбитель с позывным

Мы продолжаем знакомить читателей с умными квартирами. В прошлый раз мы рассказывали о проекте айтишника, который хотел все сделать на Wi-Fi, но передумал.

Сегодня мы посетим квартиру руководителя строительной компании, весьма далекого от темы IT. Сергей привык раздавать указания голосом, поэтому идея управления через Алису пришлась ему по душе. И в его умном доме всем заправляет эта девушка.

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

❯ Часть первая: физическая память

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

Начнем с того, что современные музыкальные сервисы не просто так называются стриминговыми. Одна из их ключевых способностей - это выдавать бесконечный поток (stream) треков. А значит, список рекомендаций должен пополняться новыми композициями и никогда не заканчиваться. Нет, безусловно, собственноручно найти свои любимые песни и слушать их тоже никто не запрещает. Но задача стримингов именно в том, чтобы помочь юзеру не потеряться среди миллионов треков. Ведь прослушать такое количество композиций самостоятельно просто физически нереально!

Так как они это делают?

Интересное начало, не так ли? Меня зовут Роман, и я младший инженер информационной безопасности Ozon. В этой статье я расскажу о проблеме отсутствия авторизации доступа к Docker daemon / Docker Engine API / командам Docker при работе с контейнерами в экосистеме Docker и как это можно решить при помощи 11 почти стихотворных строчек bash.

Говоря о стихотворчестве, первое, что приходит мне в голову, это уроки литературы, где моим самым любимым романом был «Евгений Онегин». В школе учитель литературы говорила нам: «Это вы сейчас это не понимаете... Уже потом, спустя год, пять или даже 20 лет, вы вновь прикоснётесь к книгам, которые, казалось бы, вы уже знаете вдоль и поперёк. И вот тогда вы поймёте всё то, что мы с вами тут обсуждаем, или даже откроете для себя что-то, о чем и не догадываетесь».

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

Что будет ниже:

• Поиск open source решения для общения голосом, шаринга экрана, включения видео и чатов в режиме peer-to-peer, без лишних бекендов
• Запуск этого решения в открытую в github pages
• Заворачивание этого решения на приватный сервер
• Простенькое закрытие доступа туды через basic http auth
• Заключение с описанием некоторых замечаний и потенцевальных возможностей

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

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

Кода будет много...

Наша команда проводит много red-team-проектов и, как следствие, постоянно имеет дело с различными системами мониторинга сетевого трафика. Вопрос «Как не спалиться?» в такой работе почти так же важен, как проникновение в инфраструктуру. Поэтому сегодня я хочу поговорить о маскировке сетевого трафика между С2-агентом и сервером — посмотрим на нетривиальные и даже забавные способы это сделать.

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

Часто случается так что на необходимом сайте установлена защита от ботов. Например: QRATOR, Cloudflare, Akamai Bot Manager и пр. Можно потратить множество ресурсов на обход этих систем, но если у вашего ресурса есть мобильное приложение, то можно пойти другим путём. В подавляющем большинстве случаев мобильное приложение остается без защиты т.к. методы актуальные в браузерной разработке в мобильной не актуальны. В этой статье мы совершим атаку MITM на приложение [скрыто], узнаем эндпоинты по которым приложение получает данные и получим данные сами.

Восприятие английского на слух: упражнения, полезные советы и подборка ресурсов

Привет! Это Лена, методист курсов английского в Практикуме. Мы уже знакомы по статьям про собеседование для разработчиков и small talk. В этот раз поговорим о восприятии английского на слух и прокачаем навык общения с иностранными коллегами.

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

Сегодня я хочу поговорить о двух правилах С++: правиле трех и правиле пяти.

Правильное понимание этих правил способно уберечь код от утечек и неопределенных поведений.

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

Расскажу вам насколько это актуально, с чего начать, какие ресурсы и приемы использовать и как эффективно достичь результата.

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

Пример закладок @alizar: 800+ статей.

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

Я бы хотел немного углубиться в тематику использованного механизма stick tables, но поговорить не про пользователей, активно интересующихся вашим сайтом, а про нагрузочную способность, или ёмкость, всего сайта (ну или каких-то его путей). Во-первых, любой сервис ограничен в количестве одновременных запросов, которые возможно обслужить на существующих ресурсах. Во-вторых, чаще всего у сервиса не одна площадка или хотя бы не один экземпляр балансёра. А это значит, что поймать одинокого пользователя — это, конечно, здорово, но хотелось бы решить и другую интересную задачу: защитить сервис от перегрузки в целом и в случае, если балансёров более одного. Бонусом поговорим о проблеме умного перераспределения нагрузки между локациями.