Про неолиберализм

Борис Кагарлицкий: 

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

Другими словами, если существует некий финансовый порог участия и кандидатов, и партий, и каких-то социальных сил в выборном процессе, то становится понятным, что от двух третей до трех четвертей населения (и, соответственно, их политические представители) не могут эффективно участвовать в политико-избирательном процессе. Просто потому, что не имеют для этого средств. Все недовольны, но никаких альтернатив нет. Таким образом, мы приходим к ситуации, аналогичной однопартийной системе при формальном отсутствии имущественного ценза и формальном плюрализме. Система имущественного ценза в Англии в XVIII веке или в Швеции до 1917 года была построена так: если я не имею какого-то количества имущества – я не могу голосовать. Это был пассивный имущественный ценз, направленный против избирателей.

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

Прочитать статью полностью

Вечным борцам за экономический либерализм посвящается.

Про культуру

Позавчера проехался в соседний город на маршрутном такси с кодовым названием «Газель». С некоторого времени у меня отсутствует потребность ездить на маршрутках каждый день, поэтому сейчас это для меня, скорее, уже экзотика, и можно рассуждать о предмете отвлеченно. Но раньше, в течение прошлых семи лет, приходилось ежедневно, как минимум на час, погружаться в этот восхитительный мир.

Читать далее…

О пунктах меню

Изучение премудростей дизайна пользовательских интерфейсов я начинал с прочтения отличной книги Джоэля Спольски «Руководство по UI дизайну для программистов». Поскольку там были высказаны очень здравые идеи, я стал постоянным читателем его блога JoelOnSoftware и позднее вступил в сообщество переводчиков.

А недавно Джоэль опубликовал там коротенькую заметку следующего содержания:

Не скрывайте и не выключайте пунктов меню.

Очень давно стало модным, даже рекомендуемым, выключать пункты меню, если они не могут быть использованы.

Не делайте этого. Пользователи видят выключенные пункты меню, по которым они хотят кликнуть, и остаются без каких-либо догадок о том, что они могут сделать для их включения.

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

Заметка вызвала неоднозначную реакцию на его форуме. Многие разработчики интерфейса посчитали это нецелесообразным, потому что такой подход помогает начинающим пользователям, но вызывает огромное раздражение опытных пользователей. Представьте себе ситуацию, когда вы, не выделив предварительно текст в редакторе Word, случайно нажимаете пункт меню «Правка—Копировать». И вместо того, чтобы проигнорировать действие, которое не может быть выполнено в данном контексте, на экран вываливается диалог с текстом вроде такого: «Команда Копировать недоступна, так как вы предварительно не выделили текст, который надо скопировать». Этот принцип напрямую противоречит главе 6 вышеназванной книги Джоэля, потому что опытные пользователи никогда не читают текстовых сообщений, а от появления блокирующих диалоговых окон могут иногда просто разбить монитор.

Форумчане придумали альтернативное решение: показывать пункты меню отключенными, но оставлять их доступными для нажатия, а при нажатии показывать всплывающую подсказку с пояснением причин отключения. Правда, никто не учел себестоимость реализации такого решения, потому что выключенные стандартными способами пункты меню во всех RAD-системах, которые я знаю, не генерируют событие нажатия. А потому придется «плыть против течения» и городить жуткий дополнительный код для реализации нестандартного затенения неактивных пунктов меню + отслеживания кликов по ним.

На мой взгляд, вместо этого стоит пораскинуть мозгами при проектировании интерфейса и применять подход, предложенный Джоэлем, только в тех случаях, когда предыдущий «жизненный опыт» пользователя не может помочь ему интуитивно определить причину отключении пунктов меню. В 99% случаев пользователи начинают использовать вашу программу только после знакомства с одним или несколькими десктопными приложениями, вроде MS Office. Поэтому базовые операции, которые можно/нельзя провести с различными объектами приложения, им, скорее всего, известны.

При пристальном рассмотрении своего текущего проекта я понял, что уже наполовину это реализовал. В редактор тестов можно вставлять формулы, которые являются OLE-объектами Microsoft Equation. Делается это путем выбора пункта меню «Вставка—Формула». Объект Microsoft Equation не входит в стандартную поставку Windows, а устанавливается на компьютер вместе с пакетом Microsoft Office. Потому вставка формулы невозможна при его отсутствии.

Там где формулу нельзя вставить в принципе (например, когда фокус ввода не находится в редакторах вопросов/ответов), было принято решение блокировать этот пункт меню. А в случае, если формулу вставить можно, но Microsoft Equation не установлен, соответствующий пункт меню не блокируется, и при его нажатии выводится сообщение, поясняющее отсутствие OLE-объекта на компьютере. Без этого неподготовленный пользователь вряд ли сможет проявить интуицию и догадаться, почему формулу вставить нельзя, без прочтения руководства по использованию.

О прогнозах времени

Сегодня захотел я провести обновление своей Windows XP вышедшим недавно Service Pack 3. Ну и заодно обновить DirectX, уж гулять, так гулять. Поставил их в очередь на загрузку.

Замечательная (к тому же совершенно бесплатная) программа Download Master выдала вот такой прогноз:

Скорость ADSL-канала 60 Кбайт/с практически равномерно разделилась между двумя загрузками, и для каждой загрузки был написан свой прогноз времени. Этот прогноз вычисляется динамически по средней скорости, расходуемой на закачку, потому что скорость может колебаться как из-за неравномерной нагрузки на канал, так и из-за перегруженности сервера, с которого качается файл. Так что цифры прогноза слегка скачут, но с этим можно смириться.

Для первой закачки (DirectX) осталось примерно полчаса, для второй (SP3) — 3 часа.

Значит ли это, что я скачаю Service Pack 3 через три часа?
Нет. Он загрузится гораздо раньше.

К сожалению, метод прогнозирования времени Download Master не учитывает тот факт, что при окончании закачки файла меньшего размера (DirectX) полная скорость канала будет в распоряжении второй закачки (SP3). После 30 минут загрузки со скоростью 30 Кбайт/с вторая закачка получит все 60 Кбайт/с и время ее загрузки сократится ровно в 2 раза: 1 ч. 15 мин. против 2 ч. 30 мин.

Итого, время загрузки второго файла составит 1 ч. 45 мин., а не три часа, как запланировал Download Master.

А если загружается 3 файла разного размера? А если 10 файлов? Погрешность прогноза будет только увеличиваться.

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

Версии, ревизии, сборки и другие непонятные слова

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

Как известно, номера версий программ — это побочный продукт итерационной разработки ПО, которую еще называют «Модель водопада» или «Flow».

Суть метода состоит в следующем. Как только работающая программа выпускается в свет, и у разработчиков, и у пользователей сразу возникают идеи по ее улучшению. А когда перед выпуском программу тестируют, применяя неправильную методологию, то пользователи найдут в ней со временем кучу ошибок. И если разработчики захотят учесть эти пожелания и исправить/дополнить программу, они должны будут как-то отразить процесс ее изменения перед пользователями. Самое простое, что приходит на ум, — это добавить после названия программы (торговой марки) цифру или набор цифр, показывающих номер итерации в ее цикле «разработка-тестирование-выпуск».

Читать далее…