Статье 14 лет. Но, что удивительно, перевода этой классики на Хабре нет. Значит, будет.

Итак, вы называете себя «проектировщиком интерфейсов»? Если не сможете на все вопросы ответить быстро и обоснованно — вон из профессии!

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

А если вы не знаете, что такое «закон Фиттса», просто пройдите тест, не подсматривая в ответы. Это прояснит, какими стереотипами вы руководствовались. В ответах — подробный разбор задействованных принципов, и вы можете сравнить свои стереотипы с моими ответами. И не пугайтесь плохих результатов: большинство людей, даже давно знакомых с компьютерами, в первый раз проходит тест очень плохо. Зато во второй раз ответы получаются правильные, и большинство считает эту статью самой ценной на моём сайте: одно её прочтение улучшит все интерфейсы, спроектированные в дальнейшем.

Эти вопросы предполагают, что всё экранное пространство под вашим полным контролем. Просто представьте себе, что вы главный дизайнер в Microsoft или Apple.

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

В один прекрасный момент это всё достало и было принято решение сделать что-то универсальное.

Я люблю desktop-приложения. Признаваться в этом нынче, похоже, стыднее, чем в связях с иностранной разведкой, но это так. Нет, это не значит, что я не люблю интернет-технологии. Более того, некоторые я не только уважаю, а даже более-менее знаю. Но, тем не менее, я скучаю по тем временам, когда программа писалась на одном компьютере, потом компилировалась и запускалась на других, разных компьютерах. Тогда везде (почти) была одна система — Windows с одной и той же API, почти не было проблем совместимости на уровне приложений, никто не материл разработчиков браузеров — все берегли нервы на разработчиков WinAPI, которые умудрялись создавать конфликты даже внутри нее одной. Но это я, конечно, иронизирую, а если серьезно — иногда и сейчас хочется написать просто desktop-приложение, да так, чтобы работало оно на всех популярных системах. Трудно? Если подумать и покопать, то не очень.

Еще я люблю языки высокого уровня с аккуратной архитектурой и строгой типизацией. Мои фавориты — Java и C#. Оба они предоставляют разработчику множество преимуществ по сравнению с C++, оба избавляют от ряда забот. Чем приходится платить? Тем, что таскаешь за собой тяжелую колоду, которая называется Oracle JVM, .NET или mono. Все три колоды весят сотни мегабайт и лицензию имеют такую, что каждый пользователь вынужден качать эту штуку сам, не путая при этом разрядность своего компьютера, а главное — программа на Java не может быть совместима со всеми версиями JVM разом, не так ли? И вот — мы приходим к тому, что просто скинуть программку другу (или миллиону друзей) и не заботиться о том, что она у него не запустится, не выходит. Приходится делать хитрые сетапы, вбивать костыли, и это я еще не упомянул .NET — однажды я видел у друга сразу 3 установленных версии, причем все три были нужны разным приложениям…

Стоп! А давайте напишем программу на Java, но так, чтобы она не требовала установки на машину какой-либо JVM, чтобы одним касанием собиралась под Windows, Linux и OS X и чтобы при этом занимала совсем чуть-чуть; так, чтобы никто даже не понял, что она написана, скажем, не на C. Невозможно? Совсем наоборот! (И нет, я имею в виду не gcj, который лишает Java всех ее прелестей. Рефлексия будет работать и даже сторонние jar вы сможете запускать).

Каждый из нас изо дня в день бывает в одних и тех же местах примерно в одно и то же время — дом, работа, спортзал, магазин, снова дом… Наш ежедневный маршрут достаточно стабилен и в то же время уникален. Совместное исследование американских и бельгийских учёных продемонстрировало, что степень его уникальности гораздо выше, чем можно предположить.

Анализ базы данных, в которой была собрана анонимизированная информация о времени и месте звонков и СМС 1 500 000 абонентов на протяжении пятнадцати месяцев показал, что для идентификации 95% людей достаточно знать всего четыре пространственно-временные точки.

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

