Link'и на посты о Django (старые, но хорошие)

Просматривая свой реадинг лист с июня 2007-го наткнулся на 3 поста о установке и настройке джанги. Моим студентам должно быть полезно.

Установка Django под Windows

Как установить Django на виртуальном хостинге

Отличный ролик Web 2.0 is linking people... - не Nokia, а именно Web 2.0

Толково сделано, а главное - очень динамично. Хочу, чтоб  моем блоге он тоже был.

Полезные Django линки

1. Restrict Flatpage To Group
2. Choices datatype for model
3. Django-friendly hosts
4. Djangofriendly
5. multiple-step forms in Django
6. Setup mod_wsgi for Django and Shared Hosting
7. Django and Twill

Ничего дополнительно комментировать не буду. Все хоть и на английском, но очень наглядно и понять просто. Последнее в нагрузку, т.к. практической ценности для меня не представляет.

Изобразительные инструменты UML

3 вида строительных блоков:

1. Сущности
2. Связи
3. Диаграммы

Теперь подробно о каждой из них:

Сущности - основные элементы модели. Бывают 4 видов:

1. Структурные
2. Поведенческие
3. Группирующие
4. Аннотирующие

Сейчас напишу про структурные, а про все остальные в следующий раз.

Структурные сущности - имена существительные, обозначающие либо концептуальные элементы, либо физически существующие элементы. В совокупности структурные сущности называются классификаторами.

Класс - описание набора объектов с одинаковыми атрибутами, операциями, связями и семантикой. У класса может быть несколько интерфейсов.

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

Кооперация (collabration) - совместное поведение некоторого кол-ва элементов. Кооперации бывают структурными и поведенческими. Разные кооперации могут включать один и тот же класс, элемент и пр. Кооперации и паттерны тесно связаны в проектировании.

Вариант использования (use case) - описание действия приносящего значимый результат действующему лицу (actor). Варианты использования примененный для поведенческого описания - кооперация.

Активный класс - класс, управляющий одним или несколькими процессами/потоками.

Компонент - модуль системы. Призван показать программную архитектуру ПО.

Узел (node) - например, компьютер на котором будет запущен клиент для Вашего WS.

Артефакт - уже существующая или замещаемая часть системы. То, с чем приходится мерится. Например, Вы используете jquery в проекте. Добавлять полное его описание - бред. Вы ж не будете его модифицировать (наверное). Хватит и артефакта.

Safari

Стыдно признаваться, но до сегодняшнего дня я ниразу не видел этот замечательный браузер (Safari). Сегодня поставил его себе и тут же полюбил. Шутка! Любовь -эмоция слишком сильная, чтоб испытывать её к браузеру, но у этого товарища всеж есть ряд преимуществ. О них ниже:

• внешний вид никогда не отвлечет вас от содержания страниц - именно так. Весь браузер серенький. темненький. Кнопки в глаз не лезут, оставляя эту возможность сайту, который Вы посетили.
• вроде бы, сафари даже быстрей opera обрабатывает html и javascript
• сафари дружит с javascript ом, с которым не дружит опера и при этом у меня с 15 закладками он съел 130 Мб на Виста. Видимо, с памятью у него все в порядке.

Можно ещё продолжать, но не хочется. Думаю, всем стоит хотябы попробовать.

Этапы проектирования ИАК "Экопаспорт" (все как и должно быть в RUP)

Жизненный цикл разработки программного обеспечения принято определять к одному из типов:

• процесс управления вариантами использования (use case driven)
• процесс сконцентрированный на архитектуре (architecture centric)
• итеративный и пошаговый процесс (iterative)

В работе на ИАК используем последний, в виду необходимости корректировать требования к полноте результатов каждого шага процесса.

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

Каждый шаг итеративного процесса можно дробить на фазы - отрезки времени между двумя важными контрольными точками (milestones), в которые достигаются четко определенные цели.

В проектной модели ИАК "Экологический паспорт ХМАО-Югры" необходимо отразить семь из девяти дисциплин RUP (Rational Unified Process):

1. Бизнес-моделирование (buisness modeling) - описание структуры и динамики организации заказчика;
2. Управление требованиями (requirements) - выявление требования на основе множества подходов;
3. Анализ и проектирование (analysis & design) - описание множества архитектурных представлений системы;
4. Реализация (implementation) - собственно, разработка программного обеспечения, модульное тестирование и интеграция;
5. Тестирование (test) - описание тестовых процедур, сценариев и метрик для оценки дефектов;
6. Размещение (deployment) - описание способов поставки продукта потребителю;
7. Управление конфигурацией и изменениями (configuration managment).

