Проект vbsx. Наброски архитектуры.

Постановка задачи

Ниже будет рассмотрена вольная интерпретация архитектуры MVC (Модель-вид-контроллер), применительно к скрипту блога. Сам блог ещё не существует, а его создание предполагается начать от уровня представления. Здесь описывается конкретный подход к реализации взаимодействия между сервером и собственно страницей (в браузере) с применением технологии Ajax. Будут рассмотрены основные сценарии.

1. Серверная сторона

Скрипт блога может быть реализован на любом языке. На сервер возлагается ряд обязанностей по поддержке двух уровней - модели и контроллера.

1.1 Модель

Модель реализует работу с базой данных, предоставляет элементарные действия по включению, чтению, изменению экземпляров сущностей.
Предметная область включает (для рассматриваемого случая): сообщение (заголовок, тело, другие поля); комментарий (тело). Сообщение имеет некоторое количество комментариев.

1.2 Контроллер

Контроллер рассматривается как диспетчер, принимающий запросы и формирующий ответы. Каждый запрос (за исключением некоторых) трансформируется в отклик, который содержит блок данных. То есть он не формирует всю страницу целиком, а отсылает порциями. Эти порции информации уже на уровне представления распределяются по странице (c использованием JavaScript). Отмечу, что блоки информации, отсылаемые клиенту даются в HTML-нотации, поэтому происходит некоторая подмена понятий. Контроллер, который использовал бы XML-нотацию или JSON был бы полноценным контроллером. А так... В общем выбран путь наименьшего сопротивления, так как проект не ориентируется на архитектурную эволюцию и конечную универсальность.

Кроме того, контроллер формирует два полных представления (это тот самый случай исключения): страницу блога (состоящую из полнотекстовых сообщений) и страницу сообщения (которая, помимо самой записи, включает список комментариев).

2. Уровень представления

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

2.1 Технология Ajax

Ajax именно этим и занимается. Выбор фреймворка не принципиален (я использую prototype). На уровне представления необходимо реализовать ряд операций, которые завязаны на отправке запросов.

2.2 Операции

Создание
Сообщение - createPost()
+ Запрос формы под новое сообщение - getFormForNewPost()
Комментарий - createComment()
Чтение
Список сообщений - getPosts()
Сообщение - getPost(post_id)
Список комментариев - getComments()
Обновление
Сообщение - updatePost(post_id)
+ Запрос формы, содержащей сообщение - getFormForPost(post_id)
Удаление
Сообщение - deletePost(post_id)
Комментарий - deleteComment(comment_id)

2.3 Структура страницы и сфера ответственности методов

Примерная структура страницы для сообщений (стрелкой показано, какая функция заполняет/изменяет блок; буквой "x" обозначается идентификатор сообщения):

← getFormForNewPost()← getPosts(), createPost()← getPost(post_id), deletePost(post_id)← getFormForPost(post_id)← updatePost(post_id)

Фрагмент структуры для комментариев:

← getComments(), createComment()← deleteComment(comment_id)

3. Требования к уровню контроллера

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

// postsvar url_posts_read = ''; // скрипт получения всех постов блогаvar url_post_create = ''; // скрипт создания блока сообщения (+ передача ему атрибутов нового сообщения)var url_post_read = ''; // скрипт получения блока сообщения (требуется идентификатор записи)var url_post_update = ''; // скрипт редактирования сообщения (+ передача изменённых атрибутов сообщения)var url_post_delete = ''; // скрипт удаления сообщения (требуется идентификатор записи)var url_post_form = ''; // скрипт получения формы сообщения (атрибут new=1 создаётся для принятия пустой формы; атрибут pid=x - для заполненной формы)

// commentsvar url_comments_read = ''; // скрипт получения всех комментариев для сообщения (требуется идентификатор записи)var url_comment_create = ''; // скрипт создания нового комментария (+ передача атрибутов комментария)var url_comment_delete = ''; // скрипт удаления комментария (требуется запрос с идентификатором комментария)var url_comment_form = ''; // скрипт получения формы комментария

Сам файл js

Unix way + ООП: постановка вопроса

Unix way гласит: "Write small simple things that do one thing well". Интересна мне не сама постановка, а то, к чему привести может следование этому пути. В компост можно добавить также слова Robert C. Martin'а: "Functions should do one thing. They should do it well. They should do it only."

Сначала об очевидном. Программа, как система - традиционно сложное изваяние, исправлять недостатки которой затруднительно, добавлять новые функции тем паче. Как вариант можно разбить программу на маленькие составляющие, каждая из которых имеет свою сферу ответственности. Встаёт вопрос: "А как осуществлять взаимодействие разрозненных частей?"

