[life] Погода заставляет вспомнить детство и молодость :)

Сейчас на улице настоящая зима – морозец, снега по колено, сугробы выше пояса, заснеженные елки, покрытые инеем деревья – лепота! Почему-то из детства остались воспоминания, что раньше так было всегда. Как выпадет в середине декабря снег, так и лежит до середины марта. Обычная температура – 10-5 градусов мороза, иногда ниже 15, иногда около нуля.

Вот и в этом году сначала снега навалило и мороз под 25 градусов стукнул. Потом, правда, все растаяло, но снега опять привалило. Настоящий Новый Год получается. Как в детстве ;)

В последний раз такой Новый Год, как мне помнится, был где-то в середине 90-х. Был морозчик градусов 15, снег скрипел под ногами. Я тогда к куму на работу вечером заехал, и мы с ним топали по заснеженным дорожкам в магазин (как водится, за шампанским и водкой), а потом ехали в промерзшем троллейбусе :)

А какие раньше были традиции на работе по встрече Нового Года! :) 30-го, а то и 29-го декабря накрывался стол, гудели все отделы. Старые сотрудники ходили в гости друг к другу – от нашего стола к вашему столу ;) Где-то к концу вечера можно было оказаться за одним столом с главным инженером, а то и с генеральным директором :)

Хорошее было дело – корпоративная пьянка за рабочим столом! Не то, что нонче – официальный корпоратив, в ресторане, всей толпой, да еще с супругами… Атмосфера не та! Нет того командного духа, который формировался под хмельные разговоры о том, что и как мы будем делать в будущем году ;)

А 31-го декабря, обычно, на работу ездить не нужно было. Программисты же не продавцы, все проекты к этому времени уже закрыты. Так чего на работе сидеть? Разве что здоровье подправить :)

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

А сейчас уже не то… Другие времена. Вот, сижу на работе. Трезвый. Пытаюсь работать. Вокруг меня такие же бедолаги. Трезвые. Тоже делают вид, что пытаются работать. :) И как-то живо реагируют на намеки о том, что магазин-то рядом ;)

В общем, Новый Год на дворе. Хватит в Интернете сидеть, чужие блоги читать и свои писать, пора праздновать!

С Новым Годом!

PS. Фотографии сделаны мобильным телефоном сегодня рядом с офисом. На обратном пути из магазина ;)

[comp.prog.flame] Почему мне не понравилась статья “Элементы функциональных языков”

Выполняю обещание, данное в предыдущей заметке, и пытаюсь объяснить, почему мне не понравилась статья Евгения Кирпичёва “Элементы функциональных языков”. Если коротко, то тремя вещами:

• не соответствием поставленной цели и содержимого статьи;
• стилем статьи и
• приведенными в статье примерами.

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

Поставленная цель и содержимое

Во введении указывается, какую цель преследует автор:

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

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

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

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

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

Стиль статьи

Стиль статьи не понравился мне тремя вещами.

Во-первых, восторженными эпитетами. Такие речевые обороты, как:

В статье-«жемчужине» «Generic descrimination: sorting and partitioning unshared data in linear time» Фрица Хенгляйна…

Ralph Hinze, «Fun with Phantom Types» ([75]): превосходный обзор, описывающий: язык…

Ralf Hinze, Johan Jeuring, и Andres Löh, «Typed Contracts for Functional Programming» ([76]): интереснейшая статья…

…а также в потрясающей диссертации Нила Митчелла «Transformation and analysis of functional programs»…

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

Во-вторых, подача материала с отсылками читателя к будущим разделам, для меня оказалась сложной для восприятия. Например, в разделе 5.7 упоминается какая-то система уравнений, которая будет обсуждаться только в разделе 5.10. А в разделе 5.9 дается рекомендация читателю поискать материал самостоятельно где-то в разделе 5.11:

Для всякого алгебраического типа определена чрезвычайно общая операция свертки (см. 11), абстрагирующая способ вычисления «по индукции» (снизу вверх) над значениями такого типа. Предлагается обратиться за разъяснениями к соответствующей подстатье.

При том, что раздел 5.11 так же не маленький и более точное указание места, на которое следует обратить внимание, мне бы лично не помешало.

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

В программировании данная идея впервые появилась, вероятно, в конкатенативных языках, таких как FORTH.

Вот вы раньше слышали о конкатенативных языках? Я нет.

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

Ну а главное в стиле автора – это “заумность” текста. Это проявляется как в подаче материала (скажем, главу о свертках я так и не понял, еще хорошо, что о foldl и foldr я читал раньше и имел опыт их использования в Scala), так и в отдельных фразах.

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

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

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

Monoid — класс типов, чьи значения образуют алгебраическую структуру «моноид» (см. статью «Моноиды в Haskell и их использование» (Дэн Пипони, перевод Кирилла Заборского) [137], а также презентацию Эдварда Кметта «Introduction to monoids» [98]), т. е. на значениях определена бинарная операция «комбинирования»:
mappend :: (Monoid m) => m -> m -> m
А также задан «нейтральный элемент» mempty :: (Monoid m) => m, являющийся единицей для mappend); а также похожий класс MonadPlus;

Ну и еще пара придирок по стилю:

• видимо, каждый раздел статьи раньше был самостоятельной статьей. Поскольку после их объединения в одну большую статью в тексте так и остались фразы вида “Часть способов имитации замыканий описана в статье о функциях высшего порядка (см. 3).” Это создает впечатление некоторой халтурности, т.е. отдельные статьи объединили в качестве разделов, но не изменили способ именования соседних частей большой статьи;
• лично меня напрягает, когда автор в тексте ссылается на свои собственные статьи в третьем лице: “см. статью «Изменяемое состояние: опасности и борьба с ним» Евгения Кирпичёва [180]”. Может это вполне допустимо и нормально, но меня раздражает.

Примеры кода в статье

К примерам кода в статье есть три претензии.

Во-первых, слишком большое количество языков было использовано для иллюстраций. Если не ошибаюсь, то в статье использованы: Haskell, Scheme, Python, C, Java, Matematica, Erlang, РЕФАЛ. Для меня это явный перебор. Для того, чтобы показать принципиальные элементы функциональных языков достаточно было бы использование всего лишь одного языка. Того же Haskell, к примеру.

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

