суббота, 15 февраля 2014 г.

[life.photo] Прочитал книгу "Школа фотографии Майкла Фримана. Композиция"

Книгу "Школа фотографии Майкла Фримана. Композиция" купил вместе с кучей других книг по фотографии в середине прошлого года. Но руки дошли до нее только сейчас. Прочитал книгу довольно быстро. Текста там не много, зато много фотографий, иллюстрирующих слова автора. Это большое достоинство книги.

Еще одно интересное отличие книг серии "Школа фотографии Майкла Фримана" от других книг этого автора в том, что в ней Фриман местами разбирает фотографии своих учеников. И такие разборы иногда оказываются полезнее, чем текст предшествующей разбору главы. По крайней мере очень радуешься, когда твое впечатление от фотографии совпадает с мнением Фримана.

Что касается ценности книги, то для меня это уже очень сложный вопрос. На книги о фотографии Майкла Фримана я подсел по рекомендации Дмитрия "Гоблина" Пучкова. Книги, действительно, хорошие. В отличии от, скажем, Ицхака Адизеса, Фриман не опускается до копипасты своих собственных текстов. Фотографии хорошие подбирает. "Воды" льет не много, в основном пишет по делу. Но...

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

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

[prog.flame] Хорошая заметка о выборе языка для серьезного проекта от kaa.python

Ув.тов. Александр Ставонин (он же kaa.python) написал хорошую и интересную заметку "Как выбрать язык программирования для нового проекта". Я подпишусь практически под всем, что там сказано (правда, я бы поставил Ruby в один ряд с Python-ом, но это, скорее, мои личные эстетические предпочтения).

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

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

Полагаю, многие молодые разработчики, среди которых особенно много падких на привлекательность экзотики, никогда не читали "Человеческий фактор" ДеМарко и Листера. А зря. Это, вероятно, самая лучшая книга, рассказывающая об основополагающих принципах разработки ПО. И в ней этот феномен успешности первого применения нового инструмента разбирается "по косточкам". Причины успеха при разработке нового проекта на новом языке программирования определяются вовсе не уникальными возможностями инструмента. Основная причина успеха в самой новизне: само по себе использование нового языка дает мощный толчок, мобилизует разработчиков, заставляет напрягаться и стремиться к успеху. Но, когда ощущение новизны уходит и использование нового языка переходит в рутину, все возвращается на свои места. Только, если экзотика не перейдет в мейнстрим, компания окажется в худшем положении. Ибо кадры решают все, а вот с кадрами...

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

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

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

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

Значит ли все вышесказанное, что лично я против внедрения новых инструментов и языков программирования? Нет, не значит :) Но нужно понимать, что погоня за технологическими выигрышами от нового языка сопряжена с высокими рисками. И тут уж вам самим нужно решать, готовы вы рисковать. А заметки вроде этой лишь немного подсказывают степень риска и возможные негативные последствия.

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

Ну а в завершении потока мыслей, вызванных заметкой ув.kaa.python выскажу два моих личных наблюдения о Java и C++ (при этом прошу учитывать, что Java я не люблю еще со времен ее выхода в 1995-м году, хотя при необходимости могу что-нибудь на Java изобразить; а языком C++ я с удовольствием пользуюсь уже более 20 лет):

  • из-за ущербности в своих выразительных возможностях Java заставляет писать больше кода чем на других мейнстримовых языках программирования. Следствием чего, если ваш проект на Java "взлетит", станет постоянный рост кодовой базы и постоянная необходимость увеличения проектной команды. Так что, при всем том, что Java удешевляет получение работающего решения (по сравнении с тем же C++), расплачиваться за это придется большой проектной командой, участники которой будут вынуждены работать с простым (на грани примитивности), но объемным кодом;
  • С++, напротив, имеет возможности делать нетривиальные вещи более компактными и выразительными (если сравнивать с Java). Поэтому, небольшая и сильная команда C++ников способна вести сложный проект на C++, аналог которого на Java мог бы требовать раза в два больше разработчиков. Но тут нужно понимать, что под сложностью понимается именно алгоритмическая и логическая сложность (например, сложные преобразования данных, хитрые структуры данных, изощренные алгоритмы, жесткие требования к ресурсоемкости и т.д.). Если же под сложностью понимается необходимость задействования в проекте целой кучи трех-четырех-пяти буквенных аббревиатур (вроде XML, HTTP, REST, SOAP и т.д.), то ситуация может оказаться прямо противоположной и десять Java-разработчиков легко будут делать работу двадцати C++ников.

Ну и совсем уже напоследок выскажу мысль о том, что по моим наблюдениям "за эфиром" (форумы, статьи, блоги и др. источники) сейчас такие языки, как Haskell и Erlang вполне можно считать мейнстримовыми. И, при наличии достаточного количества разработчиков для формирования проектной команды, я бы всерьез рассматривал варианты применение Haskell-я и Erlang-а наряду с Python/Ruby/Java/C#/C++. Правда Haskell бы я не выбрал из-за того, что чистая функциональность, имхо, вступает в противоречие с объективной реальностью, которую нужно выражать в коде. Ну и из-за некоторой неадекватности его адептов :) А Erlang -- из-за динамической типизации :)

PS. Блог я веду уже давно, понаписал за это время многого. Что дает возможность делать ссылки на самого себя :)
Отлично сказано! Так почему же самые продвинутые языки не попадают в мейнстрим?
Каким же образом знание разных языков делает программиста лучше?
Споры о языках программирования – не могу смолчать

вторник, 11 февраля 2014 г.