Тестирование. В современных методологиях разработки программного обеспечения этот пункт ключевой, даже опорный. Тестировать проще маленькие модули. Причём, особое значение приобретают зависимости между модулями: что если они кольцевые? Такого нужно избегать; даже ценой полной переработки (рефакторинга). Функционально законченные модули - это хорошо. В идеале зависимости должны иметь односторонний характер (если рассматривать всю систему, то структура её приобретёт вид направленного ацикличного графа). Можно даже аналогию провести, например, с простой арифметической последовательностью действий: 1 + (4-6*7) - на самом низком уровне будет расположено умножение; выше - вычитание; наверху - сложение. Если это изобразить на листе бумаги, получится древовидная карта вычисления. Наподобие этой карты будет выглядеть эталонная архитектура программы. Кстати замечу, что "unix way" тут раскроется во всей красе.

Оценка сложности. Оценку модулей (особенно самых мелких вариантов) производить, во-первых, не затруднительно, а во-вторых, актуально - точность будет на уровне. Декомпозиция сложной системы на мелкие - анализ - даст хорошие результаты, ошибки будут минимальные.

Вопрос. Хорошо ли соотносится модульная структура с парадигмой ООП? Пакеты, модули, классы, методы (классов) подходят к "unix way"? Речь не идёт о множестве программ (уже готовых) и их объединении, речь идёт о разработке конкретной программы и подходе к разработке (деление на модули, слои, уровни, модели, контроллеры, etc.).

Sun Cloud Platform: выход в открытое плавание

На днях Sun анонсировала платформу для облачных вычислений. Предлагаются следующие технологии: Java, MySQL, OpenSolaris, Open Storage. Главными и самым будоражащими терминами объявляются так называемые public clouds. Фактически Sun таким подходом перерубает пути движения проприетарщины (в лице, например, Microsoft) и ориентирует на своего рода свободу выбора. Sun Cloud Platform есть подход, реализация уже в конкретной операционной среде ей не затрагивается. Следовательно, разработчики вольны использовать или Linux, или OpenSolaris, или Windows. Проекта open source. Вектор движение направлен в сторону совместимости, открытости разработок. "Ранее писалось":http://twowords.ru/findings/38/sun-cloud, что API опубликован под лицензией Creative Commons license, что подчёркивает гибкость (например, в реализации инновационных технологий и методов), ориентирование на результате.

Анонсированная платформа (её ядро) состоит из двух составляющих: Sub Cloud Storage Service; Sun Cloud Compute Service. Последняя появится летом этого года и будет на практике выглядеть как Virtual Data Center (VDS). VDS - интерфейс, который позволит запуск и управление приложениями в рамках облака и средства администрирования через веб-интерфейс (само приложение может работать под контролем различных операционных систем). Особенностью Sun Cloud Storage Service является гибкость в масштабировании объёмов хранилища (как увеличении, так и уменьшении).

Sun Microsystems Unveils Open Cloud Platform

xmonad + xmobar: заголовки окон

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

...import System.IO.UTF8...main = doxmproc <- spawnPipe "xmobar" -- стартует xmobarxmonad $ defaultConfig{ ...-- вот здесь указывает кодировку выходной последовательности (utf8, которая была ранее объявлена через "import System.IO.UTF8")
, logHook = dynamicLogWithPP $ xmobarPP{ ppOutput = System.IO.UTF8.hPutStrLn xmproc, ppTitle = xmobarColor "green" "" . shorten 50}...}

Файл настройки xmobar (мой) такой:

Config { font = "xft:Consolas-9", bgColor = "black", fgColor = "grey", position = Top, lowerOnStart = True, commands = [
Run Network "ppp0" ["-L","0","-H","32","--normal","green","--high","red"] 10, Run Network "ppp1" ["-L","0","-H","32","--normal","green","--high","red"] 10, Run Cpu ["-L","3","-H","50","--normal","green","--high","red"] 10, Run Memory ["-t","Mem: %"] 10
, Run Swap [] 10
, Run Date "%a %b %_d %Y %H:%M:%S" "date" 10
, Run StdinReader
]
, sepChar = "%"
, alignSep = "}{"
, template = "%StdinReader% }{ %cpu% | %memory% * %swap% | %ppp0% - %ppp1% | %date%"
}

Результат

Java: а стоит оно того?

Навеяно этим.

Что можно почерпнуть из Java? Можно ли рассматривать Java как отправную точку при разработке программного обеспечения любой сложности, любого масштаба?

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