• фрагмент кода для балансировки “черно-белых” деревьев (раздел 5.10):

     balance :: Color -> Tree a b -> (a,b) -> Tree a b -> Tree a b
     balance B (T R (T R a x b) y c) z d
       = T R (T B a x b) y (T B c z d)
     balance B (T R a x (T R b y c)) z d
       = T R (T B a x b) y (T B c z d)
     balance B a x (T R (T R b y c) z d)
       = T R (T B a x b) y (T B c z d)
     balance B a x (T R b y (T R c z d))
       = T R (T B a x b) y (T B c z d)
     balance color a x b = T color a x b

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

     toUnixMillis :: String -> Integer
     toUnixMillis s = case (parseDate "YYYY/MM/DD hh:mi:ss" s) of
       Date y mon d h m ss -> ss + 60*m + 3600*h + ....

  Вот интересно, почему параметру ss (это секунды) не было дано имя s, по аналогии с параметрами d, h, m? Потому, что имя s уже занято? А до имени sec не удалось додуматься? Или же это экономия на спичках? За такой код своему подчиненному я бы устроил выволочку и заставил бы переписать, например, так:

     toUnixMillis :: String -> Integer
     toUnixMillis strDateTime = case (parseDate "YYYY/MM/DD hh:mi:ss" strDateTime) of
       Date year mon day hour min sec -> sec + 60*min + 3600*hour + ....

В-третьих, я не понял, зачем был приведен ряд примеров. Скажем, примеры на языке пакета Mathematica в разделе 10. Может быть они интересны изучающему этот пакет, но не мне. Или, к примеру, фрагмент из раздела 9:

   data JSValue = JSNull
                | JSBool Bool
                | JSRational Bool Rational
                | JSString JSString
                | JSArray [JSValue]
                | JSObject (JSObject JSValue)

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

Ну и другие непонравившиеся мне моменты

Здесь я приведу некоторые фрагменты статьи и реплики, которые у меня вырвались, когда я их читал.

Тем не менее, в течение очень долгого времени в силу ряда трудностей реализации (см. секции «Имитация» и «Реализация») «промышленные»-языки предоставляли крайне ограниченную поддержку функций высшего порядка.

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

Из-за некоторой путаницы с тем, что понимать под порядком функции при наличии каррирования (считать ли isAsubstringOfB функцией второго порядка из-за того, что результат ее применения к одному аргументу — функция первого порядка типа String -> Bool?), иногда порядком функции считают глубину самой вложенной слева стрелки: ниже приведены три типа, соответствующих функциям первого, второго и третьего порядков.

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

Таким образом, идея замыканий появилась еще до появления программирования, в момент создания лямбда-исчисления — в 1930 гг.

Существует мнение, что программирование появилось несколько раньше 1930 года, как попытка создания вычислительных программ для машины Бэббиджа. Не случайно первым программистом считают Аду Ловлес. Так что замыкания вряд ли появились еще до программирования :D

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

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

вообще говоря, алгебраические типы намного лучше подходят для описания структур данных и позволяют намного естесственнее записывать алгоритмы их обработки (при помощи сопоставления с образцом (см. 10)), чем структуры (записи) или объекты

Такое мощное утверждение нуждается в доказательстве.

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

Старые страшилки для маленьких детишек.

Что еще?

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

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

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

Итого

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

[comp.prog.flame] Краткие впечатления от статьи “Элементы функциональных языков”

В третьем номере журнала “Практика функционального программирования” опубликована большая статья Евгения Кирпичева “Элементы функциональных языков”. Хочу поделиться парочкой впечатлений, пока кратко.

Самое важное – это то, что я, похоже, понял, почему ФП до сих пор не попало в мейнстрим. Ведь, в принципе, в тех самых элементах функционального программирования нет ничего сложного. Многие из них можно объяснять буквально на пальцах. Но!

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

Во-вторых, функциональные языки по своему синтаксису очень и очень сильно в стороне от мейнстримовых C- и Pascal-еподобных языков. А нужно-то всего-ничего:

• обернуть возможности Haskell/OCaml в привычный большинству C-подобный синтаксис;
• отказаться от использования однобуквенных имен и имен с черточкой. Вместо:

  curry f = f'
       where f' x y = f (x,y)

  писать по-человечески:

  curry func = carriedFunc
       where carriedFunc x y = func (x,y)

• таки понять наконец, что скобки и запятые при вызове функций нужны! Поскольку при взгляде на:

  a = f x y * g z w

  должно быть сразу понятно, что это:

  a = f(x, y) * g(z, w)

  а не

  a = f(x, y * g, z, w)

  или

  a = f(x, y) * g(z(w))

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

В общем, пока развитием функциональных языков будут заниматься ученые-математики, ничего в мейнстриме им не светит. Зато, если какой-нибудь программист-практик засунет часть возможностей Haskell-я в C++/C#/D/Java/you-name-it – вот это будет прорыв.

Кстати, поэтому я не очень верю в шансы Scala – ведь его разрабатывают как раз таки академические ученые ;)

А сама статья мне не понравилась. Но об этом, с конкретными цитатами, в ближайшие дни.

[life.humour] Мама, а почему дятлы – это…

Хороший вопрос дочка вчера задала на прогулке по лесу. Но чтобы ее понять, сначала анекдот:

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

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

Вот и вчера, гуляя по лесу, сначала обнаружили одного, а чуть позже и второго дятла. Увидев второго я сказал: “А вот и еще один мой родственничек!” На что дочка спросила у жены: “Мама, а почему дятлы – это папины родственники?”

У меня истерика длилась минут пять. Потом я вспомнил еще один анекдот:

ГАИшник подходит к только что остановленной машине, представляется, берет у водителя документы на проверку. В этот момент с заднего сидения раздается детский голос: “Папа, а где же козел?”

Почему-то теперь я думаю, что это не анекдот, а реальная история :)

[life] О том, каких людей больше не делают

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

Однако, поскольку одной из причин возникшего спора является моя фраза “Мне кажется, что людей, способных в наше время воздвигнуть что-нибудь подобное, уже не делают… В нашей стране, по крайней мере”, то мне следует объяснить, что под этим понималось.

