Lake Dorothy (stereo)

О противном

В перерыве между осознаниями божественных откровений, поведаю несколько мыслей о низменном и противном. О программировании, о багах, о процессе и о Visual Studio Team System, в разработке которого мне довелось принять.

Есть писатели программ и есть писатели книг о программах. Я привык быть первым из этих двух, но оказалось, что это малоуважаемое занятие. И действительно, код закрытый, никто твоего творчества не увидит. Что за занятие, год за годом подтачивать напильником винтики в маньячном перпетум-мобиле? Да и вообще, никто не любит читать код. Его проще переписать, а если и не проще, то приятнее, в полном согласии с инстинктами. Больше всего в Компании уважают scope of influence. Причем знак этой influence не важен. Знак зависит от точки зрения. Отрицательный результат - тоже результат и все такое. Самое неуважаемое занятие в Компании - писать код. Даже тестеры уважаются больше, ведь они стоят на страже качества! Программист в Компании - это как рядовой советской армии, понукать и унижать которого есть, кажется, единственная её функция. Ощущение армии не покидает меня все годы работы в Компании, хотя сейчас чувствуешь себя уже "дедом".

Другое дело писать книги! Область твоего влияния распространяется на всю отрасль сразу. И что же можно такое новое написать про программирование? Все коммерческие книжки должны содержать в своем названии некий новый бренд. Например Vista, или AJAX или С#. Но новый язык - это сложно. Надо лет десять раскручивать, чтобы люди начали покупать. Да и то, только гики. Да и сложно это. То ли дело бизнесс-процесс! Это можно написать, это легко продавать, Только название придумать. Например "Scrum". Ну и что, что похоже на смесь crap-а и срама. Зато звучит. Содержание процесса тоже неважно, это как новый метод лечения всех болезней. Главное - чтобы больной сразу не помер. А там, может сам выздоровеет. Лучше всего взять побольше обычного здравого смысла и добавить чуть-чуть (главное - не переборщить!) чего-нибудь модного и экстравагантного. Для вкуса. Чтобы запомнилось.

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

Но всё-таки, серьёзно, нужен программисту "процесс"? Смотря что назвать этим словом. Если ритуальные танцы с бубном, то нет. Если весёлые ежедневные митинги, коллективные тренинги на тему build team, то нет. Если свод законов, суровый и непреклонный, установленный десять лет назад, то тоже нет. Если набор разумных практик и приёмов, помогающий писать хороший код - то ДА! И практики эти надо применять с умом, когда они имеют смысл, и набраться храбрости и не применять, когда смысла не имеет. И практик этих на самом деле кот наплакал.

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

1. Иметь source control. Обязательно.
2. Тестировать код. Все написанные строчки. Именно все.
3. Сабмитить в source control оттестированный код разумными кусками. Не каждое открытие файла в редакторе, но фичи. Каждый баг-фикс отдельно, если они независимы. И писать description, что именно засабмичено.
4. Иметь место, где записываются все баги. Не обязательно база данных, об этом ниже. Но хранить баги, как исходный код.
5. Очень хорошо, если source control хранит всё, чтобы построить проект. Т.е. добавьте туда компилятор, заголовки и библиотеки. Это позволит восстановить в точности любую версию продукта, воспроизвести и исследовать баг.
6. Сделайте 2 branches: первый будет содержать текущую рабочую версию, а второй - релизы и хотфиксы к ним.
7. Если есть спеки - положите их рядом с исходным текстом в source control. Пригодится.
8. Не надо писать неиспользуемый код. Не надо делать супер-пупер систему классов на все случаи жизни с кучей методов. Половина будет не нужна, только зря потратите время и потом будет непонятно, что работает, а что нет. Сделайте то, что надо, остальное напишете, когда понадобится. Если написали ненужное, засабмитьте куда-нибудь, но не в рабочий код.
9. Можно написать unit-тесты, но главное - напишите скрипты, которые проверяют основную функциональность всей системы. Потом достаточно будет запустить, чтобы увидеть, что не поломалось.
10. Я не сторонник стайл-гайдов с подробным перечислением количества пробелов, но некий разумный стиль необходим. Код должен быть читабельным. И не только компилятором.
11. Не увлекайтесь самыми последними технологиями. Быстро сделать продукт можно на системе, которая хорошо известна, которая имеет документацию, блоги по недокументированному и куча всяких инструментов. Новые технологии имеют кучу багов и подводных камней. То, что красиво на картинке с 5 квадратиками - не работает, когда квадратиков 1000.
12. Пишите на том, что ваши программисты знают и понимают. Не понимает народ как писать с exceptons - не используйте их.
13. Неплохо, если ваш код посмотрит ещё один человек. Не первый встречный, а тот, кто понимает и может дать дельный совет.
14. Зависимости - вот что должно определять и менеджмент и архитектуру.
15. Не надо делать всё первым пришедшим в голову способом. Подумайте, как ещё можно сделать и выберите лучший вариант из возможных.
16. Программирование - процесс итерационный. Сделайте хотя бы пару итераций перед выпуском первой версии.
17. Задача первой версии - сделать хороший стабильный прототип, обкатать принцип и сформировать API. Вторая версия - никаких новых фич, но то, что есть работает быстро и надежно. Фичи можно добавлять в третьей. И т.д.
18. Во время написания первой версии вы поняли как это надо было писать. Не бросайте и не начинайте переделывать сразу как поняли. Выпустите первую версию. Потом сделаете, то, что поняли во второй. Если перепахивать каждый день - ничего не вырастет.
19. Заведите FAQ и форум для пользователей. Возник у пользователя вопрос - впишите ответ в FAQ. Потом можно просто сслылаться на готовый ответ.
20. Вместо сложных систем баг-трекинга можно просто завести внутренний форум с несколькими правилами. Возник баг - завели тред. Первый пост - описание проблемы (способ воспроизведения или цитата из внешнего форума). Тред активный. Дальше разработчики могут добавлять свои комментарии, потом, когда проблема понята, кто-то принимает решение исправить или отложить. После этого решение записывается в треде. Когда проблема исправлена - это тоже записывается в треде и тред переводится в архив. Всегда видно, что происходит и каков статус. Старые треды тоже можно поднять и посмотреть. Ничего не стирайте!