Я в шоке

http://www.bostondynamics.com/content/sec.php?section=BigDog

Если б увидел такого в лесу - решил бы, что инопланетяне напали на землю :)

Зачем нужно моделировать?

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

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

UML - язык документирования

Успешные компании, специализирующиеся на программном обеспечении, помимо исполняемого кода производят и другие продукты, включая следующие (но не ограничиваясь ими):

• требования;
• архитектуру;
• проектные решения (дизайн);
• исходный код;
• проектные планы;
• тесты;
• прототипы;
• релизы (версии).

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

Summer of code 2008

Зашевелились разработчики со всего мира (заметно по RSS лентам).

Ниже список идей для Google Summer of code 2008 проектов, которые меня лично интересуют.

Plone

AJAXIFY PloneFormGen form editing - редактирование с создание форм в замечательном продукте FormGen в стиля вебдваноль. Всю форму можно будет, наконец, создать не покидая страницы редактирования.

The "Big Green Button" - у нас есть аналог: кнопка "сделать за**ись!" - толком не понял, но вроде, идея в том чтоб экспортировать плон сайт при каждом изменений во что-то более простое. Что именно - не ясно, но суть в том, чтоб не работать с динамикой при каждой загрузке страницы. Идея сама по себе не нова. Например, PyPy компилировал python в C, что существенно сокращало скорость выполнения скриптов.

Похоже в данном случае фронтэнд сайта планируется сделать на PHP, а Plone будет стоять на, скажем. локальной машине админа, который будет экспортировать динамический контент на сервер. Интранет и Интернет могли бы подружится в крупных конторах, использующих плон... Короче, ждем. Нефтегазу бы не помешало что-нибудь похожее.

Buildout builder - решения для простого развертывания плон-сайтов. Подробней тут: 2008 Plone Strategic Planning Summit initiative.

WSGI auth - no comments. Авторизация через WSGI. Оказывается, AuthKit, Barrel тоже умеют использовать WSGI. Не понятно, почему мы не использовали Barrel для создания единой точки входа в Нефтегазе.

Portlet management improvements - улучшение управления портлетами - исправят "shown in subfolder", добавят "shown on all pages" улучшат показа на специфичных страницах.

Document attachments engine - купу научится вести себя как FCKEditor с PloneArticle. Давно пора!

Better search for East Asian languages - тоже было б неплохо. А то на данный момент он умеет находить буквы указанные в запросе. Релевантность определяется по количеству вхождения букы на страницу - полный бред.

Rich GUI batch mode - решили прикрутить ExtJS к плону. Ну что ж, кашу маслом можно испортить, если каша и масло весят 4 тонны, а съесть их должен какой-нить ребенок, у которого физически рот так широко не откроется. CSS плона уже щас весит от 350 Кб. Что будет если добавить ExtJS со всеми потрахами, сжатая версия которого весит ещё 400-500 Кб.

Cachefu modernization.

Kupu improvements - разный контент - разный редактор.

Improve ResourceRegistries - не понял, если честно. Так глубоко не копал.

UberSelectionWidget - инструменты выборки их больших списков. Например, автокмплит.

Improved text transforms. В частности, Syntax Highlighting и TeX text support. Скоро плон редактирование превратится в вики с поддержкой альтернативных языков разметки.

Basic Social Networking Functionality - встраивать в плон инструменты различных соц. сетей.

Microformats as Input and Output - микроформаты, например такие как hCalendar смогут быть импортированы в календарь, например.

UI-Improvement setting criteria in collections - улучшение создания коллекций.

Google GData - хотят организовать взаимодействие GData protocol с Зопой.

Theme demo site and product - сайт со шкурками.

 

Django

ORM aggregation support - типа, улучшить способы сбора данных в ОРМ.

Исправить поддрежку статических страниц во встроенном девелопмент веб-сервере. В частности, баги с админскими CSS.

Изменения в языке шаблонов - пространства имен в шаблоне, Generic Overlays for the Template DOM and/or Overlays for block tag

Поддержка нескольких баз. Аллилуйя!

Отличия между моделью анализа и моделью проектирования

В чем разница между моделью проектирования (Design Model) и аналитической моделью (Analysis Model)?

Analysis Model - концептуальная модель, так как она является абстракцией системы и не затрагивает вопросов реализации,

* не зависит от проекта (подходит разным проектам),

* содержит три концептуальных стереотипа – «сущность», «управление» и «граница»,

* определяет структуру, которая будет использована при оформлении системы, включая создание классов проектирования

* не поддерживаться в течение всего жизненного цикла системы,

* последовательности уделяется мало внимания.