Другими словами, это весьма серьёзная штуковина. Сложная, да. Перспективная, да. Стоит ли на ней остановиться? Нет. Сложность Java породила множество паттернов, пытающихся укротить эту махину. Она заточена под крупные проекты, масштабируемые, распределённые. Реализовывать проекты средней и малой величины уже дело затратное (время), не оправданное какими-то явными преимуществами.

В целом, повторяется принцип бритвы Оккама, только критериями являются время, силы (а, следовательно, и деньги). Разворачивать целую кампанию с применением множества шаблонов проектирования не разумно. Гораздо резоннее использовать другой инструментарий, технологии, языки, которые позволят достигнуть нужного результата быстрее, не занимаясь идолопоклонничеством великому и могучему Sun (аналогично, Microsoft, IBM).

Sun Cloud

В этом году появится проект Sun Cloud. Вернее, всё уже готово: архитектура проработана, уровни взаимодействия реализованы. Что это такое? Во-первых, это сервис хранения данных, который управляется WebDAV. Во-вторых, это сервис предоставления вычислительных мощностей, основанный на технологии Q-layer.

Для управления всем этим паровозом разработано API, включающее два уровня. Нижний уровень основан на HTTP и исповедует философию REST. Главным термином в сетевых сервисах (подхватываемый REST) является ресурс. Ресурс (а это может быть сервер, целая сеть; более общий случай - виртуальный дата центр) представляется в виде JSON. Причём представление иерархическое, древовидное. То есть: целое облако описано JSON верхнего уровня, включающим, например, кластеры. Обращаясь к кластеру по URI, выходят на JSON, который описывает уже серверы. Верхний уровень, с одной стороны, представлен библиотеками, обслуживающими сообщения, поступающие с нижнего уровня (HTTP); они могут быть реализованы на Java, Ruby, Python. С другой стороны, имеется веб-интерфейс, через который управляют конкретным виртуальным дата центром.

Спецификации API опубликованы под лицензией Creative Commons 'Attribution' license. Всё открыто, прозрачно и подаёт надежды на облачное будущее. Так что вопрос решён: сначала интерпрайз, потом уже простые смертные.

SCRUM: характеристика. Часть 2

продолжение части 1.

Планирование спринта

Длительность. Спринт имеет фиксированные временные рамки. Обычно это период от недели до месяца. Что это даёт? Осознание и следование такой модели - последовательность спринтов фиксированной продолжительности - связано с предсказуемостью, а процесс становится ритмичным, детерминированным.

Требования. В списке требований содержаться все проблемы, которые предстоит проработать. Однако в рамках спринта будут рассмотрены лишь некоторые из них, как правило, наиболее ключевые. Поступают здесь следующим образом. Список требований ранжирован: каждый пункт имеет свой приоритет. Отбираются самые приоритетные. Обязательно участие заказчика в этом процессе. Выбранные требования в конечном счёте определят функциональность ближайшего релиза. Таким образом создаётся ориентир, очень прозрачный для всех участников проекта.

Время. На данном этапе (рассмотрение итерации) сложность возможностей и требований рассматривается с позиции времени. С одной стороны, команда располагает временным резервом - бюджетом - который включает часы каждого члена коллектива. Например, трудовой день программиста может составлять 6 часов. Суммируя часы, оценивают возможности команды. С другой стороны, происходит работа с требованиями: они разбиваются на задачи. Причём, чем меньше они по сложности (проще), тем точнее можно оценить количество времени, которое потребуется затратить на их решение. После того, как все текущие задачи оценены, время на разработку рассчитано, происходит их сопоставление. Если разногласий между требованиями и возможностями нет, то переходят к непосредственной реализации спринта. В обратном случае необходима повторная работа с заказчиком: корректирование задач (включение новых или исключение лишних).

Спринт

План составлен, задачи определены. Главное - следовать намеченному и исключить деструктивное влияние на процесс. Это касается заказчика в первую очередь. Внезапные изменения требований не влияют на текущую итерацию, а учитываются на следующих.

Команда. Команда обладает свободой, она не подчинена конкретному человеку. Весь коллектив проходит путь проектирования, тестирования и разработки. Получается тот самый вожделенный, но ограниченный коммунизм, стеснённый рамками помещения.

Тестирование здесь на ведущем месте (TDD). Оно всегда интегрировано в процесс, подчас определяет его.

Типичный день

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

Прогресс. Оценить прогресс, даже тот, который связан с решением конкретной задачи (сложность задач такова, что время на решение не превышает одного рабочего дня), помогают специальные диаграммы. Эти визуальные средства показывают находится ли проект в рамках допустимых границ: всё идёт согласно плану или же происходит опережение/отставание. В случае отставания переключаются на наиболее приоритетные задачи и корректируют план следующей итераций. Несоответствие процесса плану показывает лишь одно: команда "не вошла в ритм", переоценила свои возможности. Спустя пару итераций команда достигнет установившегося состояния, будет способна оценивать и задачи, и свои шансы на успех достоверно.

