Mar. 1st, 2009

avva: (Default)
1) 40 Inspirational Speeches in 2 Minutes


2) Soviet Movies - Hollywood Faces

avva: (Default)
[livejournal.com profile] tema пишет: "При разработке интерфейсов крайне полезно на любое сообщение об ошибке задать вопрос "Почему?". Тогда половина сообщений об ошибках перестанет быть сообщениями об ошибках.", и приводит несколько примеров.

Это интересная мысль - спрашивать "почему" и настаивать на осмысленном объяснении ошибки. Мне она, в такой форме общего принципа, не приходила в голову, хотя на практике я неоднократно так поступал (в роли программиста).

Мне кажется, одна из важных причин, что мешают сообщениям об ошибках быть понятными - модуляризация в программировании. Ошибка случается в одном месте в системе; общение с пользователем находится совсем в другом.
"Системой" здесь может быть как отдельное приложение, так и, скажем, весь интернет.

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

Скажем, ты находишься в графическом редакторе, и сохраняешь файл. В зависимости от того, где ты его сохраняешь, это может быть жесткий диск твоего компьютера или сетевая папка на сервере. Графический редактор не должен об этом ничего знать - он всего лишь пытается записать записать файл, а уже другие модули в операционной системе решают, послать этот файл на местный диск или по сети на другой компьютер. Теперь предположим, что по какой-то причине сохранить файл не удалось и программа-редактор получила код ошибки. Не так уж легко спроектировать интерфейс между программой и операционной системой так, чтобы он содержал полезную информацию о такой ошибке во всех случаях, и вместе с тем сохранить информационный барьер между программой и драйверами диска/сети, не заставлять программу что-то о них знать. Может, файл не записался оттого, что неожиданно свалился роутер, находящийся между твоим компьютером и сервером. Твое приложение не знает, что такое "роутер" и сетевые неполадки и не умеет объяснить это тебе внутри своего интерфейса, с ограничениями своего дизайна, понятным тебе языком. Ему (и его программистам) вообще ничего не хочется знать о сети, а только о том, как картинки редактировать. Оно всего лишь хотело записать файл, и это не удалось. Вот оно и пишет "Operation failed" или еще что-то в этом роде.

В примере из записи по ссылке - "удаленный хост не отвечает" - есть какой-то в цепочке роутеров от моего компьютера до хоста, который послал пакет следующему в цепочке, но не получил ответ. Ясно, что есть частные случаи, которые особенно интересны мне - например, если пакет не получен уже первым роутером, можно предположить какие-то проблемы с моим сетевым кабелем или домашним (рабочим) роутером; если получен последним, но не хостом, можно предположить проблему с удаленным сервером. Сейчас же я даже не знаю, получив такую ошибку, это у меня упал интернет или "там" что-то нет так, и должен делать дополнительные проверки, чтобы это узнать. Мне, программисту с опытом системной администрации, это сделать легко, но я не обычный пользователь. Все это - результат того, что протокол IP принципиально однонаправлен и настроен на то, чтобы роутер, отправив IP-пакет к следующему узлу, мгновенно забывал о нем. Лего понять, почему так спроектировано, из прагматических соображений; но мы платим за это, в частностью, вышеописанной непрозрачностью сбоев.
avva: (Default)
Каждый раз, когда я вижу обложку CD с классической музыкой (например, в сообществе ru_classical), где исполнитель - женского пола, она всегда оказывается красивой женщиной. Обычно даже очень красивой.

Что бы это значило?

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

2. Может, наоборот, вполне достаточно именно именно профессионального успеха, просто современная индустрия красоты вместе с Фотошопом сделает красавицей кого угодно - действительно кого угодно.

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

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

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

Кажется, я перебрал основные возможности. Впрочем,

6. Может, есть еще какая-то версия, которую я упустил.

А кто знает, как оно на самом деле?

January 2026

S M T W T F S
    1 2 3
45678910
11121314151617
18192021222324
25262728293031

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Jan. 5th, 2026 10:28 am
Powered by Dreamwidth Studios