Дайджест собирает свежие статьи по дизайну интерфейсов, а также инструменты, паттерны, кейсы и исторические рассказы с 2009 года. Я тщательно фильтрую большой поток подписок, чтобы вы могли прокачать свои профессиональные навыки и лучше решить рабочие задачи. Предыдущие выпуски: апрель 2010-март 2018.
Я занимаю должность консультанта по UX для одного из партнеров компании Mendix, и мне часто приходится работать с небольшими самоорганизованными командами, которые создают отличные приложения для решения внутренних проблем. Моя задача — совершенствовать UX в этих приложениях.
Лучшие моменты в моей работе — когда меня совершенно застают врасплох оригинальность и креативность подходов к разрешению проблем и я оказываюсь вынужден объяснять, почему некоторые, казалось бы, логичные практики на деле оказываются плохой идеей.
Все решения, которые я здесь предлагаю, не являются единственно верными, в каждом случае бывают исключения; рассматривайте все написанное ниже не как прямое руководство к действию, а как отправную точку для дальнейших рассуждений.
Читать полностью »
Людей, которые не просто хотя бы раз писали UI-тесты, а делали бы это в коммерческих проектах, довольно мало, потому что эту часть разработки очень сложно продать заказчику и аргументировать менеджеру, зачем они нужны и почему занимают столько времени. Новосибирская компания Improve Digital решилась на этот шаг по ряду причин, в частности из-за того, что разрабатываемый проект долгосрочный и с большим потенциалом дальнейшего развития.
Далее расшифровка выступления Михаила Домрачева на AppsConf 2017, в ходе которого он рассказал, как на практике внедрить UI-тесты в iOS проектах, и поделился мыслями, когда это действительно необходимо, а когда — излишне.
Забегая вперед, отметим, что тут есть и плюсы, и минусы. Но, на наш взгляд, существенное уменьшение количества дизайн-багов без огромных трудозатрат ручного тестирования — неоспоримое преимущество, которое любого должно примерить с небольшими возникающими трудностями.
В статье изложены принципы построения инфраструктуры локальной системной шины, соединяющей агенты одного сегмента стыка простого исполнителя STI версии 1.0 в объёме кристалла СБИС или ПЛИС. Рассмотрена организация дешифратора адреса, коммутаторов шин чтения данных и выборки исполнителя. Приведен пример описания шинной инфраструктуры сегмента STI на языке Verilog. Предложены варианты подключения исполнителей к сегментам шины с меньшей разрядностью данных.
Читать полностью »
В статье предложена организация взаимодействия функциональных блоков в объёме кристалла СБИС, а именно: процессорных ядер, контроллеров DMA и мостов системных шин с периферийными блоками, такими как: контроллеры GPIO, SPI, I2C, UART, таймеры и широтно-импульсные модуляторы – ШИМ. Рассмотрен набор сигналов и протокол обмена стыка простого исполнителя – локального системного интерфейса, реализующего взаимодействие перечисленных блоков кристалла. Приведены примеры синтезируемых моделей контроллера GPIO и регистрового файла, поддерживающие описанный интерфейс.
Читать полностью »
— Вы заметили, сэры, какие стоят погоды?
— Предсказанные, — сказал Роман.
— Именно, сэр Ойра-Ойра! Именно предсказанные!
(Понедельник начинается в субботу)
В настоящее время большинство сайтов представляют собой, по сути, обычную программу, которая обрабатывает те или иные действия пользователей. Для того, чтобы упрощать жизнь программистам, реализованы десятки фреймворков, помогающих решать те или иные задачи.
Если рассматривать программирование GUI или UI вообще, то в обобщенном случае UI представляет собой множество слабосвязанных задач в одном пакете.
Например, раздел "погода" на главной страничке поисковика является просто индикатором. Выбрав тему, мы можем увидеть дождик или солнышко на фоне (еще один вариант индикатора погоды). Нужно ли устанавливать взаимосвязь между разделом "погода" и темой? С точки зрения минимизации компьютерных расходов — безусловно. Не стоит перезапрашивать данные, полученные однажды. Однако, с точки зрения разработки, программирование слабосвязанных вещей может тянуть за собой настолько большие трудозатраты, что иногда проще отказаться от связанности и два раза запросить одни и те же данные.
О программировании слабосвязанных вещей в вебе мы и поговорим в этой статье.
В эти праздники мы входим с материалами про работу игрового техлида, про фичеринг в новом App Store, Мобиусами и Google Play Awards, игровыми движками и лучшими венрсиями себя. Следующий наш выпуск выйдет через две недели. Всем весны!
Мы строим свою дизайн-систему Paradigm с 2012 года. Но такого лютого взрыва интереса к теме с уймой новых примеров и публикаций, как в последние пару лет, ещё не было. В прошлом году наконец-то вышла книга Brad Frost «Atomic Design» и про дизайн-системы говорят вообще все. Правда, большинство статей — бесконечное пережёвывание теории модульного дизайна, про практику внедрения кроме Nathan Curtis почти никто не пишет. Кроме того, хотя заслуга Брэда в популяризации идеи модульного дизайна неоценима, но и сам подход, и метафора «атомарности» / «молекулярности» существовали до него (Nathan Curtis пишет, что ещё Dell в середине 90х делал компонентную систему с такой же терминологией, а в современный обиход «atomic design» ввёл Jeremy Keith в районе 2011 года).
Android почти исполнилось десять лет.
Мы решили отметить это праздничным чаепитием со всеми, кто пришел в питерский офис Яндекса на второй митап Android Paranoid. Сказано — сделано. К нашему сожалению, маршмеллоу, шоколадное печенье и желейные бобы закончились еще 28 марта.
Вместо них — доклады, записанные на видео, и короткая выжимка полезной информации для Android-разработчиков. Под катом о том,
В этой статье я хочу поделиться своим личным опытом, связанным с правильной организацией кода (архитектурой). Правильная архитектура существенно упрощает долгосрочную поддержку.
Это очень философская тема, поэтому я не могу предложить ничего более, чем мой субъективный анализ и опыт.
Мой начальный опыт программиста был весьма безоблачным – я без лишних проблем клепал вебсайты-визитки. Писал код, как я это сейчас называю “в строчку” или “полотном”. На маленьких объемах и простых задачах все было хорошо.
Но я сменил работу, и пришлось разрабатывать один единственный вебсайт в течение 4-х лет. Естественно, сложность этого кода была несопоставима с визитками из моей прошлой работы. В какой-то момент проблемы просто посыпались на меня – количество регрессии зашкаливало. Было ощущение, что я просто хожу по кругу – пока чинил “здесь”, сломал что-то “там”. И поэтом это “здесь” и “там” банально менялось местами и круг повторялся.
У меня исчезла уверенность в том, что я контролирую ситуацию – при всем моем желании недопустить баги, они проскакивали. Все эти 4 года проект активно разрабатывался – мы улучшали уже существующий функционал, расширяли, достраивали его. Я видел и чувствовал, как удельная стоимость каждого нового рефакторинга/доработки растет – увеличивался общий объем кода, и соответственно увеличивались затраты на любую его правку. Банально, я вышел на порог, через который уже не мог переступить, продолжая писать код “в строчку”, без использования архитектуры. Но в тот момент, я этого еще не понимал.
Читать полностью »
