[life.sport.darts] Расскажу про еще одни дротики от Target – Silica Apollo 22g

Чуть более недели назад я в очередной раз попытался сменить дротики. На этот раз меня соблазнили 22-х граммовые Silica Apollo от Target. Под катом более подробный рассказ о том, как я на это решился и что в итоге из этого получилось.

[life] Джимми Картер, оказывается, еще жив!

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

А ведь это оказался Джимми Картер, который 39-й президент США. Тот самый, про которого мы в первом классе рассказывали друг другу первые понятные нам политические анекдоты. Вроде таких:

Приехал Брежнев в США. Все деньги пропил, проиграл. Сидит перед Белым Домом, жует травку. Мимо проходит Картер и спрашивает:

-- Ты чего здесь сидишь?
-- Да вот, все деньги пропил, еду купить не за что, приходится траву жевать.

Ну Картер отвел Брежнева в Белый Дом, накормил, напоил, купил билет в СССР и подарков еще в дорогу дал.

Через год приезжает Картер в СССР. Все деньги пропил, проиграл. Сидит под Кремлевской стеной, травку жует. Мимо проходит Брежнев и спрашивает:

-- Ты чего здесь сидишь?
-- Да вот, все деньги пропил, еду купить не за что, приходится траву жевать.

Брежнев дает ему пять копеек и говорит:

-- Езжай на конечную, там травка повкуснее.

Правда, вскоре Картера сменил Рейган и анекдоты стали рассказывать уже про Рейгана и Брежнева:

Провели забег между Рейганом и Брежневым. Рейган занял первое место, Брежнев – второе. Американские газеты написали:

“Вчера состоялся забег между Рейганом и Брежневым. Рейган обогнал Брежнева и занял первое место.”

Газета “Правда” в СССР написала:

“Вчера состоялся забег, в котором приняли участие Президент США Рональд Рейган и Генеральный секретарь ЦК КПСС Леонид Ильич Брежнев. Леонид Ильич занял почетное второе место. Рональд Рейган пришел к финишу предпоследним.”

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

Да, так вот к исходной теме. Прошло тридцать (тридцать!!! блять) лет. Уже давно нет многих из тех, про кого мы в детстве свои первые политические анекдоты рассказывали. Ни Брежнева, ни Рейгана, ни Черненко, ни Андропова. А Джимми Картер, оказывается, все еще жив.

[prog.flame] Проведу параллель между увлечением дартсом и новыми языками программирования

На RSDN развивается небольшой (пока?) флейм под названием “Scala / F# / Nemerle и мейнстрим”. Может из-за того, что я редко читаю RSDN в последнее время, но мне кажется, что в мою бытность RSDN-ером такие флеймы случались почаще :) Впрочем, и тогда они проходили по аналогичному сценарию. Набегало несколько фанатичных Nemerle-истов и приверженцев других маргинальных (по сравнению с мейнстримом) направлений и начинали доказывать, что самые умные и продвинутые сейчас будут использовать Nemerle (Scala, Lisp, OCaml, Erlang, you name it…), получат от этого невообразимые бенефиты и снимут все сливки. А остальные (т.е. либо заросшие мхом старперы, либо настолько тупые, что не могут оценить то, что наиболее по-(про)двинутым уже давно понятно) будут продолжать плакать, но жрать мейнстримовый кактус. Как миллионы мух, которые… ну и далее по тексту.

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

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

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

Что тут же вселяет уверенность в том, что решение их купить было не просто правильным, а архиправильным. И остается только сожалеть, что ты не сделал этого раньше, и о том, что посылка по почте идет так долго.

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

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

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

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

То ли дело взять вместо наскучившего C++ новый C#… А потом вместо наскучившего C# новый Nemerle… Или Scala вместо Java… Адреналин-то возвращается. Рутина исчезает (на время, но кого это волнует). Жизнь становится лучше, жизнь становится веселее.

Однако, частая смена языков (как и частая смена дротиков) – это всего лишь бег на месте. Потом становится понятно, что для достижения значимого результата нужно остановиться на чем-то одном. По-возможности, максимально для тебя комфортном. И долбить, долбить, долбить. Превозмогая скуку, разочарования, однообразие. Да, медленно, да без адреналина.

Конечно, прогресс не стоит на месте. И Java с C# вытесняют C с C++ом, как в свое время C вытеснял ассемблер. Так же, как вольфрам и полимеры стали мейнстримом в дартсе, вытеснив в прошлое деревянные дротики с натуральными перьями. Только времени на это потребовалось очень и очень не мало. Так что мейнстрим меняется, никуда от этого не спрятаться. Но при любом мейнстриме секрет успеха будет заключаться в том, чтобы долбить, долбить и долбить… А не в ловле кайфа от процесса смены инструмента.

