переносы игр это типичный пиар ход. Они изначально знали что будет перенос, просто создают поводы для споров и обсуждений в сообществе чтобы подогреть интерес. Больше интереса - больше денег. А это бизнес , им плевать на саму игру, важны цифры в финансовых отчетах
Развернутая рецензия на статью "CRUS: принципиально новая архитектура работы с данными"
1. Структура и стиль изложения
Сильные стороны:
Статья построена как исследовательский манифест, что привлекает внимание к амбициозным идеям.
Использование метафор (например, "Святой Грааль работы с данными") делает материал доступным для неспециалистов.
Слабые стороны:
Несбалансированность теории и практики: Автор детально описывает концепции (CVRDT, шардирование), но избегает конкретных алгоритмов или схем реализации. Например:
Нет псевдокода для синхронизации лендов.
Не объяснено, как именно достигается "атомарность" в RAW-подходе.
Субъективные оценки: Утверждения вроде "деревья — частный случай графов, поэтому сетевая модель лучше" игнорируют контекст применения. Для OLTP-задач реляционные модели часто эффективнее благодаря ACID-гарантиям.
2. Технические аспекты
2.1. Преодоление CAP-теоремы
Заявлено: CRUS выбирает AP (доступность и устойчивость к разделению), жертвуя согласованностью (C). Критика:
Автор не объясняет, как система обеспечивает конечную согласованность (eventual consistency). Например:
Нет механизма разрешения конфликтов при одновременном изменении одного юнита разными узлами.
Не описано, как обрабатываются "потерянные обновления" (Lost Update), которые неизбежны в AP-системах.
Упоминание PACELC-теоремы поверхностно. Если CRUS оптимизирована для задержек (EL), как это сочетается с гарантиями актуальности (PA)?
2.2. Безопасность
Заявлено:
Zero Trust + E2E-шифрование + Ed25519 для подписей. Критика:
Уязвимости в AES-CBC: Режим CBC без аутентификации (HMAC) подвержен атакам на паддинг (padding oracle). Автор игнорирует это, утверждая, что "аутентификация достигается через подписи", но подпись не защищает от модификации ciphertext.
Недостаток в авторизации: Система прав на уровне лендов слишком грубая. Например, как ограничить доступ к части данных внутри ленда?
2.3. Модель данных
Заявлено:
Графовая модель с шардированием на "ленды". Критика:
Проблема связей между лендами: Если узел в ленде A ссылается на узел в ленде B, как гарантируется атомарность их синхронизации?
Слабая типизация: Идея "реинтерпретации DOM как JSON" звучит рискованно. Например, если пользователь А редактирует XML-документ, а пользователь B видит его как JSON, это может привести к семантическим конфликтам.
2.4. Криптография
Заявлено:
Использование BN-254 для компактных подписей (32 байта вместо 64). Критика:
Криптостойкость BN-254: Упомянутые 100 бит недостаточны для долгосрочной безопасности. NIST рекомендует минимум 128 бит для симметричных алгоритмов.
Отсутствие реализаций: Автор признаёт, что "с реализациями всё плохо", но не предлагает пути решения (например, использование альтернатив вродя BLS12-381).
3. Практическая реализация
Заявлено:
CRUS уже можно "пощупать" на сайте crus.hyoo.ru. Критика:
Нет доказательств работоспособности:
Нет тестов производительности (например, latency при синхронизации 10 тыс. юнитов).
Нет сравнения с аналогами (IPFS, Cassandra, GunDB).
Сомнительные оптимизации:
Фиксированный размер юнита (128 байт) может привести к избыточному расходу памяти. Например, хранение булева значения (1 бит) занимает 128 байт — это 1024-кратное увеличение.
Генерация идентификаторов через Proof of Work (PoW) с префиксом 0xFF повышает энергозатраты без явных преимуществ.
4. Методологические изъяны
Игнорирование состояния искусства:
Нет ссылок на работы по CRDT (например, исследования Марка Шапиро) или децентрализованным базам (например, DynamoDB, Riak).
Упрощение Jepsen-тестов: автор "рефакторит" классификацию, но не приводит примеров тестирования CRUS через Jepsen-фреймворк.
Рекламные элементы:
Критика Хабра ("отношение к авторам скверное") выглядит как попытка перевести внимание с недостатков статьи.
Упоминание "монетизации рублём" в планах ставит под сомнение академическую честность проекта.
5. Рекомендации для автора
Углубить техническую аргументацию:
Привести схемы синхронизации лендов и разрешения конфликтов.
Объяснить, как достигается атомарность в RAW-подходе без WAL.
Добавить сравнительный анализ:
Сравнить CRUS с IPFS (децентрализация), Cassandra (AP-система), SQLite (ACID).
Исправить уязвимости в безопасности:
Перейти с AES-CBC на AEAD-режимы (например, AES-GCM).
Реализовать механизм fine-grained access control.
Провести практическое тестирование:
Опубликовать метрики производительности и результаты стресс-тестов.
Интегрировать Jepsen для проверки гарантий согласованности.
Итог
CRUS — смелая попытка переосмыслить архитектуру распределённых систем, но её текущее состояние ближе к теоретическому эссе, чем к готовому решению. Автору необходимо:
Избегать декларативных утверждений ("это возможно") в пользу доказательных ("мы достигли этого через алгоритм X").
Забавно автор от SOLID перешёл к DDD. При том что первое это набор принципов организации кода, а второе это стратегия проектирования всей системы. Вещи несравнимые.
UX это хорошо, но когда с пользователей сервиса начинают брать необъективно большие комиссии за разные услуги будь то аренда жилья или продажа авто, UX всем становится не интересен. Правильные решения менеджеров гораздо важнее любого UX.
Осенью 2024-го в нашей команде уже больше 80 сотрудников: 65 исследователей и 17 человек в подразделении рекрута респондентов.
Для чего в таком относительно небольшом продукте как Авито 80 сотрудников в UX отделе? Я почти уверен, придет грамотный HR и запустит масштабную оптимизацию. Квоты на 80 человек хватит на всю команду Авито в целом без учёта саппорта.
Авито пользовались миллионы людей до появления UX команд и до того как сервис стал большим в вопросе фич. Людям нравилась простота, удобство и отсутствие навязчивых платных услуг. И по факту пользователю любого сервиса всегда нужно э именно это. Стоимость пользования продуктом и его простота наиболее критичные метрики и правильный подход здесь даст вам постоянный рост пользователей. И необязательно быть исследователем, чтобы это понимать.
Марк Гурман отметил, что Apple неоднократно успешно догоняла конкурентов, как это было с Apple Maps
Только вот LLM это не карты. Переводчик в iOS как был убогим таким и остался с релиза. А если там с трансформерами не смогли нормально реализовать перевод то нет смысла ждать от них хорошую языковую модель в ближайшие 2-3 года
Внутренние исследования показали, что ChatGPT примерно на 25% точнее, чем Siri, и может ответить на 30% больше вопросов
Как же нелепо сравнивать заскриптованную Siri с LLM. А ещё нелепее выглядит утверждение о таком незначительном отставании от GPT. Почитать бы paper исследования
Причина, по которой стартапы “взлетают”, заключается в том, что люди работают как проклятые
А есть стартапы где не работают как проклятые но принимают правильные продуктовые решения и не тратят силы впустую. Сколько продуктов закрыла гугл до пандемии? Project Ara, Stadia, google+, Spark, Allo, Hangouts, Google Play Music, Nexus и Google One-линейки, Google glass. Список можно продолжать
Совет №1: старайтесь вести разработки именно в таком порядке — от сущностей до страниц. Не надо пихать весь код кучей в pages и потом пытаться это оптимизировать.
Это плохой совет. Оптимизировать структуру нужно там где это требуется. Если не знаете куда кидать компонент, лучше начинать с widget. Иначе будете тратить силы постоянно на размышления о том куда что запихать. FSD оч сильно тормозит скорость разработки если слишком запариваться, а профиты от декомпозиции со временем кажутся не такими очевидными.
/features в FSD по факту это недопапка. Потому что кроме экшен кнопок вы там вряд ли что либо будете хранить. Возьмём например крупную фичу которую бизнес решил добавить в приложение: визуальный редактор аватара пользователя. это фича или виджет?) для бизнеса это точно фича. Но пихать столько всего в папку фичи вы не будете. Тут идёт противоречие с бизнес моделью которое всех будет вводить в замешательство.
Ждать оперативного ответа на Email... Вы же прекрасно понимаете что email не работают если нужна оперативность. Идешь и пишешь коллеге в слак/телегу/любой мессенджер. Если совсем сложно, сразу ссылку на зум на 30 мин и вопрос решен. Зачем использовать устаревшие бюрократические инструменты? А потом удивления
Иногда кажется что люди не видят на рынке иных продуктов кроме тех что выпускает Apple..... AR/VR гарнитуры на рынке уже 10 лет. Вы только сейчас открываете для себя этот мир будучи дизайнерами. Не странно?
Компания Apple — отличный пример использования формы для создания уникального потребительского опыта. Их продукты упакованы в минималистичные, элегантные коробки с гладкими, округлыми формами, что подчёркивает премиальный характер продукции и вызывает чувство качества у потребителей.
А вы точно пользовались Vision Pro? Иначе бы не писали такое. Дизайн это не про визуал. Это в первую очередь про удобство. И вот как раз с этим у vision Pro проблемы, начиная с неправильной развесовки и внешнего аккумулятора , заканчивая непрактичным стеклом и бесполезным экраном спереди. Дизайн должен быть простым и соответствовать нуждам продукта. Поэтому пожалуйста, перестаньте видеть в дизайне лишь побрекушки и красотулички. Это не про это
переносы игр это типичный пиар ход. Они изначально знали что будет перенос, просто создают поводы для споров и обсуждений в сообществе чтобы подогреть интерес. Больше интереса - больше денег. А это бизнес , им плевать на саму игру, важны цифры в финансовых отчетах
нужна сегментация по регионам иначе общая оценка будет сильно сглажена
Тем временем:
if (isNewDiscountEnabled) {А где пруфы?
Компилятор компилирует не машинный код а ассемблерный который потом попадает в asm https://go.dev/doc/asm
Хорошо что есть Deepseek R1
Развернутая рецензия на статью "CRUS: принципиально новая архитектура работы с данными"
1. Структура и стиль изложения
Сильные стороны:
Статья построена как исследовательский манифест, что привлекает внимание к амбициозным идеям.
Использование метафор (например, "Святой Грааль работы с данными") делает материал доступным для неспециалистов.
Слабые стороны:
Несбалансированность теории и практики: Автор детально описывает концепции (CVRDT, шардирование), но избегает конкретных алгоритмов или схем реализации. Например:
Нет псевдокода для синхронизации лендов.
Не объяснено, как именно достигается "атомарность" в RAW-подходе.
Субъективные оценки: Утверждения вроде "деревья — частный случай графов, поэтому сетевая модель лучше" игнорируют контекст применения. Для OLTP-задач реляционные модели часто эффективнее благодаря ACID-гарантиям.
2. Технические аспекты
2.1. Преодоление CAP-теоремы
Заявлено: CRUS выбирает AP (доступность и устойчивость к разделению), жертвуя согласованностью (C).
Критика:
Автор не объясняет, как система обеспечивает конечную согласованность (eventual consistency). Например:
Нет механизма разрешения конфликтов при одновременном изменении одного юнита разными узлами.
Не описано, как обрабатываются "потерянные обновления" (Lost Update), которые неизбежны в AP-системах.
Упоминание PACELC-теоремы поверхностно. Если CRUS оптимизирована для задержек (EL), как это сочетается с гарантиями актуальности (PA)?
2.2. Безопасность
Заявлено:
Zero Trust + E2E-шифрование + Ed25519 для подписей. Критика:
Уязвимости в AES-CBC: Режим CBC без аутентификации (HMAC) подвержен атакам на паддинг (padding oracle). Автор игнорирует это, утверждая, что "аутентификация достигается через подписи", но подпись не защищает от модификации ciphertext.
Недостаток в авторизации: Система прав на уровне лендов слишком грубая. Например, как ограничить доступ к части данных внутри ленда?
2.3. Модель данных
Заявлено:
Графовая модель с шардированием на "ленды". Критика:
Проблема связей между лендами: Если узел в ленде A ссылается на узел в ленде B, как гарантируется атомарность их синхронизации?
Слабая типизация: Идея "реинтерпретации DOM как JSON" звучит рискованно. Например, если пользователь А редактирует XML-документ, а пользователь B видит его как JSON, это может привести к семантическим конфликтам.
2.4. Криптография
Заявлено:
Использование BN-254 для компактных подписей (32 байта вместо 64). Критика:
Криптостойкость BN-254: Упомянутые 100 бит недостаточны для долгосрочной безопасности. NIST рекомендует минимум 128 бит для симметричных алгоритмов.
Отсутствие реализаций: Автор признаёт, что "с реализациями всё плохо", но не предлагает пути решения (например, использование альтернатив вродя BLS12-381).
3. Практическая реализация
Заявлено:
CRUS уже можно "пощупать" на сайте crus.hyoo.ru. Критика:
Нет доказательств работоспособности:
Нет тестов производительности (например, latency при синхронизации 10 тыс. юнитов).
Нет сравнения с аналогами (IPFS, Cassandra, GunDB).
Сомнительные оптимизации:
Фиксированный размер юнита (128 байт) может привести к избыточному расходу памяти. Например, хранение булева значения (1 бит) занимает 128 байт — это 1024-кратное увеличение.
Генерация идентификаторов через Proof of Work (PoW) с префиксом 0xFF повышает энергозатраты без явных преимуществ.
4. Методологические изъяны
Игнорирование состояния искусства:
Нет ссылок на работы по CRDT (например, исследования Марка Шапиро) или децентрализованным базам (например, DynamoDB, Riak).
Упрощение Jepsen-тестов: автор "рефакторит" классификацию, но не приводит примеров тестирования CRUS через Jepsen-фреймворк.
Рекламные элементы:
Критика Хабра ("отношение к авторам скверное") выглядит как попытка перевести внимание с недостатков статьи.
Упоминание "монетизации рублём" в планах ставит под сомнение академическую честность проекта.
5. Рекомендации для автора
Углубить техническую аргументацию:
Привести схемы синхронизации лендов и разрешения конфликтов.
Объяснить, как достигается атомарность в RAW-подходе без WAL.
Добавить сравнительный анализ:
Сравнить CRUS с IPFS (децентрализация), Cassandra (AP-система), SQLite (ACID).
Исправить уязвимости в безопасности:
Перейти с AES-CBC на AEAD-режимы (например, AES-GCM).
Реализовать механизм fine-grained access control.
Провести практическое тестирование:
Опубликовать метрики производительности и результаты стресс-тестов.
Интегрировать Jepsen для проверки гарантий согласованности.
Итог
CRUS — смелая попытка переосмыслить архитектуру распределённых систем, но её текущее состояние ближе к теоретическому эссе, чем к готовому решению. Автору необходимо:
Избегать декларативных утверждений ("это возможно") в пользу доказательных ("мы достигли этого через алгоритм X").
Устранить методологические пробелы (CAP, безопасность, типизация).
Предоставить независимой аудитории возможность проверить заявленные преимущества.
Пока статья вызывает больше вопросов, чем ответов, но при доработке CRUS может стать интересным исследовательским направлением.
Забавно автор от SOLID перешёл к DDD. При том что первое это набор принципов организации кода, а второе это стратегия проектирования всей системы. Вещи несравнимые.
FSD это просто структура папок а не архитектура
Полезнее было бы рассмотреть примеры из реального опыта. Публикация как мотивирующая получилась слишком абстрактной и не цепляющей.
Похоже на ответ ChatGPT
UX это хорошо, но когда с пользователей сервиса начинают брать необъективно большие комиссии за разные услуги будь то аренда жилья или продажа авто, UX всем становится не интересен. Правильные решения менеджеров гораздо важнее любого UX.
Для чего в таком относительно небольшом продукте как Авито 80 сотрудников в UX отделе? Я почти уверен, придет грамотный HR и запустит масштабную оптимизацию. Квоты на 80 человек хватит на всю команду Авито в целом без учёта саппорта.
Авито пользовались миллионы людей до появления UX команд и до того как сервис стал большим в вопросе фич. Людям нравилась простота, удобство и отсутствие навязчивых платных услуг. И по факту пользователю любого сервиса всегда нужно э именно это. Стоимость пользования продуктом и его простота наиболее критичные метрики и правильный подход здесь даст вам постоянный рост пользователей. И необязательно быть исследователем, чтобы это понимать.
Только вот LLM это не карты. Переводчик в iOS как был убогим таким и остался с релиза. А если там с трансформерами не смогли нормально реализовать перевод то нет смысла ждать от них хорошую языковую модель в ближайшие 2-3 года
Как же нелепо сравнивать заскриптованную Siri с LLM. А ещё нелепее выглядит утверждение о таком незначительном отставании от GPT. Почитать бы paper исследования
Это же не новая архитектура а улучшение существующей
А есть стартапы где не работают как проклятые но принимают правильные продуктовые решения и не тратят силы впустую. Сколько продуктов закрыла гугл до пандемии? Project Ara, Stadia, google+, Spark, Allo, Hangouts, Google Play Music, Nexus и Google One-линейки, Google glass. Список можно продолжать
Это плохой совет. Оптимизировать структуру нужно там где это требуется. Если не знаете куда кидать компонент, лучше начинать с widget. Иначе будете тратить силы постоянно на размышления о том куда что запихать. FSD оч сильно тормозит скорость разработки если слишком запариваться, а профиты от декомпозиции со временем кажутся не такими очевидными.
/features в FSD по факту это недопапка. Потому что кроме экшен кнопок вы там вряд ли что либо будете хранить. Возьмём например крупную фичу которую бизнес решил добавить в приложение: визуальный редактор аватара пользователя. это фича или виджет?) для бизнеса это точно фича. Но пихать столько всего в папку фичи вы не будете. Тут идёт противоречие с бизнес моделью которое всех будет вводить в замешательство.
Юзать транспилятор TS прямо в браузере откровенно говоря не лучшая идея. Минификация кода и treeshaking без сборщика? 😂
Зачем вы передергиваете, прекрасно понятно что имел ввиду автор поста
А где статистика? Или пост ради хайпа?
Ждать оперативного ответа на Email... Вы же прекрасно понимаете что email не работают если нужна оперативность. Идешь и пишешь коллеге в слак/телегу/любой мессенджер. Если совсем сложно, сразу ссылку на зум на 30 мин и вопрос решен. Зачем использовать устаревшие бюрократические инструменты? А потом удивления
Иногда кажется что люди не видят на рынке иных продуктов кроме тех что выпускает Apple..... AR/VR гарнитуры на рынке уже 10 лет. Вы только сейчас открываете для себя этот мир будучи дизайнерами. Не странно?
А вы точно пользовались Vision Pro? Иначе бы не писали такое. Дизайн это не про визуал. Это в первую очередь про удобство. И вот как раз с этим у vision Pro проблемы, начиная с неправильной развесовки и внешнего аккумулятора , заканчивая непрактичным стеклом и бесполезным экраном спереди. Дизайн должен быть простым и соответствовать нуждам продукта. Поэтому пожалуйста, перестаньте видеть в дизайне лишь побрекушки и красотулички. Это не про это
Хабр себя убивает такими useless публикациями