Design Model - физическая модель, так как она является наброском реализации,

* специфична для данной реализации (любое число физических стереотипов в классах, зависит от языка реализации),

* сильно формализована,

* динамическая, больше внимания к последовательности,

* описывает проект системы, включая архитектуру,

* поддерживается в течение всего жизненного цикла системы,

* оформляет систему, сохраняя насколько это возможно, структуру, определенную моделью анализа.

Таким образом, используя всего 3 высокоуровневых модели (Use Case Model, Analysis Model, Design Model), используя 4-5 видов диаграмм можно перейти от чистой идеи до объектной реализации.

Подборка полезных ссылок по Django за вчера и сегодня

Django tagging для Django 0.96

"django-tagging - Джанго приложение, позволяющее добавлять к объектам любой модели тэги и делающее процесс работы с тэгами проще".

Документация по Django в одном файле

Один хороший человек взял и скомпилировал всю документацию из ... в виде одного CHM-файла. Честь ему и слава!

Две модели в newforms

На днях нужно было за короткое время решить одну несложную и довольно типичную задачу на django — построение формы профайла пользователя. Я не стал искать в закладках ссылки на старые известные how-to от мэтров-джангистов :-), а попробовал посмотреть что же нового и интересного у нас имеется в последней версии django (trunk).

Аватары для Django-проекта

Это первая версия, написанная на коленке, поэтому не всё еще реализовано. Например, надо сделать в профиле пользователя форму для загрузки аватара.

django admin css

Почему при запуске runserver админка такая вся красивая, а при запуске fastcgi все кривое? всмысле без css и дизайна?

Сравнение модели вариантов использования и аналитической модели - RUP

В чем разница между моделью вариантов использования (Use Case Model) и аналитической моделью (Analysis Model)?

Первое и самое главное: Use Case Model использует язык заказчика, в то время как Analysis Model - язык разработчика.

Analysis Model не должна содержать избыточность, несовместимые требования и т.п., а модель вариантов использования - пожалуйста, ведь она должна быть понятна заказчику. Каждая модель должна быть написана на языке читателя.

Аналитическая модель описывает как именно функциональность реализуется в системе. Как эта функциональность зависит от архитектуры, описывает внутренний вид системы. Определяет реализации вариантов использования.

Хортон

Сходили на "Хортон" - класс. Отличный мульт. Очень много юмора и, как всегда, классный вокал.
Есть русскоязычный сайт мульта http://xorton.ru/, на нем подборка роликов и прочей лабуды. В роликах есть два трейлера - отличный способ сформировать первое впечатление.

Windows Live Writer

Мелокомягкие не могут смирится с популярностью google программ, поэтому начинают писать на придуманной ими платформе бэкэенды для онлайн сервисов, в том числе и не своих сервисов.

Результат зависти я как раз сейчас тестирую. Live Writer - программа для написание постов в блог без загрузки браузера, без открывания страницы и ещё со многими "без".

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

В общем, будем смотреть.

1.000.000-ое посещение tsogu.ru

1 марта 2008 года сайт http://www.tsogu.ru посетил миллионный посетитель (по данным google analytics). Ура! А мы, как всегда, не праздновали.

Конечно, это не совсем правда. Ведь, считать статистику с помошью google мы начали только 15 ноября 2005 г. Посещения были и до этой даты, но у нас о них информации нет.

Абсолютно уникальных посетителей на данный момент 530 089.

Google Apps API

Кто сказал не нельзя создавать почтовые аккаунты на гугль аппс? Я? Не может! Но факт.

На самом деле, можно.

Вот тому доказательство: creating user accounts.

Модуль написан на python'е, а значит прекрасно встраивается и в Plone и в Django проекты.

Полный список возможностей и объяснениями тут: http://code.google.com/intl/ru/apis/apps/gdata_provisioning_api_v2.0_reference_python.html#Create_Account_Example

Крышусносящие примеры uml_диаграмм

Источник: http://www.uml2.ru/forum/index.php?topic=486.0
Внимание! Не все приведенные на данном форуме диаграммы составлены правильно, отвечают поставленным перед ними задачам.

Пример. Догадайтесь о чем идет речь:
1.

2.

3.

4.


УМЛ, таки, может быть наглядным...

Управление требованиями

Сегодня мне поручили подобрать инструмент для организации поддержки пользователей-клиентов организации-разработчика программного обеспечения. Имея небольшой опыт в развертывании подобных решений сразу подумал о trac. Но серьезным недостатком trac'а для подобных задач может оказаться его ориентированность на разработчиков. У системы достаточно высокий порог вхождения.

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

