+  HandyCache форум
|-+  Главная категория» Общие вопросы» Взаимодействие программы с пользователем
Имя пользователя:
Пароль:
Страниц: 1 2 3 [4] 5   Вниз
  Отправить эту тему    Печать  
Автор Тема: Взаимодействие программы с пользователем  (Прочитано 66952 раз)
0 Пользователей и 1 Гость смотрят эту тему.
DenZzz
Модератор
*****

Репутация: +179/-11
Offline Offline

Сообщений: 5589



« Ответ #60 : 23 января 2007, 00:03:51 »

Михаил

Дорисуй "Белый список" и получишь схему из ФАКа!  Прикольно

Для чего он нужен? Ну, хотя бы, чтобы нужный сайт всегда качался из Инета (постоянно обновлялся), не кэшировался и на нем не блокировалась реклама! Это просто необходимо web-мастеру сайта!
Только не предлагай писать этот сайт в исключения в каждом из твоих блоков! Подмигивающий

Примеров полно! Почитай хотя бы описание Белого списка в "Документации"!
« Последнее редактирование: 23 января 2007, 00:44:56 от DenZzz » Сообщить модератору   Записан
Михаил
Gold beta tester
*****

Репутация: +337/-14
Offline Offline

Сообщений: 5513



« Ответ #61 : 23 января 2007, 13:21:38 »

Rick

Извини, просто не успеваю... Я ведь один. Стараюсь ответить всем.

Цитировать
(имхо вообще чушь рассматривать последний вариант как один из распространенных случаев - это, скорее, исключение).
Я понял, этот вариант всех вводит в путаницу. Ты прав, что он существует больше как исключение (людей, применяющих "гостевой доступ", я думаю, не так много /но все равно будь поосторожней насчет чуши/).
Чтобы не сбивать всех с основной мысли предлагаю временно принять, что мы не рассуждаем о таком случае вообще.
Давайте тогда исключим этот блок ("Запись истории") из схемы, как-будто его нет вовсе. Все, что остается, распространяется и на анлим, и на повременку, и на оплату трафика.

Цитировать
Вся беда (имхо), что ты пытаешься строить рассуждения на "лабораторных условиях": один URL, одно правило, одна цель...
Есть противоположная беда - это отсутствие от партнеров /(с) Путин В. В./ конкретных примеров "суровых жизненных условий" (кроме твоего про "Белый список", который далее обязательно рассмотрим). Я прошу, дайте, пожалуйста, такие примеры (без иронии), т.к. сам, хоть и являюсь давним пользователем, их не встречал. Хочу также снова отметить, что список "У" не обязательно универсален и всеобъемлющ. Если он претендует на уйму правил с еще большей уймой исключений (что само по себе пока в моих глазах еще не факт), то он может по какому либо принципу быть разбит на несколько, но только внутри блока "Экономия".

Цитировать
про БС: сейчас он нам дает возможность для определенных URL обойти/не применять любой из списков. В твоем "У" конечно должно присутствовать исключение по URL. При этом, во-первых, представляем, что все урлы из БС, нам нужно впихнуть в одно правило задающее это исключение. Во-вторых,у нас же несколько дублей одних и тех же правил - и в каждом нужно продублировать эти правила-исключения по URL.
Это я расцениваю как конструктивный диалог. Давай смотреть... Но чтоб это было не в общем, приведи, плиз, жизненный пример.

А пока что идем далее. Ведь схема-то промежуточная. В ней мы имеем "Безразличный список", который, как я отметил, ранее, является аналогом списка "Только из кэша". Аналогом, но не более. Разница между ними тем не менее существенная. "Безразличный список" содержит ненужные пользователю типы данных, соответственно в нем скорее всего отсутствуют правила типа "вся графика" или "все скрипты" (напомню, у нас отсутствует логика в терминах записи/чтения в кэш. Нам не нужно думать так: "Я отключу этот список, чтобы дать записаться данным в кэш, потом включу его и эти данные никогда больше не будут грузиться из интернет). Его единственная цель - распорядиться ненужными пользователю данными. Но если пользователю безразлично, будут ли эти данные у него или нет, то это означает, что он предоставляет это на усмотрение программы. А программа доподлинно знает другой очень актуальный для пользователя момент - тот хочет максимальной скорости работы. Так чего ж она полезет брать эти данные из кэша, если можно их просто не дать, уйдя на ветку "Стоп" (по схеме). А раз так, то чем отличается фактически наш Безразличный список от Черного? Не пинайте ногами, но исключаем Безразличный список и связанную с ним логику. Черный список теперь отвечает за резку данных, которые пользователю не нужны.

DenZzz
Сейчас обязательно прочту примеры...
Сообщить модератору   Записан
Михаил
Gold beta tester
*****

Репутация: +337/-14
Offline Offline

Сообщений: 5513



« Ответ #62 : 23 января 2007, 16:16:32 »

DenZzz
Пример 1 использования Белого списка.
Цитировать
требуется запретить запись в кэш файлов с некоего сайта. Создаем для этого сайта правило и отмечаем список "Запись в кэш". В результате правила этого списка к данному сайту применяться не будут.
В моем подходе такая потребность у пользователя возникнуть не может. Она может возникнуть только у программы, т.к. пользователь разгружен от забот о записи в кэш и за него это делает НС (в этом топике мы уже обсуждали вопрос о цели и инструменте для ее достижения).
Сообщи, пожалуйста, для развития примера конкретную цель, для чего мы запрещаем запись в кэш для сайта site.ru?
Сообщить модератору   Записан
DenZzz
Модератор
*****

Репутация: +179/-11
Offline Offline

Сообщений: 5589



« Ответ #63 : 23 января 2007, 16:55:13 »

Михаил

Цитировать
Сообщи, пожалуйста, для развития примера конкретную цель, для чего мы запрещаем запись в кэш для сайта site.ru?

Уже сообщал: чтобы веб-мастеру видеть всегда на своем сайте свежие данные (не из кэша), в т.ч. картинки и всю рекламу на этом сайте!

Если бы не было "Белого списка", то пришлось бы писать этот сайт в исключения для КАЖДОГО правила "Черного списка", "Не обновлять" и т.д.!
Сообщить модератору   Записан
Михаил
Gold beta tester
*****

Репутация: +337/-14
Offline Offline

Сообщений: 5513



« Ответ #64 : 23 января 2007, 17:05:44 »

DenZzz
Не забывай. Рассматриваем пока пример 1. из документации про "Белый список". Там речь не идет об отключении для этого сайта списков "Черный", "Только из кэша", "Не обновлять" и др. Отключается только список "Запись в кэш". Для чего?

Вот второй пример - это уже про отключение многих списков.
Сообщить модератору   Записан
DenZzz
Модератор
*****

Репутация: +179/-11
Offline Offline

Сообщений: 5589



« Ответ #65 : 23 января 2007, 17:18:51 »

Михаил

Цитировать
Не забывай. Рассматриваем пока пример 1. из документации про "Белый список".

Хватит лить воду! Мы сейчас обсуждаем необходимость "Белого списка", а не цель первого примера в Документации!

Начни с моего примера! Как ты предлагаешь обойтись без "Белого списка" в моем случае?!
Сообщить модератору   Записан
Rick
Администратор
*****

Репутация: +15/-1
Offline Offline

Сообщений: 868


WWW
« Ответ #66 : 23 января 2007, 17:30:15 »

Хочу также снова отметить, что список "У" не обязательно универсален и всеобъемлющ. Если он претендует на уйму правил с еще большей уймой исключений (что само по себе пока в моих глазах еще не факт), то он может по какому либо принципу быть разбит на несколько, но только внутри блока "Экономия".
Так в чем новизна?

Цитировать
Давай смотреть... Но чтоб это было не в общем, приведи, плиз, жизненный пример.
handycache.ru - поскольку я периодически что-то меняю, мне нужно быть уверенным, что я вижу действительный вид - поэтому у меня в БС для hc.ru отключены списки Не обновлять и Только из кэша. При этом запись в кэш я тем не менее делаю: а вдруг приспичит посмотреть в автономке?

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

чем отличается фактически наш Безразличный список от Черного? Не пинайте ногами, но исключаем Безразличный список и связанную с ним логику. Черный список теперь отвечает за резку данных, которые пользователю не нужны.
А эти данные пользователю по-разному "не нужны". Только из кэша - я вижу эти файлы только если они есть в кэше, Черный список вообще блокирует запрос этих файлов - даже из кэша. Т.е. в первом случае не нужны неизвестные данные, во втором - вообще не нужны, любые.
Сообщить модератору   Записан
Qua
Новичок
*

Репутация: +1/-0
Offline Offline

Сообщений: 22



« Ответ #67 : 24 января 2007, 02:22:18 »

Михаил
В FAQ по HandyCache есть рисунок-схема его работы. Нарисуй свое видение работы HandyCache чтобы наглядно продемонстрировать насколько твоя "логика взаимодействия пользователя с программой" лучше существующей.

Лично я против предложения по объединению списков. Этим лишь будут смешаны многие функции организации записи/чтения в кэш.
По мне так лучше увеличить количество списков - например, делить записи на "по типу данных" и "по сайту", т.к. я не люблю регулярные выражения  Подмигивающий   

Цитата Сергей:
Цитировать
Что то я не наблюдаю дублирования правил.
В списке Запись в кэш у меня описаны типы данных.
А в Не обновлять заданы сайты.
Да и два простых списка лучше одного сложного.
Золотые слова!
« Последнее редактирование: 24 января 2007, 02:26:35 от Qua » Сообщить модератору   Записан

И др., и пр., и т.д., и т.п.
Qua
Новичок
*

Репутация: +1/-0
Offline Offline

Сообщений: 22



« Ответ #68 : 24 января 2007, 11:39:22 »

Цитировать
Михаил
В FAQ по HandyCache есть рисунок-схема его работы. Нарисуй свое видение работы HandyCache чтобы наглядно продемонстрировать насколько твоя "логика взаимодействия пользователя с программой" лучше существующей.

Урра! Схему нашел.  Подмигивающий
Теперь месяц на полный анализ.  Показывает язык
Не беспокоить!  Крутой
Сообщить модератору   Записан

И др., и пр., и т.д., и т.п.
Михаил
Gold beta tester
*****

Репутация: +337/-14
Offline Offline

Сообщений: 5513



« Ответ #69 : 24 января 2007, 23:54:33 »

Rick
Цитировать
handycache.ru - поскольку я периодически что-то меняю, мне нужно быть уверенным, что я вижу действительный вид - поэтому у меня в БС для hc.ru отключены списки Не обновлять и Только из кэша. При этом запись в кэш я тем не менее делаю: а вдруг приспичит посмотреть в автономке?

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

Указанное тобой использование списка БС с одной стороны логично. Только смотри, такой способ предполагает, что после занесения в БС правила и расставив галки ты должен пойти в список "Запись в кэш" и проверить, а пропускает ли он правило "hc.ru" . Если нет, надо добавить в этот список правило, дублирующее то, которое ты указал в БС.
В том варианте, который предлагаю я (пусть список "Условия устаревания" не универсален и у нас есть еще БС), ты так же пишешь правило в БС, отключаешь в нем галку списка "Условия устаревания" и все. Того, что я выделил жирным шрифтом, ты не делаешь. Это делает сама программа (на список "Запись истории" мы по взаимной договоренности не смотрим, ибо он имеет отношение только к "гостевому" доступу и у нас жестко отключен).
Это общее преимущество подхода без учета моего отношения к списку БС, которое может и поменяться под влиянием твоих примеров.

Теперь что касется БС применительно к блокировке им списков "Т" и "Н". Знаешь, что меня смущает и не удовлетворяет в нем? Не то, что это еще один список, а я приверженец универсального списка любой ценой. У меня нет такой приверженности. Смущает то, что он позволяет применить записанное в нем исключение только ко всему списку "Т" или "Н" целиком, в то время как в большинстве случаев мы заинтересованы применить его лишь к части списка. Вот например, записывая в БС исключение для hc.ru, ты ж на самом деле не хочешь применить его к графике, таблицам стилей? А хочешь - только к html-контенту. А как применить его к части списка? Здесь БС нам не помогает. Приходится идти в "Н" и писать там соответствующее правило.
БС дает нам возможность более наглядно задать исключение, которое распространяется на все правила списка. Но если мы хотим применять это исключение не ко всем, а к части правил списка, то БС уже бессилен. А что делать, если одно правило "Н" содержит много исключений? А если группа правил "Н" должна содержать общую для них группу исключений (например, для десятка конкретных сайтов нужно включить постоянное обновление картинок, флэш-анимации и скриптов, но обновлять по общим правилам все остальное)? В этом случае также не вижу, как может нам помочь БС. Почему мы решили обособить случай, когда есть исключение для ВСЕХ правил списка, создав для указания этого случая отдельную структуру - БС?
Сообщить модератору   Записан
DenZzz
Модератор
*****

Репутация: +179/-11
Offline Offline

Сообщений: 5589



« Ответ #70 : 25 января 2007, 01:05:40 »

Михаил

Цитировать
В том варианте, который предлагаю я (пусть список "Условия устаревания" не универсален и у нас есть еще БС), ты так же пишешь правило в БС, отключаешь в нем галку списка "Условия устаревания" и все. Того, что я выделил жирным шрифтом, ты не делаешь. Это делает сама программа

А как же HC узнает, что этот сайт надо писать в кэш? Список "Условия устаревания" мы отключили правилом в Белом списке! А ведь именно через список "У" ты предлагал писать файлы в кэш!

Цитировать
Вот например, записывая в БС исключение для hc.ru, ты ж на самом деле не хочешь применить его к графике, таблицам стилей? А хочешь - только к html-контенту. А как применить его к части списка? Здесь БС нам не помогает.

Ошибаешься! В БС правило можно и так написать:  +handycache.ru*.html
Сообщить модератору   Записан
Михаил
Gold beta tester
*****

Репутация: +337/-14
Offline Offline

Сообщений: 5513



« Ответ #71 : 25 января 2007, 18:41:59 »

Цитировать
Ошибаешься! В БС правило можно и так написать:  +handycache.ru*.html

Html-контент может выражаться не только правилом *.html, а еще *.php, #_ и еще бог весть чем (например, на hc.ru это еще и что-то вроде */component/option,com_smf*) - обо всех вариантах знает только список "Н", имеющий соответствующее внушительное правило (или несколько правил), определяющее этот тип данных. Что же теперь, сдублировать все это правило (все эти правила) в БС для этого конкретного сайта-исключения? А если впридачу мы не хотим кэшировать на этом сайте информацию еще 3-4 типов, кэшируемую в обычных условиях? Тогда только для одного этого сайта придется перенести в БС полсписка "Н". А если таких сайтов 2,3,...? А вдруг для некоторых из них будет свой набор типов данных, которые не нужно кэшировать? Список "Н" у нас тогда будет содержаться в БС в нескольких экземплярах.
Сообщить модератору   Записан
DenZzz
Модератор
*****

Репутация: +179/-11
Offline Offline

Сообщений: 5589



« Ответ #72 : 25 января 2007, 20:23:30 »

Михаил

Что за привычка не отвечать на конкретные вопросы?!

Ты так и не ответил на мой вопрос:
Цитировать
А как же HC узнает, что этот сайт надо писать в кэш? Список "Условия устаревания" мы отключили правилом в Белом списке! А ведь именно через список "У" ты предлагал писать файлы в кэш!

Зато я постоянно отвечаю на твои:

Цитировать
Html-контент может выражаться не только правилом *.html, а еще *.php, #_ и еще бог весть чем (например, на hc.ru это еще и что-то вроде */component/option,com_smf*) - обо всех вариантах знает только список "Н"

В списке "Не обновлять" у меня вообще нет таких правил!
А если б и были, то под конкретную задачу их все можно отключить 1 правилом в Белом списке в формате RegExp! В большинстве случаев таких "наворотов" и не требуется!

Кстати, #_ сюда не приплетай - они встречаются только в кэше HC, а в URL на сервер в явном виде не передаются!

Цитировать
А если таких сайтов 2,3,...? А вдруг для некоторых из них будет свой набор типов данных, которые не нужно кэшировать?

Сколько надо правил - столько и будет! Хочешь в одном все объедини, хочешь - в разных! Как будто у тебя есть лучший вариант написания исключений! Писать исключение к каждому правилу в списке "Н", "Ч" и т.д. - это еще больше работы!
« Последнее редактирование: 25 января 2007, 21:37:39 от DenZzz » Сообщить модератору   Записан
DenZzz
Модератор
*****

Репутация: +179/-11
Offline Offline

Сообщений: 5589



« Ответ #73 : 25 января 2007, 20:29:20 »

Мои выводы:

Ничего рационального на всех 4 страницах этого топика ты так и не предложил!
Вместо прямых и конкретных ответов на поставленные вопросы, ты увиливаешь, отвечаешь вопросом на вопрос и выдвигаешь свои явно непопулярные идеи!

В твоей схеме нет новизны, это просто перерисовка схемы из ФАКа в новом дизайне и с измененными названиями списков, которые ничуть не лучше старых!

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

В общем, нет в этой теме конструктива!

По сему, лично я не вижу смысла продолжать этот бессмысленный спор, к которому почти все "старожилы" уже потеряли интерес, и больше не буду постить в этой теме, пока здесь не появится (если это вообще возможно!) рациональное зерно!
  Крутой
Сообщить модератору   Записан
Rick
Администратор
*****

Репутация: +15/-1
Offline Offline

Сообщений: 868


WWW
« Ответ #74 : 25 января 2007, 21:06:04 »

Михаил
У меня сложилось впечатление, что пытаясь предложить что-то новое, ты только сейчас, в процессе, познаешь существующее. Для переустройства мироздания такой подход может и обычное дело, но для изменения логики работы программы желательно все-таки разобраться с тем, а что, собственно, не так, и что хочется изменить.
Сообщить модератору   Записан
Михаил
Gold beta tester
*****

Репутация: +337/-14
Offline Offline

Сообщений: 5513



« Ответ #75 : 25 января 2007, 23:31:37 »

DenZzz
Для того, чтоб увидеть рациональное зерно, которое тебе не очевидно, недостаточно глаза иметь, надо еще ХОТЕТЬ его увидеть. Вот этого последнего у тебя не имеется с момента самого первого твоего вхождения в топик. Честно скажу, что рад не видеть далее твоих постов до конца рассмотрения вопроса. Это будет способствовать установлению истины. Возвращайся, однако, если переменишь свою цель на желание вникнуть. Тогда, уверяю, конструктив появится сам собой.

Rick
Цитировать
У меня сложилось впечатление, что пытаясь предложить что-то новое, ты только сейчас, в процессе, познаешь существующее. Для переустройства мироздания такой подход может и обычное дело, но для изменения логики работы программы желательно все-таки разобраться с тем, а что, собственно, не так, и что хочется изменить.
Если ты это про последние посты, то да, так и есть. Мысли, изложенные про БС и Т, возникли по ходу пьесы как результат неопределенных сомнений в безупречности этого подхода к организации данных. Возникли в результате постов партнеров по обсуждению.

"Что, собственно, не так и что хочется изменить" сейчас попробую резюмировать как смогу.

Работа с программой в настоящее время организована так, что вынуждает пользователя мыслить категориями, не совпадающими с его целями. Цели - экономия денег/времени, резка ненужных данных (еще одна возможная цель - "гостевой доступ" - поставлена в ходе обсуждения под сомнение). Их он вынужден разбивать на понятные программе подцели на языке записи/чтения в кэш. Цель обсуждения - прийти к мнению, можно ли возложить на саму программу вопросы, связанные с организацией записи/чтения в кэш, так чтобы пользователю необходимо было сосредотачиваться только на своих целях. Упростить тем самым диалог с программой и сократить риск возможных ошибок, приводящих к недостаточной экономии или неоправданному расходованию дискового пространства.

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

Это был исходный посыл, желание программиста, видящего как напрягаются мои коллеги-непрограммисты, пытаясь наладить взаимодействие с программой.

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

Попробую вернуться к схеме и изложу ее истинное назначение. Давайте на минуту закроем глаза, отвлечемся и представим, что у нас нет нынешней структурной организации программы, нет списков, а есть чистый лист бумаги и задача - организовать подход пользователя к взаимодействию с программой в терминах преследуемых пользователем целей. Мы выделяем две возможные цели пользователя - резать ненужные данные и максимально экономить деньги/время при доступе к нужным. При такой постановке задачи логично будет, чтобы пользователь мог задать, какие данные ему не нужны вообще (рисуем блок "Резка ненужных данных"), а из оставшихся (т.е. нужных) на каких можно экономить (рисуем блок "Экономия денег/времени"). Блоки пока нарисованы, но их внутренняя структура пока несущественна. Существенно, что задав каким-то образом (который мы пока не определили) эти данные, он напрямую определяет для программы свои цели. При этом его не заботят вопросы, связанные с организацией чтения/записи в кэш. Ему достаточно знать, что проанализировав цели пользователя (т.е. наполнение этих блоков), программа организует их выполнение максимально эффективно.

Это квинтэссенция. Если это находит понимание, я продолжу про наполнение блоков.

И еще. Если не понимают люди, которые стремятся понять, то обидно за себя, что не можешь объяснить, хотя и стремишься. Но уверен, результат будет, т.к. с такими людьми идешь однонаправленно и вместе с ними согласованно обязательно достигнешь окончательного ответа, независимо от того, прав ты был или нет.
Сообщить модератору   Записан
Сергей
Beta tester
*****

Репутация: +9/-2
Offline Offline

Сообщений: 621



« Ответ #76 : 26 января 2007, 10:55:10 »

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

А что ты предлагаешь никак понять толком не могу. Программисты наверное поняли Подмигивающий

Последнее слово всегда за автором программы.
Если не устраивает текущая функциональность - напиши спецификацию с описанием новой программы. Которая была бы, по твоему мнению, лучше. Желательно подробно.
Сообщить модератору   Записан
Михаил
Gold beta tester
*****

Репутация: +337/-14
Offline Offline

Сообщений: 5513



« Ответ #77 : 26 января 2007, 11:58:27 »

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

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

Как будет окно, перейду к наполнению блоков...
« Последнее редактирование: 26 января 2007, 12:12:15 от Михаил » Сообщить модератору   Записан
Rick
Администратор
*****

Репутация: +15/-1
Offline Offline

Сообщений: 868


WWW
« Ответ #78 : 26 января 2007, 13:05:33 »

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

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

Цитировать
Если это находит понимание, я продолжу про наполнение блоков.
Намерения понимание давно нашли. Не находит понимания, почему уж который день имеем только "декларацию о намерениях" повторенную на разные лады.
Сообщить модератору   Записан
Михаил
Gold beta tester
*****

Репутация: +337/-14
Offline Offline

Сообщений: 5513



« Ответ #79 : 26 января 2007, 19:14:27 »

Мысля дальше в направлении, изложенном выше, я пришел к следующим выводам. Программа предоставляет пользователю возможности резки ненужных данных и экономии денег/времени на нужных. Пользователь может хотеть или не хотеть использовать любую из них. Следовательно, блок "Резка ненужных данных" и блок "Экономия денег/времени" должны иметь триггеры их включения/отключения. При этом я еще не определил точную внутреннюю структуру этих блоков, но включать/отключать блок нужно иметь возможность целиком независимо от его внутреннего устройства. Ели пользователь включает блок, то он говорит программе, что он хочет использовать эту предоставляемую ею возможность и наоборот в противном случае.

Встал вопрос, какими же структурами хранения данных наполнить эти блоки и какой сделать их внутреннюю логику, чтобы они смогли выполнять указанные функции?
1. Итак, блок "Резка ненужных данных" должен получить на входе запрос на предоставление данных, а на выходе должен выдать решение, нужны ли они нам или нет. Если данные нам не нужны, то вместо них в ответ на запрос выдается "пустышка" и он считается отработанным. Если нужны, то он передает запрос в неизменном виде для дальнейшего анализа. Очевидно, что эту задачу мы исчерпывающим образом решим, определив в качестве внутреннего наполнения блока одну единственную структуру - "Черный список" (в том виде, как он есть в нынешнем варианте программы). На НЕНУЖНЫХ данных мы экономим деньги/время не методом кэширования, а путем их резки.
2. Далее, если данные нам нужны, то они поступают в блок "Экономия денег/времени на нужных данных" для анализа того, как на них можно максимально сэкономить для пользователя деньги/время. Экономия достигается за счет следующего. Большинство информации присутствует на сайтах в виде статического контента (нужные нам данные на страницах изменяются не непрерывно, а через определенные не обязательно равные друг другу промежутки времени либо не изменяются вообще никогда). При этом имеется общая закономерность: на различных сайтах сети данные одних типов как правило изменяются с одинаковой периодичностью (или не изменяются вовсе). Тогда, зная наперед или оценив этот промежуток времени для данных какого-либо типа, мы можем взять достаточно малый по сравнению с ним интервал и внутри него рассчитывать на неизменность этой информации. А если инфорацию считаем неизменной, то один раз загрузив из сети, надо записать ее на диск и при повторных запросах на протяжении этого интервала брать ее с диска, экономя деньги/время. Если же для каких-то сайтов сети эта закономерность нарушается, то мы должны иметь возможность указать такие сайты (и возможно иную, присущую им закономерность) программе.
Все. Это единственный принцип, на котором мы можем экономить деньги/время методом кэширования (это, собственно, суть самого метода кэширования).
Итак, На НУЖНЫХ данных мы экономим деньги/время методом кэширования. Описанным требованиям к хранению информации для применения этого метода в полной мере отвечает список со структурой нынешнего "Не обновлять". Но мы хотим, чтоб пользователь мыслил в первичных терминах, и не вникал в вопросы чтения/записи в кэш. А "Не обновлять" по нынешнему смыслу расшифровывается как "Не обновлять из кэша". Поэтому мы называем наш список "Условия устаревания данных, но не в кэше, а в сети". Теперь пользователь оперирует первичным термином - временем устаревания данных определенных типов в сети. А далее вопросами записи/чтения в кэш занимается сам метод кэширования, для которого указанные данные являются необходимыми и достаточными для организации МАКСИМАЛЬНО эффективной экономии денег/времени и ДИСКОВОГО ПРОСТРАНСТВА пользователя. При этом ЛЮБОЕ изменение пользователем условий записи в кэш ведет к отклонению от максимума, т.е. к снижению экономии денег/времени и/или лишнему расходованию дискового пространства. Возникла тогда быстрая мысль: а может, пользователь может вмешиваться в порядок записи в кэш исходя из каких-то других целей, не связанных с экономией? Но все цели пользователя изначально нами определены как резка ненужных данных и экономия денег/времени при использовании нужных данных. Других нет. Поэтому влиять на порядок записи в кэш нет резона. Именно поэтому я так старался и спрашивал в топике, а могут ли быть у пользователя еще какие-нибудь цели (другими словами, есть ли еще какое-нибудь назначение у программы)? Эти мои вопросы расценивались как "литье воды". Я думаю, что прежде всего это от моего неумения объяснить толком. Но объяснить не мог, т.к. цельной картины и уверенности в том, что она в итоге сложится у меня не было, а я хотел сложить ее вместе с участниками топика. Поэтому-то и топик создан не в "Новых предложениях", а в "Общих вопросах". А когда я увидел, что от меня ждут готового рецепта, конкретной новой структуры, стало совсем грустно. Ведь именно решения вопроса о возможности/невозможности реализации такого ориентированного на пользователя подхода и связанной с ним структуры хранения данных и логики программы, хочется достичь совместными усилиями. Именно поэтому старался упирать лишь на общие принципы организации такого подхода, надеясь, что сойдясь на них, дальше пойдем думать вместе. Не очень получилось, поэтому думать приходится одному, одновременно обороняясь от требований выдать конкретную структуру, которой не было и которую приходилось продумывать по ходу самостоятельно. Ну да ладно... Структура потихоньку проясняется. И хочется ее доработать совместно с теми, у кого "намерения понимание давно нашли".

Вот такая была моя логика. И сейчас, пока я не представляю себе иных назначений программы, имеется твердая уверенность о ненужности списка "Запись в кэш". Но под влиянием мнений других участников топика стали одолевать сомнения в другом: не все так гладко. Что, вот так легко и бесследно забыть активно используемые в повседневной жизни "Белый список" и список "Только из кэша"? Как они влияют на расстановку сил? Может, добавляют нечто принципиально иное?

Продолжение следует...
Сообщить модератору   Записан
Страниц: 1 2 3 [4] 5   Вверх
  Отправить эту тему    Печать  

 
Перейти в: