среда, декабря 03, 2008

Попытка написать рассказ ...

         Таксист внезапно притормозил и Саша чуть не ударился головой о пластиковую перегородку, отделявшую его от водителя. "Чёртовы светофоры!" Лекция начиналась через пять минут, а тут, как нарочно, практически на каждом перекрестке был красный. Машина наконец тронулась, и Сашу вдавило в сиденье (таксисту было обещано не обидеть, если довезет быстро). Через 6 минут такси остановилось перед зданием публичной библиотеки, Саша бросил таксисту двадцатку и, не дожидаясь сдачи, выскочил из машины и взбежал по ступеням. "Алекс, да где же вы пропадаете!" - встретил его голос куратора библиотеки - седые волосы, черный смокинг, бабочка - "Вперед! Вперед!" Вслед за пожилым куратором, Саша буквально ворвался в главный зал.

         "Итак, то чего мы все так долго ждали и ради чего собрались. С удовольствием представляю нашего уважаемого гостя. Профессор математики и главный исследователь Массачусетского Технологического Института, кафедра суперкомпьютеров: Алекс Сосновский". Пожилой куратор протянул руку, приглашая Алекса на сцену. Только когда Саша взял в руки микрофон, он понял, что на самом деле страшно волнуется. Волноваться было, в сущности, совершенно нечего. Саша был готов - полностью, стопроцентно, хотя и совершенно не готовился к лекции. Говорят, что первого советского наркома просвещения А. Луначарского как-то попросили прочитать лекцию в одном институте. Тот сразу же согласился и прочитал лекцию совершенно без подготовки. "Как же вам удается читать такие блестящие лекции совершенно без подготовки?" "Как это без подготовки? Я готовился к этому всю свою жизнь"- был ответ. Так же и сейчас. Саша готовился к этой лекции всю свою жизнь. Сегодня он, наконец, сможет рассказать всему миру о своем открытии. Что он, наконец, сделал то, о чем мечтал мальчишкой  в маленькой квартирке на окраине Москвы.

----------

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

         Филькин дядя был дипломатом, что всегда страшно веселило мальчишек, поскольку это конечно смешно, если человек работает небольшим чемоданчиком. Дипломатическая работа дяди Вити, тем не менее, и дала ему возможность привезти в СССР эту железную коробку с тумблерами и лампочками. Только через пять, уже взрослыми, как им тогда казалось,  Шурик и Филька осознали, что в Филькиной квартире они тогда видели первый персональный компьютер в мире Altair, компании MIPS. Шел 1974 год. Именно в тот год руководитель компании MIPS Эд Робертс предпринял все возможные усилия, для того, чтобы произведенный его компанией компьютер попал на обложку журнала Popular Electronics. Пробный экземпляр был послан редактору журнала Лесу Соломону. Известно, что он был послан поездом в Нью-Йорк, где находилась редакция, однако редактор так его и не получил. Журналисты напечатали на обложке фотографию пустого корпуса того, чему предстояло стать предвестником новой эры: первого в мире персонального компьютера. Никто не обратил внимания, на что, что утром, после прибытия  на центральный вокзал Нью-Йорка, из поезда вышел человек среднего роста и неприметного вида, в простеньком сереньком костюме. В руках у него была картонная коробка с рекламой супов быстрого приготовления.

         К восьмому классу Шурик и Филька уже не спрашивали "Как играть в компутер". Мигание лампочек так заворожило их в тот день после школы, что они только этим и занимались. Вдвоем они проводили ночи напролет в институте, где работал папа Шурика, и учились программировать. И не было никого более увлеченных людей, чем они. Больше всего ребят интересовал вопрос, как сделать так, чтобы программы работали чуть-чуть быстрее. В какой-то момент Шурик понял - они не могут больше улучшать сами программы - нужно улучшить сами компьютеры. Тогда они стали вдвоем собирать собственный компьютер. В десятом классе Александр Сосновский и Филлип Надеждин представили на всесоюзном конкурсе молодых изобретателей компьютер собственного изготовления. Только внимательный наблюдатель заметил бы, что контрольные лампочки были в точности такие, как у первого компьютера Altair.

         Сразу после окончания института Саша и Филлип были распределены в Научно Исследовательский Институт Вычислительных Комплексов под руководством потрясающего советского конструктора компьютеров М. А. Карцева. В то время в институте велись работе по созданию компьютеров исключительно советского производства и конструкции, многие из которых были существенно лучше имеющихся в то время американских аналогов. Саша и Филлип страшно увлеклись - сам Карцев понял, что он получил двух великолепных инженеров. Они вдвоем были выделены в отдельную лабораторию, где и посвящали все свое время созданию архитектуры нового, ещё более мощного компьютера. К их огромному сожалению планы в стране изменились, и вместо создания оригинальных компьютеров было решено копировать западные образцы. Не все однако, занимались копированием. Небольшая лаборатория, состоявшая всего из двух человек, продолжала активно заниматься разработками собственных оригинальных конструкций.

