Режимы в пользовательском интерфейсе. Расширение функциональности или головная боль?

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

Примеры:

Смеситель в ванной - имеющий переключатель "кран/душ". Бывает в двух вариантах - советском и современном. В советском варианте, вы рычагом переводили поток воды в другое русло. Проблема заключалась в том, что никто не запоминал, какое положение рычага отвечает за кран, а какое - за душ. Как следствие, если кто-то принимал душ, выключил воду и ушел, а вы собираетесь просто включить воду из крана - будете облиты водой из душа. Потому что "по умолчанию" вы ожидаете воды из-под крана, а никак не из душа. Проблема в режиме в котором находится кран и о которой вы (пользователь) никогда не помните. 

Современные краны имеют немного другой дизайн. Они сбрасывают положение рычажка (он уже в виде кнопки/гвоздя) как только вы выключаете воду. То есть, если вода не течет, то при включении воды она всегда пойдет из крана, до тех пор пока вы не переключите на душ. Эта концепция работает :)

Другой пример - пульт Logitech Harmony 555. Имеет 2 кнопки для перехода в режимы управления устройствами звука или изображения (т.е. усилителя или телика соответственно). Та же проблема. Включив режим "настроить звук" и настроив его - вы тотчас забываете что пульт все еще находится в режиме "настроить звук". Поэтому когда вы в следующий раз начнете им управлять - первые несколько действий он будет делать совсем не то, что нужно (как вода из душа на голову), пока вы не сообразите вернуть пульт из режима "управление звуком" в обычный. Решением было бы - возвращать пульт в обычный режим по тайм-ауту, но инженеры Logitech решили совсем от него отказаться и режимы в последней модели (Harmony One) убрали совсем. 

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

Задачка про таблэтки

Мы очень любили эту задачку на интервью спрашивать. Чаще её почему-то девушки хорошо и быстро решали. Надо бы теперь что-нибудь другое подыскать...

Qcon 2010. День третий

С запозданием заканчиваю делиться впечатлениями от поездки на Qcon-London 2010. Кажется, что на третий день спихнули самые сомнительные доклады, чтобы так сказать не потерять аудиторию в первые два дня. А может и нет.

Создатель Erlang рассказывал про Erlang. :) Прикольный дядька оказался, говорил много правды :) В общем, всем идти расширять сознание и учить Erlang. Нет правда. Я уже пошел.

После обеда Ральф Джонсон снова вещал со своего высокого уровня сумрака абстракции о "шаблоне языка для параллельного программирования". Он и еще несколько гуру пишут книгу на эту тему, а университеты инвестируют в это направление. Короче, года через 2-3 (4-5?) можно ожидать новой модной тенденции в сфере параллельного программирования. Хотя с другой стороны чем им Erlang не угодил?

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

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

Ну вот и всё. Ждем Qcon в Сан-Франциско и, конечно, JavaOne!

QCon 2010. День второй

Второй день начался с презентации Ральфа Джонсона (да, того самого). Доклад показался мне слегка занудным и скучноватым - видимо профессоры в computer science на седьмом десятке переходят на 5й уровень сумрака такой высокий уровень абстракции, на котором понимать их становится тяжело. Тем не менее, пара мыслей мне показалась интересной:

• Капитал в ИТ смысле - это не только программное обеспечение, но и знание о том, как оно работает. Сразу вспоминаются слова "документация", "спека", "вики-странички", правда? )
• Признание кода "legacy" - расписка в собственной некомпетентности по отношению к нему. Когда не хватает знаний об используемых там технологиях или архитектуре (функциональной и инфраструктурной).
• Скоро программисты будут работать с программами, которые старше их самих. Прям мурашки по коже )

Следующий доклад был у другого апологета. Трек, который начинал Мартин, обещал быть малочисленным, поэтому комнату под него выделили маленькую. А послушать первый доклад пришло много. Как следствие - все полтора часа слушал на ногах, стоя в дверном проеме. Может быть поэтому, а может и потому что видеоряда не было (Мартин просто вещал в народ), доклад показался мне скучным. Несколько философских вещей, которые заставили задуматься (наверное еще что-нибудь напишу по этому поводу):

• Подумай, где ты работаешь - приносит ли это пользу людям. Становится ли от этого лучше планете.
• Женщины в ИТ - почему их так мало? Это ненормальное явление и с ним надо бороться. Правда, пока неизвестно как.

Секция "Программное обеспечение в 2015" привлекла меня парой докладов. Первый был о смартфонах. К моему удивлению, спрогнозировали на удивление мало. По сравнению с текущими устройствами, в их потомках появятся датчик температуры, давление, влажности (а оно надо?) и сенсоры (вроде распознаватели отпечатков пальцев - и в топку пароли!). Отметили зоопарк технологий на сегодняшний момент (альтернативные Java и С++, Object C), слабость фреймворков (нет MVC), неприменимость относительно удачных десктопных платформ (Gears, Air, Flash) на мобильных устройствах.

Еще в будущем нас ждет:

• производительность на смартфонах сравнимая с современными серверами (!)
• управление голосом, перевод "на лету"
• использование устройства как пропуск в здение, метро, как платежное средство

Короче, вполне закономерные и эволюционные вещи. Революция уже произошла.

Про программирование Java Virtual Machine рассказывал Alex Buckley. Это действительно огромный труд про написанию подобного приложения. Приводились примеры различных оптимизаций, которые JVM делает. Делается предположение, что JVM и дальше будет увеличивать свое влияние вплоть до "Universe VM". Уже сейчас можно (нужно?):

• юнит тесты писать на Scala
• бизнес-логику на Java
• вэб-приложения на JRuby
• конфигурационные скрипты на Jithon

Складно :)

Следующему докладу я посвятил отдельную запись.

В конце второго дня был доклад человека, который называет себя "упрощателя софта". Действительно, современные многозвенки иногда производят впечатление артиллерийской установки, бьющей по голубям на крыше. И голуби разлетаются и крышу разносит и люди страдают от осадков. Главный посыл когда проектируете многозвенку - "задумайтесь, оно надо?". Рекомендую посмотреть презентацию и/или видео, это определенно взгляд на многозвенки с другого угла.

[Sun] Tech Days 2010

Побывал на tech days 2010. Хотелось сравнить с прошлогодней, особенно в свете всеми известных событий. Ну и на Джеймса Гослинга хотелось посмотреть.

День первый

Пленарка обещала быть интересной: 0 будущем Java в Oracle должен был рассказать Сам. Но не рассказал. Вместо этого почти 2 часа нас снова пичкали JavaFX (доколе?). Половина докладов была один-в-один прошлогодние, что добавляло скуки. Один из топ-менеджеров Oracle, в задачу которого я так понимаю входило "завести" аудиторию, с ней не справился и скучно вещал ничего не обещающие утверждения о том, что "с Java в Oracle все будет хорошо, потому что мы ее любим и ценим". Единственное что было услышано мной в первый (и не последний) раз - о closures в JDK7. 

Затем я отправился в секцию Solaris, где название звучало как обещание озвучить roadmap для Solaris. Опустив "рекламу" (Solaris это надежность, масштабируемость и защищенность), я вынес главное утверждение доклада - в рамках Oracle будут развиваться и Solaris и Linux. Без расставление акцентов. Оба.

Дальше прослушал пару стендовых докладов. JetBrains рассказывали про TeamCity. Ничего нового не узнал. TeamCity быстр удобен и вообще мне нравится :) Потом предствитель OpenJDK (все тот же Sun) рассказывал как собрать OpenJDK самому. Мало что запомнилось, помимо того, что это непросто и займет часы.

После обеда Саймон рассказывал про скриптовые языки в JVM. Запомнилось "Выбирайте  язык исходя из поставленной задачи, JVM всё стерпит". И еще "создатель Groovy признался, что он бы не придумал Groovy, если бы в то время была Scala". Учить Groovy сразу расхотелось :)

Николай Иготти как и в прошлом году рассказывал про VirtualBox. Продукт определенно неплохой, попробую когда начнет поддерживать MacOS как гостевую систему.

В секции стендовых докладов рассказывали про Sun Java Realtime System. За 20 минут успели рассказать что из себя она собственно представляет, но ничего нового я не услышал. Была отличная статья на английской про Java RTS, но ссылку не помню. Сановская реализация сейчас основана на JDK 5 и работает на всех Solaris и на real-time kernel Linux.

День второй

На второй день слушать про JavaFX на пленарке не было никакого желания, поэтому я выбрал сон :). А день начался со стендовых докладов. JetBrains рассказали что эксперимент с бесплатной IDEA был признан успешным, что они дальше будут портировать больше функциональности из платной версии в бесплатную. Еще сказали что дальнейшее развитие видят в минорных вещах, крупный функционал уже сделан. Порадовали проектом IDE для разработки под IPhone. Давно пора :)

Доклад о новых фишках в JDK7 ребята из Sun рассказали неплохо. Спровоцировали пару холиваров и блестяще их парировали пригласив всех в онлайн конференцию по JDK. А вообще, здесь описано лучше и объемнее чем это могу сделать я.

В секции Solaris рассказывали про "многоядерный мир" и как в нем следует разрабатывать приложения (для Solaris, конечно). Было неинтересно, я запомнил только что нужно использовать специальную солярную функцию для выделения памяти, а не malloc.

JetBrains хвастались о MPS. Штука интересная, непростая и наверное полезная. Осталость только придумать где бы ее применить да еще при желании не ломая старое, а встраиваясь в него. С последним пока непонятки... Задумался, является ли Google Protobuf MPS или нет.

Снова Sun рассказывал про новый сборщик мусора как и в прошлом году. В этот раз доклад был менее информативен в технических деталях, а потому зацепил не очень. Главное, (в чем я почему-то заблуждался) это то, что Stop-the-world пауза вызывается для сборок и молодого и старого поколений, хотя сами поколения для G1 достаточно условны. Пообещали что в JDK7 будет стабильная версия. Хотя у меня и теперешняя не падала (ну разве что в IDEA).

И напоследок был интересный доклад про "внутренности JVM". То есть, я думал, что он будет про внутренности. А нам рассказали про оптимизации, которые JVM делает во время JIT компиляции в runtime. Давно хотел это услышать из первых уст. Заниматься микро оптимизациями (вроде замены StringBuffer на StringBuilder) расхотелось совсем. У JVM всё равно получится лучше. Главный посыл - писать код как все, как рекомендуют гуру и лучше не изобретать велосипедов. Потому что JVM оптимизаторы тренируются на похожем коде библиотек, которые все используют.

Ну а дальше были выходные с отличной и нехарактерной для Питера солнечной погодой...

Архитектурные качели

Проектируя систему помимо функциональных и нефункциональных требований, архитектор должен держать в уме ещё и различные "best practices". Вроде слабого связывания и повторного использования.

Идеальное слабое связывание - набор компонент, которые ни от кого (кроме себя) не зависят. :) Утопия. Как только 2 компонента начинают иметь общий функционал, этот функционал выносится в отдельный компонент. Эта итерация повторяется до тех пор пока каждый компонент не начинает исполнять свою уникальную задачу. Казалось бы, все хорошо. И связывание слабое и повторное использование максимальное. На деле всё не всегда так. Операцию по выделению дубликатов можно проводить очень долго, спускаясь по уровню декомпозиции все ниже и ниже. В результате может получится "экономия на спичках" когда небольшой и простой функционал (например логирование) выделяется в отдельный компонент, который после выделения становится чрезвычайно негибким в плане изменений и настроек под конкретный компонент, который его использует.

Поэтому качели "слабое связывание <-> повторное использование" должны оставаться в равновесии, без перекосов.