Прежде всего я бы вывел из разговора обсуждение большевиков и советской власти. Потому, что своими достижениями я в очень большой степени обязан именно советскому строю. Бесплатное образование, бесплатная медицина, бесплатные кружки и спортивные секции, бесплатные спортивные, пионерские и трудовые лагеря, бесплатные поездки по СССР… Если бы большевики не взяли власть в 17-м, перспективы моих родителей (из простых и весьма небогатых семей), да и меня (сына простого рабочего и служащей) были бы на уровне негров и латиносов из обсуждавшейся недавно американской школы. Да и вообще вряд ли я был, поскольку, Царская Россия (если бы она осталась) во Второй Мировой бы не выжила.

Это для меня главный и незыблемый постулат. Все остальное идет в лес, как недоказуемое. Равно как и сказки о великой американской мечте или о равных шансах на успех в условиях капиталистического общества. Трындеж. Те самые благополучные западные капиталистические страны развивались в условиях махрового капитализма (да еще неслабо качая ресурсы из своих заморских колоний) в течении нескольких столетий. Тогда как Россия отменила крепостное право всего лишь 150 лет назад.

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

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

Имхо, в России на рубеже XIX-XX веков власть не справилась со своими задачами. Революционеры, вооруженные учениями Маркса-Ленина (в качестве нового опиума для народа), захватили власть и заменили правящую элиту. Затем правящая элита достаточно сурово, но эффективно защитила сама себя (как от оказавшихся не у дел остатков прошлой элиты, так и от профессиональных революционеров, отлично умеющих свергать власть, внутри самой себя).

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

А что означают все эти изменения, все эти большие стройки? Это означает, что власть тогда делала вложения в начинания, результаты которых должны были сказаться только через десятилетия. Взять хотя бы подготовку ученых и инженеров. Ведь сначала человек должен пойти в школу, затем в ВУЗ, затем в аспирантуру – а это годы трат государства на человека до тех пор, пока начнется обратная отдача. И ведь трат не на одного человека, а на десятки тысяч, чтобы из них затем отфильтровать неучей, среднюю массу и, наконец, самых-самых.

А что означает, например, строительство такого объекта, как Саяно-Шушенская ГЭС? Сначала годы на изыскательские работы, затем годы на проектирование и подготовку к строительству, затем годы на само строительство, затем годы на пуско-наладочные работы. Т.е. обличенный властью ответственный работник, принимающий решение о строительстве такого объекта, не имел шансов увидеть плоды своего решения (поскольку на таком посту вряд ли мог оказаться 30-ти летний).

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

Но потом в Союзе власть начала деградировать, противоборствующий ей активный элемент – напротив, усилился. Итогом стала перестройка и распад СССР. Власть сменилась (точнее, сменяется до сих пор). И при этом новая власть не демонстрирует способности принимать долгосрочных решений. Складывается впечатление, что ее основная задача – это латание сиюминутных дыр и получение быстрых дивидендов. А после нас, хоть потоп…

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

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

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

[comp.prog] Ruby 1.8.7-p248

25 декабря было выпущено обновление версии 1.8.7 языка Ruby. Это обновление исправляет ряд ошибок в ветке 1.8.7, подробнее можно посмотреть в ChangeLog. Публикую эту новость с некоторым запозданием после того, как стали доступны бинарники под Win32.

Исходники: http://ftp.ruby-lang.org/pub/ruby/1.8/ruby-1.8.7-p248.tar.bz2
Бинарники под Win32: http://ftp.ruby-lang.org/pub/ruby/binaries/mswin32/ruby-1.8.7-p248-i386-mswin32.zip

[life.photo] Фотографии природы от Владимира Сковородникова

Владимир Сковородников – один из монстров (в хорошем смысле этого слова) сайта PhotoLine.ru (вот его фотографии на этом сайте). А еще это один из немногих (как мне кажется) хороших российских фотографов, у которого есть собственный сайт – http://skovorodnikov.ru, откуда и взяты приведенные ниже фотографии.

[life.video.wow] Вирусный рекламный ролик SIGNS

Конец года хорош тем, что появляются различные обзоры и сборники “10 лучших/худших … уходящего года”. В данном случае это оказался сборник 10 лучших вирусных рекламных роликов 2009 года с YouTube. Один из них понравился мне настолько, что я решил опубликовать его у себя.

Во-первых, поскольку очень удивительно, что 12-ти минутное видео в качестве рекламы – это весьма необычно. Тем более, что оторваться тяжело.

Во-вторых, поскольку тема в нем затронута достаточно важная. Когда я был холостым, я очень не любил вопросов “Ну а ты когда женишься?” Теперь я сам смотрю на своих холостых коллег, с которыми работаю уже не первый год, и с трудом удерживаю себя от этого же вопроса. Причем понимая, что для некоторых из них самое сложное – это познакомиться с девушкой. А тут такая красивая романтическая история… Лепота!

[life.cinema] Очередной кинообзор

Предложение. Хорошая, добрая и сентиментальная комедия.

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

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

Турнир. В 97-м году вышел фильм Крутые стволы – чистое, незамутненное каким-то смыслом мочилово. Спустя 12 лет выходит его реинкарнация – Турнир. Такое же чистое, незамутненное мочилово. Если хочется отключить мозги и посмотреть на перестрелки и драки, то Турнир очень для этого подходит.

Бесславные ублюдки. Снято, конечно, мастерски. Тарантино мастер диалогов и диалоги в фильме играют самую важную роль. Но не понятно, зачем он был снят. Когда по мотивам Второй Мировой снимают комедии (Большая прогулка, Дачная поездка сержанта Цыбули) это еще понять можно. Но когда делают фильм с претензией на серьезность, но искажают в нем реальную историю – это мне не нравится. В итоге отлично сделанный бессмысленный фильм.

Битва у красной скалы и Битва у красной скалы 2. Масштабный исторический китайский фильм. С батальными сценами. В том числе и в духе "одним махом семерых побивахом", когда какой-нибудь былинный китайский богатырь в одичночку мочит десятки противников. Для юных зрителей, имхо, вполне приличный фильмец. Так же закрадываются опасения, что если развитие китайского кино пойдет так и дальше, то скоро в Китае будет производиться не только весь мировой ширпотреб, но и большая часть новых фильмов.

Ведьма из Блэр (The Blair Witch Project). Посмотрел под влиянием шума вокруг "Паранормального явления". Мол, уникальный ужастик, снятый всего за $60K и собравший несколько сотен миллионов. Уникальная муть и скука. Зрителей мастерски развели.

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

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

