суббота, 23 января 2010 г.

[comp.prog.flame] Еще раз о биржевом софте, на этот раз для Лондонской Фондовой Биржи

Лондонская Фондовая Биржа начинает миграцию на новую трейдинговую платформу, где в качестве основной операционки используется Linux. Новая платформа должна заменить работающую сейчас TradElect (которая написана на .NET-е, крутится на HP-шных ProLiant-ах под Win2003 Server и MS SQL Server 2000). Главная причина перехода – проблемы стабильности TradElect.

Мне, как человеку, который в свое время горячо спорил с оголтелыми .NET-чиками на RSDN, приятно читать такие новости :) Хотя дело, определенно, не в .NET-е. Рискну предположить, что все дело в людях, которые TradElect писали. Не смогли, похоже, подобрать хорошую команду разработчиков – вот и результат.

Но самое удивительное в этой новости для меня то, что в качестве новой платформы будет использоваться система MillenniumIT, которую биржа получила в свое распоряжение после покупки компании из… Шри-Ланки!

Вот никогда не слышал, чтобы на Шри-Ланке писали программы вообще. Про цейлонский чай слышал, про туризм на Шри-Ланку слышал, про вялотекущую войну местных повстанцев слышал… А вот чтобы там еще и серьезный софт писали – прям гром среди ясного неба. Глобализация, чё поделать. Да и Индия со своими тысячами программистов совсем рядом ;)

Удивительное рядом, однако.

[comp.prog.thoughts] Так вот о парном программировании

Мой недавний спор с Сергеем Зефировым произошел во время обсуждения парного программирования. Толчком к которому послужило исследования эффективности этого подхода, о результатах которого было упомянуто здесь.

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

  • это классная штука,
  • это полная фигняерунда,
  • не знаю, не пробовал.

Поскольку в последний раз в сеансе парного программирования я принимал участие в далеком 2002-м году (т.е. уже совершенно не разбираюсь в данном вопросе), то самое время высказать свое мнение по этому поводу ;) А мнение у меня такое – штука это хорошая, но очень неоднозначная и для массового применения не приспособленная. Теперь попробую это обосновать.

Начнем с того, что учиться программировать я начинал как раз в режиме парного программирования. На первом курсе у нас машинное время выделялось, наверное, всего две пары в неделю – и этого хватало, разве что, на выполнение задаваемых лабораторных работ. Но зато наш дисплейный класс с Robotron 1715 был не шибко престижным (в отличии от классов с Искрами и IBM XT-шками). Поэтому там всегда был один или два свободный компьютер, на котором можно было работать. И вот мы вдвоем-втроем устраивались за ним и коллективно писали свои первые более-менее серьезные программы.

Было здорово. Перед тем как что-то написать ты рассказываешь коллеге что ты собираешься сделать. Он тебя спрашивает: “А почему так, а не вот так?” Оба варианта сравниваются, иногда рождается какой-то третий вариант. Потом ты объясняешь, как ты будешь это делать. Тут тебе опять могут подсказать что-нибудь. Потом ты пишешь код и тебе подсказывают, что пора бы сохраниться, пора бы добавить вот эту штуку, пора бы избавиться от промежуточной заглушки и т.д.

Потом, потихонечку, практика парного программирования сошла на нет. Все-таки доступ к компьютерам становился все более и более свободным. Очередной заметный всплеск использования этой методики случился где-то в 1998-1999 годах, когда мы в КБСП сделали первую работающую версию SCADA Objectizer. Там был визуальный редактор/конструктор агентов и мнемосхем и при реализации АСУТП-шной системы мы частенько усаживались перед компьютером вдвоем-втроем чтобы сконструировать очередного агента. Было здорово.

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

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

Какие из всего этого я для себя сделал выводы?

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

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

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

Это все хорошие стороны парного программирования. Но они даются не просто так.

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

Вспоминается байка про Кернигана и Ричи. Они так долго работали вместе, что даже думать стали настолько похоже, что когда каждому из них пришлось в одиночку написать небольшую процедурку из десятка строк, то каждый из них написал один и тот же код – совпадали даже имена переменных!

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

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

Но наличие большого количества “авральных задач” должно выглядеть подозрительно. Имхо, при нормальной, размеренной разработке их должно быть минимум. Даже при очень сжатых сроках (с любимой нынче датой готовности “вчера”) все равно выгоднее много подумать перед написанием кода, чтобы потом быстро сделать. С этой точки зрения в нормальной разработке парному программированию мест найдется немного.

Одно из таких мест – это обучение новых людей. Когда человек “въезжает” в чужую разработку, ему будет проще, если он сам посмотрит как его коллеги работают, и если ему помогут поначалу код для проекта писать. Но, опять же, это временное применение парного программирования.

Итак, в сухом остатке: для некоторых ситуаций парное программирование – это отличная штука, но она не может применяться ежедневно для всех без исключения задач. Хотя, если у вас с кем-то сложится настолько же продуктивный дуэт, как у Кернигана и Ричи – тогда совсем другое дело.

PS. Что-то мне подсказывает, что найти такого коллегу, как это произошло у Кернигана и Ричи, будет посложнее, чем хорошую жену :)

пятница, 22 января 2010 г.

[life.photo] Снимок крокодила ну с очень близкого расстояния

Этот крокодил, живущий в соленой воде, вынырнул чтобы схватить камеру. Снимок сделан за мгновение до того, как это ему удалось (клик на снимке ведет на вариант в разрешении 1600x1200):

Найдено в разделе National Geographic Photo of the Day.

[comp.prog.humour] Происхождение термина “синтаксический оверхед”

Для многих старых RSDN-щиков термин “синтаксический оверхед” уже давно стал привычным и обыденным. Хотя он был введен в обиход Сергеем Губановым всего лишь 4.5 года назад. С другой стороны, по компьютерным меркам, такой срок – это очень много. И я уверен, что некоторые читатели даже никогда не слышали об этом понятии. Более того, многие, наверняка, не читали эпического флейма, в котором сей термин был впервые представлен широкой публике. А жаль… С подачи ув.тов.Quaker в комментариях к моей предыдущей заметке я разыскал ту тему на RSDN, прочитал несколько постов оттуда и впал в состояние старческого умиления – вот были же времена!

Так что рекомендую: Синтаксический оверхед.

четверг, 21 января 2010 г.

[comp.prog.wow] Sikuli: программирование в картинках

Приходилось ли вам видеть когда-нибудь вот такие программы:

И думали ли вы вообще, что можно программировать вот так? ;)

Теперь можно. В MIT's Computer Science and Artificial Intelligence Lab развивается проект под названием Sikuli (“Глаз Бога” на языке мексиканских индейцев). В рамках этого проекта созданы:

  • Sikuli Search – справочная система, которая ищет информацию по скриншоту (т.е. выделяете на экране какое-нибудь диалоговое окно Windows, а Sikuli Search ищет справку по этому окну в своих архивах), и
  • Sikuli Script – производный от Python-а язык для автоматизации действий пользователя с использованием скриншотов. Как раз приведенный выше пример кода показывает, как выглядят подобные программы.

Для создания еще большего впечатления приведу пару примеров из работы Sikuli: Using GUI Screenshots for Search and Automation:

  1. Удаление документов нескольких типов текущей папки в корзину:
     
    Здесь сначала определяются значки тех типов документов, которые мы хотим удалить. Потом в окошке ищутся значки этих типов и каждый найденный значок перетягивается на иконку “Recycle Bin”.
  2. Контроль за тем, что автобус приехал в нужную точку (с помощью отображения движения автобуса на основе GPS):

    Тут все просто. Сначала задается финальная точка маршрута. Затем периодически ищется значок текущего местоположения автобуса. Если этот значок не достиг финальной точки, то делается пауза.

Вот такая вот забавная штука.

При всей своей забавности, она может найти свое применение, например, в автоматизированном тестировании программ. И работа GUI Testing Using Computer Vision как раз описывает возможности использования Sikuli в этой области.

Первоисточник: Dr.Dobb’s: Picture-Driven Computing.

PS. Понравилось еще и то, какая сборная солянка была использована при работке Sikuli Script (включая и специализированную IDE для написания скриптов): алгоритм сопоставления картинок был реализован на C++, затем все это было обернуто в Java, на основе Java API была написана Python-овая библиотека, редактор был создан с использованием Java Swing, а для исполнения скриптов задействовали Jython.

среда, 20 января 2010 г.

[comp.prog] Ссылки про знаменитый AXD 301 – большущий флаг всех эрлангистов

Как только упоминается язык Erlang, так сразу в качестве козырного туза предъявляется проект AXD 301 – ATM switch (телефонный цифровой коммутатор, если я правильно перевожу это на русский) от Ericsson-а. Поскольку практически всегда, когда речь заходит о нем, приходиться искать в Интернете статьи с указанием объема кода и количества разработчиков, то решил некоторые из них опубликовать здесь. Итак:

AXD 301-A new generation ATM switching system – рекламное-обзорное описание самого устройства. 1998 год.

Ulf Wiger’s Four-fold Increase in Productivity and Quality – презентация с рассказом о том, как программирование на Erlang увеличивает скорость и качество разработки. С примером AXD 301, естественно. 2001 год.