Итоги спринта

В конце каждого спринта демонстрируется проект со всеми достижениями и неудачами. Это встреча заказчика и команды, на которой последняя может продемонстрировать результаты своей работы, доложить о проблемах, с которыми она столкнулась. Что это даёт? Во-первых, это психологический deadline, по-другому - стимул (для команды, разумеется). Во-вторых, происходит конструктивный диалог между представителями бизнеса и исполнителями. В результате этого диалога проясняются новые моменты, достигается (иногда) взаимопонимание. Обратная связь здесь неоценима: заказчик контролирует ход работы и, в конечном счёте, получает то, что ему нужно. В-третьих, для разработчиков важно отметить (повторить) для себя ошибки и ответить на вопросы: "Всё ли продвигалось согласно плану?", "Правильно ли оценена сложность задач?". А ответив на них, скоординировать свои дальнейшие действия.

Масштабирование Scrum

В случаях распределённых команд, работающих над одним проектом предлагают следующие положения:

• лидер (ScrumMaster) не управляет в прямом смысле, он направляет;
• каждая команда разработчиков автономна за исключением случаев, когда затрагиваются вопросы, касающиеся других команд или организацию в целом;
• каждая команда разработчиков занимается тем, что делает своё итерационное дело и передаёт результат заказчику.

Что в сумме?

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

SCRUM: характеристика. Часть 1

Цели

Рассмотреть пожалуй самого яркого представителя из мира Agile - методологию Scrum. Описать типичный процесс работы в условиях этого подхода. Выделить достоинства и недостатки.

Предисловие

Это уже вторая заметка на тему Agile, конкретизированная в реальном приложении. Первая - Extreme Programming - инженерного плана методология, более конкретная и близкая к насущным вопросам, таким как тестирование, парное программирования.
Scrum, в отличие от Extreme Programming предлагает подход не к разработке программного обеспечения, а более акцентирует внимание на управлении этим процессом. И с точки зрения управления (менеджмента) для реализации всех принципов (о них далее) необходимо наличие, во-первых, заказчика (или его представителя), который отдаст проекту своё время и мысли (выражающие желаемый результат, требования), а во-вторых, команды первоклассных специалистов по части проектирования и реализации кода.

Термины

Scrum - методология управления разработкой ПО, включающая множество моделей (о которых ниже) и ролей (ScrumMaster, Product Owner, Team).
ScrumMaster - руководитель, направляет команду по пути Scrum.
Product Owner - заказчик, клиент.
Team - команда разработчиков.
Backlog - список требований.
Sprint - фиксированная итерация, термин сугубо Scum'овский; далее по тексту "спринт".

Порядок изложения

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

Общие положения

Как было отмечено выше, для нормального Scrum понадобятся: заказчик и команда. Заказчик вовлечён в процесс разработки, это одна из ключевых претензий. Команда состоит из профессионалов, видавших виды людей. Члены коллектива равноправны, то есть не выделяется определённого механизма подчинения: каждый участник имеет право голоса и его голос может стать ключевым. Основное свойство команды: взаимодействие. Только посредством общих усилий достигаются все поставленные цели. Главный инструмент в их руках - коммуникации, общение, прямой разговор (друг с другом, с заказчиком).

Другим моментом является планирование, которое не пытается предвосхитить все детали и проработать все ответы на возникающие (а что там будет?) трудности. По факту планирование занимается разрешением текущих задач и знаменует собой лишь направление движения. Оно и понятно: изменяющиеся условия делают невозможным (или в крайнем случае затруднительным) учёт всех факторов, хотя сам учёт (в традиционной модели) отнимает очень много времени, производя документацию.

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

Следствия. Команда и её численность такова, чтобы гармонично кооперировать. Очевидно, большими такие команды быть не могут. А значит, это накладывает ограничение на величину проекта. Для крупных проектов применяется модель распределённых (по всему миру) команд. Как согласовывать их действия? Это проблемное положение, но выходы находятся (об этом в части 2).

Список требований

Список требования (backlog) может быть пополнен каждым членом команды. Но приоритеты расставляет только заказчик. В результате получается список, наверху которого расположены наиболее важные требования (которые звучат по типу "Я как (роль пользователя) имею возможность (действие) для достижения (результат)"). Каждый пункт составляется только с позиции бизнеса: наиболее приближенным к клиенту и исключающим техническую сторону. Делается это для большей наглядности с целью исключения непонимания со стороны заказчика. Будучи составленными (а на деле они всегда эволюционируют) требования должны быть всегда "под рукой", доступны для команды (вспоминаем доску на стене).

