[life] Об изменении отношения к некоторым вещам при напряженной работе

В последние две-три недели ко мне в блог некоторый процент читателей попадает по поисковым фразам вроде “работать по 12 часов в сутки”. Не то, чтобы я был докой в этом деле, но периодически работать по 10-12 часов случалось. И, надо сказать, такие вещи не проходили просто так.

Первый интересный эффект я заметил несколько лет назад. Я тогда писал so_4_book, и для этого приходись вставать в 4:45, работать несколько часов, потом собираться, ехать в офис и работать там еще полный рабочий день. Не удивительно, что при таком графике я становился раздражительным. И очень сильно раздражало меня нежелание окружающих меня людей напрягаться. Т.е. вполне нормальное желание человека отложить на следующий день то, что он не успевает сделать сегодня. Но для меня это было неприемлимым. Если я выкладываюсь для того, чтобы успеть сделать больше, то почему этого не делают другие? Умом-то я это понимал, а вот принять было тяжело.

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

[prog] Ребята из Microsoft разрабатывают менеджер OpenSource-пакетов под названием CoApp

Только недавно я матерно ругался о необходимости системы дистрибуции C++ библиотек, как оказалось, что в MS уже работают над этой проблемой – открыт проект CoApp. Только я хотел видеть кроссплатформенный менеджер, а CoApp будет специально заточенной под Windows штукой.

Проект в очень ранней стадии развития и что из него вырастет пока не понятно. Самое толковое, что я смог заметить на сайте проекта это:

• What is CoApp? – небольшая заметка о назначении и целях проекта;
• Common Package Blueprint – черновые наброски того, как планируется размещать исходные тексты и библиотеки управляемых CoApp-ом проектов. Из этого документика становится более-менее понятно, что это будет.

Чуть драматизирую ситуацию: имхо, самый худший вариант воплощается в жизнь. Раньше у Unix-оидов были свои любимые игрушки (autotools, собственные системы пакетов в каждом дистрибутиве). И их не волновало то, что под Windows все по-другому. Если доводилось использовать Unix-овую библиотеку под Windows, то приходилось самостоятельно конфигурировать ее. Теперь, если CoApp выживет, такая же любимая игрушка появится и у виндузятников. И их так же не будет волновать то, что под Unix-ами нет CoApp-а. Принцип разделяй и властвуй в действии :/

[prog.humour] Типа бизнес-идея: eBuben – сервис для разработчиков

По следам баг-трекера ну-и-Потрахаться eTraxis появилась идея: создать сервис для разработчиков eBuben – он-лайн магазин по продаже бубнов и шаманских заклинаний. Новых и бывших в употреблении. Бубнов массового изготовления от ведущих производителей и штучные, изготавливаемые под заказ известными гуру от программирования. С рейтингом популярности тех или иных видов бубнов, с обзорами независимых экспертов, с отзывами покупателей…

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

[prog.humour] Хорошее такое название для баг-трекера: eTraxis

www.etraxis.org – GPL-ный баг-трекер. Для русскоязычного пользователя его название имеет особый смысл ;)

[work.thoughts] О понимании условий задач и полезности олимпиадного программирования

Вот какая мысль одолевает меня сегодня с самого утра…

Вскоре после того, как я начал программировать, я осознал очень важную вещь – программисты ошибаются. Все. Всегда. Часто. Очень часто. Программ без ошибок не бывает. Вообще.

Если кто-то хочет с этим поспорить – лучше напишите еще сотню-другую тысяч строк кода. Спорить не придется.

Но это банальность, про это все программисты очень быстро узнают. Что есть хорошо.

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

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

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

После такого длительного вбрасывания зайду с другой стороны…

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

Более того, для меня теперь факт участия человека в олимпиадах является “волчьим билетом”. По моим наблюдениям, успешные олимпиадные программисты делятся на две категории:

