Способность по-новому взглянуть на вещи (антиконсерватизм), наибольшая эмоциональность, индивидуальность, эгоизм, упрямство, защищенность, иногда переходящая в замкнутость. Способность ослепительно улыбаться.
И откуда они все знают? ;)
PS. Найдено у thesz.
Третья часть сегодняшней серии. Как известно, в политике, медицине и футболе разбираются все. Я, к тому же, точно так же хорошо разбираюсь и в искусстве. А потому позволю себе высказаться на тему…
…ассиметричного ответа искусствоведу.
На просторах Интернета нашел ссылку на совершенно фантастический блог-пост “к сорок восьмой годовщине”. Который является ассиметричным ответом на интервью искусствоведа Е.Дёготь. Точнее, той части интервью, в которой произведением искусства объявляется “Дерьмо художника”.
На мой рабоче-крестьянский взгляд, в выступлении Е.Дёготь наибольший резонанс вызвали две вещи:
В общем, это мы, далекие от искусства люди можем придумывать себе разные критерии “искусности”. У меня, например, произведение искусства должно содержать, во-первых, неординарную идею и, во-вторых, высокое исполнительское мастерство. В произведении искусства должно быть что-то, что недоступно простому смертному ни по форме, ни по содержанию (т.е. тупо говоря, я не могу этого даже повторить). Но это все мои собственные тараканы… Очень и очень далекие от настоящего, а тем более современного актуального искусства.
Ибо, здесь уместна аналогия. Как широко известно (в узких кругах), оперировать большими суммами могут всего лишь две категории людей: математики и миллионеры. Поскольку только они, а не простые обыватели, более-менее точно представляют, что такое миллион, а что такое миллиард. Вот точно так же и с искусством. Разбираются в нем всего лишь две категории людей: искусствоведы и миллионеры. Первые, знают о искусстве, поскольку зарабатывают этим на жизнь. А вторые знают об искусстве, поскольку вкладывают в него свои деньги. Все остальные (включая меня) знают об этом столько же, сколько о политике, медицине и футболе :)
Сухой остаток. Ну я хотя бы узнал о существовании “Дерьма художника”. Границы “крепчания маразма” в моем понимании очень серьезно расширились.
Вторая часть сегодняшней серии.
А ведь мне ни разу не пригодилось резюме…
Люблю на время от времени почитать форум О работе. Такие там знатоки жизни попадаются! Везде успели поработать, все видели, все знают, все умеют, по $1K в день зашибают. В общем, такие монстры, что остается только недоумевать по поводу двух вещей:
Ну да не о том речь.
Давеча наткнулся я на тему Сколько просить за резюме? (программист C++, Москва). Девушка-программист (девушка-программист!) приводит свое резюме и спрашивает, на какую сумму она может рассчитывать в Москве. Обсуждение неинтересное, тему захламили страдающие от весеннего спермотоксикоза личности мужеского полу. Из самого резюме, если бы мне довелось его оценивать, я так и не понял, почему именно ее нужно брать на работу (ну разве что хороший английский, все остальное – какие-то общие слова).
Но меня зацепило другое. Прочитал я приведенное в начале темы резюме и задумался, а что бы я сам смог в своем резюме написать? Вот ведь, вопросец. Наверное, ничего бы не написал. Поскольку по ходу работы над проектами я никаких записок-памяток не веду и даже вспомнить сейчас многое из сделанного в прошлом вряд ли получится. Более того, я даже не знаю, что бы перечислил в списке инструментов и платформ, которыми владею. Вот ведь…
Потом я с удивлением вспомнил, что вообще никогда не устраивался на работу с помощью резюме. Году в 1993-м меня вместе с несколькими студентами один преподаватель отправил на просмотр в некую фирму. К счастью, там по какой-то мутной причине не сложилось – не довелось профессионально попрограммировать на Clipper-е :) Затем в 1994-м я сам напросился к другому преподавателю, который меня знал по своему курсу. Но и там, к счастью не сложилось – как раз летом 94-го в Белоруссии перекрыли какой-то способ обналичивания денег и фирма не знала, как выплачивать деньги своим старым сотрудникам, не говоря уже про новых. Так я и не стал профессиональным системным администратором :) Осенью 94-го (ух ты, в этом году будет 15 лет моей профессиональной деятельности) мы с друзьями подались в КБСП – нас туда позвал еще один преподаватель, который читал нам пару предметов на предыдущем курсе и который звал нас к себе. А весной 95-го на другую работу меня с другом сосватал заведующий нашей кафедрой, который так же меня хорошо знал. Вот так и получилось, что на свои первые места работы я попал исключительно по знакомству. Никакого резюме не требовалось.
В 2001-м, когда я надумал уходить из КБСП мой друг позвал меня в EPAm. Так что и туда я попал без резюме и по знакомству. И ушел из EPAm-а в Интервэйл так же по знакомству – благодаря другу, который пришел работать в Интервэйл из КБСП раньше. Так что и здесь резюме не потребовалось :)
Конечно, все это совсем не показатель, т.к. Гомель – это маленький город. Фактически даже большая деревня, в которой все всех знают. В Москве или Питере ситуация явно другая. Но, думается мне, что и там хорошие спецы (ну тут типа намек, что я и сам как бы такой хороший спец :)) находят себе работу вовсе не через рассылку резюме. В особенности, если и учились они в Москве. Ведь толковых программистов всегда мало, их замечают и начинают “сватать” еще в студенчестве. А затем стараются заполучить проверенных людей, с которыми работали раньше, переманивая их с одного места на другое. Хотя, может я и ошибаюсь.
Однако, хотелось бы думать, что найм людей “по репутации” все-таки существует. Т.е. работает себе человек, тянет проекты, где-то засвечивается. Его запоминают, а затем выходят на него с заманчивым предложением :) Поскольку мне кажется, что это более надежный способ найма правильных людей, чем анализ резюме или обращение к рекрутерским компаниям. Но, опять же, поскольку работу я менял всего лишь два раза за пятнадцать лет, то опыта в этом деле у меня нет. Поэтому и могу выдавать желаемое за действительное.
В любом случае, надеюсь, что приобретать опыт написания резюме мне в ближайшее время не потребуется. А лучше, чтобы вообще не потребовался :)
Сегодня будет серия заметок в полном смысле “размышлизмы” – думал, думал, ничего не придумал. Но ведь думал же, размышлял… :)
Что может помочь языкам вроде Ada и Eiffel?
На RSDN дали ссылочку на материалы конференции BoostCon 2009. Просмотрел бегло первую презентацию C++0x overview and Compiler support. С++0x обещает много вкусного, но жалко, что процесс его выхода откладывается до 2010/11 годов. Я уж, грешным делом, надеялся, что C++0x ратифицируют в этом году. Ну да ладно, зато есть надежда, что к моменту ратификации стандарта нужные мне вкусности языка (лямбды, Rvalue refernces, atomic-операции, поддержка многопоточности в стандартной библиотеке, вывод типов) уже будут реализованы в компиляторах GCC и VC++.
Но суть не в этом. Язык C++ после выхода C++0x станет еще сложнее. Да, в чем-то он упроститься, но все-таки в общем он станет больше и сложнее. Я уже не представляю, как можно будет обучать C++ новичков. Мне еще, можно сказать, повезло – новые возможности языка я мог осваивать постепенно, по мере выхода новых версий компиляторов. А если кто-нибудь берется изучать C++ сейчас… И что будет лет через пять?
Наверное, в том, что язык программирования становится очень сложным, нет ничего удивительного. Сложные задачи требуют сложных инструментов. И усложнения происходят не только в C++, но и в гораздо более простых, по началу, Java и C#. И данный процесс будет продолжаться.
Тезис о том, что язык становится все более и более переусложненным, и что его уже нужно будет как-то урезать, всплыл в RSDN-овском обсуждении. На что я сказал, что смысла нарушать совместимость версий C++ нет. Мол, если кто-то хочет несовместимый с C++ язык, то уже сейчас можно брать Ada 2005 или Eiffel. Поскольку они одного поля ягоды и, в общем-то, предназначены для одних и тех же задач (Java и C# здесь не будем рассматривать, т.к. это managed платформы, у них своя ориентация).
Так вот, сказал я про Ada 2005 и Eiffel и подумал: “Ведь сейчас это, фактически, нишевые языки. И даже если пока они еще не находятся в глубокой ж…, то совсем скоро рискуют там оказаться. И что может помочь им из этой ж… выбраться?”
Прежде, чем идти дальше, нужно пояснить, почему я думаю, что Ada с Eiffel находятся именно там, где они сейчас находятся. Просто потому, что они не на слуху. Мне не встречается информация о каких-то OpenSource проектах, которые делают на этих языках. Я не слышал, чтобы кто-то написал на Ada или Eiffel какую-нибудь freeware или shareware приблуду. Я не видел, чтобы где-нибудь в форумах встречался человек, который бы регулярно делился опытом выполнения проектов на Ada/Eiffel. Даже книги по этим языкам нужно целеустремленно искать. В общем, вроде как языки и есть, и даже используются в очень серьезных секторах (та же Ada до сих пор, насколько мне известно, основной язык для разработки разнообразного ПО для авиации и военных в США). Но их не видно, они не на слуху. А раз язык не на слуху, очень невыгодно брать его для реализации “обычных” проектов, в обычных условиях. Потому, что готовых специалистов для него нет, инструменты либо очень дорогие, либо их не найти, микроскопическое community.
Итак, если поставить цель сделать языки Ada и Eiffel на порядок более привлекательными для массового использования, то что дня этого нужно?
А вот и не знаю, что именно. Боюсь, что они уже достигли той точки, после который обычному разработчику они, что называется, “даром не нужны”. Т.е., даже если средства разработки и фреймворки для Ada/Eiffel будет раздаваться совершенно бесплатно для любых проектов (сейчас, AFAIK, есть GPL версии GNAT Pro и Eiffel Studio, которые бесплатны для OpenSource разработок), то они все равно окажутся невостребованными. Ну не верится мне, что, например, армия разработчиков shareware-программ вдруг откажется от C++ в пользу Eiffel (хотя с практической точки зрения это вполне могло бы иметь смысл). Т.е. для создания программ класса “быстро-написал-и-быстро-выбросил” эти языки точно не подходят. Их вотчина – солидные, большие, длительные проекты. Где они уже, собственно говоря, и присутствуют. И еще будут присутствовать какое-то время. Поскольку мегатонны кода уже написаны. Вот так Ada с Eiffel-ем, вероятно, и будут продолжать сидеть в уже занятых нишах. Откуда их потихонечку, помаленечку, будут выживать. Тот же C++ с одной стороны. Те же Java/C# с другой. Просто потому, что одно за одним подрастают поколения программистов, которые о Ada и Eiffel даже не слышали. Не говоря уже о том, чтобы попробовать. И когда на этих программистов ляжет ответственность за развитие унаследованных Ada/Eiffel проектов, то очень многие из них не откажутся от соблазна перейти на что-нибудь более привычное. Пусть не сразу, но постепенно, со временем выбрасывая старый код и заменяя его новым.
Что во всем этом мне кажется ненормальным, так это то, что с технической точки зрения у того же C++ совсем не много преимуществ над Ada/Eiffel. Правильнее было бы сказать, что где-то лучше C++, где-то хуже. А в общем, тоже самое, вид сбоку. Только С++ популярный и раскрученный, а Ada/Eiffel – нет. Хотя у Ada и Eiffel, на мой взгляд, “коэффициент спокойного сна” гораздо выше, чем у С++. Я бы и сам, наверное, сейчас предпочел бы программировать на Eiffel, а не на C++. Как раз из-за того, что в своем Eiffel-евском коде я бы был более уверен, чем в C++ном. Но, слишком много всяких нетехнических факторов против Eiffel. Это-то и обидно. Ну да ладно я, у меня ситуация такая, что слишком уж много чего от имеющегося C++ кода зависит. Но обидно, что какой-нибудь юный разработчик не сможет взять для реализации какой-нибудь своей идеи Ada или Eiffel по тем же самым нетехническим соображениям.
По большому счету, тут можно задать вопрос: “А зачем вообще нужно пробовать пропагандировать Ada и Eiffel? Чем их использование будет лучше использования C++?” Но это уже совсем другая история…
…или до чего может дойти пропаганда :)
Ярые проповедники функционального программирования иногда поражают своей верой в чудеса. Вот совсем свежий пример. В блоге известного на RSDN хаскелиста Сергея Зефирова приведена цитата:
The financial markets have crashed. One important reason seems to be the trading in financial derivatives. These derivatives can be so complex that it’s very hard to estimate their value. Now if only there was a domain specific language for describing and evaluating such financial contracts...
A few weeks ago, GMail had a major outage. Edwin Brady pointed out a press release by Google that blamed ‘unexpected side effects of some new code’ – now if only there was some way to ensure code doesn’t have side effects...
This leads me to believe that Haskell is currently solving problems that will affect society in ten years or so. I predict there’s a major telecom blackout because Erlang fails to do parallel garbage collection. Maybe major bank systems will crash because of a mistake in taking the wrong locks during transactions. Or perhaps an epic fail of Amazon’s databases after an incorrect type cast.
(сама цитата взята отсюда, выделение жирным Сергея Зефирова).
Теперь мне кажется, что агитация за функциональный подход вообще, и за языки типа Haskell в частности, недостаточно глобальна и фундаментальна. Если уж люди верят в способность Haskell-я предотвращать финансовые кризисы, то нужно еще объявить его самым лучшим средством по борьбе с парниковым эффектом. Нет… Это тоже мелко. Путь будет лучше средство от облысения! Вот! А еще лучше – эликсиром молодости! Да, вот это глобально и надежно! :)
Кстати, вот что говорит о проблемах с GMail некто Acacio Cruz, Gmail Site Reliability Manager:
Lots of folks are asking what happened, so we thought you'd like an explanation. This morning, there was a routine maintenance event in one of our European data centers. This typically causes no disruption because accounts are simply served out of another data center.
Unexpected side effects of some new code that tries to keep data geographically close to its owner caused another data center in Europe to become overloaded, and that caused cascading problems from one data center to another. It took us about an hour to get it all back under control.
В Интернете так же можно найти официальный отчет о произошедшем от Google: Gmail Incident Report.
Вот так правят баги разработчики ACE!
Есть такая C++ библиотека – ACE. В принципе, очень хорошая библиотека. С большим количеством возможностей. Портированная под большое количество платформ. Бесплатная. Пользуемся ей уже года четыре. Но чем больше пользуемся, тем больше хочется сменить ее на что-нибудь другое (например, Qt или Poco, или даже Boost). Причем не столько из-за качества самой библиотеки, сколько от качества ее развития. Как раз на днях в очередной раз был удивлен этим качеством (точнее, его отсутствием).
Итак, история такова. В сентябре 2008-го года (более семи месяцев назад!) вышла версия ACE 5.6.6. В которой я сразу же нашел критический баг – из-за ошибки в классе ACE_Thread_Manager многопоточное приложение временами падало при завершении нитей. Потратив несколько часов и убив кучу нервов (поскольку баг проявлялся в новой версии SObjectizer, которую мы только-только закончили и собирались публиковать, и я первым делом искал проблемы в SObjectizer) я ошибку нашел. И запостил описание бага в ACE-овскую багзилу, да не просто описание, а с патчем для его исправления. В сентябре 2008-го… Через полтора месяца после выхода ACE 5.6.6 вышла версия ACE 5.6.7, в которой данной проблемы уже не было. И я, грешным делом, подумал, что найденный мной баг исправили.
Но буквально позавчера (на дворе май 2009-го!) приходит мне письмо из ACE-овской багзилы. Мол, пытаемся накатить ваш патч и после этого у нас падает тест Thread_Pool_Test. Можете ли, мол, прислать работающий патч. Работающий, блин! Мало того, в описании бага теперь значится, что я числюсь как человек, который диагностировал баг, и, сюрпрайз-сюрпрайз, как ответственный за его устранение!
Зашибись, ребята работают! Я им полгода назад выслал патч для конкретной версии 5.6.6. Они его проигнорировали тогда. И вместо применения моего патча, просто откатили какие-то изменения, которые были сделаны при переходе от 5.6.5 к 5.6.6. А теперь, после выхода 5.6.7, 5.6.8 и 5.6.9, они пытаются применить мой патч. И я теперь должен опять тратить свое время для того, чтобы понять что к чему.
Для того, чтобы разобраться, пришлось тянуть HEAD-ветку из svn-репозитория. Затем ставить себе Perl, чтобы через MPC сгенерировать себе проектные файлы… И все это для того, чтобы выяснить две простые вещи:
В общем, закинул я им обновленный патч. Но осадочек-то остался. Какого хрена было тянуть полгода, а потом пытаться в версии 5.6.10 фиксить баг из версии 5.6.6? Это для меня загадка. Да при этом назначать меня ответственным за его исправление.
Вот, блин, OpenSource в одном из своих ярких представлений. Но я все равно не понимаю… Ну не хватает у вас ресурсов на поддержание проекта в актуальном состоянии, так нафига вы его под BSD-like лицензии выкладываете? Продавайте за деньги, как Qt. И живите с этих денег. А нет, так оперативно разбирайтесь с тем, что вам пользователи присылают.
А ведь где-то осенью 2008 мы заслали к ним патч для расширения функциональности ACE_TTY_IO под Win32. И он так и не был принят до сих пор. Теперь я не удивлюсь, если осенью 2009 я получу очередное письмо с просьбой прислать актуальную версию нашего прошлогоднего исправления.
2.5M euro на разработку MINIX 3!
Вот это было приятное удивление. Уже несколько лет знаменитый Эндрю Таненбаум (Andrew Tanenbaum) занимается разработкой MINIX 3, Unix-подобной операционной системы, построенной на принципах микроядра. На неделе я узнал, что в конце 2008-го года он получил грант в 2.5M евро на свою разработку. Что позволит продолжать работу над MINIX 3 еще в течении пяти лет.
Хоть мне самому от этого ни тепло, ни холодно, но все равно приятно. Имхо, это правильно, когда таким заслуженным дядькам, как Таненбаум, дают возможность сделать что-нибудь стоящее.
Водопроводный кран с тачскрином и распознаванием физиономий!
Ну это просто из разряда “афигеть”:
Водопроводный кран с сенсорным экраном. И камерой! И распознаванием лиц пользователей! Т.е. настраиваешь себе ту температуру, которая нравится, сохраняешь настройку. Потом подходишь – кран на тебя смотрит внимательно, и включает именно ту температуру, которую ты когда-то заказывал :)
