Привет, Хабр! Я – Михаил Суворов, ведущий дизайнер коммуникаций в X5 Tech. В статье я ставлю эксперименты над ИИ, пока у них нет возможности “дать сдачи” человеку. Если серьёзно, то проверим гипотезу, может ли нейросеть, генерирующая изображения, иметь собственный “авторский стиль”.
Поздравляем вас с днем 4.04! Сегодня не только красивая дата, но и день интернета по версии Папы Римского. Отличный повод поговорить о роли страницы с ошибкой 404 и полюбоваться на лучшие образцы креативности. Под катом — немного истории и много картинок: смешных, красивых и интерактивных.
Привет! Сегодня хочу поделиться опытом разработки многостраничного сайта и на конкретном примере рассказать, как действую, чем руководствуюсь и на что обращаю внимание с самого начала. Погнали.
Мой первый on-call выдался нелегким. Недели тренингов и обучения не подготовили меня к тому что придется бегать по Slack каналам различных команд и искать того, кто может что либо знать о какой-то из частей системы. Оказалось что многие страницы в корпоративной Wiki уже не обновлялись несколько лет. Команды хранили свою документацию кто где хотел: кто в Wiki, кто в Google Docs, кто в GitHub и т.д. Наш on-call был не идеален: 2 человека выходили на дежурство 24/7. Один был ответственен за всю инфраструктуру (MySql, Cassandra, Kafka, ElasticSearch, Nomad и т.д.), второй же был Developer on-call и отвечал за все микросервисы и различные легаси системы, что в сумме давало около 300 различных сервисов от 7 команд на самых различных стеках и фреймворках (Java, Scala, Node, Go). Но что меня больше всего раздражало - так это невозможность быстро оценить на высшем уровне как проходит и обрабатывается запрос от пользователя. Диаграммы для разных бизнес частей точно также были либо устаревшими, либо без прилегающей документации, либо для какой-то бизнес логики не было ничего. И вот тогда мне пришла идея, что было бы неплохо иметь диаграммы, в которых можно не только нажать на любой элемент и добыть о нем более детальную информацию, но также получить ссылки на другие диаграммы и динамически их подгружать. Мне хотелось иметь возможность быстро разобраться в неизвестной распределенной системе, не переключаясь между диаграммой и документацией в Google Docs или Wiki. Именно так я начал работать над проектом Schem.io.
Предупреждение: в статье содержится большое количество GIF-изображений.
Всем привет! Меня зовут Георгий, я старший разработчик‑исследователь в MTS AI. Одной из задач, которыми я занимаюсь в компании, является умная видеоаналитика. Это мощный инструмент, особенно с учетом современных технологий искусственного интеллекта, который может использоваться во многих отраслях: от торговли до обслуживания клиентов.
При этом у сегодняшних систем видеоаналитики есть существенное ограничение: они заточены под узкие задачи и конкретные типы событий — например, распознавание автомобильных номеров, пересечение границ, детектирование лиц. Конечно, прогресс не стоит на месте, и за прошедший год появилось много мультимодальных моделей, способных отвечать на широкий спектр вопросов по видео — но они работают лишь на очень коротких роликах и требуют серьезных вложений в «железо».
Тем не менее представьте, что можно создать общую систему видеоаналитики, которая заранее не настроена на определенные события. Она гибкая и умеет понимать задачи во время общения с пользователем. Запросы могут быть разнообразными, например: «предупреди меня, если в кадре произойдет ЧП, например, пожар или драка» или «я хочу найти кадры с желтыми автомобилями такси».
Можно ли найти подход, при котором система сможет отвечать на широкий спектр вопросов по видео, но при этом будет способна обрабатывать длинные видеозаписи и останется нетребовательной к железу? В этой статье я расскажу про один из способов создания такого решения — на примере поиска по видео.
Сколько времени я должен уделять UI/UX? Имеет ли это вообще значение для B2B-компаний?
Очень часто мы определяем ценность продукта, оценивая его внешний вид, не углубляясь в технические характеристики или анализ экономической выгоды. В конце концов, сравнивать характеристики и моделировать сценарии окупаемости инвестиций - не самое приятное занятие!
Гораздо проще предположить, что продукт с хорошо продуманным ux/ui, скорее всего, лучше других... верно же?
Фараон, вышедший в далеком 1999 году был одной из первых игр, которые предлагали поэтапное строительство зданий. Да которые еще и требовали наличие разных ресурсов. Навскидку могу припомнить серию Settlers, Majesty и может еще парочку. После Цезарь III, исхоженного вдоль и поперек, где основным ресурсом при постройке зданий были монеты, это было действительно удивительно и ново. Особым удовольствием было наблюдать, как город живет своей жизнью в процессе постройки монументов, помню просто построил минимальную необходимую инфраструктуру для монумента и просто наблюдал как архитекторы жаловались на недостаток материалов, рабы бегали то на фермы, то на строительную площадку, торговцы периодически продавали кирпичи. Ну и остальной город, конечно, жил своей жизнью, можно даже забыть на какое время про отдельные части города, игра все равно не остановится, и тут понимаешь почему игра до сих пор остается одним из лучших градостроев: отличительная особенность серии — «баланс», баланс отточенный в мелочах. Восстанавливая эту часть игры, я не перестаю удивляться как это все было реализовано на тех аппаратных средствах, замечу, очень и очень небольших, 64Мб оперативки было далеко не у всех. Одним из нововведений монументов было то, что они были составными зданиями, отдельные части могли быть заменены на другие, что в общем давало возможность из одного набора текстур создавать разные по виду здания. Это сейчас кажется, что такой подход есть в любой игре, но в 99 такой механикой могли похвастаться немногие. Сначала я пытался восстановить оригинальный алгоритм отрисовки, но быстро понял, что столько if не осиливаю не только я, но и компилятор, пришлось велосипедить.
В прошлый раз здорово пообсуждали тему намагничивания неодима вот тут. Но нерассказанной осталась история одной катушки. Не той, которую скрутило всмятку на первых этапах испытаний, а той, которая была задизайнена после такого эпичного фейла. В принципе, изделие должно было получиться простым: 20 витков эмальпровода, сложенного вчетверо, в два слоя, на каркасе диаметром 50мм и такой же примерно высоты. Но был нюанс — при прохождении тока 10кА (кило‑Ампер, значит), первое решение «по‑простому» быстро схлопывается из‑за возникающих в проводниках Амперовых сил. Так что надо было придумать что‑то покрепче и намотанное поплотнее, дабы не дать возможности проводникам перемещаться по катушке во время рабочего импульса.
Каждый геймер знаком с ощущением «И ещё одну каточку... И спать», когда невозможно оторваться от экрана. Это состояние называется игровой зависимостью или аддиктивностью. Но что именно делает игру такой увлекательной и как разработчики игр используют эту информацию для создания более привлекательных продуктов? В этой статье мы рассмотрим основные факторы, которые влияют на аддиктивность игры.
В процессе разработки продукта или фичи неизбежно возникает необходимость работы с текстом. Если в команде есть UX‑редактор, то именно ему поручается этот этап. Он играет роль дополнительного «мозга» для создания удобного и бесшовного флоу. Кроме того, UX‑редактор обладает высокой продуктовой насмотренностью — через его руки проходит множество макетов, что позволяет ему выявлять потенциальные риски, последствия и пересечения с другими продуктами в компании и на рынке.
Но бывает и такое, что в команде нет UX‑редактора и работу с текстом приходится брать в свои руки. Для таких случаев я решил поделиться своими принципами при работе с текстом, которые помогут вам самостоятельно проверять текст на качество
Привет, Хабр! Меня зовут Вадим, я мобильный разработчик в СберМаркете. В этой статье расскажу, как провести профилирование (оно же измерение производительности или оценка перформанса) в react native приложениях: как выявить источник проблем и решить их. В русскоязычных источниках не так много информации по данной теме. Я потратил немало времени, чтобы со всем разобраться, поэтому попытаюсь восполнить этот пробел и для вас :)
В крупных проектах уделяется большое внимание деталям: дизайнеры, аналитики и продуктовые менеджеры продумывают все до мелочей, чтобы максимально улучшить пользовательский опыт. В дизайне такой важной деталью становится pixel-perfect-вёрстка. Разработчики реализуют тонкости дизайна, но иногда происходит расхождение платформенного рендеринга Android TextView и Figma Text.
Сегодня трудно найти веб сайт, на котором нету хотя бы одного изображения, может быть у вас есть такой пример? На странице в интернете можно сразу увидеть много разных изображений: фото пользователя в личном кабинете, фото товара на маркетплейсе, иконка на вкладке браузера, иконка корзины на кнопке «добавить в корзину», анимированное изображение‑открытка от бабушки в мессенджере, [и еще тысяча примеров].
Если вы как‑то связаны с вебом то вам будет полезно иметь общее представление об этих images, как минимум, и уметь с ними работать как максимум. Давайте попробуем разобраться с этим вопросом?
Всем привет! В этой статье я хотел бы поделиться своими мыслями о том, почему виртуального DOM можно избежать при создании реактивности сегодня. Я работаю со всем этим уже около полутора лет, создавая фреймворк Cample.js, и у меня есть некоторые соображения по этому поводу.
В недалеком прошлом, я рассказывал, про то, как можно создавать свои кастомные элементы через генерацию мэша, будет полезно ознакомиться для понимания многих аспектов этой статьи.
Сегодня будем разбирать альтернативный способ создания, использую VectorApi.
Рассмотрим, как работает painter2D, какими функциями обладает и зачем оно может вам пригодиться.
Всем привет! Меня зовут Анна Бугрий, я старший продуктовый дизайнер и работаю в сфере шесть лет. Последние два года создаю совершенный опыт и дизайн для пользователей СберМаркета. Команда, в которой я работаю, отвечает за главный экран приложения и навигацию на всех платформах.
В этой статье я расскажу, как мы решились полностью переделать главный экран, какие исследования для этого потребовались и как мы проходили этот сложный путь.
Приложениями пользуются разные люди, и некоторым из них для этого нужны вспомогательные технологии — например, скринридеры (программы экранного доступа). Такие программы могут озвучить контент на странице, если приложение соответствует определённым стандартам. Например, они могут прочесть текст из параграфов и заголовков, списки, альтернативные описания изображений, ссылки, переключатели и другие интерактивные элементы. Таким образом скринридеры обеспечивают доступ незрячих пользователей к контенту и сервисам.
Повышая доступность интерфейса для пользователей скринридеров, мы также улучшаем его доступность и для людей с другими особенностями здоровья. Например, для тех, кто использует системную настройку «Экран вслух» или взаимодействует с интерфейсом с помощью голосового управления.
Однако навигация со скринридерами по страницам и экранам отличается от обычной, поэтому нужно соблюдать несколько правил при сборке интерфейса приложений.
Привет! Я Вячеслав Дорогинин, занимаюсь фронтендом WebView клиентского приложения Лавки. В этой статье расскажу, как мы адаптировали приложение для работы с популярными скринридерами, с какими трудностями столкнулись и как их решили.
Максим Тулов в своем обзоре удивился нашим "самодельным" корпусам и спросил почему бы не воспользоваться готовым китайским решением. IP-камера довольно типовой продукт, и подходящих решений на любой площадке — хоть отбавляй. Так зачем изобретать велосипед?
О причинах, а также о том как по пути изобрести пару велосипедов с треугольными колесами и пойдет сегодня речь.