воскресенье, 9 февраля 2014 г.

[prog.flame] Не повезло человеку, что уж поделать...

Ну да ничего, он еще, судя по всему, человек молодой. Либо научится чему-нибудь, либо найдет себя в какой-то другой области.

[life.photo] Прослушал мастер-класс "Профессиональная работа со вспышкой"

Прослушал еще один мастер-класс в виртуальной школе Profile. На этот раз это мастер-класс Александра Света "Профессиональная работа со вспышкой". Для интересующихся немного подробностей ниже.
У меня в жизни было несколько волн увлечения фотографией: одна где-то в 1980-1983-м (Зоркий-С), затем в районе 1988 (Зенит-ЕТ), затем с 2003 по 2006 (Nikon F65), последняя волна, уже полностью цифровая, с 2011-го. Но никогда я не учился пользоваться вспышкой. Вроде бы за это время в голове как-то увязались понятия светочувствительности, выдержки и диафрагмы. Что-то понял про оптику. Что-то про условия съемки. Но вот вспышка и ее использование -- это абсолютная терра инкогнита. Поэтому, когда в очередном рекламном письме от Profile я увидел мастер-класс с обещанием рассказать основные вещи о вспышке, то с радостью и энтузиазмом на данный мастер-класс записался.
Сразу скажу, что ожидания мастер-класс оправдал все и более, чем на 100 процентов. Александр Свет в начале мастер-класса сказал, что он хочет сделать такой рассказ, который бы он сам хотел услышать лет 9 назад. И именно такой рассказ он и сделал. Действительно, для начинающих фотографов рассказано и показано все и, может быть, даже больше. Дальше рассказывать бесполезно, материал все равно не будет усваиваться из-за отсутствия практической базы. Дальше нужно просто обкладываться оборудованием и пробовать, пробовать и еще раз пробовать.
По самому мастер-классу могу сказать лишь две вещи. Во-первых, он длился больше трех часов. Почему-то Profile письмо с напоминанием вовремя не прислал и в живую мастер-класс я не слушал, тупо забыл о его начале. Но это было только к лучшему. Воспользовавшись архивом Profile я посмотрел мастер-класс позже, разбив просмотр на три части, каждая приблизительно по часу. И к концу каждого часа было ощущение, что еще чуть-чуть и информация будет уходить мимо меня, я уже не в состоянии буду ее воспринимать. Как люди смогли пережить прямую трансляцию с одним 10-минутным перерывом -- хз. А вот возможность Profile затем смотреть запись в течении двух недель -- это есть рулез!
Во-вторых, когда Александр Свет рассказывает какие-то общие вещи и когда он сопровождает рассказом демонстрацию конкретных приемов -- это как будто два разных человека. В первом случае проявляется некое косноречие, слова-паразиты, повторы, не очень четко выстроенные фразы и на ходу выдумываемые объяснения/примеры. Во втором случае четкая и лаконичная речь матерого проффи. Контраст для меня был разительным. Думаю, что если Александр чуть потренируется, порепетирует и подготовит для себя куски выступлений общего характера, то ценность курса возрастет вообще до невиданных высот. Но это уже, скорее, придирка старого пердуна, нежели критика учебного курса.
В общем, если кто-то хочет узнать основные вещи об использовании вспышке при фотосъемке -- данный мастер-класс обязателен к просмотру. Это тот самый случай, когда пару часов просмотра мастер-класса дадут больше, чем самостоятельное прочтение нескольких книг.
Если говорить о том, что я сам для себя вынес из курса, то это банальные вещи: чудес не бывает, для получения приличных результатов нужно хорошее оборудование и большой опыт. Посему, если я решу развиваться в этом направлении, нужно будет серьезно обдумать приобретение еще одной (а то и двух) вспышек, пары софтбоксов, стоек, и, возможно, радиосинхронизаторов :)

[prog.flame] Какая страшная штука -- этот ваш ООП!

Настолько страшная, что нужно какие-то правила и ограничения для себя выдумывать:

Классы большей частью используются, как модули.

Наследование большей частью одноуровневое. Варианты разбираются через variable as Class.

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

Объекты классифицируются на неизменяемые и IORef-like. Неизменяемые всегда пересоздаются вместо изменений, IORef-like переписывают свое содержимое заново созданными значениями.

Последнее позволяет создавать коллекции, которые можно итерировать, не опасаясь вносить в них изменения.

Иначе, видимо, такая херня выходит... :)

Я, наверное, уже слишком старый и слишком больной на голову человек. Но, думается, лучше всего ООП вообще и использование ООП для проектирования ПО в частности, было описано всего в двух книгах. У Бьерна Страуструпа в его "Язык программирования C++" (если не ошибаюсь, начиная со второго издания там есть несколько глав, посвященных проектированию ПО, в третьем специальном издании они были точно и это было чуть ли не лучшее, что я читал по проектированию с применением ООП). И у Бертранда Мейера в "Объектно-ориентированное конструирование программных систем" (хотя там чуть ли не сразу идет проецирование материала на Eiffel).

Все остальное -- будь то хоть Гради Буч, хоть Алан Кей, хоть еще кто угодно -- все это фигня и пространное изложение богатства внутреннего мира автора.

[life.music] Обалдеть. Гитарист Estas Tonne

Музыкальная композиция почти на 20 минут. Я не смог оторваться от просмотра ни на секунду.

Как народ у него за спиной смог безучастно сидеть в кафе -- не представляю.

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

PS. Ссылки на видеозаписи Estas Tonne был найдены здесь.