[life.art.humour] Копии известных картин, но из овощей и фруктов

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

[prog] Цитата из Буча об истоках противостояния ООП и ФП

На досуге пытаюсь перечитывать книгу Гради Буча “Объектно-ориентированный анализ и проектирование”. Наткнулся на интересный фрагмент (раздел 1.3, курсивом выделена сноска и именно в ней все самое интересное):

Какая декомпозиция сложной системы правильнее - по алгоритмам или по объектам? В этом вопросе есть подвох, и правильный ответ на него: важны оба аспекта. Разделение по алгоритмам концентрирует внимание на порядке происходящих событий, а разделение по объектам придает особое значение агентам, которые являются либо объектами, либо субъектами действия. Однако мы не можем сконструировать сложную систему одновременно двумя способами, тем более, что эти способы по сути ортогональны [Лэнгдон предполагает, что эта ортогональность изучалась с древних времен. Он пишет: "К. X. Ваддингтон отметил, что такая дуальность взглядов прослеживается до древних греков. Пассивный взгляд предлагался Демокритом, который утверждал, что мир состоит из атомов. Эта позиция Демокрита ставила в центр всего материю. Классическим представителем другой стороны - активного взгляда - был Гераклит, который выделял понятие процесса"[Langdon, G. 1982. Computer Design. San Jose, CA: Computeach Press, p.6.]].

Она как! Истоки нужно искать еще в Древней Греции :)

[life.photo] Снимки диких зверей Джонатана Гриффита

Джонатану Гриффиту 32 года. Два года назад невеста подарила ему на день рождения фотоаппарат.

Попробовав снимать зверей в зоопарке Джонатан решил, что ему нужно делать это на природе. Для чего он уехал в США, где провел 15 месяцев в домике где-то в Скалистых Горах в штате Монтана. Результатом чего стала вот эта серия снимков.

[prog.flame] Пару слов об let-it-crash

Данная заметка является развернутым комментарием к одному моменту в споре об исключениях, завязавшемся в обсуждении моей предыдущей заметки о языках D и Go.

Вкратце напомню, в чем дело. Ув.тов.Left и Gaperton высказывались в том ключе, что раз в Go нет исключений, то и ничего плохого в этом нет. Что можно выделять действия, которые могут завершаться ошибкой (например, делением на ноль или попыткой вычислить квадратный корень из отрицательного числа), в отдельные goroutine. Тогда при возникновении проблемы прибивается только эта goroutine, а запустивший ее код сможет понять, что произошел сбой и что-либо предпримет.

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

Там рулит подход let-it-crash, при котором ты вообще не пишешь обработки ошибок, и закладываешься только на успешный случай. А когда оно упадет - как бы ни упало - обрабатывается падение процесса, и все.

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

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

Но в ряде случаев этот подход почему-то не нравится пользователям софта. А когда пользователям не нравится и они настоятельно просят сделать что-то, что мне, как программисту не нравится и кажется странным и абсолютно не нужным, то приходится наступать на горло своей песни. Т.е. забивать на let-it-crash, чтобы воплотить в жизнь принцип let-it-live :/

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

Казалось бы, все просто – мы в БД с select-ом, а нам вместо ответа exception. Ну мы, как приверженцы let-it-crash, описание проблемы в log, а сами зовем abort. После чего нас рестартуют, мы заново подключаемся к БД, выполняем select и продолжаем работать как будто этого сбоя и не было.

Но вот пользователям эта простота не нравится. А у нас, говорят, в логах слишком много таких ошибок появляется, временами. С ними разбираться приходиться. А у нас, говорят, системы мониторинга начинаю кричать, когда какой-то процесс аварийно завершается. А еще у нас, признаются, временами супервизоры “подвисают” и забывают упавшие процессы поднимать на автомате. Поэтому не могли бы вы, программисты вы наши всесильные, сделать так, чтобы при возникновении ошибки “нет связи с сервером БД” при select-е вы не звали abort, а просто пытались заново к БД подключиться? Раза эдак два, три. А еще лучше, чтобы параметры восстановления подключения мы бы сами в конфиге прописывали. И только если все попытки обломились, либо же если на эти попытки было затрачено слишком много времени, то тогда уже abort. Ну очень надо!

Так что let-it-crash – это очень хорошо для программиста, гораздо лучше, чем let-it-live. Только не всегда допустимо. А там где недопустимо, нужны какие-то средства, которые не позволят прозевать неожиданную проблему (вроде забытой проверки кода возврата функции). И которые позволяют проблему вовремя диагностировать и исправить. Исключения, например.

PS. Для C++ных программ, работающих в режиме 24x7, подход let-it-crash, наверное, еще более важен, чем для Erlang-а. Поскольку уронить C++ную программу очень просто. Иногда для этого достаточно просто на новую версию Visual C++ перейти :)