Плохой лейтенант. Фильм 2009-го года с Николасом Кейджем, Вэлом Килмером и Евой Мендес в главных ролях. Муть редкая, да еще и идет почти два часа.

Аватар. Фильм своим исполнением ошеломляет. Хочу дождаться появления его на BluRay и пересмотреть еще раз. После просмотра у меня возникло сожаление о том, что фантастика уже не увлекает меня так, как 10 лет назад. Но и это не мешает мне считать, что Аватар переплюнул все вышедшее в последнее время (включая Трансформеров, Терминаторов и 2012).

[life] Пять операций в день в 70 лет и персональная фотовыставка в 92 года. Завидую белой завистью

Программирование – это достаточно специфическая профессия. 18-ти летний пацан, только что освоивший азы Ruby (PHP или C#) может программировать гораздо лучше 40-летнего дядьки с 20-летним стажем. Плюс специфика профессии такова, что постоянно приходится держать “нос по ветру” и осваивать “новые” технологии. Плюс время от времени возникают разговоры о том, что после 30 (35, 40, 45…) в программировании жизни уже нет – либо толковый разработчик уходит в менеджеры, либо он из толкового программиста превращается в старого пердуна. Достоверность подобных утверждений находится сильно ниже плинтуса, но периодичность таких разговоров на мозги все-таки капает.

На прошедшей неделе довелось обратить внимание на нескольких людей. Поразил меня их возраст и то, что в своем возрасте они умудряются делать.

Во-первых, Джеймс Кэмерон, которому 55 лет, и который через 12 лет после “Титаника” (самого успешного фильма всех времен и народов) выпустил “Аватара”. В принципе, для художника (режиссера) 55 – это не много. Но меня другое восхищает: отношение Кэмерона к фантастике. Очевидно, что она ему нравится. Тогда как я сам, чем старше становлюсь, тем равнодушнее воспринимаю фантастическую литературу – уже не торкает. А вот Кэмерона до сих пор торкает. Да так, что он создает такое ошеломляющее творение, как “Аватар”!

Во-вторых, 22-го декабря исполнилось 70 лет кардиохирургу Лео Бокерия. Человек проводит в день по 3-5 операций! В своем интервью АиФ академик Бокерия привел пример других кардиохирургов:

Выдающиеся хирурги Майкл Дебейки и Фёдор Григорьевич Углов оперировали до последних лет жизни, хотя Майкл ушёл, не дожив двух месяцев до своего столетнего юбилея, а Фёдор Григорьевич — в возрасте 105 лет.

Блин, если вдуматься в это: человеку 70 лет, а он проводит по 5 операций в день, в каждой из которых нужны и точность рук, и опыт, и чутье, и большое желание заниматься этим делом!

В-третьих, на этой неделе я узнал о персональной выставке Вадима Гиппенрейтера «Заповедная Россия». А ведь ему уже, вдумайтесь, 92 года! И ведь он продолжает снимать! (Фотографии Вадима Евгеньевича можно посмотреть на его сайте или на PhotoSight.ru – посмотреть есть на что.)

Такие вот дела. В завершение хочу процитировать фразу Лео Бокерия:

«Уходить в запас» раньше времени обидно — американские кардиохирурги только начинают самостоятельную работу в 37 лет.

Оно как! ;) Остается надеяться, что со временем 40-50-60-70 летние программисты будут котироваться так же, как и кардиохирурги ;)

[life.photo.wow] Вот это туман!

Дубай, 21-е ноября 2007:

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

[life.photo] Фотографии Саяно-Шушинской ГЭС

Вот здесь:

1. Саяно-Шушенская ГЭС (История строительства)
2. Саяно-Шушенская ГЭС (Внешний вид)
3. Саяно-Шушенская ГЭС (Гребень плотины)
4. Саяно-Шушенская ГЭС (Машинный зал)
5. Саяно-Шушенская ГЭС (Береговой водосброс)

С чего все начиналось:

Как строилось:

И что было построено:

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

[life.humour] Классный рекламный ролик (забрать рыбу у медведя)

Видел когда-то по телеку только его самый финал. А сегодня случайно наткнулся в Интернете:

[comp.prog.politic] Разные мнения об использовании OpenSource

Сначала мне попалось интервью с Йон фон Течнер, одним из основателей и главой Opera Software (компании, выпускающей замечательный бесплатный браузер Opera). Где он высказал свое отношение к OpenSource:

Q. Что вы думаете по поводу Open Source, который, например, исповедует Mozilla? Какие преимущества и недостатки у этого подхода?

A. Открытый код подразумевает возможность внесения изменений сторонними разработчиками. Но многие глобальные процессы в таком случае не смогут работать нормально. Я не против идей Open Source и отчасти сам ее сторонник, но наш код останется доступным только для наших программистов.

Q. Почему?

A. Здесь есть два момента. Во-первых, бытует мнение, что открытый код является залогом успеха, но можете ли вы назвать хоть одного успешного разработчика браузера с открытым кодом? Код Firefox открыла Netscape, и теперь этой компании, как и браузера, нет на рынке. Safari тоже построен на открытом ядре WebKit, однако многие даже не знают, кто его автор. А ведь это проект KDE – компании, которая в итоге не получила за свой продукт ни славы, ни денег. Во-вторых, мы работаем над более чем 150 проектами одновременно. Это очень сложная организационная задача, поэтому необходимо быть уверенным, что каждый из них будет функционировать одинаково и развиваться в едином русле. В свое время я и сам занимался Open Source и знаю эту кухню изнутри. Очень сложно координировать работу людей, которые не слишком хорошо отделяют общие задачи от частных. Как следствие, много времени уходит на корректировку ошибок. Мы этого себе позволить не можем.

Фанатичным приверженцам OpenSource читать такое, вероятно, очень неприятно. Однако, я думаю, что Теченер таки прав. Одно дело – использовать в своем проекте куски OpenSource проектов. Совсем другое – вести свой проект посредством OpenSource разработки.