Joe Armstrong’s Concurrency Oriented Programming in Erlang – доклад о конкурентном программировании на Erlang. 2002 год (и тот же доклад, но уже в 2003 году).

Joe Armstrong’s Making reliable distributed systems in the presence of sodware errors – диссертация Армстронга, в которой он говорит, в том числе, и об AXD 301. 2003 год.

Mats Cronqvist’s Troubleshooting a Large Erlang System – небольшая статья о том, как разрабатывался софт для AXD 301. 2004 год.

Интересен рост количества строк в Erlang-овой части AXD от публикации к публикации. Ульф Виджер указывает 1M (+ еще 260K в самом OTP). Армстронг через год говорит об 1.7M (хотя в диссертации указана цифра в 1136150 строк кода). А Кронквист через два года – о 2.1M (хотя не факт, что там считались только Erlang-овские строки). Либо софт AXD 301 все время дорабатывают, либо со временем партизаны в воспоминаниях ветеранов становятся все толще и толще ;)

Меня впечатляют цифры из презентации Ульфа Виджера:

  • 1M строк кода на Erlang-е;
  • 400K строк на C/C++;
  • 13K строк на Java;
  • плюс к тому около 500K строк кода на C, который работал на т.н. device processor-ах;
  • плюс к тому около 100K строк кода на C в стороннем ПО (запуском которого занимались программы на Erlang-е);
  • плюс к тому 240K строк на Erlang-е, 460K строк на C++ и 15K строк на Java, которые входили в саму реализацию Erlang/OTP.

В статье Кронквиста указывается, что писало код около 300 человек, хотя раньше я слышал другие цифры – порядка 150.

Просьба к читателям: когда-то я читал то ли статью Армстронга (а может и не Армстронга), то ли его интервью, в котором он подробнее рассказывал о разработке AXD 301. Там, кажется, были более подробные цифры по разработчикам. Кажется, что 50 человек писали Erlang-овую часть и еще около 100 человек – C/C++ные и Java-вские модули. Еще там Армстронг указывал, что одним из факторов успеха проекта было то, что удалось всех разработчиков собрать в едином центре, что существенно сокращало издержки на коммуникации внутри коллектива. Сам я эту ссылку найти сейчас не смог. Буду признателен, если кто-то ею поделится.

[comp.prog.flame] Пример неистребимого программерского оптимизма

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

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

В блоге Сергея Зефирова (aka thesz) появилась заметка под названием “Гвоздь в гроб парного программирования”, в обсуждении которой была высказана мысль, что парное программирование может сократить риски потери участников проекта и что есть области, в которых ввод в тему нового разработчика может потребовать не менее полугода:

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

На что Сергей попросил привести примеры таких тем. В этом месте в обсуждение встрял я и привел пример с недавней новостью о запуске новой трейдинговой системы на Токийской бирже (эта новость обсуждалась в блоге ув.тов.jazzer-а и на LOR-е). Ответ Сергея на этот пример заставил меня в буквальном смысле выпасть в осадок:

Поехали по пунктам.

Speed: Enabling millisecond-level market access

Исключительно техническое дело, решается только и исключительно близостью к бирже, и никак иначе.

Не входящим в круг "друзей биржевиков" это недоступно.

Reliability: Applying the latest technology to ensure market reliability

Техническое дело, опять.

Ну, смогу я сделать достаточно надёжную программу, но где мне найти подходящее железо?

Scalability: Providing a stable trading service with abundant capacity

Снова техническое дело.

Обычному человеку такие объёмы железа недоступны.

Transparency: Increasing market transparency by significantly expanding market data

Околобиржевая штука, снова.

Innovation: Advanced technologies that underpin "arrowhead"

Ну, здесь мне непонятно. У меня нет доступа к этим проблемам, поэтому я могу судить только поверхностно.

Однако, когда мы обсуждали ленивые списки, Влад Балин сказал, что на похожей концепции у них было построено ядро системы просчёта показателей (которые определяют действия на бирже, забыл, как называются). По его словам, в CQG набирали лучших в России программистов на C++, и только примерно 10% понимала смысл происходящего в этом ядре. Программист на Хаскеле знакомится с ленивыми списками на третьем примере в любом курсе по Хаскелю, Чуть более опытный программист на Хаскеле предложит потоковые процессоры и инверсию управления, при этом построение простого варианта Easy Language займёт у него месяц, максимум.

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

И для понимания программы на Хаскеле не потребуется никакого парного программирования.

Имхо, степень программерского оптимизма в этом ответе не просто зашкаливает, она побивает все мыслимые пределы!

Как бы это лучше проиллюстрировать. Ну вот представьте себе, что есть уважаемый человек, который успешно в одиночку строит вот такие мосты (которые строятся лет десять-двадцать, а стоят потом по 300-500):

И вот смотрит он на мост “Золотые Ворота” из Сан-Франциско и говорит, что мол по большей части все это чисто технические вопросы и много чего из этого он бы сделал, да только железа такого обычному человеку взять негде. И вообще, мол, нам, камнеукладчикам, есть что предложить строителям “Золотых Ворот”.

Ну а чтобы эту аналогию прочувствовать получше, вот те самые “Золотые Ворота”:

Ну как, прочувствовали разницу? Думаю, что различия между разработкой моделей процессоров на Haskell-е и рил-таймовой трейдинговой биржевой платформой (как на техническом уровне, так и на организационном) будут не меньше. Поэтому-то и разбор по пунктам новости о возможностях новой системы от Fujitsu с оценками вида “Техническое дело, опять” выглядит даже не смешно, а печально – ведь наш программерский оптимизм и вера в то, что мы все знаем и можем – неистребимы. К сожалению.

PS. В заметке была использована фотография “Чертов мост”  с сайта http://club.foto.ru, автор Галина А.

PPS. Я сам к парному программированию отношусь неоднозначно. Но это уже совсем другая тема :)

вторник, 19 января 2010 г.

[life.art.wow] Марк Эванс вырезает ножом картины на коже

Художник Марк Эванс использует в качестве материала для своих картин кожу, а в качестве инструмента – набор ножей:

Официальный сайт художника: http://www.markevansart.com/

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

В дополнение еще две фотографии, которые есть в интернете, но нет в приведенных выше ссылках:

[comp.prog.flame] Упрощения в презентациях – повторение пути шаттла Коламбия?

После катастрофы шаттла Коламбия в 2003-м мне попалась на глаза статейка, в которой одной из причин называлось широкое использование Microsoft PowerPoint в NASA. Т.е. виноват, конечно, не сам PowerPoint, а использование презентаций в качестве основной формы докладов подразделений и руководству NASA. Презентации, якобы, не позволяли углубляться в детали, а дают только поверхностную картинку. Т.е. подчиненные подсовывали своему начальству красочные презентации, которые начальство хотело видеть. Что и привело с системным проблемам в обеспечении безопасности полетов шаттлов.

Версия, конечно, бредовая. Но негативная роль презентаций, показывающих только “светлую” сторону, определенно есть. Взять, например, презентацию Дона Сайма “Why is Microsoft investing in Functional Programming?”, а в ней картинку на странице 38:

Действительно ли показанный желтым фрагмент на F# является эквивалентом трех страниц на C#?

Как по мне – так нет. Они не эквиваленты ни по выполняемым операциям, ни по объему комментариев в коде, ни по подробности обработки ошибок.

Зато как убедительно преимущество F# выглядит в презентации! ;)

Еще один пример, на этот раз из обсуждавшейся уже здесь статьи “Элементы функциональных языков”. Фрагмент кода из раздела “10. Сопоставление с образцом”, демонстрирующий работу с POP3 сервером:

sendCommand (POP3C conn _) (RETR msg) =
     bsPutCrLf conn (BS.pack ("RETR " ++ show msg))
        >> responseML conn
   sendCommand (POP3C conn _) (TOP msg n) =
     bsPutCrLf conn (BS.pack ("TOP " ++ show msg
                              ++ " " ++ show n))
        >> responseML conn
   sendCommand (POP3C conn _) (AUTH LOGIN user pass) =
     do bsPutCrLf conn (BS.pack "AUTH LOGIN")
        bsGetLine conn
        bsPutCrLf conn (BS.pack userB64)
        bsGetLine conn
        bsPutCrLf conn (BS.pack passB64)
        response conn
     where (userB64, passB64) = A.login user pass

Красиво? А вот пример работы с POP3 сервером из библиотеки POCO:

void POP3ClientSession::login(const std::string& username, const std::string& password)
{
   std::string response;
   _socket.receiveMessage(response);
   if (!isPositive(response)) throw SMTPException("The POP3 service is unavailable", response);
   sendCommand("USER", username, response);
   if (!isPositive(response)) throw POP3Exception("Login rejected for user", response);
   sendCommand("PASS", password, response);
   if (!isPositive(response)) throw POP3Exception("Password rejected for user", response);
}

Ведь тоже красиво, не так ли? Просто, лаконично, функционально. Лепота.

Одна проблема с кодом в POCO – нихрена тайм-ауты он не считает. Поэтому, если по какой-то причине соединение с POP3 сервером “залипнет” (т.е. из него ничего не будет читаться, но и сигнала о потере не будет), то приложение на вызове POP3ClientSession::login() уснет навсегда.

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

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

понедельник, 18 января 2010 г.

[life.work] Как же тяжело иногда оставлять работу на работе

Когда-то я уже жаловался на то, что тяжело переношу размеренный ритм работы (8 часов в день, 5 дней в неделю с двумя “традиционными” выходными в субботу и воскресенье). Пожалуюсь еще раз – блин, сложно заставить себя оставить работу на работе, когда в пятницу вечером понимаешь, что недодумал важную мысль и не родил нужное решение!

Вообще, с выходными интересно получается. С августа прошлого года выходных у меня было мало. А на Новый Год (благодаря работе по российскому календарю) их выпало сразу много. Хотя оказалось недостаточно – не отоспался :) Но стоило только неделю отработать, как первые же выходные наступили очень “не вовремя” :)

Ну и по поводу 8-ми часового дня “от сих, до сих” так же нужно сказать. Когда приходится координировать и оценивать работу других людей, то программировать самому гораздо сложнее. Все-таки я сторонник того, что активность человека в течении суток определяется его (био)ритмами. Я заметил, что у меня есть два периода в течении дня, когда я легко могу погрузиться в состояние потока и когда код (ну или документация) пишутся сами собой. Между ними есть периоды полной апатии, когда вообще ничего не хочется (вот поэтому мне нравиться работать дома – в этот момент лучше всего полежать на диване минут 10-15, сразу восстанавливаешься), есть периоды, когда легко усваивается внешняя информация (в такие моменты хорошо читать документацию или статьи).

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

Отсюда возникает мысль: при переходе к управлению людьми нужно отказываться от программирования. Не уверен на 100%, что она правильная. Но пока я так думаю.

[life] Хорошая байка про хирурга в кафе

Случайно наткнулся (первоисточник):

Один мой хороший друг с Украины рассказал историю.

Он работает хирургом в травме. Точнее, хирургов на смене трое, но в этот день одного срочно забрали на отделение, а другой чем-то притравился и упал под капельницу. Такой вот неудачный день. Обещали дать замену, но... дали какого-то молодого неопытного торакальника. И то хорошо.
И, по закону сами знаете чего, оно пошло. Две аварийки, ножевое и падение с высоты. Четыре тяжёлых трёхчасовых полостных операции, не то, что отдохнуть и пообедать - чашку кофе между переодеванием и мытьём, и то второпях.
Окончив смену хирург вышел на улицу в состоянии, близком к трансу. Ну знаете - глаза не видят, ноги не ходят, голова не думает. Домой и спать. Хотя, сначала зайти в кафешку и что-нить съесть.
На автомате очистив тарелку (что заказывал? Убей, не помню!) хирург был выведен из транса хозяином кафешки.
- Доктор, у вас был тяжёлый день, да? Много операций, да? Выпейте вот сто коньяка, расслабьтесь, обед за счёт заведения, такси я вам вызвал...
Хирург пришёл в себя.
- Ну да, я хирург... и день был тяжёлый... А что, так заметно?
- Да, доктор. Вы когда поели, сказали официантке: "Я закончил. Считайте инструменты и зашивайте." Вы из травмы, да? Я шесть лет на "Скорой" работал, видел такое.

Почему-то хочется верить, что история эта правдивая.

воскресенье, 17 января 2010 г.

[life.photo] Пейзажи Юрия Бондера

В сегодняшней воскресной фотоподборке представлены пейзажные фотографии Юрия Бондера (1967-2008).

Magic Sea............
«Magic Sea............» Средиземное .......
«Средиземное .......» Зимняя Сказка
«Зимняя Сказка» Mediterranean evening........
«Mediterranean evening........» НОЧНОЕ...................
«НОЧНОЕ...................» GOLDEN MORNING
«GOLDEN MORNING» Mediterranean sea
«Mediterranean sea»
****************************
«****************************»
Fire in the Sky
«Fire in the Sky»
Диагонали
«Диагонали»
Осень
«Осень»
 Осень
«Осень»
DUNE
«DUNE»
К А Р Ь Е Р
«К А Р Ь Е Р»
Silence
«Silence»
**********
«**********»

Другие пейзажи замечательного фотохудожника Юрия Бондера можно посмотреть на photosight.ru.

Юрий Бондер оставил после себя большое количество потрясающих фотографий в разных жанрах. Сегодня я ограничился только пейзажами. Но со временем обязательно доберусь и до разделов “Путешествия”, “Природа”, “Ню”, “Портрет” – они того стоят.