Таким образом, получив из открытых источников (Facebook, Twitter, Foursquare, LinkedIn и т.п.) всего несколько характерных для человека пространственно-временных точек, можно деанонимизировать абонента мобильной связи среди миллионов записей, не содержащих вообще никакой персональной информации, и отследить все его перемещения.

Жизнь – как вождение велосипеда. Чтобы сохранить равновесие, ты должен двигаться.
А.Эйнштейн

Преамбула: в Alconost мы делаем продающие видеоролики для программных продуктов, веб сайтов, онлайн сервисов, мобильных приложений. Ключевая роль в таких роликах отводится скринкастам — показу действий пользователя в программе/сервисе/на сайте. Скринкаст — это показ товара “лицом”. Если скринкаст сделан убого — у зрителя останется ощущение убогого продукта и задача “мотивировать попробовать продукт” будет провалена.

Мы задумались над тем, почему иногда скринкасты выглядят неестественно и негармонично и как сделать так, чтобы скринкасты всегда получались хорошо. Оказывается, существуют 12 принципов анимации Диснея и если следовать им — любое действие на экране будет выглядеть красивым и гармоничным. Мы чуть-чуть поработали над этими принципами: убрали то, что не относится к скринкастам, а остальное адаптировали под специфику видеороликов о программных продуктах. В итоге у нас получилась памятка-руководство для видеодизайнеров, которой мы и хотим поделиться.

Итак, если вы заказали видеоролик, и вам раз за разом присылают промежуточные версии с отстойными скринкастами — покажите вашим «видеоменам» вот этот ролик:



Видео предназначено для людей, близких к видеодизайну, поэтому если вам нужно более подробное описание каждого принципа — добро пожаловать под кат.

На написание этой статьи меня подтолкнули многочисленные просьбы моих друзей о том, что я «должен поведать об этом миру». Разговор пойдет о компактном и достаточно мощном компьютере, собранном своими руками аж в октябре 2011 года. Изначально немного о причинах этого и истории создания.

Осторожно, в статье много картинок.

Ситуация с 3д-принтерами напоминает ситуацию с Linux-дистрибутивами, особенно для новичка. Огромная куча конструкций под кодовыми именами, половина из которых поставляется в собранном виде, половину надо собирать как конструктор из деталей, а для еще одной половины все детали надо найти самому, да еще и напильником поработать. Кстати, откуда взялась третья половина — тоже непонятно. Попробуем в этом всем разобраться.

Часто, в разных местах, требуется освещение типа «лишь бы не полная тьма». Например, лестничная клетка многоквартирного дома, где иголки на полу искать не требуется, а достаточно лишь минимального света, чтобы не оступиться или иметь возможность попасть ключом в замочную скважину. Обычно, в таких случаях, вкручивается либо 20-40 ваттная «лампочка Ильича» или «экономичная» на 7-9Ватт. Лампа накаливания имеет свойство часто перегорать, а «экономички», просто, банально крадут (у меня с лестничной клетки, за 3 года, стырили штук пять, мною вкрученных — мелочь, но неприятно). Если вам нужен экономичный и защищенный от воровства (ну, скажем так, более защищенный, чем просто лампочка) источник света, то читайте дальше.

К хорошим постам «Код в стиле «дамп потока сознания»» и «Микро-рефакторинг, о котором мы так часто забываем».

• Почему большинство программистов не любят «читать чужой код»?
• Почему рефакторинг и внесение изменений становятся серьезной проблемой?
• Почему так часто случается, что легче переписать с нуля?
• Почему одни программисты называют других хорошими или плохими словами?

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

Друзья, рады поделиться с вами несколькими тематическими примерами приложений для Windows 8, от которых вы можете отталкиваться в своей работе. Все примеры размещены на CodePlex и доступны для загрузки с исходным кодом.

