Подобная ситуация с групповыми звонками. libtgvoip давно их поддерживает, на бэкенде тоже готовы, но почему-то не включают и не реализуют в клиентах. 🤷‍♀️

Несмотря на то, что Uber продолжает работать в России, являясь фронтендом к Яндексу, Uber API больше никаких данных не возвращает :(

У нас снег, а у вас?

По итогам мучений:
1) У вас не работает/плохо работает ридер RC522? Отправьте его в помойку и купите PN532.
2) У вас не работает ридер PN532? Либо вы неправильно установили переключатели на плате, либо вы его сожгли, тогда купите новый, он стоит как чашка кофе.

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

Ещё и красивенький........................

Когда математика делает больно 😡

Если вы когда-нибудь играли в мультиплеерные шутеры, вы знаете, что такое K/D ratio. Остальным расскажу: это результат деления количества убитых вами врагов на количество ваших смертей.

Если вы совершили 16 убийств, а сами погибли 1 раз, ваш K/D за игру будет 16/1 = 16. Для большинства игр это очень хороший результат. А если система ещё и статистику игрока ведёт, то такая успешная игровая сессия положительно скажется на вашем average K/D — среднем арифметическом всех K/D за все ваши игры.

А теперь представьте, что вы убили 16 человек, а сами оставались живы в течение всей игры. Ну, допустим, вы бог Counter-Strike, или же команда противников была слишком слаба. Ваш K/D за эту игру будет 16/0. На ноль делить нельзя. Обработка таких ситуаций лежит на плечах разработчиков.

Я лучше расскажу, как такие ситуации обрабатываются в платформе FACEIT (эта штука работает с CS: GO, Doka 2, PUBG и другими играми).
Там в подобной ситуации вы получите K/D 0, а также:
1) игра будет помечена красным цветом (так помечаются игры, где вы чаще умирали, чем убивали, т.е. K/D < 1)
2) ваш average K/D УПАДЁТ, потому что к нему добавится 0.

Платформе 6 лет. Единственное решение, которое предлагают игроки в сообществе: умирать один раз намеренно. 🤦‍♀️
Багрепорт отправила, но сомневаюсь, что я первая. Скорее всего будет игнор.

Вчера долго занималась ЛОУ ЛЕВЕЛ РЕВЕРС ИНЖИНИРИНГОМ и в какой-то момент мне понадобилось найти ответ на специфический вопрос. Кстати, в 2016 я сталкивалась с похожей проблемой, но забыла, как её тогда решила.

Нашла в итоге вопрос на stackoverflow, где у человека ТОЧЬ-В-ТОЧЬ такая же проблема. Ответ там оказался грустным: задача нерешаема. Но как же меня поразило, что ситуация у человека полностью совпала с моей, будто одну жизнь живём!

А потом увидела, что автор вопроса — я в 2016 году.

Чайник Xiaomi копит в своей памяти логи: когда нагревалась вода, в каких режимах, до скольки градусов, какая температура была до нагрева.

А когда вы открываете приложение, оно запрашивает из чайника эти логи и передаёт на сервер Xiaomi.

Сами уже додумывайте, зачем они это делают 🤷‍♀️

Чайник Xiaomi многих бесит тем, что максимальное время действия функции поддержания тепла — 12 часов.

Это значит, что раз в 12 часов вам придётся снова включать подогрев нажатием на физическую кнопку.

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

Хорошая новость! Если вы — я, вы можете задать до 127.5 часов :>

Есть и плохая новость.

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

Пока мы с другом реверсили всю эту китайскую радость, не раз натыкались на GitHub репозитории, где, по нашему чутью, когда-то лежали разборы этого алгоритма, но потом внезапно пропали.
Либо у меня паранойя, либо Xiaomi вежливо потребовали удалить эти куски.

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

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

Штош, чайник официально побеждён. Как и суперсекретный (ТМ) и непобеждаемый (R) алгоритм шифрования в авторизации Xiaomi.

Новая эра спама: BLE-маячки

Есть такой протокол поверх Bluetooth, называется Eddystone. Как iBeacon, только не от Apple, а от Google.

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

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

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

Оказавшись в заведении, ваш телефон автоматически предложит посетить этот сайт. Умно.

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

https://twitter.com/buzz/status/1058143928203980800

Ладно, проблема не так страшна. Предложения посетить сайт будут появляться, если владелец смартфона включит функцию Nearby Notifications, а эта функция будет полностью уничтожена Google 6 декабря из-за нашествия подобного спама.

F

А потом они спрашивают: «а чего это среди нас так мало девушек?». Девушек не мало, они есть в любых сферах. Они просто с таким ракосообществом дела иметь не хотят.