суббота, 5 октября 2013 г.

[life.photo] Мысли в слух о мегапикселях и камерах

На днях делал резервные копии снятых в сентябре снимков. Неожиданно для себя обнаружил, что их набралось на 15Gb. Очень порадовался тому, что у меня 12Mpx камера. Была бы 24Mpx, пришлось бы бакапить уже 30Gb. Не говоря уже о 36Mpx.

В этот момент я окончательно перестал переживать, что чуть больше года назад поменял свою кропнутую D90 именно на полнокадровую D700, а не на что-то вроде D800 или D600. Хотя помню, какое разочарование у меня было после анонса Nikon D600. Ведь по деньгам замена D90 и кропнутой оптики на D700 обошлась в приличную сумму. При большом желании можно было бы отжалеть еще немного на D600.

Но время расставляет все на свои места. С 12Mpx D90 и D700 я сделал несколько больших отпечатков. Снимки в размере 60x40см смотрятся вообще здорово. Да даже 120x80см, с учетом того, что такое большое изображение нельзя рассматривать вплотную, вполне спокойно можно напечатать и повесить на стену. Главное стену найти. Оказалось, что самая большая проблема с отпечатками большого формата -- не их качество, а возможность их где-то разместить. В простой квартире возможностей для этого не много :)

Вот и оказывается, что если вы покупаете камеру для себя, для ведения семейного альбома и для фиксации собственных впечатлений, то вряд ли вам придется печатать много фотографий большего, чем 30x20см размера. Да и отпечатков 30x20см будут единицы.

Так что для меня сейчас 12Mpx -- это выше крыши. Думаю, что я бы даже с удовольствием обменял их на 9-10Mpx, так же на полном кадре, но чтобы эти 9Mpx давали больший динамический диапазон и раза в два-три лучшее качество на высоких ISO. Т.е. если бы мне сейчас представилась возможность взять цифрозеркалку с никоновским байонетом, у которой всего 9Mpx, но качество на ISO6400 такое же, как у D700 на ISO2000, я бы не задумываясь поменял бы камеру. Если бы денег хватило, конечно :)

Коль уж разговор плавно перешел на камеры, то могу сказать, что своей D700 я вполне доволен. На удивление удачная модель получилась у Никона пять лет назад. До сих пор вполне себе конкурентноспособна. Что для цифровой техники огромная редкость. Не зря сейчас подержанные D700 стоят почти как новенькие D7100 с более современной начинкой и большим количеством мегапикселей. Но если попробовать сформулировать набор качеств камеры, на которую бы я перешел с D700, то получится что-то вроде:

  • обязательно полный кадр;
  • обязательно никоновский байонет;
  • более светлый и большой видоискатель;
  • фокусировочный экран с клиньями или микропризмами (как на старых пленочных зеркалках);
  • приблизительно такое же количество мегапикселей (плюс-минус 3-4Mpx);
  • гораздо лучшее качество снимков на высоких ISO;
  • обязательно мотор для объективов без оного ("отвертка");
  • быстрый автофокус, в том числе хороший следящий автофокус;
  • обязательно пыле- и влагозащищенный корпус. Размер корпуса не меньше, чем у D700. Можно даже чуть-чуть побольше и с батарейной ручкой.

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

Кроме того, очень похоже, что года через 3-4 ситуация с цифрозеркалками кардинальным образом изменится. Очень уж шустро развиваются беззеркальные камеры. И много хвалебных отзывов мне попадается о топовых Sony Alpha и Olympus-ах (E-M5, E-M1). К тому же беззеркальные камеры намного проще по внутреннему устройству и дешевле в производстве, чем зеркальные. Да и электронный видоискатель (EVF), по отзывам, очень интересная штука. Пока, правда, по скорости EVF сильно проигрывает оптическим. Да и батареи беззеркалки, в том числе из-за EVF, жрут как не в себя. Но прогресс не стоит на месте. И как раз 3-4 лет может хватить, чтобы подтянуть эти параметры до приемлемого уровня. На данный момент ни Nikon, ни Canon не выпускают беззеркалок того же класса, как Olympus E-M1, но это явно лишь вопрос времени.