Хватит на сегодня. Продолжение последует. Как-нибудь.

Ответ на вопрос смысла жизни и всего вообще.

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

Начнем с генетических алгоритмов. Знаете, такая компьютерная штука, по Дарвину. Вносим некие случайные изменения и смотрим не стало ли "лучше". Если стало, то изменения закрепляем. Ну и далее, можно скрещивать изменения, отсеивать худшие разными методами, можно модифицировать критерий "лучшести" со временем, итд итп. (Ну мы почти так уже и пишем софт практически, куча народу делает всякие разные изменения в коде, а тестеры проверяют результат на живучесть. Пардон, отвлекся.)

Так вот, недавно ссылочку прислали. Исходник типа. Наш. В смысле, нас. Хотя скорее екзешник, чем исходник. Ну, генетический код человеческий. Open Source, хакерствуй, если понимаешь.

Ну, никто, конечно почти ничего не понимает, но перспективы поражают воображение. Стругацкие бы сказали, что модификации кода должны быть запрещены, как неэтичные. Утопия. Будут модификации. Никуда не денемся. На это наводят три соображения:

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

На самом деле у всех есть дефекты! Посмотрите на окружающих, на себя. У одного очки с детства, у другого волосы седеют рано или лысина в тридцать, у третьего зубы ни к черту. Пофиксим? Так и поехало. А заодно и кудри златые и глаза изумрудные, и, как ни странно, похож и на маму и на папу. Такой мощный рынок открывается!

Во вторых, есть болезни не наследственные, заразные и опасные. Вирусы-микробы мутируют, ищут дыры в защите, усложняются. А мы - нет! Нам вымирать надо массово, чтобы полезные изменения закреплялись. А у нас вредные закрепляются! Тот, кто раньше умер бы в детстве, сейчас до старости доживает и потомство дает. Медицина остановила нашу эволюцию и ускорила эволюцию вирусов-микробов. Угадайте, кто победит в перспективе? Так, что выход один - самим заняться затыканием дыр в своей защите.

Ну и в третьих - жить подольше хочется. Эволюция не сможет продлить жизнь дольше среднего детородного возраста. Эти изменения не смогут закрепиться в потомстве. Только intelligent design может помочь жить дольше. И рынок здесь совсем уж немеряный.

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

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

Понеслись мечты! Природа, конечно, возмутится таким вопиющим нарушением своих авторских прав и издаст спешно очередной закон об их защите. Об этот закон и разобьются наши мечты.

И какой же это может быть закон? Полагаю, что сложностный. Запросто может оказаться, что нельзя вот так просто взять и написать новую программу для DNA. Может оказаться, что нельзя предсказать какую форму примет молекула при добавлении новой цепочки и какими она будет обладать свойствами, кроме как сделать эту молекулу и посмотреть, что получится. Это как в криптографии. Обратная задача невычислима за разумное время. Т.е. может оказаться, что нельзя вычислить какой генетический код приведет к определенным заранее заданным изменениям организма. Вероятно можно комбинировать независимые части кода, но сильно-зависимые части - неразрешимы.

И что тогда делать? Это же конец! Прогресс остановился, микробы победили, все умерли. Но природа же как-то всё это делает! Идет эволюция! Если миллионы лет делать миллиарды попыток генетическим алгоритмом, можно хакнуть невычислимое.

Сделать кучу зондов. Засеять жизнью вселенную. Дать ей развиваться независимо на разных планетах, потом собирать образцы, выбирать удачные находки, встраивать в себя. Как идея?

Вот мы и подошли к смыслу жизни. Земля, как супер-компьютер, где обитатели находят генетические решения по борьбе с новыми вирусами для некоей суперцивилизации. Поняли, о чем писал Адамс? (Для тех, кто читал: вопрос не должен быть раскрыт - суперцивилизации проще уничтожить планету, чем признать, что они затеяли на окраине галактики!) Можно сделать несколько планет-черновиков. Со сходным генетическим кодом. Заразить их новым вирусом и позволить жителям умирать от него. Выжившие будут нести решение, которое можно внедрить в себя. Интересная возникает этика и практика суперцивилизаций. Поняли, чем занимаются странники? И почему тагоряне не стали инициировать саркофаг? Они, вероятно, просто знали о подобной практике. Мысли разбегаются объясняя факты реальные и вымышленные.

Как минимум, новая фантастическая идея. Дарю, пользуйтесь, я не писатель, я читатель.

Бог создал человека по образу и подобию своему. А затем создал себя по образу и подобию человека. Годится для новой религии? Нет? А если я скажу, что всё это прочитал на позавчерашнем камне, посланном мне с неба?

Загадочные письмена :-)

Fire foxes

http://thrillingwonder.blogspot.com/2007/06/rare-red-panda-or-fire-fox.html Забавный сайт. Мне так же понравилась коллекция дорожных знаков.

Почта и форумы.

Не знаю, как там было в древнем Риме с почтой, но форумы, говорят, уже были. Всё врут календари. Не верю я в древний Рим. Байки это, истории. Но речь не о нем. Речь о почте. Электронной. Весь народ сразу и бескомпромиссно делится на две части. Первые говорят, что Outlook rules, и кривятся при упоминании Gmail: "А что там, всё неудобно!" Вторые, и я в их числе, сказали "ну наконец-то сделали по человечески" и перевелись на gmail, забыв и hotmail и outlook как кошмарный сон. Почему? Как я понимаю есть два сценария работы с почтой: 1. Модель традиционной не электронной почты. Почта приходит в почтовый ящик. Её оттуда забирают. Совсем. Часть сразу выкидывают в мусорник. Остальное сразу раскладывают по полочкам - ответить, заплатить, и т.д. Почтовый ящик при этом обычно пуст. Мои сообщения не хранятся нигде, или в специальном архиве. Сообщения атомарны и самодостаточны, потому включают контекст (цитаты и пр.), а часто просто все предыдущие сообщения. 2. Модель интернет-форума. Почта приходит не мне и не в ящик, а "нам" в форумный тред. Туда же приходит и моя почта тоже. Контекст - весь тред, потому никаких цитат, кроме непосредственных цитируемых строк видеть не надо. Но надо уметь видеть сразу весь тред. Ничего ни откуда не удаляется и никуда не передвигается. То, что я хочу откомментировать, помечаю галочкой, типа просмотреть ещё раз потом и, возможно, ответить. Сообщения в этой модели не атомарны, а являются частью дискуссии. Допустимы и возможны очень короткие сообщения, состоящие из одной строчки или слова. Outlook явно сделан по сценарию 1. Это естественно, поскольку это понятно и привычно. Я всегда работаю по сценарию 2, потому не люблю Outlook. Гугл сделан значительно ближе к 2, чем к 1. Вот и вся разница. Хотелось бы пойти ещё дальше в этом направлении, но делать две почтовых системы Гугл не будет, поэтому получается компромисс: и нашим, и вашим. Да, в аутлуке тоже можно несколько приблизиться к желаемому: не удалять сообщения и включить сортировку по conversation. Если кто скажет, как туда же помещать и мои ответы, буду очень признателен. Мне всё таки кажется, что будущее за сценарием 2. Модель 1 - неестественна, она переносит на мгновенные сообщения ограничения медленной передачи бумажных писем. С другой стороны совсем мгновенные сообщения типа ACQ годятся скорее для трёпа, а не для делового общения. Модель форума кажется идеальным компромиссом. Тред в LJ - концептуально вполне удобен, хотя и не очень удобен в конкретной реализации.

Snoqualmie Valley

Просто тест: попробовал хостить картинки в Google - вполне удобно.