Gaperton's blog

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

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

Зачем банить мудаков, и что такого плохого они делают? И главное, как отличать мудаков от обычных людей? Давайте разберем тему сетевых мудаков подробнее. Это вовсе не сложный вопрос. Он простой. Ибо...

1) ...истинный мудак виден с первого комментария.
( О мудаках, или как я модерирую свой журнал )

Здесь

Слайды, в принципе, информативны, и содержат основные тезисы. Но запись лучше. Видеозапись будет доступна позднее на сайте конференции.

В конце 90-х и начале 2000-х, когда мы с коллегами-программистами начинали всерьез интересоваться проблемами организации разработки ПО, годной литературы на русском языке было очень мало, а интернет в России еще под стол пешком ходил. Но это не означает, что не было книг о Методологиях. И вера в силу методологий и процессов была невероятно высока.

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

Но понимали ли мы, почему надо делать так, как пишут в "учебниках"? Почему оно работает, когда работает, и наоборот?

Ну разумеется нет, откуда? Для этого требуется кое-что большее, чем ум, и свежая голова.
( Читать )

Это будет доклад о том, что вы всегда хотели знать, но боялись спросить. Это доклад о проектировании. Главных тезиса два.

1) Хорошо организованная группа профессионалов всегда проектирует лучше, чем один мегаумный архитектор. Я собираюсь это настолько хорошо обосновать, что это близко к "доказать".
2) Менеджер может эффективно направлять и контролировать процесс проектирования, в том числе надежно отмечать его прогресс. Я собираюсь не просто это сказать, а наглядно и просто показать - как, так, что вы сможете это повторить. Ведь понимание требуется для действия - или нафиг оно не нужно, такое негодное понимание.

В сущности, без участия менеджера (руководителя группы, отдела, whatever) групповой процесс проектирования невозможен. Это не основная мысль, это то, что станет понятно по ходу изложения.

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

P.S.: Мне повезло - в разные моменты жизни мне приходилось лично заниматься всеми из перечисленных, непохожими друг на друга, областями. :) При этом, мне не придется рассказывать вам про них, и пугать вас тем, в чем вы не разбираетесь.

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

P.P.S.: На тот случай, если кто не знает, что такое SoftwarePeople. www.softwarepeople.ru. Регистируйтесь.

Да, тот самый ДеМарко. Автор блистательных Peopeware, Deadline, Вальсируя с медведями. Лучший эксперт в области управления разработкой в мире.

Приезжает в первый раз. И не один, а вместе с Тимом Листером (соавтор Peopleware), Питером Хрющкой (один из соавторов ДеМарко в "Балдеющих от адреналина..."), и остальными своими коллегами из Atlantic Systems Guild, кроме Стива МакМиллана.

Они в пятером прочтут трехдневный семинар 28-30 марта. См. программу.

Это, безусловно, самое значительное событие в общественной жизни российского IT за всю его историю. Кто-то может считать иначе, но мне кажется именно так. Я иду.

Посмотрел все пропозалы для модулей в CommonJS, и расстроился. Настолько, что добавил к ним свой.

http://wiki.commonjs.org/wiki/Modules/Async/B

Многим кажется, что негодяй всегда имеет преимущество перед порядочным человеком. Поступки этичного человека ограничены рамками, в то время как поступки негодяя ничем не ограничены, и потому он в заведомо выигрышном положении.

В действительности, это, конечно же, не так. И более того – ровно наоборот. Люди, склонные так рассуждать, упускают простой факт - что человек животное общественное, и не может существовать сам по себе.

( more )

Нокия таки представила два новых телефона.

E6 - продолжатель знаменитого E72, прямого и очень сильного конкурента блекбери. Теперь с сенсорным экраном. Это есть у них на сайте.

И таки Nokia N9 - телефон под meego, разработка которого со слов одного мудака будет свернута. Meego - лучшая, и наиболее совершенная разработка Nokia.

Напоминаю, что если бы не слова одного мудака представителя менеджмента Нокиа, то акции Nokia не припали бы за несколько месяцев до 5 баксов с 12-ти, с момента, когда он эти слова произносил (справка - столько стоили акции Нокиа в 98 году). И это событие - выпуск первого аппарата на Meego - было бы событием, а не так, как сейчас.

Топ-менеджменту, право, стоит хорошенько думать о том, что он говорит.

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

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

( More )

Программист, заступая на новую работу, каждый раз искренне изумляется и негодует, что "система не документирована". Это негодование - по соей силе бледное подобие негодования второго рода, которое тот же программист испытывает, если ему предложить описать простым человеческим языком, что он недавно наколбасил. И не забывать регулярно обновлять каждый раз, когда он вносит в колбасево изменения.

Но это все проза жизни. Что _действительно_ удивительно - это то, перечисленное не мешает программисту на следующем месте работы опять искренне удивляться, что "система не документирована". Ну пиздец же, правда? :)

Терминальной стадией болезни является требование найма "документатора". Это обычно нихуя не понимающий ни в коде, ни в предметной области несчастный человек, который должен оное колбасево описывать. Извлекая информацию посредством ментального сканирования.

А у нас применяется JavaDoc/Oxygen/ПрочаяХуйня, скажете вы. А я всегда аккуратно пишу эти гребанные комментарии, языком Пушкина и Толстого, скажете вы.

А я вам, во-первых - на предмет "аккуратно" и "всегда" не поверю. :) Ну, в самом деле, говорить всякое можно, но меру-то знать надо. :)

А во-вторых - в описываемом мной явлении дело вовсе не в JavaDoc. И не в том, что надо, наступив себе на яйца, непрерывно "документировать".

Дело в другом. Если вы все понимаете, то реальность - она такая, какая есть. Что характерно - если вы не все понимаете - то она один хер такая, как есть. Она состоит в том, что "документация" - это неуловимый Джо, и на это есть вполне объективные причины. Если, конечно, речь не идет о публичном API систем, которым активно пользуются, ну, хотя-бы, десятки тысяч людей (и тогда аудитория "читателей" сравнима с тиражом книги).