Про смех над Рокстарами и неоптимальным парсингом джейсона.

К слову, ещё до его разбора сама строка, приходящая с бэка, разбирается по одному символу, что тоже странно, конечно.

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

Разработчик делает посимвольное чтение. ПРЕДПОЛАГАЮ, что он делает это потому что на этапе написания игры с бэка приходили совершенно ёбнутые данные и он пытается откинуть только их, не прекращая работу над остальными. Ну не круто откидывать джейсон целиком, если из Х элементов пришёл один проблемный. Мало ли по какой причине проблема и когда её устранят? Что же теперь, не давать играть вовсе?

Далее он начинает делать сравнение. Не понимаю, почему над этим так проигрывают местные. Если человек делает сравнение, значит на этапе написаний и согласований о каких-то стандартах не договорились. Вполне вероятно, что ему приходят одинаковые объекты с написанием в разных регистрах, или же просто одинаковые совсем. Что надо делать, если пришёл "АаааА" и "АААаА"? Можно ли это нормализовать?

А что делать, если есть 2 объекта джейсона, которые совпадают всеми полями по значению, но у одного полей больше? А если часть полей не совпадает? Как эту проблему устранить, кроме как сравнивать всё со всем? А если название объекта вообще рандом и сравнивать нужно только по полям этого объекта?

В общем, я к тому, что у такого странного поведения вполне могут быть разумные причины. Так получилось, что один из моих последних проектов в ЛК вёл себя именно так, как описываю. Там был джейсон с неизвестноый заранее глубиной, многие поля нужно было разбирать рекурсивно. Значения полей противоречили требованиям, отсутсовали обязательные поля, были не ожидаемые. Мне пришлось положить кучу сил на автоматизацию всего этого добра. И попытки продавить мысль "давайте делать нормально" проваливались по непонятным мне причинам (видимо у моих руководителей давилка была меньше, чем у тех).

Когда игра вышла на продакшен и когда прошло несколько ЛЕТ с её выхода, вполне вероятно, что изначальные проблемы устранили и сейчас всё это можно поправить и будет здорово и эффективно. Только очень редко компании исправляют то, что не сломано. Игра, в которой главные поставищики денег проводят много часов не принесёт больше денег, если в неё начнут заходить те, кому было лень ждать 5 минут. Такие люди денег не будут приносить. А то, что всё-таки занесут, будет ничтожными копейками по сравнению с рефакторингом.

@rf

Сделал вот такую приложеньку https://play.google.com/store/apps/details?id=xyz.myachin.saveto
Суть в том, что в некоторых приложениях неудобно сделано сохранение картинок: нельзя выбрать место сохранения или вообще нельзя сохранить. Но если в приложении есть шаринг, то можно пошарить картинку в моё и сохранить куда угодно.

Разумеется опенсорс: https://notabug.org/Umnik/SaveTo

В F-droid тоже будет, но на следующей неделе, видимо: https://gitlab.com/fdroid/rfp/-/issues/1634#note_501599340

@rf

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

Но благодаря тому, что они открыли исходный код клиентов, могу сказать, что они не идеальны. Тот, над которым работает наша команда, ещё пизже. Самый банальный пример. И мы, и они, шифруем файлы. Только при попытке передать файл во внешнее приложение они создают дешифрованную копию, которую уже шарят и затем удаляют. А мы даже временного файла не создаём. Мы шарим во внешнее приложение с дешифровкой только ин мемори. Дешифруем чанками, так что шарить можем файл любого размера.

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

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

Вот этот текст я писал. Не уверен, что написал грамотно. Он сообщает, что принимающая сторона может охуеть.

Наш менеджер ориентирован только на организации. Сервер разворачивается у вас. Так что дать погонять, к сожалению, не могу.

@rf

Скопирую сюда тред, который запостил в Твиттере. Можете меня похуесосить за незнание матчасти, если сможете. @rf

Мне Ютуб подкинул какого-то техноблоггера, который замерял скорость памяти телефона какой-то тулой. Скорость памяти. Телефона. Скорость. Памяти. Телефона.

Проблема не в том, что он запускал бенчмарк и деалал какие-то выводы, нет. Проблема в том, что он говорил зрителям, что это скорость памяти (чтения и записи). В конкретных единицах.
НО ЭТО НЕ ТАК! Это просто попугаи, которые нужно сравнивать ОТНОСИТЕЛЬНО других.

Дело в том, что в современных телефонах нет "прямой" записи и чтения (прямой в кавычках, разумеется). В них используется 2 слоя шифрования: FDE и FBE. То есть шифруется носитель на одном ключе (разные партиции на разных и то не все, но это дело пятое), а затем ещё и каждый файл отдельно шифруется на своём ключе. 1 файл - 1 ключ. Это и есть FBE — file based encryption (про фул диск экрипшен более-менее знают даже техноблоггеры). Потому и нет просто записи и чтения файлов. Эти файлы на лету шифруются и дешифруются.

Скорость этих операций, очевидно, зависит от скорости памяти. Но ещё она зависит от алгоритмов шифрования, от ключей, от аппаратной реализации. Но так как на всех современных телефонах не лоу энд сегмента установлена нормальная память, то она перестаёт быть узким горлышком. Скорость начинает упираться как раз во все перечисленные вещи. И это я не трогаю тему пропускной способности шины канала.
Та же Сони в первых ревизиях ПС 4 подключала сата накопители через USB. В итоге HDD особо не страдали на ранних играх, потому что это были кроссген с PS3. Зато позже люди ловили бугурт, что установка SSD никак не повышает скорость. Да и сейчас бугуртят, что фатки, и только они, совершенно не вывозят Киберпанк 2077. Идиотию устранили в поздних ревизиях. Впрочем, не уверен, что устранили в фатках в принципе, знаю только, что в слимках и прошках этой глупости уже не было.

Значит ли это, что замеры не имеют смысла? Разумеется нет. Это лишь означает, что это не скорости чтения/записи, как это говорят блоггеры. Это просто абстрактные попугаи, которые не означают сами по себе совсем ничего. Они имеют смысл только в сравнениях с другими. Но даже это сравнение нужно делать ОЧЕНЬ осторожно.
Во-первых в разных ОСях (многие такие утилиты ТИПА кроссплатформенны) каждый из пунктов, влияющих на результаты, может быть реализован по-разному.
Во-вторых в пределах одной ОС есть разные версии, где были разные требования к каждому из пунктов. То есть один и тот же телефон на разных версиях ОС может давать разные попугаи и это совершенно нормально.
В-третьих в прошивке и драйверах могут быть проблемы, которые производитель устранил, условно, через час после выхода обзора, что приведёт к росту числа попугаев. Или наоборот, отсыпал новых проблем.
В-четвёртых могут быть ранние ревизии устройств с какими-нибудь детскими болезнями на аппаратном уровне, а затем будут ревизии этих же моделей с фиксом (то, что одна модель телефона на разных рынках — это аппаратно разные модели, это даже упоминать не хочется).

Я опустил много совсем уж технических вещей, типа реализации /dev/urandom (да, если вы только вышли из каменного века, то знайте, что /dev/random не рекомендуется к использованию, кроме пары вполне конкретных сценариев). Потому что если бенчмарк будет получать данные из пула и их энтропия будет недостаточно большой (потому что производитель решил внести какие-то непоправимые улучшения в неправильный Линукс), то будет прирост производительности, которого на самом деле нет. Просто это контроллер умный.
А ещё производителю никто не навязывает конкретную ФС и флаги для неё (главное, чтобы ФС поддерживала FBE с fscrypt). К примеру, память может давать не слишком впечатляющие попугаи, но на пользовательском опыте это не сказывается практически, потому что есть всякие плюшки типа COW.

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

Типа, убирать фоновый шум, оставляя на потребление только сырые данные и делать свои прикидки.

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

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

Посоны, что это может быть такое?

```
"r2---sn-n35qp-n8vl.gvt1.com": {
"sni": [],
"methods": [
"GET"
],
"ports": [
80
],
"ips_fact": [
"87.255.30.141"
],
"ips_possible": []
},
"r2---sn-n35qp-n8vs.gvt1.com": {
"sni": [],
"methods": [
"GET"
],
"ports": [
80
],
"ips_fact": [
"87.255.30.205"
],
"ips_possible": []
},
"ryuyycmlyafbmo": {
"sni": [],
"methods": [
"HEAD"
],
"ports": [
80
],
"ips_fact": [],
"ips_possible": []
},
"whasxnvj": {
"sni": [],
"methods": [
"HEAD"
],
"ports": [
80
],
"ips_fact": [],
"ips_possible": []
},
"gqacjbjshfztklr": {
"sni": [],
"methods": [
"HEAD"
],
"ports": [
80
],
"ips_fact": [],
"ips_possible": []
}
```

Странные очень адреса. У тех, которые с доменом верхнего уровня, у них IP адреса моего провайдера. А некоторые вообще без доменов.

@rf