One-Click Install: Установка ПО без лишних хлопот

openSUSE содержит тысячи пакетов, которые часто разбросаны по разных репозитариях. Такие репозитарии как Packman, Guru’s RPM и, конечно, openSUSE Build Service, снабжают тисячами пакетов для пользователей openSUSE. Однако, проблема в поиске пакетов, добавлении репозитария и наконец установке его. Это может быть надоедливым процессом, особенно, намеренно используете много пакетов с разных репозитариев (тоесть, в Build Service).

One Click Install решает эти проблемы.

В openSUSE 10.3, если вы ищете, чтобы установить приложение, в openSUSE Build Service, вы можете использовать новую web front-end для поиска, просмотра и установки приложения в один клик мышкой. Для примера, поиск Filelight (приложение для визуализации использования дискового пространства на вашем компьютере) в openSUSE Factory показан ниже:

После нажатия на 1-Click Install, Вы попадете в мастер, который будет руководить простым процессом установки приложения. Он автоматически добавит репозитарий и установит пакет. Этот процесс показан ниже:

Все это можно прямо сейчас испытать, предполагая, что вы запускаете на openSUSE 10.3 Beta 1 или на текущей openSUSE Factory с помощью Konqueror. Чтобы получить тот же эффект на Firefox, прочитайте это описание.

Эту возможность можно будет использовать в будущем и на openSUSE-Community.org. Поиск ПО тоже скоро будет иметь обновлённую версию с возможностью One-Click Install. Ниже еще раз пример поиска filelight:

Нажав на одну из этих ссылок, вы так же попадете в простой мастер, как указано выше.

Перевод: Sneak Peeks at openSUSE 10.3: 1-Click Install

Продолжаю переводить серию статей о реализации Undo.

Это вторая часть первой части серии заметок “Функция отмены последнего действия (Undo)”. Если вы её пропустили, то сначала прочитайте первую часть (перевод первой части).Один с моих читателей, Alex Botero-Lowry, отметил большую проблему реализации Undo c очереди полностью на стороне клиента: если пользователь открывает эту же страницу на второй вкладке браузера для просмотра, то эти страницы могут быть не синхронизированы. В примере to-do листа, если вы удаляете три to-do листа и открываете новую вкладку или окно этой же страницы, то эти to-do всё-таки останутся. Почему? Потому что первая страница знает о удалении (хотя оно и не законченное), а вторая – нет.

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

Хочу подчеркнуть, что метод очереди событий – очень легкое решение отмены действия. Существуют другие, более надёжные пути реализации Undo, такие как основаные на серверной стороне command pattern (пару моих читателей обратили на это внимание и я, возможно, рассмотрю это в следующих заметках). Но это не относится к делу. Когда мы, как инженеры, стараемся решить сложные проблемы, мы часто слишком обобщаем и слишком абстрагируемся к своему back-end решению, не замечая других вариантов. Когда мы делаем это, мы пропускаем простые решения, которые могут помочь пользователям уже сейчас. Некоторые формы Undo как низко-висячие фрукты, почему же не сорвать их? Конец отступления.

Повторяю, мы решаем что случится, когда пользователь удалит некоторые элементы, откроет другую вкладку этой же страницы и те пункты, оказывается, не удалены. Предположим, что очередь событий хранит идентификаторы удалённых объектов и каждый раз когда элемент удаляется или удаление незаконченное, мы пишем очередь в cookie; когда страница закрывается – мы очищаем куки. Когда страница загружается – мы проверяем куки и если в них есть не пустой список, то мы на стороне клиента “удаляем” элементы и добавляем их в очередь. Теперь каждая новая вкладка/окно открывается, мы гарантировано синхронизируем их.

Проблема решена.

Сложность

Итак, что случится когда вы сделаете изменения на одной странице, а потом переключитесь на другую, уже открытую страницу? Это может усложнить жизнь. Мы спасены от необходимости иметь дело с всей проблемой, потому что web не технология “толчка”. В настоящее время, никакое приложение сети, о котором я знаю, без возможности ручного обновления, не может обновить страницу, когда она изменена в другой вкладке. Пользователи используют обновление страницы, чтобы увидеть изменения. Это означает, что мы должны правильно обходится с вариантом, когда пользователь удаляет и восстанавливает данные в одной вкладке, возвращается в другую и нажимает refresh.

Чтобы решить эту проблему, мы должны сделать предположение, что последняя вкладка/окно, в котором пользователь что-то редактировал, содержит наиболее актуальную информацию. Это резонное предположение, потому что последнее с чем пользователь работал, наиболее вероятно будет тем, о чем пользователь думал как последняя версия.

Когда же пользователь обновляет страницу, вызывается метод onUnload. В нём мы должны проверить, совпадает ли очередь страницы с очередью последней сохранённой в кукисах очередью (помните, что очередь событий сохраняется в cookie, когда пользователь удаляет или отменяет удаление). Если две очереди одинаковые, то страница актуальна и мы продолжаем передачу изменений ксерверу. Если две очереди не одинаковые, то текущая страница требует синхронизации с сохранённой в куках очередью, в результате чего она обновляется.

Попробуйте

Поиграйте с этим, затем откройте новое окно браузера. Теперь, измените что-то в новом окне и потом обновите старое окно. Всё правильно обновляется.

Исходный код

…находится здесь.

Заключение

Польза от пути cookie заключается в том, что это улучшает положение с уже редком случае, когда пользователь теряет свою работу в случае краша браузера. Когда браузер “падает”, то все изменения сохраняются в куках, итак, когда пользователь загружает страницу опять, его изменения вся-таки применяться.