Потом в Dr.Dobb’s Journal появилась интересная статья “9 Ways To Avoid Open Source Pitfalls”, в которой мне понравились советы №1 и №4. Совет №1 прост – когда появляется желание связаться с OpenSource, то нужно спросить себя “Зачем”. Тогда как многие спрашивают “А почему нет?” Автор статьи говорит, что использование OpenSource не уменьшает затрат на разработку, а заставляет перераспределять затраты по-другому. (eao197: Грубо говоря, если раньше вы должны были потратить 3 человеко-месяца на разработку нужной вам библиотеки для SMTP, то теперь вы потратите те же самые ресурсы на интеграцию в свой продукт готовой OpenSource SMTP библиотеки.)

Но для меня самым важным оказался совет №4, который говорит, что вам нужно определиться со стратегией собственных вложений в используемое OpenSource ПО. Т.е. если вы взяли OpenSource компонент в свой проект, то вам нужно четко понимать, как вы будете помогать развитию этого компонента. Например, только информирования о найденных багах может быть недостаточно, нужно еще предоставлять патчи для их исправления. А это уже контрибуция. И раз вы начинаете контрибуцию собственного кода в (по сути чужой) проект, то кто будет в дальнейшем нести ответственность за внесенные вами изменения? По хорошему, это должны быть вы.

Такая постановка вопроса стала для меня откровением. Поскольку до сих пор я придерживался простого принципа – если кто-то начал свой OpenSource проект, то он сам себе злобный Буратино. Это было его решение, он выбрал такую форму развития проекта. Путь теперь сам несет свой крест. Если я нахожу баги, я о них сообщаю. Если при этом я вижу, как их можно исправить – я готовлю патч или просто описание своего решения. На этом все, мое участие заканчивается. Нести пожизненную ответственность за предложенные изменения я не хочу. Хотел бы – написал собственную реализацию, создал бы еще один home grown проект, еще одно проявление NIH-синдрома, и сопровождал бы его. Заодно была бы хорошая гарантия от прихотей работодателя – попробуй уволь меня, если большая половина кода написана мной и мной же сопровождается ;)

Поэтому я считал, что если я присылаю какой-то код разработчикам OpenSource проекта и они включают его в проект, то далее ответственность за его развитие лежит уже не на мне. А вот согласно совета №4 в упомянутой статье получается, что я не прав.

Сразу хочу сказать, что OpenSource сейчас – это очень масштабное явление. И я имею дело с очень небольшой его частью. В основном – это использование OpenSource библиотек в своих проектах (ACE, PCRE, Crypto++, OTL, POCO, libcurl, gSOAP, SQLite). Здесь ситуация одна. А вот если взять, скажем, Linux, который разные фирмы и корпорации затачивают под свои нужды, там ситуация будет уже другой. Ведь если какой-нибудь Google модифицировал ядро под себя, то было бы логично, если бы именно Google развивал дальше свои модификации, а не перекладывал ответственность на плечи остальных разработчиков ядра Linux.

Так что, возможно, совет №4 относится как раз к таким масштабным OpenSource проектам. Хотя даже в случае простого использования OpenSource библиотек к нему все же следует прислушиваться. Поскольку разработчики OpenSource проектов могут именно так к вашим модификациям и относиться – вы исправили, вы и отвечайте теперь за свои исправления.

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

[life.painting.wow] Трехмерная картина на стене

Трехмерные рисунки на асфальте стали уже привычными. Но, оказывается, есть и трехмерные картины на вертикальных стенах!

Найдено в блоге “Обратная сторона реальности”

А вот еще:

Две приведенные выше фотографии из Квебека.

Вот эти из французского Лиона:

Это Канны:

Это где-то в Германии:

Это в Торонто:

Перечисленные выше фотографии (а также многие не перечисленные) были найдены здесь.

Ну а тем, кто хочет еще:

Сайт художника Eric Grohe
Подборка похожих фотографий в DailyMail (сильно рекомендую – тут фотографии хорошего качества и половина Интернета их потом у себя перепечатывает)

[life] Happy Birthday My Blog!

Вот так, тихо и незаметно, подкрался маленький праздник – исполнился первый год моему блогу. За это время было опубликовано почти четыреста заметок. Я не рассчитывал, что будет так много, но в последние месяцы Остапа что-то понесло ;)

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

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

Если кому-то интересно, то за все здесь написанное отвечает вот эта наглая рожа (спасибо Славе Костину за отличную фотографию):

Что хочется еще сказать? Пока мне это занятие нравится! Так что, еще пообщаемся :) А пока пора бежать в магазин! ;)

[comp.prog] POCO 1.3.6p1 released!

Менее чем через месяц после релиза версии 1.3.6 состоялся выход обновленной версии 1.3.6p1. В основном это bug-fix версия, которая рекомендуется тем, кто использует модули Crypto, NetSSL и XML. Но есть и одна новая особенность – теперь POCO позволяет использовать уже установленные в системе zlib, pcre, expat и sqlite3 (до этой версии POCO брал только те версии этих библиотек, которые были включены разработчиками в состав POCO).

Полный CHANGELOG.

URL для скачивания: http://sourceforge.net/projects/poco/files/sources/poco-1.3.6

[life] Впечатления учителя о плохой американской школе

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

Под конец дня было "веселье". Один из учеников-восьмиклассников в соседнем кабинете наехал на учителя. Пришлось вызывать полицию. Парня увели в наручниках прямиком в отделение полиции. Учитель подал на него заявление. Мама...куда я попала?

Но хочу сказать, что эта школа скорее исключение из правил. Находится она в плохом районе и для очень бедных слоёв населения. Так что такие вот страсти. А так школы тут довольно неплохие, особенно частные.

У меня в классе дети вообще по нулям. Сегодня долго и мучительно вспоминали в ними что такое сущетсвительное и глагол. Такие вещи как прилагательное и (о боже!) наречие вводят их в состояние ужаса. У меня волосы дыбом. Пошла сегодня в книжный и купила учебников за 1, 2 и 3 классы. Начинать с ними надо будет с нуля. Читают половина совсем по слогам. Отдельные личности читают более-менее и пара человек читать вообще не умеют. Грамматики никакой. Словарный состав скудный. Учебник явно не для их уровня. Я и не удивляюсь, что они орут, что им скучно. Они же по этому учебнику наверное вообще не въезжают что к чему.

…