Очевидно, что для меня и самого сейчас очень важно разобраться с тем, что ж такое "управление требованиями".

Об управлении требованиями можно говорить, как о дисциплине (http://www.uml2.ru). Данная дисциплина рассматривается в рамках проектирования ПО при помощи UML. Однако, наиболее предпочтителен (мной и не только :) ) итеративный жизненный цикл разработки ПО, поэтому, требованиями можно управлять и в процессе (уже хорошо для моей задачи).

Что в себя включает "управление требованиями", как дисциплина?
Ответ: действия по управлению требованиями.

Какими могут быть эти действия?
* определение основной версии требований (моментальный срез требований для конкретной версии продукта);
* просмотр предлагаемых изменений требований и оценка вероятности воздействия каждого изменения до его принятия;
* включение одобренных изменений требований в проект установленным способом;
* согласование плана проекта с требованиями;
* обсуждение новых обязательств, основанных на оценке влияния изменения требований;
* отслеживание отдельных требований до их дизайна, исходного кода и вариантов тестирования;
* отслеживание статуса требований и действий по изменению на протяжении всего проекта.

Все указанные задачи в полной мере справедливы для моей задачи.


Таким образом, требования - это (IEEE Standard Glossary of Software Engineering Terminology):
1. условия или возможности, необходимые пользователю для решения проблем или достижения целей;
2. условия или возможности, которыми должна обладать система или системные компоненты, чтобы выполнить контракт или удовлетворять стандартам, спецификациям или другим формальным документам
3. документированное представление условий или возможностей для п. 1 и 2


Рекомендации по формулировки требований

Типичное требование

<Тип пользователя> должен иметь возможность <описание возможности>


Требование с ограничениями и условиями

<Тип пользователя> должен иметь возможность <описание возможности> с <показатель производительности> от <момент отсчета>, находясь в <условия эксплуатации>

Пример:
Оператор должен иметь возможность произвести выстрел в течение 3 секунд с момента обнаружения цели радаром, находясь в сложных морских условиях.

Требование - ограничение

<Тип пользователя> не должен попадать под действие <соответствующее законодательство>

Системное требование

<Система> должна <выполняемая функция> не менее чем <количество> <объект> функционируя в <условия эксплуатации>

Пример:
Телекоммуникационная система должна обеспечивать телефонную связь не менее чем с 10 абонентами, функционирую в условиях отсутствия источника внешнего электрического питания

Периодическое требование

<Система> должна <выполняемая функция> <объект> каждые <показатель производительности> <единица измерения>

Пример:
Кофе-машина должна производить горячий напиток каждые 10 секунд

Производительность/возможность

<Система> должна <выполняемая функция> <объект> не менее чем <производительность> раз в <единица измерения>

Производительность/возможность

<Система> должна <выполняемая функция> <объект> типа <характеристика> в течение <производительность> <единица измерения>

Производительность/мощность

<Система> должна <выполняемая функция> не менее чем <количество> <объект>

Производительность/своевременность

<Система> должна <выполняемая функция> <объект> в течение <производительность> <единица измерения> с момента <событие>

Производительность/периодичность

<Система> должна <выполняемая функция> не менее чем <количество> <объект> в течение <производительность> <единица измерения>

Способность к взаимодействию/мощность

<Система> должна <выполняемая функция> <объект> состоящий из не менее чем <производительность> <единица измерения> c <внешняя сущность>

Устойчивость/периодичность

<Система> должна <выполняемая функция> <объект> с <производительность> <единица измерения> каждые <производительность> <единица измерения>

Окружение/работоспособность

<Система> должна <выполняемая функция> <объект> функционируя в <условия эксплуатации>

Детализация требований

Пример:
Телекоммуникационная система должна поддерживать телефонную связь не менее чем с 10 абонентами (выделен показатель производительности) функционируя в условиях отсутствия внешнего источника электроэнергии (выделено ограничение)

Альтернативное представление детализации требований

Пример:
Функционируя в условиях отсутствия внешнего источника электроэнергии коммуникационная система должна поддерживать телефонную связь не менее чем с 10 абонентами
телекоммуникационная система должна поддерживать радиосвязь не менее чем с 15 водителями скорой помощи



Какие бывают требования?

Требования к ПО состоят из трех уровней — бизнес-требования, требования пользователей и функциональные требования. Вдобавок каждая система имеет свои нефункциональные требования.

Бизнес-требования (business requirements) содержат высокоуровневые цели организации или заказчиков системы. Как правило, их высказывают те, кто финансируют проект, покупатели системы, менеджер реальных пользователей, отдел маркетинга. В этом документе объясняется, почему организации нужна такая система, то есть описаны цели, которые организация намерена достичь с ее помощью. Принято записывать бизнес-требования в форме документа об образе и границах проекта, который еще иногда называют уставом проекта (project charter) или документом рыночных требований (market requirements document). Определение границ проекта представляет собой первый этап управление общими проблемами увеличения объема работ.

Требования пользователей (user requirements) описывают цели и задачи, которые пользователям даст система. К отличным способам представления этого вида требований относятся варианты использования, сценарии и таблицы «событие — отклик». Таким образом, в этом документе указано, что клиенты смогут делать с помощью системы.

Функциональные требования (functional requirements) определяют функциональность ПО, которую разработчики должны построить, чтобы пользователи смогли выполнить свои задачи в рамках бизнес-требований. Иногда они называются требованиями поведения (behavioral requirements), они содержат положения с традиционным «должен» или «должна»: «Система должна по электронной почте отправлять пользователю подтверждение о заказе».
Функциональные требования документируются в спецификации требований к ПО (software requirements specification, SRS), где описывается так полно, как необходимо, ожидаемое поведение системы.

Системные требования (system requirements) - это высокоуровневые требования к продукту, которые содержат многие подсистемы. Говоря о системе, мы подразумеваем программное обеспечение или подсистемы ПО и оборудования. Люди — часть системы, поэтому определенные функции системы могут распространяться и на людей.

Бизнес-правила (business rules) включают корпоративные политики, правительственные постановления, промышленные стандарты и вычислительные алгоритмы. Бизнес-правила не являются требованиями к ПО, потому что они находятся снаружи границ любой системы ПО. Однако они часто налагают ограничения, определяя, кто может выполнять конкретные ВИ, или диктовать, какими функциями должна обладать система, подчиняющаяся соответствующим правилам. Иногда бизнес-правила становятся источником атрибутов качества, которые реализуются в функциональности. Следовательно, можно отследить происхождение конкретных функциональных требований вплоть до соответствующих им бизнес-правил.

Нефункциональные требования описывают цели и атрибуты качества. Атрибуты качества (quality attributes) представляют собой дополнительное описание функций продукта, выраженное через описание его характеристик, важных для пользователей или разработчиков. К таким характеристикам относятся:
* легкость и простота использования
* легкость перемещения
* целостность
* эффективность и устойчивость к сбоям
* внешние взаимодействия между системой и внешним миром
* ограничения дизайна и реализации. Ограничения (constraints) касаются выбора возможности разработки внешнего вида и структуры продукта

Характеристика продукта (feature) — это набор логически связанных функциональных требований, которые обеспечивают возможности пользователя и удовлетворяют бизнес-цели. В области коммерческого ПО характеристика представляет собой узнаваемую всеми заинтересованными лицами группу требований, которые важны при принятии решения о покупке — элемент маркированного списка в описании продукта.


Характеристики правильных спецификации требований:
* полнота
* корректность
* осуществимость
* необходимость
* однозначность
* согласованность с другими (в том числе высокоуравневыми)
* модифицируемость (переработки требований, если понадобится с поддержкой истории изменений и информации об авторе)
* трассируемость - возможность переработать требования в другие элементы UML. Например в usecase или элемент дизайн-модели (очевидно, справедливо не для всех видов требований)
* проверяемость
* приоритетность (по другому: у хорошего требования есть приоритет)

Требования не должны касаться деталей дизайна или реализации (кроме требований к дизайну и реализации :) ).


Итог: с требованиями мне все ясно. Будем искать программный продукт, способный удовлетворить:
<Программный продукт> должен уметь <принимать требования> от <пользователей>, предоставлять их в <удобном для разработчика виде>, давать возможность <следить за реакцией> <разработчиков>.


Данный материал "скопипастен" и переработан с http://www.uml2.ru/ и http://www.intuit.ru/ не корысти ради, а для более удобного понимания предмета в рамках поставленной задачи.

Линкотека: отличная находка

UML Jokes

До смешного простая методика построения юз-кейс диаграмм

Методика приведена в книге Java 2. Руководство разработчика Майкла Моргана.

Автор предлагает не заморачиваться на всяких-там правилах выделения экторов, выделениях прецедентов и прочей фигне... :) Что в замен? Нужно просто взять текст описывающий предметную область, выделить в нем существительные и глаголы. Указать к каким существительным относятся глаголы.
Существительные - потенциальные экторы.
Глаголы - варианты использования или связи между вариантами использования и экторами.

Уверен. что это работает не везде, но для моей задачи (к которой у меня 2 прекрасно написанных документа) подходит идеально.