Amazon Kindle 2 и Unicode

Недавно, 24 февраля компания Amazon начала поставки своей "читалки" электронных книг Kindle 2.

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

Ну что тут сказать. Первая версия Kindle была выпущена в конце 2007, вторая соответственно в 2009. Unicode консорциум был образован в январе 1991 года. 17 лет всего прошло, это конечно немного.

Я могу довольно легко понять, что Kindle - устройство в основном расчитанное на американский рынок и все такое. Тем не менее, идея что в 2008, ну или скажем 2007 или 2006 (когда они начинали писать firmware) программисты сядут и напишут не unicode программу, тем более программу которая является читалкой книг, блогов, газет и к тому же web-браузером, кажется мне диковатой.

P.S. Может быть программистам Amazon стоит прочитать небольшую статью Joel Spolsky: The Absolute Minimum Every Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!). Шутка. На самом деле я почему-то уверен, что это было бизнес решение.

Про офис

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

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

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

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

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, взаимодействие заказчиков и разработчиков сильно улучшается и снимаются возможные проблемы, так что по крайней мере старая шутка по качели станет на один шаг короче:

Требования: возраст до 35 лет

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

Ну и в качестве подготовки просмотрел вакансии некоторых популярных и не очень популярных компаний. В качестве disclaimer, хочу сказать что я конечно смотрел не все вакансии, а некоторые, и при этом "программистские" - С++ программист, java программист и тому подобные. Ну и список компаний, конечно достаточно произвольный, просто те что так сказать "на слуху".

Результаты довольно интересные:

• Компании, не устанавлювающие никаких ограничений по возрасту
  

1. Яндекс
   
2. Google.Россия
3. Дизайн Студия Артемия Лебедева
4. CQG
5. Люксофт
6. Quest Software (Moscow)
7. IBM Россия
8. РБК Медиа
9. EGAR
10. Acronis
11. CBOSS
12. Deutsсhe Bank Россия

• Компании, устанавливающие ограничения

1. Крок - в среднем ограничение возраста 23-35 лет
2. Результаты поиска в группе форумов RSDN ( Программирование :: Работа):
   "По запросу '"возраст до" | "Возраст до"' найдено документов: 51".
   

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

1. Желание нанять людей неопытных, готовых работать за небольшие деньги и не до конца понимающих свои права. Тех, кто не сможет постоять за себя. А это обычно молодые ...
   
   
2. Довольно распространённое мнение, что если после какого-то возраста человек ещё не стал "начальником", то значит он неудачник или недостаточно квалифицирован, а значит "нам не нужен".
   
   
3. Молодая команда (собственно то, о чем изначально я собирался написать), которая естественным образом хочет работать с похожими по духу, а значит и по возрасту людьми

Рассмотрим эти причины в обратном порядке.

Молодая команда

Если в компании всем людям по 20 лет, то им не хочется нанимать 40-летнего коллегу. Скучно, страшно, неинтересно, ритмы другие. Некоторое время назад практически вся программистская индустрия в России состояла из очень молоых людей и сответственно приобщались к ней молодые. Во-первых потому что других особо и не было, во-вторых по уже изложенным причинам. Но молодость - это недостаток который быстро проходит. И поэтому со временем происходит (и уже произошло) взросление команд и соответственно возрастные рамки расширяются.

"Не хотим брать неудачников"

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

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

Поэтому мне думается, что такое объяснение - плохой повод для введения ограничений по возрасту.

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

Экономия

Ну тут-то мне кажется ничего особо говорить не надо? Под видом двух предыдущих причин попытаться нанять дешёвых людей делать дорогую работу. И все тут.

Заключительные мысли

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

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

Успех? Терпение!

Довольно давнее время назад мне попалась на глаза статья Eric Sink, под названием "Career Calculus". Статья показалась довольно интересной, и я даже перевёл её на русский язык.

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

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

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

Действительно ли способности так важны? Мне кажется влияние способностей сильно преувеличено. Более того, ссылка на "отсутствие способностей" очень часто является просто поводом "увильнуть" от неприятной для человека работы.

Конечно, способности оказывают влияние, вопрос только какое именно?

Мне кажется существенно большее влияние на "успешность" оказывает упорство и трудолюбие. Заметим, при этом я не говорю о "великих", хотя и они, в большинстве своём, были большими тружениками. Я говорю о "крепких середняках", людях вполне добившихся успеха, но не о Биллах Гейтсах, Ньютонах или Пеле.

