О программировании

/// @author Vital

Метка: design

  • Desktop wallpaper в качестве инструмента проверки браузера под различным разрешением

    Используем обои для рабочего стола

    У моего монитора разрешение 1680×1050, а в работе иногда нужно время от времени смотреть как будет выглядеть содержимое браузер например под разрешением 1024×768 или 1280×800.

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

    Инструмент готов к использованию. Конечно это не так радует глаз как какая-нибудь супрематическая конструкция, но зато вполне утилитарно. Теперь для того, чтобы быстро проверить верстку в 1024×768 — подгоняем размер браузера под нужный прямоугольник и смотрим.

    При желании можно поместить в свободное пространство какую-нибудь приятную вам картинку. Я поместил Дюка (жавный маскот с красным носом). Он сейчас стал опенсорснутым, то есть вы его можете свободно (т.е. на халяву и безболезненно) использовать в различных целях. Например выкладывать в блогах и на своих веб страничках. Подробнее можно прочитать в “Open Source Duke”.

    Сами картинки с Дюком можно взять здесь.

  • Нефункциональные требования к проектируемому ПО.

    Краткий справочник по  Non-functional Requirement.

    Перед разработкой архитектуры системы или на ранней стадии ее проектирования,
    всегда следует уделять внимание так называемым нефункциональным показателям (Non-functional QoS). Они определяют характеристики, которые не связаны с конкретным поведением системы, но при этом задают требования с точки зрения бизнеса.
    Как и для любых показателей, которые определяются на этапе проектирования, кроме  желаемых характеристик, следует также, в первую очередь, выявить их минимально допустимые значения. Например, если система будет доступна в рабочем состоянии меньше 100 часов в неделю (Availability = 100/168 ~ 59.52%), то такая система для бизнеса будет не интересна (убыточна, не приносить никакой пользы). Зачем это нужно?
    Дело в том, что далеко не все базы данных, сервера приложений или технологические платформы могут обеспечить необходимые показатели доступности (availability), масштабируемости, надежности и т.д.. Выбор тех или иных решений должен зависеть от этих характеристик.

    Краткий список нефункциональных показатели системы (Non-functional QoS):
    Scalabitlity – Масштабируемость. Возможность увеличивать производительность системы пропорционально выделенным ресурсам. Бывает горизонтальная и вертикальная. Вертикальная – докупаем более быструю память, более шустрый жесткий диск или переносим всё на один еще более мощный сервер. Горизонтальная – покупаем еще один сервер и запускаем приложения  в кластерном режиме, в случае необходимости – докупаем еще один сервер и втыкаем к двум уже работающим и так далее.
    Extensibility – Расширяемость. Возможность добавление дополнительного функционала.
    Flexibility – Гибкость. Возможность менять существующую архитектуру (например в зависимости от ценовой политики). В отличие от Extensibility, речь идет только об изменениях без дополнительного функционала. Например у заказчика нет денег на нормальную СУБД (допустим ORACLE). Наша задача сделать систему настолько гибкой, чтобы в случае необходимости мы смогли её подпилить так, чтобы она смогла  бы обойтись чем-нибудь бесплатным (MySQL или PostgreSQL).
    Насколько должна уметь прогибаться система, желательно, по мере возможности, определить по-раньше…
    Maintainablity – Поддерживаемость, ремонтопригодность. Способность поддерживать систему в работоспособном состоянии. Показатель определяет насколько легко (или сложно) вносить исправления в работающую систему, возможно ли повторное развертывание и запуск системы после сбоя, возможность восстановить из резервных хранилищ и т.д.
    Availability – коэффициент доступности(готовности). Процент времени проведенного  системой в работоспособном состоянии к общему времени работы системы.

    часто высоко доступные (High Availability) системы меряются девятками:

    • 99,9 % (три девятки) = система недоступна не более 8,76 часов/год
    • 99,99 %  (четыре девятки)= не более 52,6 минуты/год
    • 99,999 % (пять девяток) = не более 5,26 минуты/год

    Manageability – управляемость. Возможность отслеживать и предотвращать возможные сбои в системе. Это в первую очередь наличие логирование (журналирование), системы оповещения о сбоях, возможность предотвратить возникновения ошибки.
    Reliability – надежность. Вероятность безошибочного выполнения операций в определенный период времени в определенном окружении.