Вот здесь приличная подборка фотографий, посвященных прыжкам в воду. Для примера приведу одну, самую необычную:
Там есть несколько работ с соревнований Red Bull Cliff Diving. Я о них никогда не слышал, поэтому полез в YouTube посмотреть что же это такое. Несколько роликов оттуда:
Да и на самом сайте RedBull-а можно найти множество роликов об этом соревновании.
Внушать, однако.
После первого случайного достижения – попадания второго дротика точно в хвост первому дротику – подобные вещи стали происходить со мной регулярно. Особенно после перехода на короткие хвостики и pear-перышки: каждую неделю по одному, а то и два таких случая происходит.
И я, кажется, понял рецепт :)
Для того, чтобы повторить достижение Робина Гуда в дартсе достаточно всего лишь поставить на дротик новый хвостовик. И на 99% успех гарантирован. Но 100% гарантия обеспечивается только в случае, если поставленный хвостовик оказывается последним из имеющихся в наличии :/
Небольшая ремарка для непосвященных. Подобное попадание, как правило, убивает пластиковый хвостик сразу. Более стойкими оказываются алюминиевые хвостики – как минимум одно прямое попадание они выдерживают без проблем. Потом нужно только поправить разогнувшиеся усики. Лучше всего себя ведут нейлоновые хвостики с металлическим колечком – у них достаточно заменить колечко (старое перестает держать, т.к. растягивается).
PS. Не могу удержаться, чтобы не похвастаться очередным покоренным сектором утроения :)
PPS. Играйте в дартс – это классно! :)))
Недавно я писал о выходе HTTP-сервера mongrel2. Он использует интересную схему взаимодействия с Web-приложениями: приложение оформляется в виде отдельного процесса, а с mongrel2 общается посредством ZeroMQ. Я тогда высказал мысль о том, что это какая-то стремная схема – Web-приложение намертво привязывается к конкретному HTTP-серверу. В комментариях так же была высказана мысль о том, что mongrel2 подойдет только для очень узкого круга задач. А вчера подумалось о потенциальной предметной области, в которой лично я рискнул бы использовать mongrel2.
Сейчас очень модно и востребовано оформлять интерфейсы к различным программулинам через Web-интерфейс. Не суть важно, что это за программулина – какой-нибудь AlwaysUp, система контроля версий (см.например, Fossil), консоль управления ADSL-модемом или корпоративный почтовый сервер. Все равно управление через Web-интерфейс должно быть. И хоть я считаю, что это в большей степени маразматично, чем практично, но раз пользователи хотят, значит нужно Web-интерфейс делать. Но как и на чем? И вот тут, имхо, вещи вроде mongrel2 могут стать мной востребованными.
Скажем, если я пишу какой-нибудь сервер на С++, к которому нужно прикрутить Web-морду, то зачем мне городить огород из какого-то мощного Web-сервера (вроде Apache), [Fast]CGI-скриптов на каком-то языке и канала из CGI-я в мой C++ный сервер? Или даже встраивать какой-нибудь легковесный Web-сервер в собственную программу? Ведь я спокойно могу взять ZeroMQ, встроить в свой сервер логику Web-морды и работать через mongrel2.
На первый взгляд, должно получиться и удобно, и надежно. По крайней мере, выглядит проще, чем с Apache+CGI (что мне приходилось проделывать).
И вот что важно. Мой аргумент о жесткой привязке к конкретному HTTP-серверу будет уже не столь актуален. Поскольку здесь ситуация такая же, как с базовыми библиотеками – какую выбрал, к такой и привязался, и просто так не отвяжешься. Скажем, взял для работы по TCP/IP ACE вместо Boost::Asio и все, уже ничего не изменишь без глобального переписывания. И это нормально.
Поэтому для целей встраивания в C++ные “черные ящики” Web-интерфейса mongrel2 стал для меня заманчивой штукой. Нужно будет “взять на карандаш”.
Постепенно превращаясь из программиста в тим-лида обнаружил интересный эффект: объем работы, с которым нужно справится, постоянно увеличивается, но как раз это позволяет со спокойной совестью работать только с 9:00 до 18:00.
Раньше было как? Есть задача, которой ты занимаешься. Приближается конец рабочего дня и ты понимаешь, что чуть-чуть не успеваешь. Поэтому решаешь задержаться, чтобы доделать, чтобы на завтра не оставлять. Часто доделываешь. Из-за чего в последствии опять возникает соблазн задержаться и доделать :)
А что сейчас? Сейчас задач много. Настолько много, что хоть сиди на работе целые сутки напролет, все равно их все не переделываешь. Поэтому и смысла задерживаться нет.
Видимо, в дело вступает принцип “всю работу не сделаешь, всех денег не заработаешь, всех… (ну и далее по тексту)”. И в 18:00 с работы сваливаешь со спокойно спящей совестью. Не то, что раньше :)
Нравится мне пока этот эффект. Глядишь, так я и в отпуск соберусь :) Если раньше не уволят за пофигизм и тунеядство :)))
Продолжается серия статей с описанием нововведений в Scala версии 2.8. На этот раз на английском можно прочитать статью Chained Package Clauses.
PS. Ранее была опубликована статья The Scala 2.8 Collections API.
Чуть меньше года назад я задал в своем блоге риторический (как оказалось) вопрос о том, как можно писать по 1K (тысяче строк) на языке C в день на продолжении длительного времени. Вчера герой моего вопроса – Лев Валкин – написал в своем ЖЖ большую заметку “RSI — как бороться с туннельным синдромом”, в которой раскрыл эту тему подробнее.
Выяснились две довольно очевидные вещи:
Собственно, наличие проблем со здоровьем делает эту тему весьма щепетильной. Напряженная работа и переработки обязательно скажутся на здоровье. Пусть не туннельным синдромом, так лишним весом, облысением, севшим зрением, остеохондрозами, геморроем или съехавшей крышей.
Посему остановлюсь вот на чем: “А что, 1K строк ежедневно – это доблесть?” Читая Льва Валкина у меня складывается впечатление, что да, доблесть. Человек с гордостью говорит о том, что он мог работать в таком темпе. Более того, в комментариях прозвучала фраза “Но я, конечно, не дорос ещё до 1К строчек в день.”, поэтому, боюсь, доблесть видит в этом далеко не один человек.
Я хочу, чтобы читатель задумался о том, что значит 1K строк в день.
Обычный рабочий день составляет 8 часов. Всего 480 минут. И 1000 строк. Больше, чем две строки в минуту. Только набирать нужно больше двух строк в минуту! А когда же думать над тем, что пишешь?
Пусть каждая строка после написания переписывается два раза. Т.е. выдача “на гора” составляет ~330 строк. Т.е. около 1.5 минут на строку. Из которых часть времени занимает ее набор и исправление (т.е. физические действия), поэтому на обдумывание остается меньше времени. Путь будет 1 минута. Т.е. на обдумывание кода уходит, вроде бы, ~5.5 часов. Кажется, что неплохо – больше пяти часов на обдумывание кода в день.
К сожалению, плохо. Поскольку это, во-первых, суммарное время. Оно размазано среди всего процесса набора, исправления, удаления, восстановления, нового исправления и т.д. И, во-вторых, это время включает в себя время как на первоначальное придумывание строки, так и на последующие ее изменения. Т.е. последующие действия убивают время, затраченное на предыдущие действия.
Именно поэтому каждая результирующая строка кода обходится дороже того, что она должна стоить. Ведь из 1000 набранных строк остается только треть, а то и меньше. При таких темпах набора кода фаза тщательного обдумывания перед написанием текста программы просто отсутствует.
А вот если бы она присутствовала, фаза эта? Представьте себе, что сначала пять часов тратиться на обдумывание, на рисование каракулей на бумаге или доске, на написание отдельных фрагментов на бумаге. Вплоть до тех пор, пока разработчик не поймет, что у него перед глазами прошло все, что он хотел набрать на компьютере. Сколько в результате получится строк? Да, в худшем случае, те же самые триста с плюсиком. Хватит ли оставшихся трех часов, чтобы спокойно и не напрягаясь набрать их? Как два байта…
Почему я сказал, что триста строк получится в худшем случае? Просто потому, что в лучшем случае их будет гораздо меньше. Это будут уже почти готовые и отлаженные строки. Нормально отформатированные, хорошо закомментированные. С намного меньшим процентом ошибок. С намного меньшим процентом серьезных ошибок.
Цифры “валовой продукции”, конечно, будут намного меньше. Не 1K, и даже не 300. А около 100 строк в день (это я цифры для C++ привожу, для других языков может быть и того меньше).
Что заставило меня написать столь много слов на данную тему? Будучи человеком среднего ума я, однако, являюсь хорошим программистом (не супер-пупер, к сожалению, но хорошим). А вокруг намного более умные люди, чем я, пишут отвратительный и неработающий код. По одной простой, как мне кажется, причине – они думают в процессе написания кода, а не до этого :(
Последствия “обдумывания кода во время написания” зачастую сказываются на мне. Два дня назад в библиотеке, разработанной полтора года назад думающим-в-процессе-программистом, внезапно всплыл злобный баг и мне предстоит убить еще день на окончательное преобразование говнокода во что-то более-менее нормальное.
В последнее время это, мягко говоря, задалбывает. Поэтому я поступлю цинично и вопрошу:
Любишь колбасить по тысяче строк в день, вместо того, чтобы потратить три-четыре-пять-шесть часов на предварительное обдумывание?
Думаешь, что это круто – работать в таком темпе?
Думаешь, что таким количеством говнокода ты двигаешь проект вперед?
Если да, то готов ли ты к встрече с туннельным синдромом?
A?
…то получится сей забавный девайс:
Данный велосипед производит и продает компания ElliptiGO.
Сам не велосипедист, но интересно, а в горку на нем как? Проще, чем на обычном или нет?
Прочитал статью “Programming With Reason: Where Are We Going?” в Dr.Dobb’s Journal. Статья, собственно, не о чем, можно даже не тратить на нее время. Но вот один момент зацепил.
Автор описывает свое первое место работы, где ему приходилось разрабатывать торговую систему. Ядром системы был DEC VAX с 512Mb оперативной памяти (по тем временам вообще-то огромный объем). Что сильно впечатлило автора.
Дело было, как я понял, где-то в районе 1992-1993 годов. Для меня тогда 512Mb было не то что огромным объемом – это было что-то фантастическое, существующее где-то там, в далекой буржуиндии :)))
Когда я осенью 1994-го пришел в КБСП, у нас был, по-моему, 386-й с 4Mb на борту. В последствии на нем крутился OS/2 Warp с TShell-ом, под которым успешно бегал DOOM2.
Весной 1995 наша лаборатория в универе приобрела 486-й с 4Mb. К концу года мы обзавелись вторым 486-м, на котором довели объем RAM сначала до 8Mb, затем до 16Mb. А когда мы где-то в декабре 1996-го заказывали в ТАИР-е Pentium 100MHz с 32Mb RAM у нас даже спросили: “А куда вы такой мощный сервер берете?” :)))
И я вот одной вещи понять не могу: переход с 8086/286 и даже с 386-х на 486-е и Pentium-ы действительно был качественным. Совсем другие возможности, совсем другие по сложности задачи можно было решать. И, что характерно, на Pentium II с 64-мя мегабайтами оперативки мы делали, в сущности, тоже самое, что сейчас на четырехядерных Core i5/i7 с гигабайтами оперативки и терабайтными дисками. Субъективно, делаем не лучше и не быстрее. Комфортнее – это да. Но не лучше. Как так?
Впрочем, вопрос риторический. Я просто ностальгирую. Вспоминаю, насколько более мокрой была раньше вода :)
PS. Раз уж упомянул данную статью, то до кучу скажу, что еще там зацепило. Автор привел высказывание некоего Greg Bollella, о том, что большому софтверному проекту требуется от 10 до 15 лет до достижения успеха. Считается время от зарождения самых-самых зачатков идеи, ее реализации, продвижения и, в конце-концов, до финансового успеха. Внушаить, однако.
Вчера впервые на широкой публике было объявлено об уходе Артема Кузнецова. Событие лично для меня очень серьезное, масштаб которого я пока еще не очень осознаю.
Артем – это один из тех немногих людей, с которых около восьми с половиной лет назад начиналось софтверное подразделение компании Интервэйл. С его непосредственным участием стартовало несколько стратегически важных направлений в линейке наших продуктов. А без его таланта, способностей и трудолюбия, я уверен, изрядная часть из них просто не выжила бы.
Мне повезло, что я проработал с Артемом эти восемь лет. Зачастую мы сильно спорили, часто занимали диаметрально противоположные позиции. Но, надеюсь, наши споры шли на пользу как нам самим, так и нашим разработкам. Лично я много чему научился от него. Скажу больше – за все время занятия программированием (а это уже более 20 лет) я был лично знаком всего с тремя людьми, которые программировали значительно лучше меня. Один из них – Артем Кузнецов.
Теперь пришло время человеку что-то серьезно поменять в своей жизни. Все течет, все изменяется. Очень жаль, но такова жизнь.
PS. Компания, которая упустит сейчас шанс заполучить Артема к себе потеряет очень и очень многое.
Вышла очередная версия библиотеки ACE – 5.8.2. Из основных изменений:
Скачать эту версию можно отсюда: http://download.dre.vanderbilt.edu/previous_versions/
Выглядит очень классно, но я не уверен, что сам бы хотел оказаться в числе тех, кого так провожают/встречают :)
Ссылка найдена здесь.
Сегодня в рубрике “Знакомство с фотомастером” пейзажи страстного фотолюбителя (а в обычной жизни ученого-физика) Леонида Домбровского.