Из этих предположений я для себя делаю такой вывод. Если и менять сейчас камеру на что-то более современное, то только на самые топовые модели, которые сохранят свою актуальность еще в течении несколько лет. Для Nikon-а это сейчас D800E и D4. Вкладываться во что-то уровнем пониже (тот же D600) или во что-то из DX-вской линейке смысла нет. Определенно, через короткое время они будут сильно проигрывать новым беззеркальным моделям.

пятница, 4 октября 2013 г.

[work] Подумалось про формальные процессы

По ходу спора в ЖЖ ув.тов.grundik всплыли упоминания о PSP/TSP. О PSP читал когда-то давным-давно. Пришлось восстановить в памяти. По ходу дела придумалась интересная аналогия.

Внедрение формальных процессов разработки ПО (например, RUP, PSP/TSP или даже строго соблюдаемый SCRUM) -- это как режим дня и расписание тренировок у спортсменов. Да, подготовленный спортсмен, которого заставляют дважды в день посещать спортзал, уделает новичка. Но когда на старт выходят спортсмены одинакового уровня, то кому достанется победа? В какой степени она будет обусловлена расписанием тренировок или строгостью распорядка дня? И каково будет влияние других факторов?

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


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

Во-вторых, имеющиеся публичные материалы больше наводят на мысль о религии. Ну или о секте. Или о продавцах чудо-таблеток. Сплошные хвалебные речи :) Мол, если следовать PSP, то вы повысите точность своих предсказаний, существенно уменьшите количество дефектов в ПО и пр., и пр. Хотя из заявляемых пунктов этой методики особо не видно, за счет чего это будет происходить. И тут следует возвращение к "во-первых": для познания дзена овладения этим процессом нужно потратить много сил, денег и времени.

В-третьих, если удается отыскать какие-то примеры, то они несколько озадачивают. Вот, скажем, довольно большая и хоть что-то поясняющая о PSP статья. Автор говорит, что благодаря следованию PSP ему удалось существенно сократить количество дефектов в своем коде. Мол, сделав классификацию и разбор совершаемых им ошибок, он предпринял некоторые меры для предотвращения части из них. Например, стал писать end сразу вслед за begin-ом и тем самым совершенно исключил ошибки незакрытых begin-ов. Занавес.

В общем, пришел к мнению, что вещи вроде PSP нужны для тех, кто в прямом смысле сидит на попе ровно. Ничему не учится сам. Ни к чему не стремится. Анализировать результаты своей работы не хочет. Критический разбор своего кода не делает и т.д. В советские времена в больших конторах таких программистов было достаточно. Но сильно сомневаюсь, что кто-то из них на просторах СНГ пережил 90-е годы в профессии. И что к таким можно отнести тех, кто пришел в программирование еще лет 7-8 назад. Хотя, возможно, в больших столичных конторах таких и сейчас можно будет отыскать. Но сама-то методология PSP появилась в Штатах. Там, подозреваю, ситуация несколько другая. И, возможно, для Штатов PSP намного актуальнее, чем для нашего, практически полностью офшорного рынка труда.

четверг, 3 октября 2013 г.

[prog] Online-интервью Андрея Александреску на reddit.

На RSDN нашел ссылку на online-интервью Андрея Александреску на reddit-е. Любопытно. Ниже немного из того, что бросилось в глаза. На всякий случай напомню, что сейчас Александреску работает в Facebook, поэтому это название ниже будет употребляться довольно часто. Да, и свою комментарии я даю в скобках курсивом.

Язык D в Facebook не используется. Александреску собирается предпринять какие-то действия по продвижению D в FB, но как это пойдет и чем закончится, он пока и сам не знает.

Языку D сейчас очень на хватает качественной реализации (что звучит довольно странно, учитывая возраст языка и количество потраченного на него времени и усилий).

Соотношение объемов кода на PHP и C++ в Facebook сейчас порядка 70/30 (т.е. 70% кода на PHP, 30% на C++). Несколько лет назад это соотношение было 90/10 (что меня, как старого C++ника, не может не радовать). Так же в некоторых проектах FB плотно задействована Java.

В Facebook нет отдельного QA подразделения, тестированием кода занимаются сами разработчики. Нет в FB и формализованных процессов разработки. Однако, код должен a) проходить через навороченный lint (статический анализатор кода), b) быть покрыт unit-тестами, c) проходить code review хотя бы одним независимым разработчиком (в обязанности которого входит и проверка наличия unit-тестов для кода). Ну и, прежде чем попасть в продакшен, код проходит через ряд "песочниц" и тестовых стендов.

На вопрос "Что вы думаете о языке Go и чтобы вы оттуда взяли в D" Александреску высказался в том духе, что не будь за Go такого мощного двигателя, как Google, этот язык вряд ли вызвал к себе интерес. А из Go в D он бы взял людей, которые написали для Go библиотеки для работы с сетью :)


Лично я уже давно разочаровался в D. Но сейчас, когда приходится в C++ выдумывать схемы подсчета ссылок на перемещаемые между несколькими нитями объектами, становится жалко, что пока у C++ нет реальной альтернативы. Т.е. нативного языка с такими же выразительными возможностями (шаблоны, множественное наследование, исключения), скоростью работы, поддержкой низкоуровневых вещей, но со сборкой мусора. Так что я не буду разочарован, если в отношении D я ошибусь и силами Брайта и Александреску со товарищи, он таки взлетит когда-нибудь. Хотя к тому времени будет уже намного более удобный для повседневной работы C++18 ;)

среда, 2 октября 2013 г.

[prog.thoughts] Мое мнение о defensive programming

Боюсь, что моя вчерашняя реплика о защищенном программировании могла быть понята не правильно или даже не понята вовсе. Во-первых, из-за того, что defensive programming -- это весьма древнее по современным меркам понятие, которого многие молодые программисты могли даже не слышать. Во-вторых, просмотрев несколько статей на тему defensive programming я увидел, что их авторы, мягко говоря, путают теплое с мягким, приписывают defensive programming выдуманные ими самими проблемы, а потом доблестно их решают и признают defensive programming несостоятельным/вредным. В данной заметке я выскажу единственное верное мнение попробую объяснить свое понимание защищенного программирования.

О защищенном программировании я узнал в 90-м году, причем даже не применительно к языку C (к которому любят привязывать примеры в разговорах о defensive programming), а по отношению к языку Pascal. Так что, во-первых, защищенное программирование -- это общее понятие, которое может быть применено к любому языку программирования. Только вот не в каждом степень успешности этого применения будет одинаковой, о чем я скажу дальше.

Во-вторых, за последние двадцать лет сформировалось достаточно мощное и важное надмножество защищенного программирования, которое иногда называют тем же самым именем, но которое бы следовало называть "защищенное от уязвимостей программирование". Т.е. это техники и инструменты для разработки ПО, призванные не допустить появления в ПО потенциальных уязвимостей, которые могли бы быть использованны злоумышленниками для противоправных действий (как то: захват контроля над удаленной компьютерной системой, кража информации, нарушение работоспособности ПО и т.д.). Для этого направления защищенного программирования есть такие термины, как secure software development, secure development lifecycle. На эту тему намного больше смогут рассказать специалисты по информационной безопасности. И эта тема намного шире, чем простое защищенное программирование, о котором речь пойдет дальше. В частности secure software development уделяет огромное внимание контролю полученной от пользователя информации, тогда как для собственно defensive programming эта проблема не актуальна.

