Страница:
Разумеется, обе научные группы пока лишь в самом начале пути. Пройдет еще немало времени, прежде чем новые методы станут привычным инструментом биологов. Но эти разработки способны навести долгожданный мост между молекулярной и клеточной биологией, и возможно, что открытия вскоре посыплются как из рога изобилия.
Разработчики новейших методик стараются сблизить два полюса биомикроскопии, разделенные по разрешающей способности пропастью шириной более чем в два порядка: оптическую микроскопию, позволяющую исследовать не только мертвые, но и живые клетки, и электронную микроскопию, изучающую клетки заведомо убитые, но зато с завидной точностью. Граница применимости «прижизненной» микроскопии понятна: с длины волны ниже 400 нм начинается губительный для клеток ультрафиолет.
Что же до электронной микроскопии, то именно благодаря достигаемому ею разрешению в несколько ангстрем удалось составить подробные карты «внутриклеточного ландшафта» и воочию, без домыслов, увидеть строение клеточного ядра, а также митохондрий, рибосом и других клеточных органелл. Но понятно, что на острие электронного пучка, разогнанного в вакууме полем напряженностью в десятки киловольт, живьем ничего не разглядишь. Электронная микроскопия знает лишь один экзотический пример, когда твердейший хитиновый покров членистоногих сканируют без всякой предварительной подготовки. А так - нежную и трепетную живую ткань приходится фиксировать альдегидами и четырехокисью осмия, обезвоживать, заливать полимеризующимися материалами, пропитывать специальными «электронными» красителями и готовить тончайшие срезы «на просвет».
А биология сегодняшнего дня предъявляет все больший спрос на исследование клеток и тканей непосредственно в процессе их жизнедеятельности. Чтобы сохранить «щадящий» характер световой микроскопии и при этом повысить разрешающую способность, исследователи идут на компромисс - скажем, в обмен на вожделенную точность смиряются с необходимостью многократных повторных измерений. Компромисс, однако, всегда штука непростая. Обратим внимание: схема, при которой процесс получения одной-единственной сверхточной картинки растягивается на минуты и даже часы, может безотказно работать только на неподвижном объекте, отдельные части которого не расползутся в разные стороны прямо по ходу «сложносочиненного» замера. Собственно, все сенсационные результаты новейших методик высокого разрешения и были получены на специально фиксированных объектах. Но ведь поставленная сверхзадача - исследование функционирующей клетки со всеми ее внутриклеточными транспортными потоками, сократительными белками и т. п. И мы не можем, подобно пляжному фотографу, скомандовать ей «замрите, снимаю».
Судя по оптимистичному тону профессора Сяовэя Чжуана (Xiaowei Zhuang), уверенного в возможности ускорения процедуры STORM-микроскопии вплоть до исследования живых клеток с молекулярным разрешением в реальном масштабе времени, разработчики надеются преодолеть это концептуальное противоречие. Но, может быть, ближе к истине профессор Дженнифер Липпинкотт-Шварц (Jennifer Lippincott-Schwartz), видящая будущее новых методик в их сочетании с электронной микроскопией: «Соотнося результаты PALM-микроскопии с электронномикроскопической картиной, можно понять, как отдельные активные молекулы распределены по тонким субклеточным структурам».
МЫСЛИ: Жизнь технического задания
Автор: Олег Бунин
Этой статьей я не хочу доказать, что написание технического задания - зло и корень всех бед, нет, ни в коем случае. Все и всегда относительно, а в нашем случае - зависит от задачи. Я хочу показать, что классические схемы разработки программного обеспечения работают не всегда, не всегда эффективны, часто приводят к ненужным конфликтам между менеджерами и исполнителями. Особенно это касается разработки веб-приложений. Я расскажу об экстремальном программировании, но не так, как пишут в книжках, а исходя из реалий - из того, что попробовали команды под моим руководством. О тех методиках, которые работают.
Когда я слышу о техническом задании на разработку веб-сайта, я внутренне улыбаюсь - еще один продукт, устаревший уже в момент выхода. Это первая проблема всех технических заданий - предположение, что внешняя среда не меняется.
Вторая проблема хорошо известна и отражена в древней мудрости: чтобы задать правильный вопрос, надо знать половину ответа. В ситуации, когда каждый новый сайт вы разрабатываете с использованием только что появившихся технологий (новые модули, новая версия собственного движка, новая версия базы данных), - фактически вы каждый раз многое делаете заново. Это значительно осложняет процесс разработки, потому что вы не знаете, как будете это разрабатывать.
Третья проблема классическая - заказчик не всегда точно знает, чего он хочет. И когда подходит срок сдачи проекта, вы слышите, что вот здесь хорошо бы подправить, вот здесь изменить, а вот здесь добавить. Частично эту проблему решает моделирование конечного продукта, но, повторюсь, лишь частично.
Выпуск конкурентами нового продукта, появление нового брэнда, новой технологии, нового браузера, изменение предпочтений потребителей - все это требует немедленной реакции, изменяет предметную область, описанную в ТЗ. Заказчик увидел сайт конкурирующей компании и хочет такую же «штуку». При этом вы не знаете заранее, как будете реагировать и сколько времени потребует реализация той или иной вашей реакции. Одним словом - хаос…
Ниже я опишу простейшие методы, которые позволят компании постепенно уйти от классической каскадной модели цикла разработки программного обеспечения. Каскадную модель вкратце можно описать так: сначала мы просим пользователей или заказчика сформулировать свои требования, затем разрабатываем проект системы, составляем техническое задание. Затем пишем код, тестируем его. Увы… Эта модель не годится для большинства проектов по разработке веб-приложений.
Что же делать? Ответ прост: принять окружающую действительность, принять изменчивый мир, принять хаос. Стать гибким и разрабатывать свою стратегию с учетом того, что нас окружает хаос. Это нормально. И убедиться при этом, что уже существуют инструменты, позволяющие успешно действовать в условиях хаоса. Например, инструменты экстремального программирования. Все они создавались исходя из того, что окружающая среда гибко и динамично меняется, и не пытаются зафиксировать ее, а наоборот - приспосабливают производственные процессы под подобную среду.
Итак, мы приняли концепцию изменчивого мира. Что это меняет? Сразу становится ясно, что писать подробнейшее техническое задание не имеет смысла - оно стремительно устаревает. Ограничимся описанием функций, причем так, как их видит пользователь системы. Как правило, заказчик достаточно хорошо их представляет.
На основе такого описания команде разработчиков, дизайнеров, верстальщиков становятся ясны их ближайшие шаги. Основные архитектурные решения, общие рамки будущего сайта, общее устройство. Но я подчеркиваю - ближайшие шаги. Достаточно одного-двух. Шаги должны быть небольшие (неделя, несколько дней). После каждого шага - пересмотр всех условий, учет всех изменений. В экстремальном программировании такие шаги называют итерациями.
Итак, если мы на каком-то этапе работы пошли по неверному пути, мы очень быстро это поймем - одна-две итерации, и ошибка будет исправлена.
И все же нам нужно чем-то заменить отсутствие формального технического задания, - ведь мы должны сделать то, что требуется заказчику. Выход - тесное общение с представителем заказчика и пользователями на всех этапах работ (не только в точках проверки, не только в начале и конце работ, а в течение всего времени работы над проектом).
Постоянное сотрудничество с заказчиком, когда его представители присутствуют на планерках, видят все процессы «изнутри», позволяет не делать лишних предположений и, соответственно, не писать лишнего кода. Те, кто имеет отношение к разработке ПО, хорошо знают, как часто даже на начальном этапе возникают вопросы к заказчику. Если эти вопросы будут немедленно разрешаться, мы получим значительную экономию ресурсов.
Еще один прием, который позволит частично компенсировать отсутствие подробного технического задания, - частые релизы. Покажите заказчикам вашу работу как можно раньше.
Отсюда, кстати, известное выражение «вечная бета» - веб-сайт выкладывается «в бой», программа становится доступной пользователям как можно раньше. И далее проектная команда корректирует процесс разработки (вплоть до концепции самого проекта) «на лету», наблюдая за реакцией пользователей.
Подобный подход, движение вперед маленькими шагами требует от исполнителей гораздо более высокой ответственности, нежели простое кодирование. Вам потребуются креативные специалисты, способные самостоятельно находить оптимальные решения. В подобном процессе разработчикам не раз приходится переписывать код, поэтому для облегчения их работы в экстремальном программировании есть несколько практик. Я не буду описывать их подробно, это тема отдельной статьи, но упомяну:
• Тестирование до начала разработки.
• Парное программирование.
• Постоянный рефакторинг.
• Простота разработки.
• Коллективное владение кодом.
• Быстрый выпуск версий.
• Постоянная интеграция.
• Стандарты кодирования.
Тестирование до начала разработки предполагает написание тестов, в том числе приемочных, до того как будет написан сам код. Это дает значительные преимущества, особенно в сложных системах, где изменение одного компонента неизбежно влияет на работу других. В таких случаях приемочные тесты жизненно необходимы.
Парное программирование я рекомендую использовать только в случаях, когда вам нужен очень качественный результат. Мой опыт говорит о том, что двое программистов за одним компьютером программируют медленнее, чем двое за двумя, но программный код, который получается в экстремальном варианте, содержит на порядок меньше ошибок.
Постоянный рефакторинг заключается в регулярном пересмотре того, что уже написано, уже разработано. И в постоянном его улучшении.
Простота разработки - из двух вариантов выбирается более простой и быстро реализуемый.
Коллективное владение кодом означает, что все участники проекта свободно читают и знают любой участок программы. Это достигается путем введения стандартов кодирования - некоторых правил написания программного кода, обязательных для всех, что облегчает чтение кода, поскольку он становится однородным в рамках проекта.
Постоянная интеграция - мы пробуем запустить вместе даже недописанные и не до конца отработанные компоненты системы, чтобы как можно раньше увидеть разного рода несовместимости и ошибки в проектировании. Для этих же целей служит быстрый выпуск версий - постоянная корректировка процесса разработки с учетом мнений пользователей и заказчика.
Одно из важных следствий принятия концепции хаотичности окружающего мира - исчезновение конфликтов между менеджерами и исполнителями. Эти, казалось бы, вечные «грабли» хорошо знакомы всем, кто имеет отношение к разработке веб-сайтов. В традиционной (каскадной) модели разработки пик конфликта приходится на самый важный этап - предвыпуск или выпуск проекта. Главная причина - разработчики сделали не совсем то, что хотел менеджер или заказчик.
Как вы понимаете, эта проблема исчезает, если мы априори принимаем, что мнение заказчика может измениться, но и мы сможем своевременно на это отреагировать: ведь наши рабочие процессы построены так, что нам не придется переписывать заново половину программного кода, соответственно, изменение задачи не приведет к психологическому «напрягу» разработчиков.
Специалисты по управлению проектами справедливо заметят, что описываемые мною приемы напоминают спиральную модель жизненного цикла разработки программного обеспечения. Почему же эта модель, несмотря на очевидные достоинства (снижение рисков, повышение качества продукта и степени удовлетворенности заказчиков и разработчиков), не используется повсеместно в разработке ПО и веб-приложений?
Потому, что это сложно. Потому, что требует большей ответственности от всех участников процесса, большей гибкости, большей сознательности и даже храбрости - в экстремальном программировании это качество в почете.
СОФТЕРРА: Высокохудожественный командный интерпретатор
Автор: Илья Шпаньков
Когда разговор заходит о растровых графических редакторах, абсолютное большинство людей в первую очередь вспоминает Adobe Photoshop. Сторонники свободного софта, конечно, не забудут упомянуть и своего фаворита The Gimp, по умолчанию входящего в большинство GNU/Linux-дистрибутивов. Возможно, кто-то вспомнит Paint.NET или еще какой-нибудь «легкий» редактор «для дома, для семьи». Но сегодня мы поговорим не о них.
Все эти популярные средства создания и редактирования графических изображений обладают хорошо развитым интерфейсом и содержат сотни функций, позволяющих создавать настоящие шедевры цифровой живописи. Меж тем наряду со своими известными «коллегами» живет и здравствует еще один своеобразный редактор по имени ImageMagick, который скромно трудится на ниве обработки цифровой растровой графики уже не первый год. Широкой публике этот редактор (а точнее - пакет графических утилит) практически неизвестен в силу особенностей, о которых будет сказано ниже. Однако в некоторых случаях он даст фору любому именитому аналогу.
Прежде всего, ImageMagick является платформнонезависимым: на сайте разработчиков можно найти установочные пакеты для Windows, Linux, Mac OS X, Solaris, FreeBSD и Cygwin. Помимо этого, редактор распространяется под свободной лицензией, совместимой с GPL, благодаря чему доступны все исходные коды, а пользователи практически ничем не ограничены в плане использования программы и ее «подгонки» под свои специфические цели. Но и это еще не все: авторы предлагают более десятка различных вариантов интерфейса ImageMagick, написанных на C, C++, Java, Perl, PHP и других, более экзотических языках. Несмотря на довольно аскетичный внешний вид (остающийся неизменным несколько последних лет), свое дело ImageMagick делает хорошо и к тому же освобождает авторов программы от излишних хлопот по внедрению и отладке новомодных веяний интерфейсостроения, позволяя уделять больше внимания совершенствованию функциональных возможностей. Подобная неприхотливость редактора способствует полноценному выполнению своих функций в любом программном окружении, а также открывает большой простор для интеграции с другими приложениями. Особенно рады этому разработчики свободного ПО: библиотеки ImageMagick входят в состав многих GNU/ Linux-дистрибутивов и часто используются различными программами, обладающими функциями просмотра или редактирования изображений. Наличие же в системе одного из вариантов интерфейса позволяет работать с ImageMagick как с обычным графическим редактором (рис. 1).
Список функций достаточно велик, чтобы удовлетворить потребности пользователей в создании и редактировании растровых изображений. Программа поддерживает больше сотни графических форматов и позволяет свободно конвертировать готовые работы в любой из них. Как и более популярные редакторы, ImageMagick предлагает множество вариантов трансформации и корректировки изображений, включая работу с цветовой гаммой или наложение специальных эффектов. Имеются и средства художественной обработки рисунков, позволяющие превратить обычную фотографию в имитацию картины, написанной, к примеру, масляными красками или угольным грифелем (рис. 2).
Впрочем, нет смысла подробно описывать все функциональные возможности программы, доступные из графического интерфейса: во-первых, пользователям других редакторов они привычны, а во-вторых, полный список вариантов изменения изображений явно уступает арсеналу более известных собратьев. На самом деле ImageMagick может себе это позволить, ведь его истинные возможности значительно превышают стандартный редакторский набор и для их использования не требуется красивый интерфейс или сложная система контекстных меню. Скрытые таланты необычного редактора проявляются в полной мере только при работе из командной строки.
На первый взгляд работа с графикой в консольном режиме кажется невозможной: все мы привыкли, что на дисплее отображается некий графический объект, с которым мы поэтапно производим различные манипуляции. При этом на обработку одного изображения нередко уходит слишком много времени. Благодаря использованию командной строки, ImageMagick позволяет делать то же самое, но одномоментно, а при необходимости - и в пакетном режиме, применяя одни и те же средства редактирования сразу ко множеству файлов. По принципу работы этот необычный способ напоминает командный интерпретатор, хорошо знакомый пользователям GNU/Linux-систем. Сначала вводится команда, далее - набор параметров, указывающих последовательность и содержащих описание действий, которые необходимо выполнить команде в отношении указанного объекта. Таким образом, при наличии некоторых навыков работа, занимающая обычно несколько минут, выполняется в считанные секунды. В качестве примера предположим, что нам нужно поместить рисунки police.jpg и boat.jpg в рамку, снабдить подписью, разместить все это на синем фоне, а конечный результат преобразовать в формат png. В обычном редакторе эта задача выполняется в несколько довольно затратных по времени этапов, а для ImageMagick достаточно войти в режим командной строки (или открыть консоль в случае работы в UNIX-подобной операционной системе), перейти в каталог с изображениями и ввести следующую последовательность:
montage -label %f -frame 5 -background blue -geometry +4+4 boat.jpg police.jpg galery.png
В результате через секунду в каталоге с исходными изображениями появится то, что требовалось (рис. 3).
Впрочем, работа с уже существующими изображениями выглядит не так эффектно. Чтобы усложнить задачу, попробуем создать графический файл из обычного текста. Как правило, именно изготовление красочных надписей или заголовочных баннеров отнимает массу времени и сил. Приходится работать со слоями, постепенно добавляя к тексту необходимые декорации в виде, например, обрамления букв и тени. ImageMagick выполняет подобную работу без особого труда. Вот как выглядит команда с назначенными параметрами:
convert -size 600x85 xc:transparent -font Bookman-DemiItalic -pointsize 72 -draw “text 25,60 ‘Компьютерра’” -channel RGBA -gaussian 0x6 -fill darkblue -stroke white -draw “text 20,55 ‘Компьютерра’” computerra-title.png
После того как команда выполнена (что может занять две-три секунды), в нашем рабочем каталоге появится готовый графический файл с красочно оформленным текстом (рис. 4).
Также можно создавать и более сложные варианты текстовой графики, одновременно добавляя фоновый рисунок, сгенерированный самим редактором или взятый извне. Список параметров в этом случае значительно увеличится, и для сохранения журнального места и психического равновесия читателей мы его не приводим. Впрочем, на скорость выполнения команды разрастание кода практически не повлияет. Через пару секунд в нашем распоряжении окажется файл, на создание которого с помощью обычных графических редакторов ушло бы не меньше часа-двух (рис. 5).
Всего в ImageMagick насчитывается одиннадцать команд, фактически являющихся отдельными приложениями (см. врезку). Каждой из них соответствует по несколько десятков параметров, что позволяет очень точно указывать, какие действия необходимо произвести с исходным материалом. Учитывая, что практически каждому параметру можно присвоить сотни значений, можно представить, насколько гибкий и мощный инструмент попадает в наши руки после установки ImageMagick на компьютер. Естественно, все функции, доступные при работе в графическом интерфейсе этого редактора, тоже остаются в нашем распоряжении, только для их использования уже не придется гонять курсор мыши по меню.
При первом знакомстве с подобным стилем работы неизбежно появляется ощущение, что все это слишком сложно и непонятно: физически невозможно запомнить все параметры команд, а тем более с первой попытки правильно выставить их значения, чтобы получить ожидаемый результат. На самом деле, чем чаще вы будете пользоваться редактором, тем проще будет выполнять поставленные задачи. Достаточно накапливать часто используемые комбинации в виде текстового файла-хранилища, а впоследствии лишь копировать нужный кусок кода в командную строку с внесением некоторых изменений. В конце концов в ваших руках окажется солидная подборка уже готовых решений почти на все случаи жизни. Если же вы захотите привнести в свои работы свежие идеи, к вашим услугам сайт разработчиков редактора, где опубликовано подробное описание всех команд и операторов, позволяющее быстро найти подходящий вариант.
Заканчивая рассказ об ImageMagick, отмечу, что для большинства пользователей, работающих с графикой от случая к случаю, использование этой программы может оказаться не совсем рациональным: не исключено, что быстрее выполнить небольшую работу привычным способом, нежели изучать консольные команды. Впрочем, при совершении простых однотипных операций над большим количеством изображений (например, изменение размера или добавление подписи) ImageMagick, используемый вместе с каким-нибудь скриптовым языком (bash, Perl, Python или собственным Magick Scripting Language), может существенно сэкономить время. Для тех же, кто постоянно занимается созданием и редактированием графических изображений, ImageMagick может стать неплохим инструментом, если не заменяющим, то весьма удачно дополняющим даже самые именитые программы.
• imagemagick.org- официальный сайт проекта: релизы для скачивания, исчерпывающая документация, полезные ссылки.
• www.cit.gu.edu.au/~anthony/graphics/imagick6- обширная галерея примеров использования ImageMagick.
• animate - отображение анимации (слайд-шоу) из набора файлов через X-сервер;
• compare - визуальное сравнение файлов и количественная оценка степени их схожести;
• composite - наложение изображений;
• conjure - выполнение скриптов на собственном языке Magick Scripting Language;
• convert - конвертирование изображений из одного формата в другой, а также применение к ним самых разнообразных операций (изменение размера, наложение фильтров и т. д.);
• display - отображение изображений и слайд-шоу через X-сервер;
• identify - получение информации о формате и параметрах одного или нескольких графических файлов;
• import - сохранение скриншотов произвольных областей экрана;
• mogrify - изменение размера изображения или применение к нему различных операций. Отличается от convert тем, что меняет исходный файл, а не создает новый;
• montage - объединение нескольких изображений в одно;
• stream - средство сохранения информации о цветовых каналах в различные форматы.
Софтерринки
Автор: Илья Шпаньков
• ОС: Windows
• Адрес: www.agnitum.ru
• Версия: 3.51
• Размер: 5,5 Мбайт
• Интерфейс: русский, украинский
• Цена: 699 руб.
Outpost Firewall Pro является одним из лучших по функциональности персональных брандмауэров. Приложение позволяет в автоматическом режиме блокировать проникновение из Интернета вредоносных программ самого разного профиля. Наличие «скрытого» режима делает компьютер полностью невидимым для злоумышленников. Одновременно программа контролирует передачу данных в Сеть, предотвращая потерю конфиденциальной информации, а также позволяет ограничить доступ к внешним ресурсам нежелательного содержания. Новая версия Outpost Firewall Pro обладает встроенным модулем Outpost AntiSpyware.
***
• ОС: Windows
• Адрес: www.hddlife.com/rus
• Версия: 2.8.99
• Размер: 4,3 Мбайт
• Интерфейс: многоязычный (русский поддерживается)
• Цена: бесплатно, 500 руб. (версия Pro), 700 руб. (версия for Notebooks)
• Ознакомительный период: 14 дней
Иногда внезапная кончина жесткого диска может нанести катастрофический урон накопленным данным и рабочим материалам. Исключить подобный форс-мажор призвана программа HDDlife Pro. С заданной пользователем периодичностью она отслеживает состояние накопителей с помощью встроенной в них системы самодиагностики S.M.A.R.T. и своевременно предупреждает о возможных проблемах. Кроме того, HDDlife осуществляет мониторинг температурного режима HDD, предотвращая его перегрев, и сигнализирует о заполняемости накопителей. В случае отсутствия пользователя программа способна автоматически переводить компьютер в спящий режим с сохранением текущих документов.
Что же до электронной микроскопии, то именно благодаря достигаемому ею разрешению в несколько ангстрем удалось составить подробные карты «внутриклеточного ландшафта» и воочию, без домыслов, увидеть строение клеточного ядра, а также митохондрий, рибосом и других клеточных органелл. Но понятно, что на острие электронного пучка, разогнанного в вакууме полем напряженностью в десятки киловольт, живьем ничего не разглядишь. Электронная микроскопия знает лишь один экзотический пример, когда твердейший хитиновый покров членистоногих сканируют без всякой предварительной подготовки. А так - нежную и трепетную живую ткань приходится фиксировать альдегидами и четырехокисью осмия, обезвоживать, заливать полимеризующимися материалами, пропитывать специальными «электронными» красителями и готовить тончайшие срезы «на просвет».
А биология сегодняшнего дня предъявляет все больший спрос на исследование клеток и тканей непосредственно в процессе их жизнедеятельности. Чтобы сохранить «щадящий» характер световой микроскопии и при этом повысить разрешающую способность, исследователи идут на компромисс - скажем, в обмен на вожделенную точность смиряются с необходимостью многократных повторных измерений. Компромисс, однако, всегда штука непростая. Обратим внимание: схема, при которой процесс получения одной-единственной сверхточной картинки растягивается на минуты и даже часы, может безотказно работать только на неподвижном объекте, отдельные части которого не расползутся в разные стороны прямо по ходу «сложносочиненного» замера. Собственно, все сенсационные результаты новейших методик высокого разрешения и были получены на специально фиксированных объектах. Но ведь поставленная сверхзадача - исследование функционирующей клетки со всеми ее внутриклеточными транспортными потоками, сократительными белками и т. п. И мы не можем, подобно пляжному фотографу, скомандовать ей «замрите, снимаю».
Судя по оптимистичному тону профессора Сяовэя Чжуана (Xiaowei Zhuang), уверенного в возможности ускорения процедуры STORM-микроскопии вплоть до исследования живых клеток с молекулярным разрешением в реальном масштабе времени, разработчики надеются преодолеть это концептуальное противоречие. Но, может быть, ближе к истине профессор Дженнифер Липпинкотт-Шварц (Jennifer Lippincott-Schwartz), видящая будущее новых методик в их сочетании с электронной микроскопией: «Соотнося результаты PALM-микроскопии с электронномикроскопической картиной, можно понять, как отдельные активные молекулы распределены по тонким субклеточным структурам».
МЫСЛИ: Жизнь технического задания
Автор: Олег Бунин
Этой статьей я не хочу доказать, что написание технического задания - зло и корень всех бед, нет, ни в коем случае. Все и всегда относительно, а в нашем случае - зависит от задачи. Я хочу показать, что классические схемы разработки программного обеспечения работают не всегда, не всегда эффективны, часто приводят к ненужным конфликтам между менеджерами и исполнителями. Особенно это касается разработки веб-приложений. Я расскажу об экстремальном программировании, но не так, как пишут в книжках, а исходя из реалий - из того, что попробовали команды под моим руководством. О тех методиках, которые работают.
Изменчивый мир
Когда я слышу о техническом задании на разработку веб-сайта, я внутренне улыбаюсь - еще один продукт, устаревший уже в момент выхода. Это первая проблема всех технических заданий - предположение, что внешняя среда не меняется.
Вторая проблема хорошо известна и отражена в древней мудрости: чтобы задать правильный вопрос, надо знать половину ответа. В ситуации, когда каждый новый сайт вы разрабатываете с использованием только что появившихся технологий (новые модули, новая версия собственного движка, новая версия базы данных), - фактически вы каждый раз многое делаете заново. Это значительно осложняет процесс разработки, потому что вы не знаете, как будете это разрабатывать.
Третья проблема классическая - заказчик не всегда точно знает, чего он хочет. И когда подходит срок сдачи проекта, вы слышите, что вот здесь хорошо бы подправить, вот здесь изменить, а вот здесь добавить. Частично эту проблему решает моделирование конечного продукта, но, повторюсь, лишь частично.
Выпуск конкурентами нового продукта, появление нового брэнда, новой технологии, нового браузера, изменение предпочтений потребителей - все это требует немедленной реакции, изменяет предметную область, описанную в ТЗ. Заказчик увидел сайт конкурирующей компании и хочет такую же «штуку». При этом вы не знаете заранее, как будете реагировать и сколько времени потребует реализация той или иной вашей реакции. Одним словом - хаос…
Экстремальное программирование
Ниже я опишу простейшие методы, которые позволят компании постепенно уйти от классической каскадной модели цикла разработки программного обеспечения. Каскадную модель вкратце можно описать так: сначала мы просим пользователей или заказчика сформулировать свои требования, затем разрабатываем проект системы, составляем техническое задание. Затем пишем код, тестируем его. Увы… Эта модель не годится для большинства проектов по разработке веб-приложений.
Что же делать? Ответ прост: принять окружающую действительность, принять изменчивый мир, принять хаос. Стать гибким и разрабатывать свою стратегию с учетом того, что нас окружает хаос. Это нормально. И убедиться при этом, что уже существуют инструменты, позволяющие успешно действовать в условиях хаоса. Например, инструменты экстремального программирования. Все они создавались исходя из того, что окружающая среда гибко и динамично меняется, и не пытаются зафиксировать ее, а наоборот - приспосабливают производственные процессы под подобную среду.
Итерации
Итак, мы приняли концепцию изменчивого мира. Что это меняет? Сразу становится ясно, что писать подробнейшее техническое задание не имеет смысла - оно стремительно устаревает. Ограничимся описанием функций, причем так, как их видит пользователь системы. Как правило, заказчик достаточно хорошо их представляет.
На основе такого описания команде разработчиков, дизайнеров, верстальщиков становятся ясны их ближайшие шаги. Основные архитектурные решения, общие рамки будущего сайта, общее устройство. Но я подчеркиваю - ближайшие шаги. Достаточно одного-двух. Шаги должны быть небольшие (неделя, несколько дней). После каждого шага - пересмотр всех условий, учет всех изменений. В экстремальном программировании такие шаги называют итерациями.
Итак, если мы на каком-то этапе работы пошли по неверному пути, мы очень быстро это поймем - одна-две итерации, и ошибка будет исправлена.
Общение с заказчиком
И все же нам нужно чем-то заменить отсутствие формального технического задания, - ведь мы должны сделать то, что требуется заказчику. Выход - тесное общение с представителем заказчика и пользователями на всех этапах работ (не только в точках проверки, не только в начале и конце работ, а в течение всего времени работы над проектом).
Постоянное сотрудничество с заказчиком, когда его представители присутствуют на планерках, видят все процессы «изнутри», позволяет не делать лишних предположений и, соответственно, не писать лишнего кода. Те, кто имеет отношение к разработке ПО, хорошо знают, как часто даже на начальном этапе возникают вопросы к заказчику. Если эти вопросы будут немедленно разрешаться, мы получим значительную экономию ресурсов.
Ежедневные релизы
Еще один прием, который позволит частично компенсировать отсутствие подробного технического задания, - частые релизы. Покажите заказчикам вашу работу как можно раньше.
Отсюда, кстати, известное выражение «вечная бета» - веб-сайт выкладывается «в бой», программа становится доступной пользователям как можно раньше. И далее проектная команда корректирует процесс разработки (вплоть до концепции самого проекта) «на лету», наблюдая за реакцией пользователей.
Творчество, а не копирование
Подобный подход, движение вперед маленькими шагами требует от исполнителей гораздо более высокой ответственности, нежели простое кодирование. Вам потребуются креативные специалисты, способные самостоятельно находить оптимальные решения. В подобном процессе разработчикам не раз приходится переписывать код, поэтому для облегчения их работы в экстремальном программировании есть несколько практик. Я не буду описывать их подробно, это тема отдельной статьи, но упомяну:
• Тестирование до начала разработки.
• Парное программирование.
• Постоянный рефакторинг.
• Простота разработки.
• Коллективное владение кодом.
• Быстрый выпуск версий.
• Постоянная интеграция.
• Стандарты кодирования.
Тестирование до начала разработки предполагает написание тестов, в том числе приемочных, до того как будет написан сам код. Это дает значительные преимущества, особенно в сложных системах, где изменение одного компонента неизбежно влияет на работу других. В таких случаях приемочные тесты жизненно необходимы.
Парное программирование я рекомендую использовать только в случаях, когда вам нужен очень качественный результат. Мой опыт говорит о том, что двое программистов за одним компьютером программируют медленнее, чем двое за двумя, но программный код, который получается в экстремальном варианте, содержит на порядок меньше ошибок.
Постоянный рефакторинг заключается в регулярном пересмотре того, что уже написано, уже разработано. И в постоянном его улучшении.
Простота разработки - из двух вариантов выбирается более простой и быстро реализуемый.
Коллективное владение кодом означает, что все участники проекта свободно читают и знают любой участок программы. Это достигается путем введения стандартов кодирования - некоторых правил написания программного кода, обязательных для всех, что облегчает чтение кода, поскольку он становится однородным в рамках проекта.
Постоянная интеграция - мы пробуем запустить вместе даже недописанные и не до конца отработанные компоненты системы, чтобы как можно раньше увидеть разного рода несовместимости и ошибки в проектировании. Для этих же целей служит быстрый выпуск версий - постоянная корректировка процесса разработки с учетом мнений пользователей и заказчика.
Сотрудничество, а не конфликтование
Одно из важных следствий принятия концепции хаотичности окружающего мира - исчезновение конфликтов между менеджерами и исполнителями. Эти, казалось бы, вечные «грабли» хорошо знакомы всем, кто имеет отношение к разработке веб-сайтов. В традиционной (каскадной) модели разработки пик конфликта приходится на самый важный этап - предвыпуск или выпуск проекта. Главная причина - разработчики сделали не совсем то, что хотел менеджер или заказчик.
Как вы понимаете, эта проблема исчезает, если мы априори принимаем, что мнение заказчика может измениться, но и мы сможем своевременно на это отреагировать: ведь наши рабочие процессы построены так, что нам не придется переписывать заново половину программного кода, соответственно, изменение задачи не приведет к психологическому «напрягу» разработчиков.
Спиральная модель жизненного цикла разработки ПО
Специалисты по управлению проектами справедливо заметят, что описываемые мною приемы напоминают спиральную модель жизненного цикла разработки программного обеспечения. Почему же эта модель, несмотря на очевидные достоинства (снижение рисков, повышение качества продукта и степени удовлетворенности заказчиков и разработчиков), не используется повсеместно в разработке ПО и веб-приложений?
Потому, что это сложно. Потому, что требует большей ответственности от всех участников процесса, большей гибкости, большей сознательности и даже храбрости - в экстремальном программировании это качество в почете.
СОФТЕРРА: Высокохудожественный командный интерпретатор
Автор: Илья Шпаньков
Когда разговор заходит о растровых графических редакторах, абсолютное большинство людей в первую очередь вспоминает Adobe Photoshop. Сторонники свободного софта, конечно, не забудут упомянуть и своего фаворита The Gimp, по умолчанию входящего в большинство GNU/Linux-дистрибутивов. Возможно, кто-то вспомнит Paint.NET или еще какой-нибудь «легкий» редактор «для дома, для семьи». Но сегодня мы поговорим не о них.
Все эти популярные средства создания и редактирования графических изображений обладают хорошо развитым интерфейсом и содержат сотни функций, позволяющих создавать настоящие шедевры цифровой живописи. Меж тем наряду со своими известными «коллегами» живет и здравствует еще один своеобразный редактор по имени ImageMagick, который скромно трудится на ниве обработки цифровой растровой графики уже не первый год. Широкой публике этот редактор (а точнее - пакет графических утилит) практически неизвестен в силу особенностей, о которых будет сказано ниже. Однако в некоторых случаях он даст фору любому именитому аналогу.
Скромный трудяга
Прежде всего, ImageMagick является платформнонезависимым: на сайте разработчиков можно найти установочные пакеты для Windows, Linux, Mac OS X, Solaris, FreeBSD и Cygwin. Помимо этого, редактор распространяется под свободной лицензией, совместимой с GPL, благодаря чему доступны все исходные коды, а пользователи практически ничем не ограничены в плане использования программы и ее «подгонки» под свои специфические цели. Но и это еще не все: авторы предлагают более десятка различных вариантов интерфейса ImageMagick, написанных на C, C++, Java, Perl, PHP и других, более экзотических языках. Несмотря на довольно аскетичный внешний вид (остающийся неизменным несколько последних лет), свое дело ImageMagick делает хорошо и к тому же освобождает авторов программы от излишних хлопот по внедрению и отладке новомодных веяний интерфейсостроения, позволяя уделять больше внимания совершенствованию функциональных возможностей. Подобная неприхотливость редактора способствует полноценному выполнению своих функций в любом программном окружении, а также открывает большой простор для интеграции с другими приложениями. Особенно рады этому разработчики свободного ПО: библиотеки ImageMagick входят в состав многих GNU/ Linux-дистрибутивов и часто используются различными программами, обладающими функциями просмотра или редактирования изображений. Наличие же в системе одного из вариантов интерфейса позволяет работать с ImageMagick как с обычным графическим редактором (рис. 1).
Рисуй, консоль!
На первый взгляд работа с графикой в консольном режиме кажется невозможной: все мы привыкли, что на дисплее отображается некий графический объект, с которым мы поэтапно производим различные манипуляции. При этом на обработку одного изображения нередко уходит слишком много времени. Благодаря использованию командной строки, ImageMagick позволяет делать то же самое, но одномоментно, а при необходимости - и в пакетном режиме, применяя одни и те же средства редактирования сразу ко множеству файлов. По принципу работы этот необычный способ напоминает командный интерпретатор, хорошо знакомый пользователям GNU/Linux-систем. Сначала вводится команда, далее - набор параметров, указывающих последовательность и содержащих описание действий, которые необходимо выполнить команде в отношении указанного объекта. Таким образом, при наличии некоторых навыков работа, занимающая обычно несколько минут, выполняется в считанные секунды. В качестве примера предположим, что нам нужно поместить рисунки police.jpg и boat.jpg в рамку, снабдить подписью, разместить все это на синем фоне, а конечный результат преобразовать в формат png. В обычном редакторе эта задача выполняется в несколько довольно затратных по времени этапов, а для ImageMagick достаточно войти в режим командной строки (или открыть консоль в случае работы в UNIX-подобной операционной системе), перейти в каталог с изображениями и ввести следующую последовательность:
montage -label %f -frame 5 -background blue -geometry +4+4 boat.jpg police.jpg galery.png
В результате через секунду в каталоге с исходными изображениями появится то, что требовалось (рис. 3).
convert -size 600x85 xc:transparent -font Bookman-DemiItalic -pointsize 72 -draw “text 25,60 ‘Компьютерра’” -channel RGBA -gaussian 0x6 -fill darkblue -stroke white -draw “text 20,55 ‘Компьютерра’” computerra-title.png
После того как команда выполнена (что может занять две-три секунды), в нашем рабочем каталоге появится готовый графический файл с красочно оформленным текстом (рис. 4).
При первом знакомстве с подобным стилем работы неизбежно появляется ощущение, что все это слишком сложно и непонятно: физически невозможно запомнить все параметры команд, а тем более с первой попытки правильно выставить их значения, чтобы получить ожидаемый результат. На самом деле, чем чаще вы будете пользоваться редактором, тем проще будет выполнять поставленные задачи. Достаточно накапливать часто используемые комбинации в виде текстового файла-хранилища, а впоследствии лишь копировать нужный кусок кода в командную строку с внесением некоторых изменений. В конце концов в ваших руках окажется солидная подборка уже готовых решений почти на все случаи жизни. Если же вы захотите привнести в свои работы свежие идеи, к вашим услугам сайт разработчиков редактора, где опубликовано подробное описание всех команд и операторов, позволяющее быстро найти подходящий вариант.
Заканчивая рассказ об ImageMagick, отмечу, что для большинства пользователей, работающих с графикой от случая к случаю, использование этой программы может оказаться не совсем рациональным: не исключено, что быстрее выполнить небольшую работу привычным способом, нежели изучать консольные команды. Впрочем, при совершении простых однотипных операций над большим количеством изображений (например, изменение размера или добавление подписи) ImageMagick, используемый вместе с каким-нибудь скриптовым языком (bash, Perl, Python или собственным Magick Scripting Language), может существенно сэкономить время. Для тех же, кто постоянно занимается созданием и редактированием графических изображений, ImageMagick может стать неплохим инструментом, если не заменяющим, то весьма удачно дополняющим даже самые именитые программы.
Ссылки
• imagemagick.org- официальный сайт проекта: релизы для скачивания, исчерпывающая документация, полезные ссылки.
• www.cit.gu.edu.au/~anthony/graphics/imagick6- обширная галерея примеров использования ImageMagick.
Команды пакета ImageMagick
• animate - отображение анимации (слайд-шоу) из набора файлов через X-сервер;
• compare - визуальное сравнение файлов и количественная оценка степени их схожести;
• composite - наложение изображений;
• conjure - выполнение скриптов на собственном языке Magick Scripting Language;
• convert - конвертирование изображений из одного формата в другой, а также применение к ним самых разнообразных операций (изменение размера, наложение фильтров и т. д.);
• display - отображение изображений и слайд-шоу через X-сервер;
• identify - получение информации о формате и параметрах одного или нескольких графических файлов;
• import - сохранение скриншотов произвольных областей экрана;
• mogrify - изменение размера изображения или применение к нему различных операций. Отличается от convert тем, что меняет исходный файл, а не создает новый;
• montage - объединение нескольких изображений в одно;
• stream - средство сохранения информации о цветовых каналах в различные форматы.
Софтерринки
Автор: Илья Шпаньков
• ОС: Windows
• Адрес: www.agnitum.ru
• Версия: 3.51
• Размер: 5,5 Мбайт
• Интерфейс: русский, украинский
• Цена: 699 руб.
Outpost Firewall Pro является одним из лучших по функциональности персональных брандмауэров. Приложение позволяет в автоматическом режиме блокировать проникновение из Интернета вредоносных программ самого разного профиля. Наличие «скрытого» режима делает компьютер полностью невидимым для злоумышленников. Одновременно программа контролирует передачу данных в Сеть, предотвращая потерю конфиденциальной информации, а также позволяет ограничить доступ к внешним ресурсам нежелательного содержания. Новая версия Outpost Firewall Pro обладает встроенным модулем Outpost AntiSpyware.
***
• ОС: Windows
• Адрес: www.hddlife.com/rus
• Версия: 2.8.99
• Размер: 4,3 Мбайт
• Интерфейс: многоязычный (русский поддерживается)
• Цена: бесплатно, 500 руб. (версия Pro), 700 руб. (версия for Notebooks)
• Ознакомительный период: 14 дней
Иногда внезапная кончина жесткого диска может нанести катастрофический урон накопленным данным и рабочим материалам. Исключить подобный форс-мажор призвана программа HDDlife Pro. С заданной пользователем периодичностью она отслеживает состояние накопителей с помощью встроенной в них системы самодиагностики S.M.A.R.T. и своевременно предупреждает о возможных проблемах. Кроме того, HDDlife осуществляет мониторинг температурного режима HDD, предотвращая его перегрев, и сигнализирует о заполняемости накопителей. В случае отсутствия пользователя программа способна автоматически переводить компьютер в спящий режим с сохранением текущих документов.