Минимализм в UI часто воспринимается как эстетический выбор. Но на самом деле за ним стоят измеримые нейробиологические механизмы: ограничения рабочей памяти, дофаминовое подкрепление, гештальт-принципы восприятия и влияние цвета на уровень стресса.
В этой статье я разберу, почему минималистичные интерфейсы действительно проще для мозга, как это влияет на доверие и конверсию.
ЗРИ В КОРЕНЬ:
Про вызовы текущего момента в очень простой двоичной логике (специально для ХАБРа).
В качестве введения
Те, кто системнее понимает прикладную задачу (структуру, условия, взаимосвязи), тот сделает лучшую постановку задачи и достигнет больших результатов от ее решения. Поэтому предлагаю читателям ХАБРа познакомиться с системным подходом для анализа Прикладного промышленного мира и постановкой задачи по радикальному повышению экономической эффективности деятельности промышленных предприятий/цепей поставок от эксперта консалтинговой группы компаний «Приоритет».
Я поделюсь знаниями из нашей «внутренней кухни», чтобы содействовать сближению видения представителей Прикладного промышленного и IT миров на постановку задачи: «Что делать, чтобы стать лучше? Намного лучше!».
Глава 1. «Бытие определяет сознание, или что происходит и к чему это обязывает?»
Пара вопросов в качестве разогрева и гимнастики для ума:
В этой статье я представлю мой завершённый очень быстрый алгоритм преобразования дат.. Он обеспечивает существенный прирост скорости, по величине сравнимый с приростом, достигнутым предыдущим самым быстрым алгоритмом (Neri-Schneider 2021) относительно его предшественника (C++ Boost). Полная реализация алгоритма на C++ выпущена как свободное и бесплатное ПО (лицензия BSL-1.0).
Алгоритм генерирует точные результаты за период ±1,89 триллиона лет, поэтому подходит для обработки полного 64-битного времени UNIX (в секундах).
В этом посте будут объяснены две стратегии оптимизации WebAssembly, которые не так давно были реализованы в движке V8 и вошли в версию браузера Google Chrome M137. Речь пойдёт о спекулятивном встраивании call_indirect inlining и о поддержке деоптимизации в WebAssembly. В сочетании два этих приёма помогают генерировать более качественный машинный код, так как основаны на допущениях, которые строятся, исходя из обратной связи, поступающей от среды исполнения. Благодаря этому, WebAssembly выполняется быстрее, особенно это касается программ WasmGC. Например, проверив эти приёмы на наборе микробенчмарков, написанных на Dart, видим, что комбинация двух оптимизаций даёт ускорение в среднем более чем на 50%. В более крупных и реалистичных приложениях и на тех бенчмарках, которые рассмотрены ниже, достигается ускорение между 1% и 8%. Деоптимизации — также очень важная составляющая для дальнейшей оптимизации в будущем.
Когда вы заходите на сайт, ему нередко нужно знать, какой у вас браузер и устройство. Это помогает показывать подходящую версию страницы, например мобильную или полную, а также включать только те функции, которые может поддерживать ваш браузер.
Раньше для этого можно было использовать только строку User‑Agent, которую браузер отправляет автоматически, но её избыточность и сложность парсинга стали сдерживать развитие веба. Client Hints предлагает другой подход: вместо того чтобы сразу раскрывать всю информацию, браузер передаёт только те данные, которые действительно нужны сайту.
На связи Степан из команды Яндекс Браузера. Сегодня поговорим о том, как мы переходим от устаревшего User‑Agent к современной технологии Client Hints. В статье разберём, почему User‑Agent стал проблемой, как работают хинты под капотом и какие перспективы у перехода на новую технологию.
Прошло почти 5 лет с момента вскрытия уязвимости кнопки «Безопасность» в сервисе Яндекс.Такси, который ныне зовётся YandexGo. Но я снова решил сожрать тот же кактус.
И отправил двух дорогих мне людей на этом сервисе...
В мире современного программирования эффективное использование ресурсов, включая память, является ключевым аспектом разработки приложений. Сегодня мы поговорим о том, как можно оптимизировать доступные ресурсы в процессе разработки.
Язык программирования C#, несмотря на то, что обеспечивает автоматическое управление памятью с помощью механизма сборки мусора (GC), требует от разработчиков специальных знаний и навыков для оптимизации работы с памятью.
Всем привет! Сегодня хотелось бы затронуть такую тему, как оптимизация CPU для ваших приложений на C#. В целом, эффективное использование вычислительных ресурсов, включая процессор, является одним из главных аспектов разработки программного обеспечения. В этой статье мы рассмотрим несколько ключевых подходов и стратегий оптимизации нагрузки на CPU в языке программирования C#.
В одном из моих докладов по ассемблеру я показал список из 20 самых часто исполняемых команд на среднем десктопе x86 с Linux. Разумеется, в этом списке были привычные mov, add, lea, sub, jmp, call и так далее; неожиданным стало включение в него xor — «eXclusive OR». В эпоху, когда я занимался хакингом на 6502, наличие XOR было почти абсолютно точным указанием на то, что найдена часть кода, связанная с шифрованием, или какая-то подпрограмма обработки спрайтов. Поэтому удивительно, что машина с Linux, просто занимающаяся своими делами, выполняет такое количество этих команд.
Но потом мы вспоминаем о том, что компиляторы любят генерировать xor при присвоении регистру нулевого значения.
С нуля собрали кредитное PWA-приложение за 6 месяцев. Рассказываем, какие решения помогли быстро выйти на рынок и выдержать рост.
Обычно, в 1С много показателей и отчётов по ним, а при желании почти каждый можно собрать под свои потребности, так как платформа гибкая и легко поддается доработке. Но это долго и разработка стоит дорого, особенно если речь про кастомный отчёт под руководителя. А с обработкой можно получать короткий отчет сразу в Telegram.
В статье расскажу, как работает решение, для кого оно будет полезным, а еще поделюсь историей, как размещали продукт на Инфостарте и почему его сначала вернули на исправление.
Всем привет! Меня зовут Сергей Бунатян, я руководитель службы в Техплатформе Городских сервисов Яндекса.
На сегодняшний день существует довольно много брокеров сообщений. Наиболее часто используемыми в индустрии, пожалуй, будут те, которые, реализуют парадигму очереди сообщений. Самых известных представителей вы наверняка знаете, — Apache Kafka и RabbitMQ, а внутри Яндекса широко используется Logbroker. И, тем не менее, как нетрудно догадаться из этого вступления, мы зачем‑то решили написать свой брокер сообщений.
Сегодня я расскажу про нашу систему, которая называется STQ — Sharded Tasks Queue. По названию системы можно было бы подумать, что это ещё один сервер очередей, однако это будет не совсем верно. STQ — это скорее message broker.
В этой статье я постараюсь рассказать о том, какие задачи перед нами стояли и как это нас привело к решению написать что‑то своё. А заодно поделюсь опытом эксплуатации нашей системы и расскажу про влияние STQ на опыт разработчиков.
Вы работаете над устоявшимся продуктом, в котором уже достигли PMF. Ваша команда выкатывает новую фичу за фичой. A/B‑тесты показывают +3% к конверсии. Продакт ставит задачам статус «Done», команда получает поздравления от СРО. А через два месяца выясняется: 40% пользователей по‑прежнему отваливаются на том же критичном шаге. Проблема не решена. Но в бэклоге она больше не приоритетна — там уже 47 других «важных» задач. СРО требует результат. Кажется что‑то не так.
Привет, Хабр! Меня зовут Алексей, я занимаюсь беспроводными технологиями и сегодня хочу рассказать об опыте проведения большого исследования - опроса абонентов провайдеров, который охватил почти сто тысяч абонентов и длился больше трёх лет. История, которая началась как товарищеский спор, но которая быстро смогла нас всех увлечь и поразить полученными результатами. Это был действительно увлекательный опыт. Первые опросы мы проводили в домовых чатах, до которых могли достучаться, и нужно сказать, что это, наверное, самый действенный механизм взаимодействия с целевой аудиторией. Затем мы создавали опросы в Google и Яндекс.Формах, пробовали даже поднять свою опросную платформу на базе Limesurvey, привлекали в качестве помощников в опросе студентов (спасибо коллегам из вузов и студенческих профсоюзов). Некоторые ответы ставили нас в тупик, а некоторые порождали ещё больше вопросов. Тогда мы отступали на шаг, проводили проблемные интервью с некоторыми из опрашиваемых и вновь повторяли опросы.
Это история о том, как написать компилятор Python, генерирующий оптимизированные ядра и при этом позволяющий сохранить простоту кода.
Этот пост станет глубоким разбором того, как мы снизили задержки P95 конечной точки API с 5 до 0,3 секунды при помощи нишевого трюка computer science под названием «фильтр Блума».
Мы расскажем о том, почему конечная точка была медленной, о решениях, которые мы рассматривали для повышения её скорости, и о критериях выбора между ними. Также мы объясним, как всё это устроено внутри.
Меня зовут Наталия Зеленкина, я управляю командой, которая оцифровывает продажи нефтехимической продукции — от поиска клиента до заключения контракта и дальнейшего сопровождения. Моя CRM-система обслуживает 1200 пользователей: от менеджеров по продажам до логистов и производственников.
До этого я десять лет работала в финтехе. Разрабатывала банковские приложения, карточные продукты, транзакционные сервисы. Привыкла к метрикам типа конверсии и среднего чека. А потом попала на производство.
В первую неделю коллега уронил телефон в реактор полимеризации. Экран расплавился. Началось помутнение гранул. Тонны полипропилена превратились в брак. А мы не могли запустить новую функцию на склад, пока не вывезем весь этот брак.
Я тогда поняла — здесь все по-другому.
Однажды я заехал в гости к знакомому — владельцу цеха по металлообработке и невольно оказался свидетелем скандала. Произошло это в день зарплаты.
Чтобы был понятен контекст, немного опишу суть процесса.
Конечное изделие состоит из двух деталей (условно "мама" и "папа"), которые вытачиваются из одного и того же материала — стального прутка. Для упрощения представим, что продукция собирается из болта и гайки. Гайка накручивается на болт — изделие готово.
Каждый станок настроен на обработку конкретного диаметра прутка. Пока есть материал с таким диаметром, станки не перенастраивают, меняют только инструмент, чтобы получился болт или гайка.
Сначала станок изготавливает гайки, а когда материал выработан наполовину, нужно позвать мастера, чтобы поменять инструмент для производства болтов.
В задачу оператора станка входит своевременно заряжать материал, выгребать готовые детали, собирать конечный продукт и упаковывать его по коробкам.
Не раз слышал от коллег и сам сталкивался с ситуацией, когда пользователь в чате, отзыве или даже в инциденте попутно делится ценным предложением по улучшению. И что в результате? Ему вежливо предлагают оформить отдельную заявку/FR (особенно когда это происходит внутри компании). А если это внешний клиент, то ему могут ответить что-то вроде "спасибо, мы учтем", но дальше оно не пойдет и этого предложения никто, кроме оператора, не увидит.
Браво! Так мы теряем уникальную информацию.
Во-первых, есть явление, описываемое правилом 1-9-90:
1% — создает контент
9% — взаимодействуют (лайки/дизлайки, репосты, коменты)
90% — просто читают/смотрят (их видно только по количеству просмотров/посещений)
В случае с обратной связью всё еще более плачевно — от 0.1 до 1% (отчеты об ошибках, вопросы в техподдержку или просто "мне не нравится, как это работает")
И как же не упустить самое главное?
Яндекс Карты — это не просто приложение для навигации, а один из самых высоконагруженных мобильных сервисов с широкой аудиторией. В центре всех наших сценариев — сама карта, которая уже сегодня не уступает по сложности отдельным игровым движкам. Мы постоянно работаем над тем, чтобы сделать её более удобной для ориентирования, и постепенно идём к высокодетализированным и реалистичным картам будущего: добавляем трёхмерные здания, разметку на дорогах, детализированные развязки и другие городские объекты.
Но чем богаче визуальное и информационное наполнение, тем выше требования к устройствам, на которых работает приложение. Улучшая пользовательский опыт с помощью новых технологий и более детальной картографии, мы сталкиваемся с постоянным ростом потребления ресурсов — прежде всего оперативной памяти (RAM). Наша задача — находить баланс между развитием продукта и сохранением его стабильной и быстрой работы на разных устройствах, включая самые бюджетные модели.
Меня зовут Игорь Зверев, я руководитель группы разработки автонавигации в Яндекс Картах. Сегодня я расскажу, как мы подошли к решению этой задачи: что изменили в процессе разработки, как создали и используем систему RAM‑классов для выпуска требовательных функций и какие технические выводы сделали на этом пути.