Боже, сколько времени уходит. Сижу в школе до 7 вечера. Потом дома до часу ночи обычно. Очень много документации заполнять. Причём мне говорят, что я на самом деле практические ничего и не делаю, мол, документация будет потом. Но нужно организовывать планы (нужно их ВСЕ всегда с собой иметь), заранее готовить копии (кстати, сдала ещё ажно в понедельик раскопировать кое-что для занятий, а копий так и нет, а уже пятница на дворе), переносить на каждого студента оценки и поведение в grade book. Учеников у меня 140, на каждого заполнить оценки, проверить их работы, выставить баллы, потом отметить поведение в классе и мне ещё намекнули, что желательно на каждого ученика вести записи о том, как он работает в классе. Когда всё это делать?? У меня только проверить то, что написали и выставить оценки каждый день уходит около 4 часов. Причём в классе ничего нет. Я уже вторую неделю пытаюсь добиться от них хотя бы filing cabinet, потому что нужно заводить файлы на учеников, а складывать их некуда.

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

Помню, у меня был шок, когда в университете я рассказал, что в моем классе училось несколько второгодников – мои одногруппники были сильно удивлены. Оказывается, они никогда второгодников в глаза не видели. Блин, я себя реально self-made man почувствовал (типа вырвался из гетто и все такое). А пару лет назад встретил знакомую, которая училась в параллельной группе, но на преподавателя математики. Работает сейчас учителем в обычной школе. Говорит, что обстановка разве что в тюрьме хуже, хотя она и не уверена.

Так что впечатлили меня в этих рассказах вовсе не “школьные ужасы”. Я не понимаю, какой смысл был оказаться в Америке, чтобы работать в таком кошмаре. Вот нахрена?

[life.photo.wow] Обычный закат, но вот где?!!!

Вот такая, на первый взгляд, обычная фотография заката:

Только это закат Солнца на Марсе!

Фотография сделана марсоходом Spirit 19-го майя 2005 года. Цвета не настоящие, а адаптированные к тому, что привык воспринимать человеческий глаз.

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

[life.photo] Пейзажные фотографии Михаила Рейфмана

В большом количестве представлены на PhotoSight.ru. В большинстве своем очень впечатляющие, но, почему-то, оставляющие меня равнодушным. Мне кажется, что в них очень много “профессионализма”. Снимки отточены чуть ли не до совершенства, я бы даже сказал до неествественности, и как раз это мне мешает.

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

Hveradalir

Фотография о том, как хорошо стоять одному рано утром перед водопадом

Из серии “Палузские Пастели”

odd place, odd games…

Sunrise Hunter

PS. Чуть не забыл указать сайт автора: http://www.mikereyfman.com

[life.photo] Как Олимпийский Огонь перевозят с континента на континент?

Кто-нибудь задумывался о том, как именно в самолетах перевозят Олимпийский Огонь? А вот так:

Найдено в фоторепортаже о передвижении Олимпийского Огня в Канаде.

Не могу не опубликовать еще одну фотографию оттуда:

[life.business] Поток сознания на тему “Своя Компания”…

…родившийся по мотивам заметки “Своя Компания” и комментариев к ней в блоге “Алёна C++”.

В детстве было очевидно, что когда я вырасту, то стану знаменитым и богатым. Такое будущее воспринималось как естественное и само собой разумеющееся. Но время шло, и все острее вставал вопрос: “Ну и где, собственно?” ;)

Главный ответ на этот вопрос мне повезло вычитать в какой-то книжке в возрасте 16-ти или 17-ти лет: нельзя стать миллионером, работая “на дядю”. Но создавать свое дело у меня никогда не было большого желания. Первая причина – наследственная неспособность дешево купить и дорого продать. Со временем стала понятна и вторая причина – трудности в общении с людьми. Поскольку бизнес, как мне представляется, это связи. Которые нужно заводить, нужно поддерживать, нужно использовать. Причем связи не только в смысле “блата” или “полезных знакомств”, а даже взаимоотношения между коллегами и подчиненными – суметь заинтересовать кого-то своей идеей – это большое дело.

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

На том и успокоился. Что, видимо, и привело в конечном счете, к формированию “психологии наемного рабочего”, готовности продавать свои мозги и свое время за фиксированную ставку. Зато получив возможность концентрироваться на вопросе “Как?” вместо вопросов “Что? Зачем? По чём?”

Если на этом моменте сильно акцентировать внимание, то возникает соблазн провести четкую грань: наемный рабочий – лузер, а владелец компании – соответственно, виннер. Такое бинарное деление мне просто фиолетово. Курчатов и Королев были, по сути, наемными рабочими. Или, чтобы быть ближе к своей профессиональной области – Никлаус Вирт, Бьярн Страуструп, Джеймс Гослинг или Гвидо ван Россум. Мне всегда хотелось сделать востребованный язык программирования, а не бизнес по продаже компиляторов.

Но чем старше я становлюсь, тем чаще возникают сожаления о том, что я не (со)владею каким-нибудь бизнесом. Временами накатывает нежелание выполнять чужие поручения. Временами задумываешься, а за счет чего придется жить, если не повезет дожить до пенсии? Временами становиться страшно, когда думаешь, что останется моей семье, если со мной внезапно что-нибудь случится (недавние смерти Романа Трахтенберга и Владимира Турчинского, скоропостижная смерть знатока Дмитрия Коноваленко несколько лет назад)?

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

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

А вот со стартовыми условиями ситуация иная, более-менее мне знакомая. Так уж получилось, что в двух из своих четырех мест работы, я работал как раз в условиях стартапов. Сначала в КСБП, где за очень смешные деньги мы пытались родить новую SCADA-систему. Затем в Интервэйл (особенно его подразделение в Гомеле), когда из небольшой фирмочки с едва ли десятком сотрудников (включая директора и бухгалтера) выросла приличная компания, с филиалами в нескольких странах. У нас в Гомеле изначально даже не было офисного помещения – несколько местных сотрудников встречались в аудиториях ВУЗ-ов, в кафе, на квартирах. Потом появился первый офис – комната в 15 метров с четырьмя столами. Потом следующий офис – уже из трех комнат. Теперь мы снимаем половину этажа в местном научно-исследовательском институте и планируем занять весь этаж.

Так что работу в условиях стартапа я себе прекрасно представляю. Более того, именно такая работа мне больше всего нравится: есть цель, есть несколько единомышленников, всех остальных нужно сделать, если не мы, то нас… Ну и все такое. Плюс никакой бюрократии, иерархии, сложных служебных взаимоотношений и прочей политики. Лепота! Хорошие были времена. Правда, хорошие.

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

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

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