Для достижения "нормальных" результатов в спорте, программировании и даже музыке или рисовании необходимо только одно - упорство. Все это лестница и талантливые просто начинают с более высокой ступеньки. Конечно, Леонардо Да Винчи большинство из людей не станет, но научиться рисовать "приемлемо" вполне возможно. (между прочим Леонардо, который, как известно, испытывал свои силы практически во всех областях наук и искусств, говорил "“Счастье приходит к тому, кто много трудится”; неизвестно, добился бы он таких успехов, если бы "не очень" старался)

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

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

Enterprise улетает с Альтаира?

Недавние мои собственные посты на темы "portable applications" и по поводу "носителей информации", а также комментарий Morph натолкнули меня на следующие размышления.

Действительно, сейчас наблюдаются несколько тенденций, которые тянут "персональные данные" в противоположные стороны.

Все своё ношу с собой

С одной стороны, portable программы получили большое развитие. Все больше программ становятся независимыми от реестра (в windows мире), поскольку хранят свои настройки в собственных конфигурационных файлах (и .NET только способствует этому). А раз так, то они по сути все ближе приближаются к portable миру. Flash-ки и внешние USB-винчестеры становятся все более ёмкими и надёжными, возможность полностью носить с собой всю свою рабочую "среду" является все более и более реальной (например "нафаршированная" флэшку n-Key Flash).


Omnia mea mecum porto

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

Сейчас есть возможность не носить с собой ничего. Google, а сейчас и многие другие компании создали в Сети такую среду, что многим людям достаточно иметь компьютер, подключенный к интернет, а все необходимы им программы и данные они могут найти в сети. Вся почта в gmail, все документы в Google Docs или подобных системах.

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

Большой брат

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

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

Размышления

И что же мы видим? Мне видится два момента.

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

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

В 1975 году появился компьютер Altair, что ознаменовало собой начало эры персональных компьютеров. Говорят, что название компьютера было придумано дочерью технического редактора журнала "Popular Electronics" Леса Соломона, поскольку в тот день корабль Enterprise из популярного сериала "Звездный путь" должен был направится именно на Альтаир. Прошло 32 года. Эра персональных компьютеров закончилась? Enterprise улетает с Альтаира?

Носители информации: несколько мыслей

Недавно мой КПК упал на асфальт. У меня Dell Axim X50v. Довольно приличная машинка - вполне удовлетворяет всем моим потребностям, которые ограничиваются, если честно, адресной книгой, калькулятором и программкой-хранителем паролей.

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

Но в этот раз везение кончилось. Теперь при включении КПК стал выдавать сообщение о какой-то "Memory error". И дело кончилось тем что мне пришлось произвести полную его перезагрузку. Кто пользовался КПК знает что полная перезагрузка подразумевает приведение машинки в девственно-чистое состояние, при котором исчезают все установленные программы и данные (ну кроме данных которые записаны на flash карту).

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

Я "много думал" :-) Сначала мне вспомнились многочисленные виды носителей информации, придуманные человечеством за всю историю его существования. О них я писал в предыдущем посте: "Носители информации: краткая истрия в картинках". А потом я начал анализировать чего мы добились и какой ценой.

Современные носители - характеристики

1. Объем: к настоящему времени мы придумали такие способы сохранить информацию, что информацию, содержащуюся в миллионе книг можно уместить в устройстве, размером с небольшой дипломат.
   
   
2. Поиск: И к тому же при помощи современных средств хранения информации можно ещё и найти что-нибудь в этом море информации.
   
   
3. Универсальность: мы можем сейчас хранить существенно больше видов информации чем раньше. Нам теперь доступны возможности хранения видео и звука, что было затруднительно раньше.
   
   
4. Простота репликации: благодаря современным способам хранения информации, её копирование стало чрезвычайно простым и дешёвым, и это возможно самое важное достижение, без которого все остальные были бы не очень ценны из-за чрезвычайного снижения надёжности носителей информации (см. ниже).
   

Однако все имеет свою цену.


Современные носители - цена

1. Современные носители информации таковы, что для извлечения информации требуется потратить существенно больше энергии, чем раньше. Для считывания информации с бумаги, с глиняной таблички или поверхности камня необходимо было лишь небольшое количество света и некоторые затраты, которую требуются человеку для осуществления самого процесса чтения. Сейчас, чтобы считать информацию, находящуюся на DVD Диске или на карте памяти требуется специальное устройство, тогда как все остальные расходы конечно сохраняются.
   
   
2. Мы платим за все плюсы современных средств хранения информации очень небольшой их надёжностью, по сравнению со средствами хранения, которые были у нас раньше. Наскальные рисунки сохранились многие тысячи лет, тоже можно сказать о глиняных табличках, берестяных грамотах и египетских папирусах. Возьмите CD 15-летней давности ...
   

Разное

