10 сентября 2010 г.

Виртуальные рабочие столы

В *nix-системах довольно популярна идея (и реализация в рамках дистрибутива OS) виртуальных рабочих столов.
В win-системах это реализуется только сторонними приложениями.
Наличие единственного рабочего стола больше соответствует понятию "рабочий стол", используемому в реальной жизни: посмотрите на свой рабочий стол, на котором стоит Ваша клавиатура (ноутбук, книжка, кружка ... :) ) - сколько столов вы видите? :) Получается, что в реальной жизни Вам хватает одного стола, а в виртуальной - нет. :)
Основным удобством виртуальных рабочих перед реальными (из реальной жизни) является возможность переключаться между различными активностями: например, на одном столе можно "обложиться учебниками и писать диплом", а на другом "пить чай с плюшками". В реальной жизни нам пришлось бы либо ходить от стола к столу, либо объеденить эти активности, и рисковать "залить диплом чаем". :)
Тем не менее, мало кто из нас может одновременно (именно одновременно) работать плодотворно сразу на двух столах: писать диплом, глядя в книгу, и пить чай с плюшкой - либо мы смотрим в книгу, либо в кружку; либо мы держим ручку, либо кружку. Происходит постоянно переключение внимания.
Нет, чай-то мы, конечно, попьём, но получим ли мы от этого удовольствие? :) И уж точно, на время совмещения, у нас снизится скорость написания диплома.
Предлагаю не создавать одновременно множество виртуальных столов, а иметь один, но при необходимости выгружать его и загружать другой. Например:
  • включили компьютер и сразу выбрали нужный рабочий стол (с дипломом);
  • поработали за ним - записали состояние стола, выгрузили, выбрали и загрузили другой стол (с чаем и плюшками);
  • попользовались другим столом - записали состояние, выгрузили, выключили компьютер.
Т.е. стол один, но дел, которых мы за ним можем сделать - несчётное множество. И главное - эти дела не мешают друг другу.

7 сентября 2010 г.

Управление вводом/изменениями данных на формах

Сейчас в системах Windows (другие не рассматриваю, ибо не знаю как "там" сейчас) принята следующая идеология при вводе или изменении данных на формах: пользователю предоставляются 3 (не всегда) кнопки:
  • OK - применяет все изменения на форме и закрывает форму;
  • Apply - применяет все изменения на форме и оставляет форму открытой;
  • Cancel - отменяет все изменения на форме, которые были сделаны до последнего нажатия кнопки Apply.
Но иногда бывает полезно ввести/изменить данные, посмотреть как это "выглядит", и затем отменить ввод. Для выполнения этого сейчас надо выполнить следующие действия:
  1. Открыть форму и ввести/изменить данные.
  2. Нажать OK или Apply (в последнем случае нам не надо будет закрывать форму).
  3. Посмотреть полученный результат.
  4. Опять открыть форму (или перейти на неё, если на шаге 2 мы нажали Apply).
  5. Отменить все исправления, сделанные на шаге 1.
  6. Нажать OK.
Предлагается для достижения того же результата изменить эту последовательность действий на следующую.
  1. Открыть форму и ввести/изменить данные.
  2. Нажать Apply (форма остаётся открытой).
  3. Посмотреть полученный результат.
  4. Перейти на форму.
  5. Нажать Cancel.
Т.е. нам не придётся повторно отменять (кликать по всем контролам) все исправления. Т.е. предлагается изменить фукнционал кнопки Cancel на такой, что её нажатие будет отменять все изменения, сделанные на форме, не до последнего нажатия кнопки Apply, а до момента открытия формы.

P.S. Возможно, таким образом мы потеряем какой-то другой фунционал. :)

Контроль качества

Разработчики создают программы. Отдел качества их тестирует. Пользователи - используют.
Но иногда компании экономят на отделе качества (например, выделяют недостаточное количество тестеров на проект или предоставляют недостаточное количество времени для тестирования). Таким образом роль тестеров достаётся конечным пользователям.
Предлагается.
Создаётся интернет (онлайн) сообщество тестеров, желающих заниматься тестированием на следующих условиях:
  • Разработчик перед выкладыванием проекта для тестирования, выделяет на это определённую сумму денег.
  • Тестер по желанию может присоединиться к любому проекту.
  • Необходимо гарантировать, что пользователи знают об описываемом сообществе тестеров. (???)
  • Тестер (практически по желанию, но теоретически это понадобится) знакомится с документацией по проекту.
  • Тестер по желанию может заниматься поиском ошибок в программе.
  • Если тестер(1) находит ошибку в программе, которая не соответствует функционалу (это обязательное условие), описанному в документации, то он сообщает о ней в сообществе.
  • Если другой тестер(2) видит, что кто-то нашел ошибку, то он может проверить её: действительно ли ошибка имеет место быть.
  • Если ошибка подтверждается, каждый тестер получает определённое, но различное количество баллов.
  • Если ошибка не подтверждается, то инициируется процедура судейства (???), после которой с какого-нибудь тестера (или с обоих) могут снять часть баллов.
  • Найденная ошибка уходит разработчикам (на исправление).
  • Разработчик также может быть не согласен с наличием ошибки (???).
  • После завершения этапа тестирования, начинается этап опытной эксплуатации пользователями.
  • Если пользователь находит ошибку, он сообщает о ней в сообщество тестеров.
  • Каждая найденная пользователем ошибка также обрабатывается на соответствие документации, с привлечением, при необходимости, процедуры судейства. (???)
  • Если ошибка подтверждается, то со всех тестеров, участвующих в проекте, снимается определённое количество баллов, а пользователь, нашедший ошибку, наоборот, получает определённое количество баллов.
  • После завершения этапа опытной эксплуатации, выделенная разработчиком на тестирование сумма, делится между тестерами и пользователями, в соответствии с набранными ими баллами.
Знаками "???" пометил места, которые требуют дополнительного обдумывания.

Описание изменений ТЗ

Каждое ТЗ (фича) всегда описывает не только то, что необходимо сделать в рамках данного ТЗ, но и то, что было сделано ранее. Основной плюс т...