----------

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

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

            Первые суперкомпьютеры были разработаны в компании Control Data Corporation в США в 60-х годах двадцатого века основателем компании и её главным идеологом Сеймуром Креем. Впоследствии многие компании разработали собственные суперкомпьютеры, в том числе и такие, которые были организованы из множества "маленьких", "персональных" компьютеров, объединенных вместе.

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

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

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

            Через 2 минуты после того как замолкли последние аплодисменты Саша уже снова сидел в такси. "В аэропорт!" - скомандовал он. В Бостоне, в здании его небольшой лаборатории все его восемь сотрудников (лаборатория не сильно расширилась со времен НИИВК, но все-таки расширилась) встречали его у входа. "Ну что, включаем?" - хор голосов слился в вопросе. "Включаем!". Саша протянул руку, и палец легко нажал кнопку включения. Хлопнула пробка от шампанского, открытого кем-то из ребят! "Ну что? Заработало!".

----------

            Вот уже восьмой час Ганс Брюгер пытался победить тролля-охранника моста. Создание было настолько сильным, что как Ганс не пытался, тролль постоянно его побеждал. Ганс каждый раз заново возрождался в болоте. А убить тролля было очень важно, иначе Ганс не мог продвинуться в основном задании, где трольь был только первым шагом. Но, чтобы убить тролля, ему нужно было набрать больше опыта, а без выполнения задания опыта не набрать. Заколдованный круг какой-то получается. Недаром игра - самая популярная многопользовательская игра этого года - так и называлась - "Заколдованный круг". Миллионы людей в неё играют по всему миру и Ганс в их числе, но вот же незадача никак не может убить мерзкого тролля. "Хрлюююп!"- снова сказал тролль, и игрок увидел знакомые очертания болота. В этот момент в правом нижнем углу замигала желтая иконка системного сообщения. "Хоть какое-то развлечение" - подумал Ганс и вывел сообщение на экран. "Компания "Заколдованный круг" сообщает о введении в строй нового игрового сервера, который в состоянии поддержать одновременную работу дополнительных ста миллионов пользователей, которые по нашим прогнозам подключатся к игре в этом году. "Эх, фигня какая-то"- подумал Ганс и вернулся к своему троллю.

вторник, сентября 16, 2008

Рынок, Роботы, Люди

Сейчас, как известно, финансовый кризис. И вот на его фоне прочитал совершенно удивительную историю. Оригинал можно прочитать тут


Итак, в один прекрасный день, акции одного из крупнейших авиаперевозчиков США United Airlines падают почти в 4 раза, вот так, как этот провал на графике:

(график взят тут)

Что же произошло? У меня здесь не финансовый блог, так что не пугайтесь. 


Пролог (рынок)
декабрь 2002 года, Чикаго

В  2002 году компания United Airlines испытывала значительные финансовые трудности и, в итоге, объявила себя банкротом. В декабре 2002 года в газете Chicago Tribune была по этому поводу опубликована статья.

Роботы
6-7 сентября 2008 года, Интернет (Флорида, Калифорния, Нью-Йорк)

восточное время (7 сентября), 00:08

Чуть позже полуночи ссылка на статью 2002 года каким-то образом появилась в списке "самых просматриваемых" ссылок сайта газеты The Sun Sentinel, принадлежащей той же компании, которой принадлежит и Chicago Tribune, а потому пользующейся общим с ней архивом старых выпусков.

западное время (6 сентября), 21:23

Робот автоматической службы новостей Google News обнаружил ссылку на сайте The Sun Sentinel, обработал страницу и посчитал её новостью, поскольку в самой статье даты не было, зато страница содержала текущую дату. Тогда робот добавил новость в индекс, проставив ей то число, когда он её нашел, то есть ... 6 сентября 2008 года (поскольку Google находится на западном побережье США и там 7 сентября ещё не наступило). На главной странице Google News новость видна не была, но она была видна в поиске, а также была выслана по почте и RSS рассылкам, тем кто был подписан на новости с определенными ключевыми словами в них.

восточное время (7 сентября), 8: 15

Сотрудник компании Income Security Advisors получил уведомление от Google News о новости про авиакомпанию и немедленно выслал информацию в информационное агенство Bloomberg, специализирующееся на финансовых новостях. Которое, в свою очередь, быстро выдало информацию "в эфир". 

восточное время (7 сентября), 9:02

Акции United Airlines рухнули, но очень быстро выяснилось, что "новость" о банкротстве является ошибочной и акции восстановились почти до прежнего уровня.

Люди
17 сентября 2008

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

А я вот о чем подумал. Я вполне легко могу себе представить все случившиеся "технологические" ошибки. Нет даты на странице. Запросто. Дата есть, но она всегда текущая. Легко. Статья 2002 года непонятно как попавшая в список "Самые просматриваемые". Элементарно. Бот, проиндексировавший именно эту статью. Естественно.

Что мне трудно понять, так это то, что профессиональный сотрудник Income Security Advisors не проверил новость просто потому, что она получена от Google. 

Мне начинает казаться, что нужно обучать людей отличать достоверную информацию в интернете от недостоверной. 

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

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

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

P.S. Времена (00:08 и т.п.) происходящих событий выдуманы, остальное вроде так и было.

воскресенье, сентября 07, 2008

Программирование и игра в ГО

Забавная статья: http://railspikes.com/2008/7/14/why-programmers-should-play-go. 


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

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

P.S. Ну вот, написал, отвлекся и вижу, на RSDN это уже обсуждают. Все равно нажму publish :-)

суббота, июля 26, 2008

Fog Creek Open House

В четверг (17 июля) сходил на Fog Creek Open House.

Краткое пояснение для тех кто случайно не знает про FogCreek: есть такой сайт www.joelonsoftware.com, на котором человек по имени Joel Spolsky пишет разные интересные статьи на программистские и около программистские темы. Также у этого человека есть собственная компания, разрабатывающая программы. Эта компания и называется Fogcreek Software. Joel Spolsky многократно упоминает в своем блоге (которым сайт joelonsoftware собственно и является) о том, как важны правильные условия работы для успеха программистской компании и о том, что он то уж у себя создал самые лучшие возможные условия труда для программистов. Апогеем является наверное статья "Bionic Office", в которой подробно описываются чудеса офиса FogCreek.

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

Вот и сходил. Ну что сказать ... все правда. Ну почти. Действительно у большинства программистов собственные кабинеты, хорошая техника. Самая аккуратная серверная которую я видел. Шикарная техническая библиотека. Аквариум с рыбками. Каждый день привозят обед, что для американских компаний не очень распространено. 4 недели отпуска, что для американских компаний тоже не очень распространено.

Самым удивительным наблюдением было то, насколько у людей все аккуратно. Старые номера MSDN Magazine разложены в ящики по годам. Может, конечно, они их не читают, или ко дню открытых дверей специально подготовились.

В общем, впечатления самые положительные.

Возник в голове вопрос, сколько же компания собственно зарабатывает, чтобы обеспечивать сотрудникам нормальные условия (утверждается, что зарплаты у них тоже на уровне, хотя точных цифр конечно никто не называл). При том, что продукты, которые они делают, я бы не назвал самыми"денежными". FogCreek делает баг-трекинг систему (FogBugz), сайтопостроитель (CityDesk) и аналог WebEx или GotoMeeting (CoPilot). При этом они не являются лидерами ни по одному из направлений. Небольшой поиск дал следующие результаты:

Year 2007
Industry Software
Founded 2000
Growth 423.2%
2003 Revenue $566,576
2006 Revenue $3.0 million
Employees 11

Конечно не Google, но на кусок хлеба с маслом им вполне хватает :-)

среда, июля 02, 2008

Ещё немного про Google

Для тех кто ещё не читал этот рассказ, я думаю будет интересно:

Рассказ Сергея Соляника, который работал в Microsoft, потом перешел в Google, а теперь снова вернулся в Microsoft. В рассказе объясняется почему.

P.S. В комментариях есть интересная ссылка: Google C++ Style Guide.

пятница, июня 27, 2008

Последний день Билла Гейтса

Сегодня кончается целая эпоха. Билл Гейтс уходит из Microsoft.

http://www.microsoft.com/presspass/exec/billg/videos/

четверг, июня 19, 2008

5 программ, которые я использую ежедневно

Вот и меня посчитали. До меня дошла игра в 5 инструментов, которая как мне казалось уже закончилась :-) К тому же, про многие мои инструменты я уже писал в посте "Джентльменский Набор". Тем не менее с удовольствием напишу про то, чем пользуюсь именно каждый день и не только про portable :-)

  1. Файловый менеджер - уже несколько лет - Total Commander
  2. Основной браузер - Mozilla Firefox
  3. Miranda и Skype - для мгновенных сообщений
  4. Почтовый клиент(рабочий), календарь, список задач: MS Outlook
  5. Почтовый клиент(личный) - gmail.com
  6. Редактор(заменитель notepad): EditPlus
  7. Разработка (хотя последние несколько месяцев непосредственно разработкой практически не занимаюсь)
Ну вот, получилось правда не 5, а чуть больше инструментов, но они ведь все хорошие, как я их мог упустить :-)

P.S. Поскольку то что мы тут делаем - это типичная пирамида, то я конечно должен теперь написать здесь список блогов людей, об инструментах которых мне было бы интересно узнать. К сожалению большинство из них в игре уже поучаствовали, а другие боюсь не читают этот блог. Но, попытка - не пытка. Мне было бы интересно узнать про инструменты которыми пользуются:
  1. Эльдар Мусаев
  2. Руслан Богатырев
  3. Владислав Балин

среда, июня 18, 2008

Про офис

Нужен ли офис в программистской компании? Почему бы собственно программистам не сидеть дома, писать себе спокойно программы? Интернет сейчас быстрый поставить недорого. Средства обмена информацией есть в огромном количестве - недорогие и много чего умеющие. Электронная почта, телефон, разнообразные интернет-пейджеры, в том числе и поддерживающие разговоры голосом, телеконференции. Да и показать что происходит можно легко - есть и WebEx и Netmeeting и GoToMeeting и ещё масса подобных программ.

Зачем же нужен офис - за него ведь деньги платить нужно[имеется ввиду за аренду], к тому же в него нужно ездить - тратить время на дорогу.

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

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

среда, мая 07, 2008

Про письма

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

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

Есть масса вещей, способствующих непрозрачности команды программистов. Языковый барьер, который присутствует просто потому что для одних родной язык русский, а для других английский. Сам факт того что люди сидят далеко друг от друга. И ещё отсутствие писем.

Совершенно необходимо писать письма и отвечать на письма. Это единственный надежный инструмент общения. Далеко не все в США пользуются ICQ или "впишите-здесь-имя-своего-любимого-интернет-пейджера". На любое письмо должен быть ответ. Даже если в ответе написано, что настоящий ответ будет завтра. И завтра, если настоящего ответа нет, нужно опять написать что ответ будет завтра. Это очень простой и на самом деле самый верный способ дать своим коллегам на "той" стороне уверенность что их читают, о них помнят и вообще что с той стороны хоть что-то происходит.

Пишите письма!

понедельник, марта 10, 2008

Отчет об ошибке

Вы заранее знаете все что будет написано в этом посте. И тем не менее все равно хочется написать. Каким должен быть отчёт об ошибке в программе? Про это написано множество статей и даже книжек. Мне иногда кажется что из-за того что их написано такое множество, и выходит так, что большинство отчётов невозможно толком понять.

Поэтому я завязываю с предисловием и перехожу к сути дела.


  1. Перед тем как добавить новый отчёт об ошибке (новый баг, CR типа дефект, называйте как хотите) необходимо убедиться что его ещё нет в системе.

  2. Уточнить о какой версии продукта (и модуля, и если нужно подмодуля) идет речь. До последней цифры, даже если их 18.

    Например: Программа Феликс, версия 4.2.1121.1356b

  3. Описать проблему в примерно таком порядке:
    1. Краткое описание
      Неправильное сложение отрицательных чисел
    2. Последовательность шагов, которую нужно проделать для того чтобы проблему воспроизвести
      • Ввести операцию сложения (ну может Феликс в польской записи работает :-) )
      • Ввести '-2' в качестве первого аргумента
      • Ввести '-3 в качестве второго аргумента
      • Нажать на кнопку получения результата
    3. Ожидаемый результат - вы думали что когда это проделаете, то получится то-то
      Ожидали получить -5
    4. Полученный результат - а на самом деле получилось ....
      Получили -1
    5. Существует ли способ получить ожидаемый результат (способ обойти ошибку)? Если да, то какой?
      Да, если сначала ввести -3, а потом -2 то сложение выполняется верно
  4. Все сообщения об ошибках должны быть обязательно приведены (желательно в виде скриншота)
    Сообщений об ошибках не выдаётся


И все ...

P.S. Зачем нужен пункт, описывающий способ обойти ошибку (если он существует)? Во-первых, для удобства приоритезации. Ошибкам обычно присваивается приоритет и часто ошибке которая не приводит к полной потере работоспособности имеет смысл присвоить более низкий приоритет. Во-вторых, часто описание способа обхода дает разработчиками ключ к пониманию того, почему же собственно программа неправильно работает.

пятница, января 18, 2008

А вы читали "Искусство программирования"?

Прошлый пост был посвящён Дональду Кнуту и, в частности, в нём упоминалась самая известная его книга "Искусство программирования". К посту был сделан следующий комментарий:



И мне тоже стало интересно. Посему я создал голосование на известном программистском ресурсе RSDN.

Для тех кто с RSDN не знаком, два небольших замечания:

  1. RSDN - очень "профильное" и довольно высокопрофессиональное место
  2. В голосование можно было добавлять свои варианты ответа, так что первые пять вариантов ответа - это то, что я предложил, а остальное добавлено самими участниками
Вот результаты этого голосования:



Если честно, голосование ещё не закончено и результаты могут немного измениться, но мне кажется что тенденция ясна уже сейчас.

Вот такой вот ответ на вопрос.

P.S. По ссылке с сайта "Информатика в России" нашёл видео-подборку лекций Кнута. Это лекции, которые он время от времени читает в Стэнфорде.

P.P.S. Удивительно, как все-таки формируется наше "мнение" о той или иной работе, книге, статье. Порой репутация автора или людей, его рекомендовавших существенно больше влияет чем собственное мнение о конкретной работе. Да наверное даже в большинстве случаев это так - мнение то у нас есть много о чем, а основано оно на чем? На вере в авторитеты. Репутация авторов - часто единственное на что можно ориентироваться, если ты не специалист в предмете.

четверг, января 10, 2008

Дональду Кнуту исполняется 70 лет

Сегодня - 10 января - день рождения Дональда Кнута - всемирно известного автора "Искусства программирования".

Кнут - удивительный человек, написавший удивительные книги, в первую очередь конечно "Искусство ..." - книга, которая заняла огромную часть его жизни и которая все ещё не закончена. По замыслу, она должна содержать в себе все знания, необходимые для программирования машин традиционной архитектуры. Сейчас, как известно, существуют первые три тома, несколько кусков четвёртого и дополнения к ним (вещи, которые должны были попасть в первые тома, но ещё не существовали тогда, когда Кнут их писал). Пятый том планируется закончить к 2015 году.

Цитата из предисловия к "Исскусству":

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

Том 1. Основные алгоритмы

    Глава 1. Основные понятия
    Глава 2. Информационные структуры

Том 2. Получисленные алгоритмы

    Глава 3. Случайные числа
    Глава 4. Арифметика

Том 3. Сортировка и поиск

    Глава 5. Сортировка
    Глава 6. Поиск

Том 4. Комбинаторные алгоритмы

    Глава 7. Комбинаторный поиск
    Глава 8. Рекурсия

Том 5. Синтаксические алгоритмы

    Глава 9. Лексикографический поиск
    Глава 10. Синтаксический анализ"
После этого планируются ещё 6 и 7 тома. Подробное описание можно найти на собственной страничке Кнута, посвящённой "Искусству".

Кнут также известен созданием системы Tex. А ещё есть масса занимательных фактов из жизни этого неординарного человека:
  • Кнуту принадлежит высказывание: "Beware of bugs in the above code; I have only proved it correct, not tried it.''

  • Кнут выплачивает 2 доллара 56 центов любому, кто найдёт ошибку в любой из его книг (потому что 2.56 - это один шестнадцатеричный доллар)

  • Кнут пользовался электронной почтой с 1975 по 1990 год, после чего решил что для него этого вполне достаточно - с тех пор он не пользуется электронной почтой
P.S. Ну и популярность конечно тоже не обошла Кнута стороной :-)

суббота, января 05, 2008

MRD: Marketing Requirements Document

Уже почти год назад я писал о ролях в разработке программного обеспечения. А именно о том, в чем состоят обязанности людей, играющих определённые роли и на чьей стороне (заказчика или разработчика) они играют.

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

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



Я хочу сегодня рассказать про один из аспектов взаимодействия Product Manager (в терминах моей старой статьи) с разработчиками, заказчиками и высшим руководством.

Замечу, что под разработчиками здесь я понимаю не только программистов, но также и тестировщиков и технических писателей и работников технической поддержки и специалистов по внедрению. Соответственно "команда разработчиков" включает в себя (при необходимости конечно) всех этих людей.

Напомню, что Product Manager:


Отвечает за продукт с точки зрения заказчика. То есть product manager — это человек, представляющий заказчика в команде разработчиков. В обязанности Product Manager входит:

  1. Исследование рынка
  2. Выявление потенциально нужных заказчикам продуктов, сервисов, функциональности
  3. Исследование конкурентов (иногда этим занимаются специально выделенные люди)
  4. Маркетинговые исследования, PR акции, пресс-релизы (иногда эту работу делают специальные Product Marketing Manager, иногда она производится совместно этими двумя ролями)
  5. Выработка списка "features" продукта
  6. Определение приоритетности тех или иных "features" (что делать обязательно, что нет)
  7. Позиционирование продукта (на какой рынок продукт нацелен, портрет покупателя)
  8. План развития продукта (RoadMap)
  9. Ценообразование (сколько продукт будет стоить, какая будет модель лицензирования)
  10. Взаимодействие с высшим руководством компании, если таковое необходимо
  11. Взаимодействие с отделом продаж и совместная выработка стратегии продаж



Взаимодействие с разработчиками происходит как формальное, так и неформальное. Основным формальным документом, который является результатом работы Product Manager и определяет продукт для разработчиков и является MRD - Marketing Requirements Document.

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

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

Теперь попробуем описать какие разделы должен включать MRD. Для удобства я попытаюсь сразу после описания соответствующего раздела давать пример.

MRD представляет из себя документ, в общем, свободного формата. Основная аудитория MRD - это:
  • Разработчики
    Разработчикам MRD необходим для понимая того что же именно нужно написать.

  • Высшее руководство
    Ну, во-первых, начальство конечно должно быть в курсе что собственно делается ;-) Во-вторых, MRD - это документ, являющийся обоснованием для получения ресурсов (материальных и людских), если их не хватает.

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

MRD для нового продукта "Феликс"
  1. Цель создания продукта или выпуска очередной версии.
    В данном разделе описывается проблема, существующая у потенциальных или реальных заказчиков и объясняется, как именно продукт или новая версия продукта эту проблему устранит. Это очень важный раздел, он должен сравнительно кратко объяснить что же именно предстоит сделать.

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

    Год

    Потери

    2004

    $200млн.

    2005

    $300млн.

    2006

    $400млн.


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

  2. Описание того, какой результат должен быть достигнут и в какие сроки.
    Здесь необходимо описать что именно должно получиться (web-сервис, java-приложение, некоторый документ, который описывает что-то, некоторое устройство, обладающее определёнными характеристиками). Также в этом разделе обычно указывается желаемый (с точки зрения заказчика) срок получения продукта. Хочу специально отметить, что это не срок, за который продукт будет сделан. Это всего лишь желаемый срок. MRD проходит в своём развитии много итераций и реальные сроки исполнения в нем обычно не указываются. Заказчику сроки исполнения обычно предоставляются в других документах. Тем не менее указать желаемое время (например некоторое важное с маркетинговой точки зрения событие) здесь вполне возможно.
    Пример: Поскольку по результатам исследований выяснилось, что большинство кассиров в магазинах пользуется мобильными смартфонами с установленной на них операционной системой компании Microsoft - Windows Mobile 6.0, то Феликс должен представлять собой программу работающую под управлением этой и последующих версий ОС Windows Mobile 6.0. В сентябре следующего года ожидается всемирная выставка Кассир-2008 в Лас-Вегасе и первую версию программы очень желательно иметь к этому времени, для того чтобы мы могли разрекламировать её во время выставки.

  3. Описание функциональных возможностей продукта.
    Данный раздел собственно и составляет самую большую часть MRD - в нем описывается какие именно функции должен выполнять продукт. В зависимости от самих функций, квалификации Product Manager и принятых в компании правил, раздел может быть более или менее подробным. В частности, подробные сценарии использования (use cases) каждой из функциональных возможностей могут присутствовать, а могут и нет. Также MRD может включать или не включать в себя внешний вид пользовательского интерфейса. В любом случае, сценарии использования и внешний вид пользовательского интерфейса обычно появляются на той или иной стадии разработки и обычно являются дополнениями к MRD, поскольку дают более полное представление о продукте.

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

    Пример: Феликс должен обладать следующими возможностями:
    • Сложение действительных чисел, при помощи стандартных правил сложения, описанных в учебнике Г.М. Фихтенгольца
      Приоритет: очень важно
    • Вычитание действительных чисел, при помощи стандартных правил вычитания
      Приоритет: очень важно
    • Умножение действительных чисел
      Приоритет: очень важно
    • Деление действительных чисел
      Приоритет: очень важно
    • Скорость выполнения операций не должна быть больше 10 секунд на одну операцию
      Приоритет: очень важно
    • Программа установки, выполненная по стандартам Windows Mobile 6.0
      Приоритет: очень важно
    • Drag&Drop
      Приоритет: очень важно
    • Plug&Play
      Приоритет: очень важно
    • Возможность распечатывать результаты
      Приоритет: очень важно
    • Наличие подробной документации по всем функциям программы
      Приоритет: очень важно
Заметили ли вы некоторые странности в последнем примере? Что за удивительная функция Drag&Drop? А что такое Plug&Play? Какое отношение они имеют к программе "Феликс"? А может быть есть ещё какие-то странные требования? А почему собственно приоритет ВСЕХ функций поставлен как "очень важно"? Частенько Product Manager формулирует свои требования не достаточно чётко или само требование не кажется особенно осмысленным. Поэтому составление MRD часто требует нескольких итераций, так что каждая следующая делает этот документ более "внятным".
Для того чтобы уменьшить количество этих итераций, описание функциональных возможностей также иногда делят на части:
  • Описание - эта часть у нас уже была
  • Приоритет - эта часть также уже была
  • Цель - какую задачу решает наличие данной функции. Обычно цель очевидна, а вот если она не очевидна, то может быть и сама функция не нужна.
  • Откуда появилась идея - требование заказчиков, наличие такой функции у конкурентов, наличие проблем в существующей версии продукта
Такие функциональные возможности, которые предложил Product Manager для программы Феликс - Drag&Drop и Plug&Play возможно являются следствием того, что он бездумно пошёл на поводу у рекламы и просто включил в список пару "красивых" с его точки зрения фраз.

Составление MRD требует от Product Manager довольно большой работы, анализа конкурентов и ситуации на рынке, а также, иногда, понимания технической стороны вопроса.
Но, при наличии грамотно составленного MRD, взаимодействие заказчиков и разработчиков сильно улучшается и снимаются возможные проблемы, так что по крайней мере старая шутка по качели станет на один шаг короче:

вторник, января 01, 2008

С наступившим!

С наступившим, всего самого лучшего в новом году! Успехов, удачи, здоровья, всего!