пятница, 25 марта 2011 г.

[prog.idiotic;humour] Он знал ну уж очень много страшных слов

Я так понимаю, что в Рунете стремительно раскручивается эпидемия ссылок на неслабый перечень “всех-страшных-слов-которые-когда-либо-от-кого-либо-доводилось-слышать” под названием “Теоретический минимум для программиста”. Ну а если кто-то (как и я совсем недавно) еще не в курсе, то вот ссылка. Приятного чтения! :)

Лично меня убило упоминание LaTeX-а в пункте №33 “Проектирование GUI”.

Кстати, тем, кто хочет вывести свой блог в топы, имеет смысл изучить данный феномен. Вроде бы ничего сверхъестественного, но какой резонанс! :)))

[prog.bugs;humour] В какой-то левой кодировке ищут сейчас в Беларуси

Такой вот баннер обнаружился только что в одноклассниках:

Программ без багов не бывает ;)

[life.video.wow] Круто! (сбор дикого меда)

Внушаить. Жалко, что не показали, как он спускался.

Найдено здесь (via здесь).

четверг, 24 марта 2011 г.

[work] Быть начальником? Индивидуалист vs командный игрок

Небольшая заметочка в серию “Почему я не хочу быть начальником?” (предыдущая часть здесь).

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

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

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

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

На мой взгляд, дело в том, что в случае неудачи проекта программист все-таки может остаться довольным своим личным вкладом в проект. Это как в футболе – команде нужно было обязательно выиграть, но она с трудом сыграла в ничью 0:0. Результат неудачный, но вратарь, который вытянул несколько совершенно невероятных мячей и спас команду от, казалось бы, неминуемого разгрома, может быть доволен своей собственной игрой. Ведь не исключено, что это был лучший матч в его карьере ;)

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

[comp] Испытал легкий шок от фотографии MacBook-чной клавиатуры

Просматривал обзор новых MacBook-ов и взгляд зацепился за фотографию его клавиатуры:

Блин, а где же аппаратные клавиши Home, End, PgUp, PgDn?

У меня дома нетбук HP-шный и у него этих клавиш тоже нет. Что не просто страшно, а очень страшно раздражает. Но то нетбук 9” за $500 (в лучшие времена). А это топовая 17” модель MacBook-а за 100 с лишним тысяч RUR.

Афигеть.

Не, я понимаю, что яблокоманы смотрят на мир иначе и понятия об удобствах у них собственные. Я не понимаю, почему аблокоделы не могут 17” ноутбук снабдить нормальным набором кнопок.

[life.humour] Рекламное письмо напомнило анекдот

Только что получил рекламный e-mail с предложением некоторых услуг от какой-то шарашки за авторством менеджера по продажам по фамилии Ёжиков. Сразу вспомнился бородатый анекдот:

Выдержка из протокола заседания правления Банка Возрождение:

“…Запретить юрисконсульту Ёжикову В.А. отвечать по телефону: "Банк Возрождение, Ёжиков. Слушаю...", в связи с некорректными последующими вопросами контрагентов…”

Ну и чтобы два раза не вставать, еще один старый анекдот про неожиданные совпадения:

Приходит директор Института Культуры на работу и видит в своей приемной заплаканную секретаршу.

-- Наденька, что случилось?

-- Я двадцать лет ждала, ждала, что когда-нибудь позвонят и спросят: “Аллё, это прачечная?” и… И… И… вот сегодня позвонили, а я… а я… а я, дура, сказала, что они ошиблись номером….

среда, 23 марта 2011 г.

[prog.tools] Библиотеки для быстрой компрессии/декомпрессии данных

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

Ранее я сталкивался только с одним представителем данного класса – инструментом LZO (и его вариантом miniLZO). А сегодня, прочитав на opennet.ru анонс Google-овской библиотеки snappy с удивлением обнаружил, что LZO далеко не единственный представитель этого класса. Поэтому, в качестве памятки на будущее для себя решил составить вот такую табличку:

Инструмент Язык реализации Лицензия Примечания
LZO C Коммерческая или GPL  
Snappy C++ Apache  
libLZF C BSD Последний релиз в 2008.
FastLZ C MIT  
QuickLZ C Коммерческая или GPL Позционируют себя как самую быструю библиотеку в своем классе. Есть варианты на C# и Java.