Оценка сложности требований

Оценка требований производится на верхнем уровне. До конца глубина задачи не ясна, поэтому это оптимальный вариант. По каждому пункту из списка требований команда делает вывод о том, насколько сложной является реализация. Вывод, как не сложно догадаться, основан на опыте разработчиков. Более того, ценным является индивидуальный подход, то есть требование не обсуждается совместно, а каждый член коллектива даёт свою оценку. Далее оценки усредняются здравым смыслом. Как показывает практика, вариант действенен. Теперь о системе баллов. Оценка производится исключительно с использованием своей системы (численной). Что это будет за система, не имеет особого значения. Основной смыл - выразить относительную сложность. Временные оценки исключены (никаких человеко-часов). Участие заказчика в этом процессе ни к чему, он не имеет представления о системе координат команды, а вводить его в курс дела затратное по времени и нервам занятие.

продолжение в части 2.

47% американцев не в курсе, что Земля вращается вокруг Солнца

Совсем трудные времена настали для штатов, хоть плачь. Ну о том, что там стали совсем непросвещёнными (а зачем, когда жизнь малина?), известно давно (из ящика пропихивали, да и на генном уровне чётко пропечатано :)). Больший интерес вызвали рассуждения "осведомлённой" части, светочей ихней науки, о там, как жить и что делать. Навзрыд встречены повсеместная глупость, запущенность образования, декаданс. Но, конечно, в дискуссию вступила и та часть аудитории, которая вхожа в 47%-ный резерв. Для них, например, всё хорошо и объясняется по типу "зачем учить, если всего познать нельзя". Зачем тебе жить, баран, если сдохнешь в конце? Между делом началась игра у кого длиннее на вопрос "А скока процентов площади планеты покрыто водой?", хорошо, что до тысячных не дошли. Находятся даже идеалисты, которые убеждены, что дети _по определению_ стремятся к знаниям, мол это биологическая привязанность. Ну да, кругом там академики. Промелькнуло интересное выражение "silly cow" (тупая корова), но бы запомнить.
В общем, советую почитать, сбросить излишки нервной энергии :), хороший тренажёр.

Extreme programming: характеристика

Цели

Раскрыть сущность Extreme programming (XP), выделить основные компоненты модели, коротко их охарактеризовать.

Предисловие

Ранее рассматривалась концепция Agile для разработки программного обеспечения. Это отправная точка для конкретных методик, в число которых входит и XP. Agile очень ёмкое понятие, больше философия, ряд предписаний и тезисов. Последнее время она стала очень актуальной, объясняется это тем, что традиционный способ разработки ПО сталкивается с препятствиями, неудачами, причина которых заложена в самой модели. Как раз здесь Agile (и XP в частности) предлагает пути преодоления трудностей путём тесного взаимодействия с заказчиком, командной работы, фокусировании на достижении требований, а не написания документации (корень зла традиционной модели).

Термины

Термин (и методологию) Extreme Programming ввели в обиход Kent Beck и Ward Cunningham в 90-е годы двадцатого столетия, в дальнейшем корректировали основные положения.

Порядок изложения

Ниже будут рассмотрены, во-первых, заимствования из Agile, во-вторых, основные черты планирования, релизов, подготовки прецедентов, характер программирования, коллективная работа, тестирование.

XP is an Agile Methodology (Agile is not XP)

XP исповедует Agile. Это значит, что процесс разработки эволюционный. С одной стороны, наращивание функциональности от релиза к релизу. С другой, гибкость по отношению к требованиям и их изменениям; подстраивание под реалии среды. Административная составляющая упрощается ввиду несостоятельности и ненужности. Фактически команда саморегулируемая, участники уравнены в правах.

Планирование и релизы

Планирование не фокусирует внимание на деталях, не пытается учесть всё. Напротив, акценты расставлены на приоритетных задачах, периоды планирования короткие, документации минимум. Релизы продукта происходят часто и сопровождаются внедрением в среду заказчика (для обратной связи). От релиза к релизу функциональность наращивается, и в конце клиент получает полностью соответствующий его требованиям продукт.

Система прецедентов

Прецеденты (или сценарии) составляются совместно с заказчиком, расставляются приоритеты. Отмечу, что когда стоит вопрос о проработке определённой функции, которая нужна для следующего релиза (не для текущего), руководствуются фразой YAGNI - "You Aren’t Going to Need It" ("вам это не нужно"). На деле это значит, что не стоит работать над тем, что может поменяться, и в последствии потребует полностью переписать код.