Система очереди событий с синхронизацией на куках – это низковисячий фрукт. Это работает не везде, но будет работать в поразительно большом количестве случаев. Это стоит сравнительно небольших сроков.

На следующей неделе, я напишу о решении Undo для время-зависимых действий.

Перевод: Undo Made Easy with Ajax (Part 1.5)

Я почитываю материалы по многим темам Internet, в том числе и по usability. А тут попалась на глазуа статья, как делать отмену последнего действия под Web. Стало интересно – решил переводить.

Как пользователи, мы делаем ошибки. Как дизайнеры, мы должны спроектировать интерфейсы с учётом этого, как я и утверждал в своей недавней статье Never Use a Warning When You Mean Undo ( перевод этой статьи – Реализуйте возможность отмены действия, вместо диалогов подтверждения ). Undo – это отличный спасательный круг, придающий потрясающее чувство надёжности работы интерфейса. Вот почему каждое десктопное приложение от Word до Photoshop предоставляет возможность многоуровневой отмены действия.

Так почему же Web-приложения которые предоставляют хоть какую-либо возможность отмены так немногочисленны? Ответ я часто получал, что эту функцию трудно реализовать.Я здесь, чтобы сказать вам, что это не так.

В этой серии записей в блоге, моя цель объяснить как легко реализовать функциональность отмены действия. Недавно, я дал предварительный вариант этой заметки на семинаре. После показа демо того, как может работать отмена, аудитория слегка привстала со своих мест. Когда же я открыл исходный код и начал показывать как это реализовано, универсальный возглас был: “Зачем Вы объясняете это? Это же всем понятно. Мы же разработчики ПО. Это легко!”

То-то же!

Добавление Undo в ваши интерфейсы сильно и положительно повлияет на удобство пользования вашим сайтом. Это уменьшит разочарования пользователя и увеличит его доверие.Оба этих умозаключения означают, что большие количество
пользователей вернуться, что увеличит вашу прибыль. Запомните: для пользователя, интерфейс – это продукт.

Теперь вы не можете не реализовать функцию отмены. Итак, без дальнейших хлопот, вот вам первый метод реализации.

Метод 1: Очередь событий

Ситуация: Вы сделали онлайновый to-do список и пользователя нужна возможность удалить любую сущность со списка. Вы не хотите, чтобы пользователь удалил сущность случайно, также вы не хотите чтобы он изменил своё мнение после удаления или через 2 секунды. Этот метод теперь реализован в Интернете через уведомление пользователю диалоговым окном.

• 
• Даже 37 Signals, обычно оплот хорошего дизайна, использует уведомление вместо отмены действия.

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

Попробуйте поработать со списком to-do со стандартным (но не очень гуманным) окном предупреждения.

Теперь представим, что мы изменили своё мнение о удалении чего-либо или хотите удалить 3 строчки. Как бы расстраивает, не так ли?

Правильно решение функции отмены, которое мы можем осуществить здесь имеет очередь событий и вызов “onUnload”. Когда мы нажимаем на удаление, to-do сущность исчезает. В общем, в этой точке мы должны будем отправить AJAX-запрос на сервер, чтобы удалить её. Когда пишем Undo, вместо немедленного вызова AJAX, мы ждём пока пользователь уйдёт с текущей страницы (это мы определяем, используя вызов “onUnload”). Это достигается путём добавления ссылки на to-do в очередь для безопасного сохранения.

Когда пользователь нажимает на Undo, мы достаём последнюю добавленную в очередь и делаем её видимой опять. Когда же пользователь уходит со страницы или закрывает её, вызывается метод “onUnload”. На данном этапе мы получаем собитие с очереди и отправляем AJAX-запрос о удалении списка.

Одним с больших преимуществ метода с очередью событий в том, что это делает реализацию многоуровневой отмены задачей очень тривиальной. И это также даёт безболезненное удаление списка to-do кучей (чего нет, когда удаление происходит с сообщением). Попробуйте!

Исходный код

Заинтриговало? Хотите знать больше? Хорошо. Вот и задокументированный исходный код.

Предупреждение

Метод очереди событий в реализации функции отмены не идеален:

• Если браузер пользователя или компьютер вызовет ошибку, тогда работа пользователя потеряется. Это явно не оптимальный расклад..С другой стороны,это редкое явление и можно смело игнорировать все, кроме жизни и смерти
  важных данных.
• Работа в реальном времени не работает в этом методе, потому что данные не отправляются серверу пока пользователь не уйдёт со страницы. Таким образом, другие пользователи не увидят изменений в реальном времени. Другие методы
  реализации Undo обходят даную проблему, но надо ждать другую заметку с этой серии.
• Этот метод не целесообразно использовать для отправки emails или других срочных действий. Потому что действие будет завершено только тогда, когда пользователь покинет страницу, а это может растянуться на полчаса или час пока email будет отправлено. Это неприемлемо.

Вывод

Как Вы видите, Undo не слишком трудоёмкое занятие. Метод очереди событий можно даже сделать полностью на клиентской стороне, что означает, что вы можете реализовать отмену даже без изменений “back end”.

Итак, больше никаких отговорок по-поводу сложности реализации функции отмены последнего действия! Пришла пора Undo в web!

На следующей неделе я покажу, как сделать Отмену для срочных действий.

Перевод статьи Undo Made Easy with Ajax (Part 1)

Гореть GTK в аду!!!

Решилось тупо:

rpm -qa | grep gimp