Студия нанимает работников за их умение обращаться с фотоаппаратом и общаться с посетителями (особенно с детьми), а не за компьютерные навыки. Возможно, дома они владеют Photoshop на профессиональном уровне, но в студии никто не ожидает от них подобного мастерства. Более того, в «горячую пору» студия может привлечь временных работников, поэтому очень важно, чтобы они как можно быстрее освоили работу с оборудованием.
А как же OSGi?
Когда мы начинали работу над этим проектом в конце 2004 года, инфраструктура OSGi только завоевывала популярность – главным образом благодаря тому, что она была принята в Eclipse. Мы в общих чертах познакомились с ней, но нас отпугнуло отсутствие широко доступной информации, опыта и методик.
Однако цели OSGi идеально подходили для тех задач, с которыми мы столкнулись. Поддержка разных конфигураций развертывания с общей кодовой базой, управление зависимостями между модулями, активизация их в правильной последовательности… Все те же проблемы.
Полагаю, тот факт, что мы не использовали OSGi, отчасти объяснялся неудачным выбором момента, а отчасти – нашим нежеланием идти на то, что мы воспринимали как дополнительный технический риск. Обычно я предпочитаю следовать принципу «бери и интегрируй» вместо принципа «сделай сам», но в данном случае меня отпугнула другая опасность: использование проектов с открытым кодом, известных минимальной поддержкой и слабыми сообществами, создает больший риск, чем хорошо понятные, общепринятые протоколы. Я также стараюсь избегать «псевдо открытых» инфраструктур, которые в действительности правильнее было бы отнести к стандартам фирм-разработчиков. Обычно они служат интересам фирм-разработчиков, а не пользователей.
На тот момент нам было неясно, к какому лагерю будет относиться OSGi. Если бы мы занимались этим проектом сегодня, то, вероятно, воспользовались бы OSGi вместо разработки собственного решения.
Один из архитекторов также занимался разработкой пользовательского интерфейса системы. Он всегда имел четкое представление об интерфейсе, даже если мы не всегда соглашались по поводу того, в какой степени его представление можно было реализовать на практике. Он хотел, чтобы интерфейс был дружественным и наглядным. В интерфейсе не должны были использоваться меню – пользователи взаимодействуют с изображениями напрямую. Большие, яркие кнопки наглядно представляют все варианты. Короче говоря, рабочая станция должна была иметь интерфейс в стиле «киоск».
Оставалось принять решение относительно того, какая технология должна использоваться для вывода информации.
Один из участников нашей команды провел анализ доступных UI-тех – нологий Java (как массовых, так и периферийных). Мы надеялись найти хорошую декларативную UI-инфраструктуру, нечто такое, что поможет нам избежать бесконечной возни с настройками Swing. Результат поразил всех.
В 2005 году, спустя 10 лет после появления Java, существовало две основные категории решений: «кошмарXML» и «спагеттиGUI-строения». В решениях на базе XML компоненты Swing более или менее напрямую отображались на сущности и атрибуты XML. Нам это не подходило. Изменения в GUI требовали публикации новой версии кода независимо от того, реализовывались изменения в чистом коде Java или в файлах XML. Зачем держать в голове два языка – Java и схемы XML – вместо одного (Java)? Кроме того, с XML неудобно работать в программном коде.
Весь энтузиазм по поводу построителей GUI у нас пропал задолго до этого. Никто не хотел, чтобы бизнес-логика вплеталась в обработчики событий, встроенные в JPanel.
Мы с неохотой остановились на «чистом» Swing GUI, но с некоторыми дополнительными правилами. После нескольких обедов в местном ресторанчике Applebee был выработан новаторский механизм, который позволял нам использовать Swing, не увязая в его мелочах.
No related posts.