(Собственно) программирование

XP предлагает использовать подход Pair Programming (два человека за компьютером). Здесь ключевую роль играет кооперация между коллегами, которые общими усилиями достигают значительных (по факту и времени) результатов.

Тестирование

Очень большое внимание уделяется тестированию. Оно всегда продолжительное, интегрированное в процесс разработки. Тесты пишут до написания кода приложения. Это называют Test-driven Development. Порядок следующий: написать тесты, написать код, проверить код тестами, в случае ошибок исправить код и повторить тестирование. Достоинства: тесты пишутся; у программистов возникает чувство удовлетворения (преодоление теста - вызов, процесс преодоления - fun); становятся ясны детали программного продукта; имеется возможность автоматизации этого процесса.

Коллектив

Команда разработчиков - единый организм. Здесь нет уединённых участников. Члены коллектива имеют равные права по вкладу в результат и это делает их сплочёнными. Однако команда немногочисленна (иначе начинаются трудности и деление на группы) и требует привлечения профессионалов.

Что в сумме?

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

***

Кроме XP к Agile относятся Scrum, Crystal, RUP. Они будут рассмотрены позже.

СГТУ, конференция "Teaching English Professionally and CommunicationCompetently". 10 марта

Сего дня посетил конференцию, главным образом адресованную преподавателям английского языка - школ и вузов. За день прошло пять выступлений: два до кофе-брейка, три - после. Наиболее яркой считаю первую часть: интересно и, главное, по делу. После перерыва понесли околесицу. Но по порядку.

Первым выступал Wayne Rimmer с докладом на тему "Changes in Contemporary English Grammar". Познавательно о тенденциях последнего времени эволюции английского языка. Например, отмечено, что увеличилось употребление таких оборотов как need to (123%), want to (70%), going to (50%), used to (45%). В Великобритании (а докладчик родом от туда) почти вымерло слово shall, указующее на будущее время. В штатах так вообще давно не употребляется, а вот в старой доброй бывает, но исключительно в таких словосочетаниях, которые гуляют между друзьями, подругами по типу "А не пойти ли нам на звёзды поглядеть?". Так что можно смело вычёркивать это слово из постоянного обращения, но вписать в графу интимных фраз. Другие изменения коснулись глагола be (теперь его употребляют в меньшей степени, -20%), ему за замену пришёл get (+60% в частоте использования). Докладчик заметил, что get пользуют для передачи сенсационного сообщения, например, криминального толка, преступления.
В обыденной речи возросла роль оборота to have a ..., обозначающего общее событие (позавтракал, принял душ).
Возросла роль слов which и that, раскрывающих характеристики объекта. Принадлежность сущности чему(кому)-либо обозначают добавкой 's. Другой возможностью является использование предлога of. Так вот: последний вариант употребляется реже, чем первый, оно и понятно, так как проще.
Нельзя не отметить употребление слова like (его часто используют), которое эквивалентно as.

Это что касается первого доклада. Второй озвучивала Людмила Кожевникова (Cambridge University Press), тема звучала как "Alternative Assessment", а суть состояла в ответах на вопросы "Каким образом оценивать знания?", "Какова роль учителя?", "Какой подход необходим к ученику?". В целом неплохо, предлагается индивидуальная работа (на первом этапе) с обучающимися: выделение сильных сторон, уровней восприятия информации, деление по результатам на родственные по ряду признаков группы. Тестовая система отвергается, предлагается введение портфолио и уже на его основе судить о знаниях. Что понравилось: начинают об этом задумываться, какие-то попытки совершаются (предлагаются взвешенные варианты). Что не понравилось: подстраивание под реалии, поверхностно копают. Обсуждаемый вопрос - обучение иностранному (в данном случае - английскому) языку. Как недостаток отмечено длительное время ученичества, так прорабатываются все уровни восприятия (визуальный, аудиальный, чувственный), но и результат ожидается лучший.

После перерыва 50 минут тратил David Fay с темой "Testing English as an International Language", на мой взгляд совершенно напрасно. Основная мысль: существует множество разновидностей (диалектов) английского языка (индийский английский, афро-американский и проч.); позиция - принять эти разновидности, иметь их в виду и использовать, когда нужно. Высосано из пальца, моё мнение.

Дальше был Eric Sandeen, американский ирландец. Рассказывал в картинках сначала про Нью-Йорк, затем про штаты. Пускал в зал разговоры американизировавшихся китайцев, африканцев. Собравшиеся насладились ирландской песней невидимой девушки, видами направлений миграции иноземцев в глубь США. Интересно? Быть может...