Итак, само по себе defensive programming подразумевает всего лишь три простые вещи:

  1. Диагностирование нарушения контрактов в коде. Говоря простым языком -- это передача некорректных значений аргументов в функции/методы и возврат некорректных значений из функций/методов, а так же нарушение инвариантов (логической и/или физической целостности) объектов.

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

    Гораздо более удачным примером является передача отрицательного значения в функцию sqrt или нуля в качестве делителя в функцию div.

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

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

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

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

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

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

    Специально подчеркну, что если язык программирования не позволяет заявить об обнаруженной проблеме так, чтобы это заявление невозможно было проигнорировать, то нормального использования defensive programming в этом языке не будет.

    Яркий пример -- это приснопамятный C-шный assert. От которого есть польза только в DEBUG-сборках. Но который запросто пропускает ошибки аргументов, возвращаемых значений и нарушения инвариантов в реальной эксплуатации ПО, скомпилированного в RELEASE-режиме. Отчасти этой же проблеме подвержены и механизмы обеспечения Design By Contract в Eiffel (там многие проверки могут быть отключены в параметрах компиляции и повторяется та же история, как с C-шными assert-ами).

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

    Кстати говоря, принцип fail fast вполне может рассматриваться как хорошее воплощение этой практики защищенного программирования.

  3. Воспрепятствование возникновению ошибок. Т.е. использование таких приемов и практик при кодировании (а так же при проектировании), которые исключают целые классы ошибок. Например, если использовать std::vector в C++ вместо ручного выделения памяти под вектора, то устраняется пласт проблем с управлением динамической памятью. Использование механизма RAII (или using в C#, или scope(exit) в D) решает проблему утечек других типов ресурсов. Разумное использование модификатора const в C++ для запрещения модификации объектов. Передача обязательных аргументов по ссылке или по значению, а не по указателю в C/C++. И т.д.

    Какие-то из этих практик/техник могут быть включены в сам язык (например, запрет на уровне языка на объявление переменной без начального значения). Либо же быть частью стандартной библиотеки (см. std::vector, std::unique_ptr в C++). Либо же предоставляться сторонними библиотеками (например, OTL как хорошая обертка над вызовами ODBC).

Само defensive programming, насколько я помню, появилось как средство для контроля за соблюдением программных контрактов. Оно возникло когда стало развиваться структурное и модульное программирование. Разработчик программного модуля мог задекларировать каким-то образом контракт для своего модуля, но не имел механизмов для проверки того, что этот контракт будет соблюдаться теми, кто этот модуль использует. В функции модуля могли поступать неправильные значения из-за программных ошибок в вызывающем модуле, из-за использования устаревшей документации, из-за неправильного понимания задачи. Но самому модулю от этого было не легче. Нужно было как-то указать, что корректные результаты выдаются только при наличии корректных параметров. Для этого и стали пытаться применять defensive programming.

Как раз то, что defensive programming следит только за соблюдением программных контрактов, и является для меня основным водоразделом между defensive programming и secure software development. Допустим, что есть программный модуль, один из методов которого получает строку с параметрами подключения к БД, и использует ее для осуществления цепочки вызовов ODBC-функций. С точки зрения defensive programming метод должен просто убедится, что строка ему была передана, что в ней есть необходимые параметры, что эти параметры должным образом будут извлечены и переданы в ODBC-функции. То, что эта строка может быть получена от пользователя, которому нельзя доверять, и что в ней могут быть какие-то хитрые значения, которые используют некую уязвимость в конкретной версии ODBC-драйвера, с точки зрения defensive programming не важно. Эта проблема должна решаться на каком-то другом уровне, например, в модуле взаимодействия с пользователем. А вот с точки зрения secure sofware development все может быть совершенно иначе. Но, повторюсь, на тему защищенного от уязвимостей программирования лучше выслушать мнение специалистов по информационной безопасности.

На мой взгляд, ключевыми для успешного использования defensive programming являются два первых пункта из трех перечисленных выше: диагностирование и информирование о проблемах. Если эти два пункта должным образом используются, то defensive programming ни в коем случае не скрывает ошибки, как об этом некоторые пытаются говорить. Напротив, defensive programming дает разработчику (именно разработчику, а не пользователю ПО) инструмент для как можно более раннего выявления проблем в run-time.

Однако, нужно понимать, что defensive programming обходится очень недешево. Снабжение программного кода должным количеством проверок увеличивает время разработки. Это точно и, по-хорошему, должно быть очевидно (хотя я не уверен, что все желающие попробовать defensive programming отдают себе в этом отчет). Вставка в код необходимых проверок может сказаться и на сложности разработки. Хотя здесь не так все однозначно. С одной стороны формальная фиксация контрактов для методов/классов/модулей заставляет лучше и глубже их прорабатывать. Но, с другой, облегчается использование уже написанных модулей, т.к. их контракты помогают быстрее понять, каким именно образом модуль должен использоваться, а как его применять ни в коем случае нельзя.

Еще одной вещью придется пожертвовать при использовании defensive programming -- скоростью выполнения кода. Поскольку польза от проверок есть только, если они выполняются. Если же из результирующего кода тем или иным способом проверки изымаются (например, изъятие assert-ов из C/C++ного кода в RELEASE сборках или отключение проверок контрактов в Eiffel), то defensive programming работает только на этапе отладке. В эксплуатации вы вынуждены полагаться на полноту и корректность своего тестирования. Если же проверки в RELEASE-сборках остаются, то скорость исполнения кода с проверками может быть в разы меньше, чем кода без проверок (я проверял это как-то в Eiffel-е, компилируя программу с разным уровнем проверок в коде). Для каких-то задач это может не иметь значения, для каких-то быть просто недопустимым (воспроизведение или перекодирование видео, большие вычисления, криптография и пр.).

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

Затрудняюсь сказать насколько defensive programming актуально сейчас. На мой взгляд, за последние десятилетия акцент сместился на третий пункт из приведенного выше перечня. А именно на средства и инструменты по предотвращению некорректного использования программных модулей/классов/функций. Т.е. разработчики давно пытаются вместо проверки корректности параметров или последовательности API вызовов строить свой API так, чтобы его можно было использовать единственным способом. Например, если ваш API предоставляет класс File, у которого нужно вызвать метод open, а лишь затем использовать методы read/write, то ваш API может быть использован неправильно. В результате ошибки кто-то может вызвать read до open. Может вам было бы лучше сделать класс FileIO, который бы предоставлял только методы read/write и функцию open_file, который бы возвращал FileIO. Т.е. когда нет открытого файла, то не у кого вызывать read.

Сюда же идут различные языковые возможности, которых не было 30-20 лет назад. Такие, как конструкции using в C# или scope(exit) в D. Сюда же поддержка константности и иммутабельности для объектов. Да та же поддержка исключений, которая известна уже давно, но которую в том же C++ до сих пор упорно игнорируют (а в новом Go пытаются изобрести какую-то ущербную замену). Сюда же можно добавить и проникновение в массы функционального программирования, соответствующих языков и используемых там приемов контроля за наличием побочных эффектов (или же паттерн-матчинг с контролем за обработкой всех вариантов).

Сюда же можно добавить и различные верификаторы ПО. Хотя, насколько я помню, серебряную пулю там давно уже никто не обещает :)

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

PS. Не могу не сказать про ублюдочность некоторых аргументов о том, что defensive programming якобы позволяет защищаться от сбоев в аппаратуре. Мол, если вы запишете обход строки так: for(size_t i=0;i<strlen(s);++i), то это будет надежнее, чем если вы запишете условие входа из цикла через неравенство: (i!=strlen(s)). Мол, если случайна элементарная частица прошьет микросхему памяти и вызовет установку случайного бита в i, то первый вариант окажется устойчивым к данному сбою, чем второй. Бред. Я не уверен, что даже разработчики софта для космических аппаратов или для промышленных компьютеров, работающих в условиях повышенной радиации заботятся об этом. Кроме того, допустим, что эта частица не увеличит, а напротив, уменьшит значение i. И ваш код в обоих вариантах проделает несколько лишних итераций. Спасет ли от этого defensive programming и какой-либо из способов записи условия в таком цикле? :)))

вторник, 1 октября 2013 г.

[prog.wow] Еще претендент на увековечивание в бронзе

Найден здесь. Сразу предупреждаю: указанную статью лучше не читать. Пожалуй единственное, что в ней есть толковое -- это рассуждение о не очень четком определении термина Defensive Programming (за которым в русском языке давным-давно закрепилось определение "защищенное программирование"). Ну а теперь сам перл:

Защитное программирование скрывает от нас наличие багов

Прочитав такое хочется настоятельно порекомендовать ресурсу dev.by взять к себе в штат вменяемых редакторов, не публиковать у себя больше таких материалов и уж тем более не давать на них ссылки в своих еженедельных дайджестах "самого интересного". Не нужно скатываться в совсем уж полное говно.

понедельник, 30 сентября 2013 г.

[life.cinema] Очередной кинообзор (2013/09)

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

Риддик. Фильм для поклонников истории о Риддике. Поскольку к сим можно, отчасти, отнести и меня, то фильм мне понравился. Далеко не шедевр, конечно, да и подзатянут местами, но в целом достойное продолжение "Черной дыры".

Два ствола. Можно один раз с удовольствием посмотреть ради отдыха, с выключенными мозгами.

Ангел-хранитель. Местами очень неплохо. Местами примитивно, предсказуемо и нереалистично. Ну а финал просто обязан был быть драматичнее, но не смогли.

Мальчишник: Часть III. Мне показалось, что это вообще какой-то другой фильм, лишь за уши притянутый к двум предыдущим частям. Средней руки комедия на один просмотр. С первой частью не идет ни в какое сравнение.

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

Тепло наших тел. Довольно забавная романтически-мелодраматическая история про зомби для молоденьких девушек.

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

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

Незнакомцы. Не смотря на участие Лив Тайлор, фильм -- унылое говно. А от тупости поведения главных героев иногда начинают болеть зубы.


В завершение предостерегу от двух фильмов, в которых оказались задействованы не самые плохие в прошлом актеры. Но мое терпение при просмотре закончилось где-то на 15-20 минутах фильмов, так что ни один из них я досмотреть не смог. Это "Кровь искупления" (Дольф Лунгрен, Билли Зейн, Винни Джонс, Роберт Дави) и "Наемный убийца" (Гэри Бьюзи, Кристианна Локен). Кстати, кроме прочего эти фильмы, похоже, демонстрируют то, что эффективные менеджеры со своими способностями резать косты добрались и до кинопроизводства. Это раньше нужны были профессиональные приротехники и гримеры, которые организуют стрельбу холостыми патронами, взрывы, рикошет пуль от стен, попадание пуль в тело и потоки крови из ран. А сейчас все это можно передать на аутсорсинг какой-нибудь заштатной фирмочке по компьютерным эффектам где-то в развивающейся стране. Итог получается на редкость убогим. Очень убогим я бы сказал. Единственное удовольствие -- это представить себе, как Дольф Лунгрен бегает по съемочной площадке с игрушечным пистолетом и для имитации выстрелов приговаривает "Пуфф-пуфф-пуфф, пафф-пафф-пафф" :)

воскресенье, 29 сентября 2013 г.

[life.photo] Велогонка по пересеченной местности "На взлет" 2013

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

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

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

Погода так же радовала :) Пасмурно, дождик, опять пасмурно, опять дождик, Солнышко, ливень, опять Солнышко, ливень с градом :))

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

Ну а теперь, собственно, основная цель поста. Фотографии. Все получившиеся фотографии собраны в этом альбоме

Всех интересующихся гомельским велоспортом сразу адресую туда, там больше двухсот снимков.

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