Журнал «Компьютерра» N 33 от 12 сентября 2006 года
Шрифт:
Вторая группа использовала возбуждаемые лазером люминесцирующие белки. Ее метод позволил добиться лучшего пространственного разрешения в пределах 2-25 нм. Однако здесь за одну секунду удается сделать лишь один-два снимка, и для получения полного изображения с высоким разрешением требуется около двенадцати часов. Для демонстрации возможностей своей методики ученые получили изображения определенных белков в лизосомах и митохондриях, а также ряд других интересных фотографий живой клетки.
Любопытно, что два основных автора PALM-микроскопии Харальд Хесс (Harald Hess) и Эрик Бетциг (Eric Betzig) построили первый прототип своего нового микроскопа еще в сентябре прошлого года в гостиной Хесса. Будучи в то время без работы,
Разумеется, обе научные группы пока лишь в самом начале пути. Пройдет еще немало времени, прежде чем новые методы станут привычным инструментом биологов. Но эти разработки способны навести долгожданный мост между молекулярной и клеточной биологией, и возможно, что открытия вскоре посыплются как из рога изобилия.
Разработчики новейших методик стараются сблизить два полюса биомикроскопии, разделенные по разрешающей способности пропастью шириной более чем в два порядка: оптическую микроскопию, позволяющую исследовать не только мертвые, но и живые клетки, и электронную микроскопию, изучающую клетки заведомо убитые, но зато с завидной точностью. Граница применимости «прижизненной» микроскопии понятна: с длины волны ниже 400 нм начинается губительный для клеток ультрафиолет.
Что же до электронной микроскопии, то именно благодаря достигаемому ею разрешению в несколько ангстрем удалось составить подробные карты «внутриклеточного ландшафта» и воочию, без домыслов, увидеть строение клеточного ядра, а также митохондрий, рибосом и других клеточных органелл. Но понятно, что на острие электронного пучка, разогнанного в вакууме полем напряженностью в десятки киловольт, живьем ничего не разглядишь. Электронная микроскопия знает лишь один экзотический пример, когда твердейший хитиновый покров членистоногих сканируют без всякой предварительной подготовки. А так - нежную и трепетную живую ткань приходится фиксировать альдегидами и четырехокисью осмия, обезвоживать, заливать полимеризующимися материалами, пропитывать специальными «электронными» красителями и готовить тончайшие срезы «на просвет».
А биология сегодняшнего дня предъявляет все больший спрос на исследование клеток и тканей непосредственно в процессе их жизнедеятельности. Чтобы сохранить «щадящий» характер световой микроскопии и при этом повысить разрешающую способность, исследователи идут на компромисс - скажем, в обмен на вожделенную точность смиряются с необходимостью многократных повторных измерений. Компромисс, однако, всегда штука непростая. Обратим внимание: схема, при которой процесс получения одной-единственной сверхточной картинки растягивается на минуты и даже часы, может безотказно работать только на неподвижном объекте, отдельные части которого не расползутся в разные стороны прямо по ходу «сложносочиненного» замера. Собственно, все сенсационные результаты новейших методик высокого разрешения и были получены на специально фиксированных объектах. Но ведь поставленная сверхзадача - исследование функционирующей клетки со всеми ее внутриклеточными транспортными потоками, сократительными белками и т. п. И мы не можем, подобно пляжному фотографу, скомандовать ей «замрите, снимаю».
Судя по оптимистичному тону профессора Сяовэя Чжуана (Xiaowei Zhuang), уверенного в возможности ускорения процедуры STORM-микроскопии вплоть до исследования живых клеток с молекулярным разрешением в реальном масштабе времени, разработчики надеются преодолеть это концептуальное противоречие. Но, может быть, ближе к истине профессор Дженнифер Липпинкотт-Шварц (Jennifer Lippincott-Schwartz),
МЫСЛИ: Жизнь технического задания
Автор: Олег Бунин
Этой статьей я не хочу доказать, что написание технического задания - зло и корень всех бед, нет, ни в коем случае. Все и всегда относительно, а в нашем случае - зависит от задачи. Я хочу показать, что классические схемы разработки программного обеспечения работают не всегда, не всегда эффективны, часто приводят к ненужным конфликтам между менеджерами и исполнителями. Особенно это касается разработки веб-приложений. Я расскажу об экстремальном программировании, но не так, как пишут в книжках, а исходя из реалий - из того, что попробовали команды под моим руководством. О тех методиках, которые работают.
Когда я слышу о техническом задании на разработку веб-сайта, я внутренне улыбаюсь - еще один продукт, устаревший уже в момент выхода. Это первая проблема всех технических заданий - предположение, что внешняя среда не меняется.
Вторая проблема хорошо известна и отражена в древней мудрости: чтобы задать правильный вопрос, надо знать половину ответа. В ситуации, когда каждый новый сайт вы разрабатываете с использованием только что появившихся технологий (новые модули, новая версия собственного движка, новая версия базы данных), - фактически вы каждый раз многое делаете заново. Это значительно осложняет процесс разработки, потому что вы не знаете, как будете это разрабатывать.
Третья проблема классическая - заказчик не всегда точно знает, чего он хочет. И когда подходит срок сдачи проекта, вы слышите, что вот здесь хорошо бы подправить, вот здесь изменить, а вот здесь добавить. Частично эту проблему решает моделирование конечного продукта, но, повторюсь, лишь частично.
Выпуск конкурентами нового продукта, появление нового брэнда, новой технологии, нового браузера, изменение предпочтений потребителей - все это требует немедленной реакции, изменяет предметную область, описанную в ТЗ. Заказчик увидел сайт конкурирующей компании и хочет такую же «штуку». При этом вы не знаете заранее, как будете реагировать и сколько времени потребует реализация той или иной вашей реакции. Одним словом - хаос…
Ниже я опишу простейшие методы, которые позволят компании постепенно уйти от классической каскадной модели цикла разработки программного обеспечения. Каскадную модель вкратце можно описать так: сначала мы просим пользователей или заказчика сформулировать свои требования, затем разрабатываем проект системы, составляем техническое задание. Затем пишем код, тестируем его. Увы… Эта модель не годится для большинства проектов по разработке веб-приложений.
Что же делать? Ответ прост: принять окружающую действительность, принять изменчивый мир, принять хаос. Стать гибким и разрабатывать свою стратегию с учетом того, что нас окружает хаос. Это нормально. И убедиться при этом, что уже существуют инструменты, позволяющие успешно действовать в условиях хаоса. Например, инструменты экстремального программирования. Все они создавались исходя из того, что окружающая среда гибко и динамично меняется, и не пытаются зафиксировать ее, а наоборот - приспосабливают производственные процессы под подобную среду.