Заканчивал снова Wayne Rimmer. Говорил об ошибках, которые преследуют наших (российских) студентов в терниях английского языка. Спешил, так как время подходило. Зал устал, а кто-то даже спал. Завтра продолжение.

Мастерство программирования

Кооперативы программистов? Да пожалуйста. Цель: взять новичка, обучить его, вырастить мастера, посвящённого во все тонкости разработки. Конвейер по производству спецов. Неплохо. Такие цели преследует, например, 8th light. Основные моменты, ею предлагаемые изложены в манифесте, который подписали около 600 человек из разных уголков цивилизованного мира. Вообще многое перекликается c agile, конкретно следующее: нацеленность на тесный контакт с заказчиком, внутрикомандное взаимодействие, возможность быстрого реагирование на изменение требований.

Компания занимается ученичеством, да таким плотным, что держись крепче. Вырабатывают единый стиль программирования, единый стиль думания, единый взгляд на будущее программного обеспечения. Кузница работает денно и нощно, в массовом порядке плодя мастеров своего дела. По истине завораживающе звучит фраза "We build software that we are proud to have built and that our clients are proud to have." Сразу ясно, светлые головы занимаются тем, делают своё дело верно, охотно и столь же охотно гордятся своими успехами. Молодцы!

Maestro: очередное извращение Microsoft

Судя по описанному, Maestro не есть очередной объектно-ориентированный язык. Это - фокус, который даёт возможность меньше думать о параллельных вычислениях (вспоминаем сразу облачный рай; плюс ко всему у Microsoft есть проект Azure), оставаясь приверженцем объектно-ориентированному подходу. Взаимодействие компонентов происходит с помощью сообщений, а компоненты сами изолированы друг от друга. С тексте промелькнуло сравнение с Erlang'ом. Позиция Microsoft ясна, она идёт на поводу большинства. Нужен инструментарий для параллельных вычислений - сделают; программистам не надо переучиваться: как знали ООП, так и будут. А что предлагает функциональная парадигма? А она по определению параллельная, каждая функция изолированная. Считай-не-хочу. Но Microsoft, конечно, виднее.

Книги: новые издания в области программирования.

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

Интерпретируемые языки программирования. Уровень удовлетворения.

Интересные результаты соревнования интерпретируемых языков программирования приведены на просторах интернета.
Рассматриваются следующие:

• Actionscript
• Flex
• Javascript
• Microsoft F#
• Microsoft Powershell
• Perl
• PHP
• Python
• Ruby
• VB Script

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

На первом месте расположился PHP. Его сильными сторонами оказались беспроблемное внедрение и платформонезависимость, доступность и качество средств разработки и быстродействие.

Замечу, однако, что один язык выделяется из общего строя - F#. По сути функциональный, по родословной - наследник OCaml (а первопричина и того - Lisp). Оказался он на восьмом месте (третьем с конца). Однако...

Технические несовершенства = загубленные нервы и деньги

Кто постигает новое, лелея старое, Тот может быть учителем.

Конфуций

По мотивам.

Начинающие команды разработчиков. Как оно случается.

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

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

PHP: компоненты и инструкции к действию

Вот тут приводятся инструменты полезные разработчикам сайтов, регулярно сталкивающимся с задачами совершенствования дизайна и эффектов юзабилити.
Что тут есть:
Главным образом представлены инструкции, компоненты (исключительно бесплатные) ориентированные на визуальную часть. Рассматриваются темы: построение дерева директорий (с привлечением также Ajax), метод нумерации страниц, построение диаграмм. Кроме того, такие мелочи как визуализация форм, проверка на валидность ввода данных (с участием как PHP, так и JS), скрипты ресайза и нарезки изображений и их вывода. Есть даже тьюториал для создания собственной CMS. Большинство инструкций сопровождается демонстрацией результата - можно пощупать предварительно и сделать вывод "а надо ли".

Scheme: функциональный рай

1. Функциональное прошлое и будущее

Выдержки из учебного пособия:

bq. На функциональном языке программист не должен описывать порядок вычислений. Нужно просто описать желаемый результат как систему функций.
В чистом функциональном программировании оператор присваивания отсутствует, объекты нельзя изменять и уничтожать, можно только создавать новые путём разбора и сбора существующих.
Каковы же преимущества чистых функциональных языков? Помимо упрощения анализа программ есть ещё одно — параллелизм. Раз все функции для вычислений используют только свои параметры, мы можем вычислять независимые функции в произвольном порядке или параллельно, на результат вычислений это не повлияет. Причём параллелизм этот может быть организован не только на уровне компилятора языка, но и на уровне архитектуры.

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

1.1 Происхождение

Lisp как первый функциональный язык придуман давно, диалектов создано тоже предостаточно. Императивные языки, в основной массе которые объектно ориентированные, начинаю разрастаться лямбда расширениями. Что это даёт: мешанину мух и котлет, вопросы по типу "А чем пользоваться?", разрываться. Переходный момент? Возможно. Что останется? Если будущее за параллельными вычислениями - функциональные, а потом и другие, более совершенные, более абстрактны, человеко-ориентированные. Если провести параллель с искусственным интеллектом - самое то: распределённая сеть функциональных узлов, завязанная на знании, опыте.

1.2 Концепция

Центральным понятием является функция, она же атрибут, она же цель вычисления. Пример ниже, я думаю, раскрывает логику.

2. Совмещение

2.1 Java

Что есть здесь? А здесь пожалуйста: тот же scheme в ре-инкарнации kawa: (пишите на scheme, компилируете в байт-код, исполняемый на виртуальной машине java; плюс ко всему доступ к бесчисленным библиотекам).
Нашёлся ещё один язык для jvm - Clojure. Подробное введение описано здесь. Ну и scala не будь дурой также для jvm.

2.2 CSharp

В .net 3.0 появились безымянные функции, придумали даже F#. Тенденция, однако.

2.3 Others

Насколько я помню, собираются лямбда расширение прикрутить и к PHP. Ну что ж, весьма. Ребята не отстают.

3. Web

Для web-сервисов применение функциональных языков более, чем оправданно. Наткнулся на пример выполнения скрипта на scheme. Интересно дико. А главное - прозрачно и открывает глаза на то, как доступно и понятно можно описать. Однозначно - не зря мигрируют на эту парадигму. Если кого заинтересовало, то вот проект PLT-Scheme в состав которого входят IDE, JIT, web server, библиотеки и документация. Кросс-платформенный. Кроме того, имеются хорошее пособие по scheme и книга рецептов.

3.1 CGI

Запускать веб-приложения можно как fastCGI, или же "нативно" - посредством PLT-Scheme.

4. ПО

Scheme как самостоятельный продукт - используем DrScheme, входящий в PLT-Scheme.
Ниже окно программы: лаконичное, минимальный функционал. Пример такой: нужно добавить к слову заданную последовательность символов дважды. В данном случае - к "hello" дважды восклицательный знак. Сверху функции, снизу исполнение.

Облака не за горами, они уже стелятся по земле

Возвращаемся к истокам: зачем тебе реляционная база данных, когда лучше объектная: и семантически верно и управлять легко? Зачем тебе дома компьютер, платить за его обслуживание, нести накладные расходы, когда можно арендовать у дяди за "символическую денужку" и радоваться "Ах, как хорошо-то!". Вот и родятся такие проекты как LightCloud. Во-первых опенсурс, что уже радует, во-вторых, по уверениям - быстродействие на уровне memcached. Распределённая объектная база - вот что это.
Из возможностей / особенностей:

• лёгкое масштабирование, заключающееся в добавлении очередного узла в базу;
• расширение функциональности посредством языка Lua, скорость исполнения соотносимая с C;
• написана на python, но в силу простоты может быть портирована на другие языки.

Html, css: делаем, смотрим результат

Нашёл сегодня сервис http://htmlplayground.com/, который служит для создания набросков, размеченных html и css. Весьма удобный интерфейс: страница поделена на четыре части (теги, их описание, атрибуты, собственно код и его отображение). Не очень понравилось, что результат набранного выводится в ограниченном пространстве, грандиозного не накидаешь. А так весьма полезно, особенно когда нет под рукой стационарного средства работы со стилями. Короче, если надо что-то поправить, а из доступного только интернет, то непременно штука полезная.

JDK7: горсть изменений

В Java DevKit 7 появятся некоторые улучшения, призванные скрасить жизнь программиста. Мелочь как говорится, а приятно.

1. Блок исключений приобретёт более логичный и лаконичный вид:

try (BufferedReader br = new BufferedReader(new FileReader(path)) {
return br.readLine();
}

вместо

BufferedReader br = new BufferedReader(new FileReader(path));
try {
return br.readLine();
} finally {
br.close();
}

2. Самое интересное, по моему мнению, введение блоковой структуры наподобие следующего:

double pi2 = (double pi = Math.PI ; pi*pi)**;

3. Проще стало с generics: по всей видимости, чтоб не править долго и во многих местах.


Map<String, List<String>> anagrams = new HashMap<String, List<String>>();

примет вид


Map<String, List<String>> anagrams = new HashMap<>();

Источник