Да как-то нет задачи создать непроходимый барьер. Это невозможно. Каждый следующий шаг по повышению устойчивости будет дороже предыдущего. А эффект от него — меньше.
В конце концов можно использовать людей для регистрации и тогда вообще ничего не будет работать.
Цель в том, чтобы создать систему, которая будет с минимальными усилиями проходиться человеком, но представлять хоть какую-то проблему для роботов. ну или для желающих по быстренькому написать бота, который будет в эту форму гадить.
Здорово.
Кажется, правда, что человек может это пропустить, недосмотреть и так ошибиться. Я бы спрашивал во всплывающем окне «Вы робот?» А там можно даже немного схитрить с расположением кнопок или надписях на них.
Тогда уж «штука в кармане распознает текст, подгоняет синтезированный голос под спектр голоса иностранца, вырезает голос иностранца из потока, и вещает в ухо уже перевод голосом иностранца». Так должно быть удобнее, да и можно сразу говорить с несколькими.
Хотя с другой стороны, если я не ошибаюсь, то бОльшую часть изображения человек видит как раз центром сетчатки, а остальная часть достаточно смутно воспринимается. А цельность получается за счет практически постоянного движения. Если с этой позиции смотреть, то да — можно сделать центральную часть высокого разрешения, а вокруг — гораздо более низкого, чтобы покрыть боковые участки.
Вообще HD будет сильно курить в сторонке :)
Вторая идея разумнее. Даже с той точки зрения, что птиц не будут кормить чем попало. В этом автомате можно продавать в самом деле корм.
Так можно и в зоопарке поставить автомат и в него загрузить корм. Чтобы животных не перекармливали — загружать дневную норму, а в конце дня отдавать животине остатки из автомата. Так и перекармливать не будут и те, кто хотят покормить — будут довольны.
Все еще сомневаюсь, что это устройство сможет заменить клавиатуру. В итоге останется все та же клавиатура, которой надо будет изредка пользоваться для допиливания недопиленного и будет это пульт, который будет только как пульт.
Да универсальных пультов вроде как хватает, с этим проблем нет, вроде как.
А вот как это использовать даже в качестве пульта — слабо себе представляю. Вот клавиатура справа она подразумевает работу на ней только большим пальцем правой руки? Или его для этого надо на стол класть… много всяких вопросов, по этому и сомнения в практической применимости этого устройства.
Почему-то кажется, что не будет эта железяка удобна ни геймерам для игры, ни просто для набора текста, ни как пульт. В общем не будет удобна совсем нигде.
>>что вам мешает, поставить индикатор на эту запись, но при этом отобразить ее в общем списке?
Если будет однозначно понятно, что запись добавляется, а не добавлена — то это по мне. Это хорошо. А если она будет сразу добавлена и асинхронно добавляться на сервере, то это та асинхронность о которой я говорю. И мне кажется не только я. Речь о том, что запись будет добавлена как будто уже все случилось, хотя на самом деле в фоне только ушел запрос.
Про оставленный в браузере сайт не очень понял к чему это. Да, оставил, ну пришел — отправил, в любом случае там могла сессия протухнуть, у меня мог смениться ip и слететь авторизация и так далее. Все равно мне не дадут добавить запись, так как у меня нет на это прав.
>>Тогда какая разница где создавать очереди на клиенте или на сервере?
Разница в том, что очередь на клиенте не контролируема, может быть прервана, утрачена и пользователь должен четко понимать, что действие НЕ выполнено до сих пор, а это уже синхронность. Иначе будут потери, будут откаты и все остальные неприятности.
Чего стоит откат операции, которая уже была объявлена как совершенная. Хуже сложно себе придумать. Нечто вроде «ваш платеж проведен», а потом «в процессе работы возникла ошибка, платеж не проведен». Жуть!
Не подумайте, что я против подобных интерфейсов, я вот прямо сейчас применяю асинхронный подход, но в том месте, где это в самом деле актуально и где потеря данных не приведет ни к каким проблемам. А бездумное и неуместное применение подобного подхода — опасно и может привести к серьезным проблемам. Не везде это можно применять и далеко не всегда.
Нет в этом месте отличий с асинхронным интерфейсом. Совсем. Просто при асинхронной обработке интерфейс сначала говорит, что все прошло хорошо, а потом уже может сказать, что произошла ошибка (что само по себе странно, правда?), а синхронный интерфейс будет ожидать окончания операции и потом либо произведет действие, либо сообщит об ошибке.
Обработка ошибок никак не отличается в этих ситуациях.
Как быть когда вы проголосовали за 10 комментариев, показали что все прошло отлично, а потом оказалось, что сервер недоступен? В случае синхронного интерфейса достаточно будет уведомить об ошибках и не производить изменений с элементом, а в случае с синхронным — откатить изменения назад.
>>зачем для каждого элемента городить огород в виде кнопки с индикацией загрузки, окна с индикацией загрузки, иконки с индикацией загрузки?
Затем, что индикация где-то там вдалеке от элемента — видна куда хуже, чем сам элемент. Если элемент реагирует на действие, то это сразу видно. Перед кликом человек смотрит на элемент, а не на таскбар. Если элемент сразу сигнализирует о том, что происходит действие, то это видно. А если реагирует никак не связанная с ним область, то связать два действия воедино — куда сложнее. А еще это отвлекает.
>>чтобы не блокировать весь интерфейс на время выполнения одной задачи.
Никто не говорит о блокировке всего интерфейса. Если я голосую за комментарий — не надо мне блокировать отправку сообщений. А вот элементы голосования заблокировать нужно. И индикацию мне тут показать тоже нужно. А не высовывать мне таскбар на каждый чих в котором будет 100500 уведомлений о том, что выполняются мои запросы.
>>как и откуда мне извлечь данные которые не ушли
Точно так же по таймауту запрос не будет выполнен, вы получите свою форму и свои данные назад. Не вижу связи вообще.
В конце концов можно использовать людей для регистрации и тогда вообще ничего не будет работать.
Цель в том, чтобы создать систему, которая будет с минимальными усилиями проходиться человеком, но представлять хоть какую-то проблему для роботов. ну или для желающих по быстренькому написать бота, который будет в эту форму гадить.
Кажется, правда, что человек может это пропустить, недосмотреть и так ошибиться. Я бы спрашивал во всплывающем окне «Вы робот?» А там можно даже немного схитрить с расположением кнопок или надписях на них.
Вспомнился милый сердцу робофорум :)
Вообще HD будет сильно курить в сторонке :)
Про применение в зоопарках не знал.
Так можно и в зоопарке поставить автомат и в него загрузить корм. Чтобы животных не перекармливали — загружать дневную норму, а в конце дня отдавать животине остатки из автомата. Так и перекармливать не будут и те, кто хотят покормить — будут довольны.
А вот как это использовать даже в качестве пульта — слабо себе представляю. Вот клавиатура справа она подразумевает работу на ней только большим пальцем правой руки? Или его для этого надо на стол класть… много всяких вопросов, по этому и сомнения в практической применимости этого устройства.
Вообще дело даже не в грузоподъемности. Мечта не просто несбыточная, а можно считать утопичная.
Если будет однозначно понятно, что запись добавляется, а не добавлена — то это по мне. Это хорошо. А если она будет сразу добавлена и асинхронно добавляться на сервере, то это та асинхронность о которой я говорю. И мне кажется не только я. Речь о том, что запись будет добавлена как будто уже все случилось, хотя на самом деле в фоне только ушел запрос.
Про оставленный в браузере сайт не очень понял к чему это. Да, оставил, ну пришел — отправил, в любом случае там могла сессия протухнуть, у меня мог смениться ip и слететь авторизация и так далее. Все равно мне не дадут добавить запись, так как у меня нет на это прав.
>>Тогда какая разница где создавать очереди на клиенте или на сервере?
Разница в том, что очередь на клиенте не контролируема, может быть прервана, утрачена и пользователь должен четко понимать, что действие НЕ выполнено до сих пор, а это уже синхронность. Иначе будут потери, будут откаты и все остальные неприятности.
Чего стоит откат операции, которая уже была объявлена как совершенная. Хуже сложно себе придумать. Нечто вроде «ваш платеж проведен», а потом «в процессе работы возникла ошибка, платеж не проведен». Жуть!
Не подумайте, что я против подобных интерфейсов, я вот прямо сейчас применяю асинхронный подход, но в том месте, где это в самом деле актуально и где потеря данных не приведет ни к каким проблемам. А бездумное и неуместное применение подобного подхода — опасно и может привести к серьезным проблемам. Не везде это можно применять и далеко не всегда.
Обработка ошибок никак не отличается в этих ситуациях.
Как быть когда вы проголосовали за 10 комментариев, показали что все прошло отлично, а потом оказалось, что сервер недоступен? В случае синхронного интерфейса достаточно будет уведомить об ошибках и не производить изменений с элементом, а в случае с синхронным — откатить изменения назад.
Затем, что индикация где-то там вдалеке от элемента — видна куда хуже, чем сам элемент. Если элемент реагирует на действие, то это сразу видно. Перед кликом человек смотрит на элемент, а не на таскбар. Если элемент сразу сигнализирует о том, что происходит действие, то это видно. А если реагирует никак не связанная с ним область, то связать два действия воедино — куда сложнее. А еще это отвлекает.
>>чтобы не блокировать весь интерфейс на время выполнения одной задачи.
Никто не говорит о блокировке всего интерфейса. Если я голосую за комментарий — не надо мне блокировать отправку сообщений. А вот элементы голосования заблокировать нужно. И индикацию мне тут показать тоже нужно. А не высовывать мне таскбар на каждый чих в котором будет 100500 уведомлений о том, что выполняются мои запросы.
>>как и откуда мне извлечь данные которые не ушли
Точно так же по таймауту запрос не будет выполнен, вы получите свою форму и свои данные назад. Не вижу связи вообще.