вторник, 22 марта 2011 г.

[work] SourceForge перестал считать Web-статистику

В течении последних нескольких недель SourceForge в разделе статистики упорно показывал нули в счетчике посещений Web-страниц проекта. А затем окончательно объявил о том, что больше такая статистика не ведется:

Ранее эта статистика, насколько я помню, считалась на основе количества показов логотипа SourceForge, который нужно было размещать на страничках проекта.

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

понедельник, 21 марта 2011 г.

[work] Вообще-то я вовсе не против менеджеров, но вот планы…

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

Начну издалека, из детства :) В детстве, а затем и в юности, меня донимал вопрос: “Зачем оркестру дирижер?”

Ну действительно, зачем? Ведь у каждого музыканта есть ноты, каждый должен просто играть свою партию и всех делов. Вот в рок-группах, например, дирижеров нет, а как играют! Так зачем же дирижер оркестру?

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

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

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

Так что я вовсе не против менеджмента :)

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

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

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

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

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

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

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

А теперь попробуйте составить план-график разработки дизайна ванной комнаты!

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

Сколько вам нужно времени, чтобы выбрать плитку? На пол. На стены. Будет ли вообще плитка и там и там, или же нужно что-то другое? Если будет плитка, то какая: мелкая, обычная, крупная? Или их сочетание? Если сочетание, то какое? Плитка чьего производства, по какой цене, какого цвета и рисунка, в каком магазине, когда будет в наличии? А теперь укажите прогресс в данном вопросе в процентах!

Какая вам нужна ванна? И нужна ли вообще? Может лучше душевую кабину – с мелким поддоном? Или с глубоким? А какая должна быть раковина? И где она должна стоять? А будет ли она мешать стиральной машине? А если стиральная машина со временем поменяется? Насколько процентов вы реализовали данную задачу за прошедшую неделю?

Так что все-таки на счет план-графика создания дизайн-проекта? В каком порядке должны выстраиваться конкретные работы? Какие между ними зависимости? Какова их длительность? Насколько актуально будет вести отчетность об этом процессе в Project-е? И опять же, почему не проставлены проценты в текущих тасках?!!! ;)

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

[life.sport.darts] Продаю дротики Target T0.1 23g 80% в Гомеле

В связи с расширением своего арсенала вынужден сокращать старые запасы. В связи с этим продаю свои Target T0.1 весом 23g с 80% содержанием вольфрама.

Подробнее можно посмотреть здесь.

В комплект входят:

  • три барреля (б/у, но в хорошем состоянии);
  • два комплекта новых нейлоновых хвостиков размера medium с колечками;
  • два комплекта новых 100мкм перышек McCoy (стандартной формы);
  • фирменная коробка Target T0.1 (заменяет кейс для дротиков).

Цена вопроса – 60K BYR. В Гомеле. (Для справки – в местных магазинах латунные дротики Harrows весом в 18-19г. стоят 100K, а вольфрамовых нет как класса).

В принципе, можно и в Минске, но там я окажусь только на ближайшем турнире БПФД, а когда этот турнир состоится – пока неизвестно :(

[work] На этом месте в резюме я всегда плачу…

…когда соискатель перечисляет уровни владения языками программирования в баллах (1 – имею общее представление, 2 – написание небольших программ, 3 – большой опыт программирования):

C 3
C++ 3
Visual C++ 3
C# 3
WWW 1
HTML 2

Собственно, постебаться можно и с языка WWW, и с небольших программ на языке HTML.

Но печально совсем другое: как можно имея серьезный опыт разработки программ выделять отдельно C++ и отдельно Visual C++? Ну нет такого языка программирования! Нет! Есть C++, есть (или был) C++/CLI (а до этого Managed C++). Но Visual C++ – это не язык программирования. Это среда разработки.

Так что уважаемые соискатели, не позорьтесь! Сразу после того, как вы объявляете о хорошем знании языка Visual C++ желание продолжать разговор мгновенно испаряется.

PS. Все совпадения с реальными персонажами случайны и непреднамеренны.