Будучи дизайнером интерфейсов, до сих пор часто вижу ситуацию, когда проектировать интерфейсы приходится разработчикам или кому-то еще из команды.
Конечно, лучше, когда дизайнер в команде есть, но что делать, если его нет?

Когда-то я собрала набор простых правил, которые помогают избежать 80% самых распространенных ошибок, касающихся построения интерфейсов. Решила расшарить их для хабрасообщества.
Кому интересно — добро пожаловать под кат.

Есть у меня любимый форум, посвящённый головоломкам. Недавно я наткнулся там на следующую задачу:

Сидел однажды Вася у себя на кухне и от нечего делать спички ломал. Поломал, поломал и задумался — чему равна вероятность того, что по крайней мере одна спичка будет переломана точно посередине? Запас спичек у Васи неограничен.

Я довольно быстро доказал, что вероятность этого события равна нулю. Гордый собой, я запостил решение и ответ, ожидая плюсика в карму. Оказалось, однако, что авторский ответ совсем другой: 1 — 1/e. Забегая вперёд, скажу, что этот ответ неверен.

Неправильные авторские решения — довольно частое явление в интернет-головоломках. И я ни за что не стал бы писать этот пост, если бы автором задачи, а также её неверного решения, не был британский логик и алгебраист Чарльз Л. Доджсон, более известный под псевдонимом Льюис Кэрролл.

Всем привет!

Вашему вниманию предлагается перевод статьи уже известного на Хабре автора. На этот раз он делится своими видением того, как часто нужно применять в своей повседневной разработке те или иные свойства языка Java.

---

Java — это язык с мощными стандартными возможностями, но «Большая сила налагает большую ответственность». Я видел много java-кода, в котором чрезмерно (и зачастую — неправильно) использовались «редкие» свойства языка, в то время как основы основ были почти полностью проигнорированы. Эти наблюдения и послужили стимулом к написанию статьи.

Это не список обязательных к использованию каждым программистом особенностей языка. Скорее наоборот. Я разделил их на 3 группы: "для каждодневного использования", "для периодического использования" и "только для фреймворков и библиотек!". Правило простое: если вы понимаете, что используете указанные свойства чаще, чем рекомендуется, то, скорее всего, ваш код развивается по неправильному пути. Если же наоборот — вы редко используете какие-то свойства, чем я рекомендую, значит вы упускаете какие-то интересные и важные возможности языка.

Обратите внимание, что я говорю о разработке типичных серверных бизнес-приложений (JVM, JDK, вот это все) и не даю рекомендаций относительно каких бы то ни было фреймворков.

С течением времени изменяются наши представления о способах взаимодействия с компьютером. На смену «классических» клавиатуры и мыши, в нашу жизнь прочно вошли тачпады и сенсорные экраны. Но это не последняя ступень эволюции для средств ввода информации. С появлением устройств дополненной реальности, например таких, как Google Glass, возникает необходимость в интерфейсах способных гармонично вписываться в данную концепцию. Предпосылки к возникновению таких интерфейсов имеются, так, например, появились такие устройства как Intel Creative Camera, Microsoft Kinect или Leap Motion. Основными управляющими элементами в данных устройствах являются руки пользователя. Поэтому, одной из фундаментальных алгоритмических задач, для взаимодействия с подобными устройствами, является детектирование рук и пальцев пользователя и реконструкция их пространственного расположения.
В данной статье речь пойдет о одном из способов решения задачи детектирования ладоней и пальцев.

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

Идея распознавать людей по радужной оболочке появилась в далёком 1987 у доктора Джона Доугмана и была запатентована в 1989. Примерно тогда же появился прототип. На тот момент это была вершина технологии. Пару лет до первой коммерческой цифровой камеры + алгоритм обработки изображения на компьютерах уровня i386/i486. До сих пор я не представляю, как можно получать на таком оборудовании стабильный результат.
Задачка о которой я хочу рассказать появилась на свет где-то в 2006-2009 годах. Процессоры к этому времени несколько ускорились, появились хорошие камеры, патент 1989 года истёк и системы распознавания по глазам теперь получил право делать каждый. Люди, которые решили сделать клон системы захотели использовать современные технологии и улучшить алгоритм. Самое первое, что бросалось в глаза — старый алгоритм сравнения глаз использовал изображение глаза в близком ИК диапазоне. То, что глаза бывают цветными не учитывалось.

Ролики с демонстрацией пиксельной подсветки выглядят довольно эффектно — куча разноцветных всплохов, динамичные отблески смотрятся просто замечательно и выглядят более подвижными по сравнению с другими типами подобной подсветки.
Желание поработать с управляемыми огоньками с помощью arduino побудили меня соорудить такую систему. Как оказалось, это довольно простое мероприятие, на которое в сумме было потрачено всего несколько часов (собственно, само сооружение — 10 минут, остальное — софт). Детали процесса сборки и программирования я и изложу в этой статье. Софт, выводы и демо прилагаются.

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

За долгое время работы в Яндексе нам удалось систематизировать все наши знания и огромный опыт в создании фронтенда веб-сервисов. Результатом этого осмысления и длительной работы стала первая Школа разработки интерфейсов, занятие которой шли в московском офисе Яндекса. Вся практическая часть обучения проходила в реальных проектах Яндекса. Теоретическая же состояла из лекций, которые читали ведущие разработчики интерфейсов Яндекса: Сергей veged Бережной, Михаил mishanga Трошев, Алексей doochik Андросов, Михаил azproduction Давыдов и другие.



Сегодня мы выкладываем видеозаписи каждой из них. Весь курс систематизирован и поделен на пять блоков: инструменты разработки, технологии в разработке интерфейсов, языки программирования, фреймворки, дизайн.

В первой части я рассказал о причинах, побудивших меня заняться построением своего “умного дома”, и об используемом “железе”.
Но “железо”, само по себе, умным быть не может, главное это “софт”. Вот об этой стороне своего проекта я и хочу рассказать в этой части. Банальное управление освещением с пульта, конечно, выглядит круто в глазах непосвященной публики, но “ума” тут никакого.
Так что же такого умного можно сделать? И, главное, как?

Предисловие: мой предыдущий пост на эту тему попал в утиль — на хабре, увы, больше нет раздела «ссылки», а даже частичный копипаст в виде затравки с ссылкой на оригинальный текст, запрещен правилами. Тем не менее, я считаю случившееся событие очень важным, поэтому рискую еще раз вынести это текст на обсуждение. Чтобы остаться в рамках правил, постараюсь пересказать основной текст своими словами.

Итак, с середины с декабря прошлого года в Google начал работать известный изобретатель и футуролог Рей Курцвейл. Как пишет в свой статье Олег Парамонов (а это и есть основной текст, на который я хотел сослаться), событие это из ряда вон выходящее и, я не побоюсь этого слова, революционное.



Давайте сначала разберемся зачем гуглу вообще исскуственный интеллект. На фоне новостей про Android, гидроэлектростанции и прочее-прочее-прочее, легко забыть, что Google, это прежде всего поиск. Собственно, именно он приносит львиную часть доходов. Но что такое поиск завтрашнего дня?

Цитата 1:
«Ещё в 2000 году Ларри Пейдж, один из основателей Google, объявил, что идеальной версией поисковика будет искусственный интеллект.
Цитата 2 (из документа Google для внутреннего пользования 2006 года):
»Чтобы стать лучшими в поиске, мы должны создать исследовательский центр мирового класса, занимающийся искусственным интеллектом".»

Изначально для основного освещения одной из комнат, где шёл капитальный ремонт, планировалась обычная люстра. Но недавно мне на глаза попалась суперяркая светодиодная лента Ultra 5000 со светодиодами smd 5630 торговой марки Arlight. Решение было принято быстро, окончательно и бесповоротно — хочу такую ленту в качестве основного света в комнате.