• Мы пытаемся решить проблему надёжности бесконечным копированием информации (созданием "резервных" копий), потому что на самом деле другого способа нет
  
  
• Уменьшение надёжности , как мне кажется является вполне естественным - чем больше информации мы умещаем на небольшой площади тем менее избыточным, а значит менее надёжным становится наше хранилище
  
  
• Именно из-за чрезвычайного уменьшения надёжности концепция "безбумажного офиса" до сих пор окончательно не реализована
  
  
• Мы заплатили за все современные возможности носителей информации увеличением цены (большими затратами энергии) и уменьшением надёжности. Мне кажется это слишком дорого, чем-то конечно нужно платить, но хватило бы либо цены, либо надёжности.
  
  
• Революция случится тогда, когда будет создан носитель информации имеющий современные характеристики и хотя бы такой же надёжный как бумага
  
  

Вот такие вот мысли. Выводов никаких нет ...

Архивы в сети

В Сети помимо порнографии есть и ещё кое-что :-) В частности, выложены в сеть архивы многих выдающихся учёных.

Программистское

• Архив Э. Дейкстры
  
• Архив академика А.П. Ершова
• Архив Алана Тьюринга
• Архив Конрада Цузе
  

• Подборка статей классиков программирования (Вирт, Ершов, Хоар, Кнут, Бэкус, Наур и др.)
• Подборка классических работ по версии ACM: http://www.acm.org/classics
  

И не только

• Архив Бертрана Рассела
• Электронный архив академика Вернадского
• Архив работ Исаака Ньютона

• Архив работ Карла Фридриха Гаусса (осторожно - латынь!)
• Архивы Российской Академии Наук (В.И. Вернадский, С.И. Вавилов и другие)
• Работы Чарльза Дарвина

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

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

А во-вторых о том, не случится ли что-то с этими сайтами в будущем, не исчезнут ли они? Каждый раз хочется все к себе скачать :-)

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

Ответ на статью: Путь без конца или Дао русского программиста

Я сегодня выступаю в не очень привычном для себя жанре. Этот пост - ответ.

Я думаю что Максима Кононенко, также известного как Mr.Parker знают все. Ну если и не знают, то слышали про него уж точно очень многие. Он - создатель популярного сайта Владимир Владимирович™, известный блоггер, сетевой писатель и журналист. А также программист. Вот я как раз про это. Некоторое время назад вышел пост Максима под названием: Путь без конца или Дао русского программиста. Именно этот пост я и хочу здесь разобрать. Так что уж не обессудьте, для того чтобы читать дальше придётся сначала сначала прочитать исходный пост.

(замечание: данный ответ также опубликован и как комментарий к самому посту Максима - только без вступительной части)

К вопросу о терминологии

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

• Руководство разных уровней
• Бухгалтер
• Программист
• Тестировщик
• Системный администратор
  
• Менеджер проекта - подробнее об этой роли я писал вот в этой статье
  
• Менеджер продукта - об этой роли я также писал вот в этой статье
• Специалист по продажам
• Специалист по рекламе
• Специалист по связям с общественностью
• Секретарь
  
• Специалист технической поддержки
  
• ....
  

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

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

О предмете программирования

Я хочу остановиться на вопросе о предмете программирования. И я прочёл (не буквально, а "увидел", "интерпретировал") в самом посте, а также, кажется в каких-то ответах автора к комментариям на LiveJournal (затрудняюсь их сейчас здесь привести) мнение о том, что программирования как предмета не существует. То есть мне показалось, что автор утверждает: нет никакой "computer science", есть несколько областей математики, плюс некоторые ремесленные приёмы.

Я увидел эту мысль и в утверждениях что "нигде программированию не учат 5 лет" и в том что "что программирование - не ахти какое сложное занятие".

Я же убежден что "программирование имеет свой предмет, не сводящийся ни к конкретным языкам и системам, ни к методам построения быстрых алгоритмов" (Шень А. "Программирование: теоремы и задачи"). Попробую объясниться.

Дело в том, что программирование, также как и математика, например или к примеру, упоминаемая автором медицина - это очень "широкая" дисциплина. Человек, пишущий скажем компилятор - программист, человек пишущий "графический движок" игры - тоже программист, пишущий plug-in к браузеру Firefox - тоже, пишущий адресную книгу для сотового телефона тоже, но и пишущий на php формочку, чтобы отправить письмо со своего веб-сайта - тоже. Есть масса разных ответвлений и уровней. Как и везде - есть сложные части, а есть простые, есть требующие больших знаний в "сопутствующих" областях, а есть меньших.

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

Остальное

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

P.S. Вот ещё что хотелось сказать. Ведь Максим Кононенко написал ещё и рассказ Покемон. Удивительно что один и тот же человек написал две такие совершенно разные [по духу] работы.