• первая и самая большая – это люди, которые могут решать олимпиадные задачи в олимпиадных условиях и все. В пиковом режиме “расколоть” очередную задачку на перебор и поиск чего-нибудь, быстро и абы-как все это закодировать и пройти максимум тестов – это пожалуйста. Но если скрупулезно изучать чужую спецификацию и педантично воплощать ее в жизнь в течении нескольких месяцев (а то и лет) –  здесь они пасуют;
• вторая, редкая и малочисленная – это программисты от Бога, которым все равно, решают ли они олимпиадную задачу, реализуют ли они TCP/IP стек для встраиваемой операционной системы или делают Web-2.0 морду для очередного интернет-магазина. Столкнуться с таким человеком – это большая удача, практически, как найти килограммовый золотой самородок. Лично я за 20 лет занятия программированием встречался только с двумя такими людьми (один из них работает у нас).

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

А теперь возвращаемся к первоначальному вбрасыванию…

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

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

Вот так, неожиданно для себя, я открыл хорошую сторону олимпиадного программирования. Т.е., если без фанатизма, то в школе/ВУЗе принять участие в 2-3 олимпиадах может быть и полезно.

PS. Кстати говоря, домыслы программистов об условиях задач – это очень серьезный бич. Например, есть задача – отослать в 01:00 на указанный e-mail сводку об активности за день, которая должна находиться на указанном сетевом ресурсе. Тупая реализация в лоб: берешь сводку, отсылаешь, забиваешь на все ошибки. Если же подойти обстоятельно, то нужно уточнить: а что делать, если сводка не готова к указанному времени? А что делать, если размер сводки по каким-то причинам оказался больше разумного объема (и есть ли вообще этот разумный объем)? А что делать, если связаться с STMP сервером не удалось? А что делать… В общем, в любой задаче есть достаточно вопросов, чтобы задолбать ими постановщика задачи ;)

[foto.humour] Нафотошопили! :)

Блог, в котором демонстрируются ляпы фотошоперов: Photoshop Disasters. Поскольку я далек от этого ремесла, то иногда приходится долго рассматривать картинку, чтобы понять что к чему. Но некоторые “вставляют” даже меня:

[comp.prog] Amazon’s Dynamo: заключительная заметка

Эта (давно обещанная) заметка завершает рассказ о статье Dynamo: Amazon's Highly Available Key-value Store. Вот предыдущие части:

Amazon’s Dynamo: версионность объектов
Amazon’s Dynamo: распределение объектов по узлам системы
Amazon’s Dymano: репликация объектов и диагностирование сбоев

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

Service Level Agreements (SLA). В статье упоминается, что все службы внутри Dynamo договариваются между собой о качестве предоставления услуг посредством т.н. Service Level Agreement (SLA). Например, сервер в своем SLA может указать, что он гарантирует время отклика в 300ms для 99.9% запросов при пиковой нагрузке в 500 запросов в секунду. При этом подчеркивается, что в Dynamo делают расчет именно исходя из цифры 99.9%. Т.е. если какой-то сервер заявляет свои возможности, то он заявляет их для 99.9% запросов. Так обеспечивается качество обслуживания для подавляющего большинства пользователей Amazon-овских сервисов.

Меня, правда, больше интересует, каким образом SLA используется на программном уровне при построении компонентов. Например, подключается какая-то Amazon-овская служба к нескольким узлам Dynamo и получает от каждого узла SLA. Используются ли эти SLA для распределения запросов по узлам? Или может ли узел Dynamo динамически изменять свой SLA в зависимости от количества подключившихся к нему клиентов? Скажем, первому он обеспечивает отклик в 300ms, второму – всего лишь 450, а третьему – жалкие 800ms? К сожалению, в статье об этом не говорится.

Два способа общения с узлами Dynamo. Когда какой-нибудь сервис хочет воспользоваться услугами Dynamo, он имеет выбор: либо подключиться через Dynamo-вский балансировщик нагрузки, либо использовать специальную клиентскую библиотеку. Если работать через балансировщик, то запрос проходит дополнительную стадию – выбор узла для обработки запроса. А в случае клиентской библиотеки этой стадии нет, и запрос сразу же направляется нужному узлу. Что может уменьшать время выполнения запроса в два и более раз.