Так что небольшой совет желающим открыть свой маленький свечной заводиксофтверный бизнес: не стесняйтесь предлагать работу опытным разработчикам за маленькое вознаграждение и партнерство в предприятии – кто-нибудь может и согласиться ;)

[comp.prog] Интересное высказывание о стоимости строки кода

Сделано тов.gear nuke в одном из форумов RSDN:

Строка кода ничего не стоит. Строка кода с ошибкой стоит дорого. А платят за решение проблем, или — реже — за надежду

Согласиться с этим пока не готов. Но мысль интересная.

[life.photo] О величии стихии и дерзости человека

Фото найдены здесь.

А в завершение небольшой видеоролик, который позволяет ощутить все это еще острее:

[life.thoughts] Повод застрелиться: “Если ты доцент, и у тебя нет бизнеса…”

Сегодня в блоге “Алёна C++” появилась заметка “Своя компания”. Поскольку в последнее время меня донимают разные мысли на эту тему, то я стал обдумывать свой собственный очередной блог-пост. А тут наводка в Тупичке Гоблина на феноменальное высказывание Анатолия Чубайса:

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

Мое первое впечатление – если это не вырванная журналистами из очень узкого контекста фраза, то это просто приплыздец… Еще больше убеждаешься в разумности анекдота: “Я не знаю, о чем вы тут разговариваете, но таки послушайте, что я вам скажу – ехать надо!”

Потом погуглил. Нашел статью, в которой контекст этой фразы развернут более широко:

— Только один Массачусетский технический институт за время своей работы создал столько бизнесов, что их ежегодный объем продаж равен четырнадцатому ВВП в мире, — обратился Анатолий Чубайс к опыту зарубежных коллег. — А у вас целых 36 вузов. Да голову надо приложить, голову к этой задаче! Спроси любого ректора, сколько студентов, какой объем научно-исследовательских разработок выполняете, — с ходу ответит. Задаешь третий вопрос — сколько бизнесов создал вуз? Ответят: «Ну, вот полторы компании есть, одна скоро точно появится... Если ты доцент или заведующий кафедрой и у тебя по твоему направлению нет бизнеса своего, да на кой черт ты мне нужен? Это вчерашний день, и профессионал-преподаватель сегодня, не способный создать своего бизнеса, ставит под вопрос свой профессионализм, — высказал свою точку зрения Анатолий Чубайс.

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

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

Так вот, если в России действительно внемлют словам Чубайса и начнут претворять их в жизнь с чисто русским размахом (“…до основания, а потом…”), то приплыздец обязательно случится.

PS. Есть у меня мнение, что куча бизнесов вокруг MIT возникла вовсе не усилиями преподавателей, а силами бывших студентов и аспирантов MIT-а. И еще мне кажется, что MIT-овские профессора в советах директоров разных компаний – это в большей степени PR-ходы самих компаний, которые таким образом пытаются создать себе больший вес в глазах клиентов. Сами же профессора к именно бизнесу имеют посредственное отношение. Впрочем, здесь я не копенгаген…

[life.photo] Отличные фотографии с Олимпийских Игр 2008

Повезло найти в Интернете (общим числом 39). Вот некоторые из них:

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

[comp.prog.doc] Слова Джеймса Кэмерона, которые я бы отнес и к документированию

Отлично сказано:

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

Имхо, эти слова должны запомнить программисты, которые пытаются писать документацию к своей программе.

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

[comp.prog] Презентация об использовании Erlang в Facebook

Erlang at Facebook – интересная PDF-а на 40 страниц.

Erlang использовался для реализации части сервиса Chat в Facebook. Прототип сервиса был создан в январе 2007, затем командой из 4 человек доводился до ума до осени 2007-го. В феврале 2008 проект был запущен в тестовую эксплуатацию.

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

[life] Шкафы-купе: на что нужно обращать внимание?

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

Хотим заказать себе такой для прихожей, пытаемся сейчас определиться, что он должен из себя представлять. Но опыта использования подобных конструкций ни у меня, ни у жены нет. Собираем впечатления у знакомых.

Еще один вопрос к читателям-гомельчанам. Пока мы думаем заказывать в “Дом-Интерьер”. Если у кого-то есть компромат на эту контору, поделитесь, плз. :)

[life.wow] Лепота: кофе, сигарета и –23 за бортом ;)

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

В качестве бонуса. Жена отводила дочку в школу сегодня:

Идем пару минут, молчим. Потом я спрашиваю:
-- Тебе холодно?
-- Нет.
Еще через пару минут молчания спрашиваю:
-- Что у тебя замерзло?
-- Все!

[life] Мебель для детской

По осени появились таки возможности и время прикупить новую мебель для детской комнаты. Комната маленькая, порядка 2.85x2.5 метра. Поэтому выбор оказался непростой задачей – пересмотрели несколько каталогов с готовой мебелью, долго облизывались на мебель Дядьково… Но в результате решили заказать изготовление мебели по нашим размерам, т.к. готовые варианты не вписывались ни по размерам, ни по расцветке, ни по вменяемости цен.

В результате заказали в Lex’s-Мебель. По двум причинам. Во-первых, не слишком дорого. Во-вторых, они делают не только корпусную, но и мягкую мебель. А нам нужен был такой диван, на котором можно было бы спать не раскладывая его. У них такой был, подходящего нам дизайна, упругости матраса и расцветки.

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

Еще пример для иллюстрации доброжелательного отношения со стороны Lex-овцев. Мы к ним забрели в первый раз с нарисованным от руки эскизом того, что мы хотим. Дизайнер отсканировала наш рисунок и сказала, что набросает предварительный проект и прикинет примерную стоимость. И действительно перезвонила она нам через несколько часов. Через пару дней мы туда еще раз приехали. Она нам показала проект на компьютере. Т.е. человек взял и сам, без нашей просьбы, нарисовал на компьютере проект, сделал расчет и сообщил нам практически точную цену. А ведь мы даже не изъявляли желания заказывать у них что-нибудь. И она не знала, приедем ли мы к ним еще раз.

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

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

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

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

1. Ведите все согласования только с одним и тем же дизайнером. Он будет помнить, что и как он делал, и что мы от него хотели. При передаче информации между разными дизайнерами обязательно возникнет эффект “испорченного телефона”.
2. Когда вы заказываете шкафчики глубиной, например, 400mm, уточните, будет ли это глубина только шкафа или сюда будет добавлена еще и толщина дверцы. Мы, например, хотели 400mm вместе с дверцей, а получили 400mm глубиной (а с дверцей где-то 420mm).

Ну и в завершение упомяну еще один фактор, из-за которого мы остановились на Lex’s-Мебель. Во многих подобных конторах в Гомеле макет рисуют вручную на бумаге, а не моделируют на компьютере. В Lex’s же мы увидели, как наш проект будет выглядеть почти “в живую”. Конечно, компьютерная модель и реальность далеко не одно и то же, но все же очень похоже.

[life.photo] Ой, мое ухо, ухо! – Поздно, прокомпостировали!

Отлично пойманный спортивный момент:

Найдено в очередном выпуске WSJ’s Pictures of the Day.

[comp.prog.flame] null-указатели и притягивание за уши решений из функциональных языков

В RSDN-овском обсуждении Billion-dollar mistake тов.Кодёнок продемонстрировал, как тип Maybe из функциональных языков:

data Maybe a = Nothing | Just a

мог бы использоваться в C++/C# для сокращения количества проблем с null-указателями:

struct Maybe<A> {}; struct Nothing<A> : Maybe<A> {}; struct Just<A> { A value; }; void fun(Maybe<A> x) {     print(x.value); // type ERROR     if (x is Just<A>)         print( (Just<A>)x.value ); // OK }

Мои скромные познания в C# позволяют думать, что это пример C#-ного кода. В C++ такой подход выглядел бы более сурово, за счет использования dynamic_cast-ов или каких-то других фокусов. Поэтому я думаю, что подход с типами Maybe, Nothing и Just в C++ не прошел бы. Для C++ нужно было бы иметь что-нибудь более заточенное под C++, а не кальку с функционального языка.

Например, можно было бы использовать Boost-овский Optional. Что-то вроде:

// Здесь мы не должны получать NULL. void g( A & a ) { ... } // А вот здесь мы можем получить NULL или не-NULL. void fun(boost::optional<A*> x) {     if (x)         g( **x ); // OK }

Но для Boost.Optional null-указатель является допустимым значением. Поэтому можно было бы создать более простой аналог Boost.Optional, заточенный специально под хранение указателей:

// Класс, который не может хранить внутри себя нулевые указатели. template< class T > class not_null_ptr   {   public :     not_null_ptr( T * ptr )       // Вспомогательная функция ensure_not_null порождает исключение       // если получает нулевой аргумент.       : p_( ensure_not_null( ptr ) )       {}     ...     T * get() const { return p_; }     ...   private :     T * p_;   }; // Класс, который может хранить внутри себя нулевые указатели. template< class T > class nullable_ptr   {   public :     nullable_ptr( T * ptr )       : p_( ptr )       {}     ...     bool is_null() const { return !p_; }     // Безопасный доступ к указателю.     not_null_ptr<T> get_not_null() const { return not_null_ptr<T>( p_ ); }     // Прямой доступ к указателю.     T * get_any() const { return p_; }     ...   private :     T * p_;   }; // Здесь мы не должны получать NULL. void g( not_null_ptr< A > a ) { ... } // А вот здесь мы можем получить NULL или не-NULL. void fun( nullable_ptr< A > x ) {     if( !x.is_null() )         g( x.get_not_null() ); // OK }

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

PS. Это всего лишь набросок того, что я бы хотел видеть в C++ в качестве средств борьбы с нулевыми указателями вместо Maybe. Реальное решение должно быть более продвинутым. Например, должны решаться вопросы владения указателем (совмещение nullable_ptr с auto_ptr/unique_ptr и/или shared_ptr). Кроме того, в C++ null-указатель еще не самая страшная проблема – повисшие и запорченные указатели куда страшнее.

Но я хотел показать, что просто так тянуть Maybe из функциональных языков в C++ не нужно. Поскольку в каждом языке есть свои собственные тараканы, с коими нужно считаться.

PPS. Вот интересно, если бы шаблоны в C++ были с самого начала, могли ли классы вроде nullable_ptr/not_null_ptr появиться в стандартной библиотеке C++ сразу? Чтобы функции std::strcpy имели прототип:

not_null_ptr<char> strcpy(   not_null_ptr<char> dest,   const_not_null_ptr<char> src)

:)

[comp.prog] Ruby 1.9.1-p376

7-го декабря была выпущена обновленная версия Ruby 1.9.1 – Ruby 1.9.1-p376, в которой была исправлена уязвимость с переполнением хипа и сделано еще более ста исправлений. Публикую эту новость с недельным опозданием, поскольку сразу не были доступны бинарники для Windows. Сейчас доступны, так что можно обновляться не только под Unix-ами, но и под Windows.

Исходники: http://ftp.ruby-lang.org/pub/ruby/1.9/ruby-1.9.1-p376.tar.bz2
Бинарники под Win32: http://ftp.ruby-lang.org/pub/ruby/binaries/mswin32/ruby-1.9.1-p376-i386-mswin32.zip
Бинарники под Win64: http://ftp.ruby-lang.org/pub/ruby/binaries/mswin32/ruby-1.9.1-p376-x64-mswin64_80.zip

PS. Сам я на Ruby в последнее время практически ничего не пишу, т.к. полно работы на C++. Поэтому продолжаю пользоваться, по уже сложившейся традиции, Ruby 1.8.7. Но надо, думаю, потихоньку переползать на ветку 1.9.

[life.photo] Фотографии животных от Сергея Урядникова

Увидел их на PhotoLine.ru, но поскольку не понял, как вставлять в блог фото оттуда, то пришлось разыскивать в других источниках. К счастью это удалось сделать, большой фотоальбом работ Сергея Урядникова есть на сайте журнала “Вокруг Света”.

Борнейская пиратка

Crossing Pepe

Дубль 2 (этой антилопе убежать удалось, но крокодил слопал следующую)

Бонобо 5

Возвышенные чувства

Полярный кенгуру

PS. Рекомендую все-таки смотреть фото автора на PhotoLine.ru.