Выбор узла для чтения значения. Для того, чтобы оптимизировать распределение запросов между узлами, в Dynamo применяется простой трюк: координатором для операции read назначается узел, который до этого выполнял координацию операции write. Т.е. если клиент записал объект X и координатором выступал узел N, то при последующем чтении объекта X (которое, как правило, сразу же следует за записью), узел N будет координатором операции чтения.

Read repair. Когда координатор операции read принимает ответы от реплик, он не сразу прекращает прием ответов. Вместо этого он еще некоторое время ждет ответы от всех узлов и проверяет полученные версии. Если какой-то узел присылает устаревшую версию (т.е. узел по какой-то причине пропустил обновление объекта), то на узел отсылается новая версия объекта. Эта операция называется read repair и используется она для уменьшения энтропии в случае рассогласования реплик.

Детали реализации. Все службы Amazon’s Dynamo написаны на Java. При реализации использовался событийно-ориентированный подход и организация очередей сообщений между стадиям обработки запросов по образу SEDA. В качестве хранилищ информации используются Berkeley Database Transactional Data Store, Berkeley Database Java Edition, MySQL и in-memory буфера с периодическим сбрасыванием содержимого на диск. BDB используется для хранения объектов, не превышающих размеров более нескольких десятков килобайт, тогда как MySQL задействуется для объектов большего размера. Большинство узлов Dynamo задействуют BDB Transactional Data Store.

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

PS. Вот, собственно, и все. Приношу читателям свои извинения за то, что рассказ об Amazon’s Dynamo затянулся на два месяца. Надеюсь, что данная серия заметок была интересной.

[prog] О том, что нужно OpenSource проекту для привлечения пользователей (на примере супер-пупер языка на букву Ны)

Представьте, что вы развиваете OpenSource проект. Что-нибудь для разработчиков – язык программирования, СУБД, универсальную библиотеку общего назначения или какой-то специализированный фреймворк. Вы воплощаете в нем свои идеи и вам кажется, что вы все делаете правильно. Но почему-то пользователей у вашего проекта не много. Почему?

Имхо, это вопрос почти на миллион долларов :) Ведь если узнать причину неудачи, то можно ее устранить. Так что дело за малым – узнать ;)

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

На мой взгляд, с основными причинами нежелания разработчиков связываться с Nemerle нужно ознакомиться всем лидерам подобных OpenSource-проектов. Поскольку, если заменить Nemerle на, скажем, Vala, Falcon, Fanton или SObjectizer, то список причин не сильно изменится.

Итак, начинать нужно с голосования: http://www.rsdn.ru/poll/2558.aspx
Самая важная причина (на данный момент) – отсутствие серьезной организации за проектом (~49% опрошенных).
Далее следуют:

• разработчикам хватает возможностей других мейнстрим-инструментов (~27%);
• опасение за то, что уход владеющего инструментом разработчика оставит команду в сложном положении (~23%);
• недостаточно стабильный статус проекта, обилие багов (~23%);
• невозможность использования проекта из-за привязки к конкретной платформе (~22%).

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

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

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

В общем, community привлекает community. Хотите иметь community вокруг проекта – уделяйте community не меньше внимания, чем самому проекту. А то и больше.

[life.humour] Вот это первоапрельский розыгрыш!

http://ifun.ru/view/126365 – это нужно посмотреть самому, пересказывать бесполезно :)

PS. Ссылка найдена здесь: http://www.rsdn.ru/forum/humour/3762787.aspx

[work] Впечатления после второго раунда собеседований

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

Самое яркое впечатление от второго раунда – наблюдается перекос в обратную сторону: от примитивных реализаций тестовой задачи на 2-3 странички к развесистым решениям на 15-20 страниц; от незнания элементарных вещей в C++ к злоупотреблению этими знаниями. Второй волне соискателей явно не хватало опыта, чтобы понять, что “простота не предшествует сложности, а следует за ней” (Алан Перлис) или, говоря по-русски: “сложно сделать не сложно, не просто сделать просто” ;)

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

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

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

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

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

[life.photo] Макрофотографии Mirosław Świętek

О фотографе Mirosław Świętek я узнал с подачи ув.тов.ShaggyOwl. Посмотреть действительно есть на что: