Цветы жизни

Фаркаш Бояи, венгерский математик, отец одного из "опровергателей" пятого постулата эвклида и создателя неэвклидовой геометрии Яноша Бояи писал своему сыну:

"... для некоторых вещей существуют эпохи, когда они появляются одновременно во многих местах, совершенно как фиалки, которые ранней весной выходят на свет отовсюду".

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

Вот например сегодня сразу пара материалов на очень близкие темы попалось мне под руку. Почитайте в любом порядке:

1. Why nerds are unpopular? - статья Пола Грэма
2. Человеководство и компьютер - статья Михаила Ваннаха в Компьютерре

Только просьба - не обращайте внимания на частности - пробуйте найти что-то общее между всеми этими ... "источниками".

P.S. О Фаркаше и Яноше Бояи можно прочитать в книге "Три судьбы" Анны Ливановой. Книгу эту я в интернет магазинах не нашёл, зато нашёл её оформленной в виде курсовой работы вот тут.

Portable Skype

Я давно пользуюсь Miranda в качестве Instant Messenger. При этом Miranda у меня находится на USB-винчестере. Все это очень хорошо и удобно, но вот последнее время мне часто приходится использовать Skype. Соответственно я скачал плагин, позволяющий использовать Skype прямо из Miranda. И все бы хорошо, но Skype приходится инсталлировать, и к тому же настраивать, на каждом из используемых компьютеров.

Сегодня я выяснил - сам не понимаю, как я об этом раньше не знал, что Skype вполне может быть portable.

Очень просто - копируешь skype.exe в любой каталог на USB-диске или flash-ке, и запускаешь вот так:

skype.exe /datapath:"путь к каталогу где будут жить настройки" /removable

где datapath указывает на каталог где будут жить все настройки. И все работает. Плагин для Miranda тоже можно настроить так, чтобы он использовал не стандартный Skype, а portable:



Кстати вот тут: Skype Command Line Options почему то эти опции не описаны.

Вот так вот. Если я тормоз, а все это и так уже знают - прошу прощения за баян.

Про парное программирование - часть 2

Продолжу пост, начатый здесь. Напомню, что я остановился на том, что недавно, а именно в февральском номере журнала IEEE Transactions on Software Engineering была опубликована статья Erik Arisholm, Hans Gallis, Tore Dyba и Dag I.K. Sjøberg посвящённая проведённому ими исследованию в области парного программирования.


Исследование Simula Research Laboratory

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

• В описываемом эксперименте принимало участие 295 Java-разработчиков - 98 пар и 99 соло программистов из различных европейских компаний (всего 29 компаний).
  
  
• Эксперимент состоял из двух фаз - первая фаза была проведена в 2001 году и в ней участвовали только соло-программисты.
  

• Вторая фаза состоялась в конце 2004 начале 2005 годов и в ней участвовали пары
  
  
• В данном эксперименте, в отличии от всех предыдущих, участники не должны были выполнить некоторую программистскую задачу с нуля. Все задания (кроме тренировочного) состояли в том, что необходимо было внести некоторое изменение в уже существующую программу.
  
  
• Задания:
• Тренировочное задание: сначала каждому участнику была выдана простое задание : прочесть цифры с клавиатуры и вывести их в порядке обратном порядку ввода. Данное задане все участники выполняли для того чтобы ознакомиться с окружением и правилами эксперимента
• Индивидуальное тестовое задание: каждый из участников должен был внести изменение в программу. Все участники должны были внести одно и тоже изменение в одну и ту же программу. В рассматриваемой программе было 7 классов и 354 строки кода. Необходимо было добавить лог а также возможность распечакти баланса банковского счета. Данная программа не была похожа на программы, использовавшиеся во время самого эксперимента. Тестовое задание использовалось для того, чтобы сравнить относительные уровни программистов, участвующих в тестах.
• Основные задания эксперимента (4 задания):Основные задания были основаны на программе управления кофе-машиной. При этом существовало два вида такой программы, с одной и той же исходной функциональностью. Одна из программ была устроена более сложно и состояла из 12 классов. Другая программа была устроена проще и состояла из 7 классов. Для каждой из программ существовали UML описания сценариев работы, для того чтобы можно было лучше понять архитектуру программ. Сами задания состояли в добавлении следующих новых возможностей в программу управления кофе-машиной:
• Реализации кнопки: возврат монеты
• Добавление нового вида напитка (бульон)
• Проверка того, имеются ли в наличии все ингредиенты для выбранного вида напитка
• Добавление возможности содания своего собственного напитка, при помощи разрешения пользователю выбора из всех доступных ингредиентов.
• Синхронизационное задание: последнее предлагаемое участникам задание имело специальную цель. Результаты его выполнения не учитывались, но участники об этом не знали. Таким образом им приходилось работать над всеми реальными заданиями со всей возможной скоростью.
• Обстановка эксперимента:
• Сам эксперимент проводился в течение 27 дней - 10 дней для соло-программистов и 17 дней для пар
• Все происходило в собственных офисах разработчиков или в офисах Simula Research Laboratory.
• Всем участникам был предоставлен доступ в интернет, книги и так далее
• Каждый участник мог также пользльваться любым средством разработки по желанию: Eclipse, IntekkiJ Idea, JBuilder, NetBeans - чем угодно.
• Все это было сделано для того, чтобы максимально приблизить условия эксперимента к реальным, в которых консультанта нанимает компания-клиент, для того чтобы произвести некоторое изменение в программе.
• Для того, чтобы более точно учитывать потраченное время, перерывы разрешалось делать только между заданиями, но не во время выполнения одного задания.
• Что оценивалось:
• Длительность - время (в минутах), потраченное на то, чтобы справиться с основными заданиями эксперимента
• "Цена" - человеко-минуты ( ну то есть попросту говоря зарплата), потребовавшиеся на задания. Для пар цена представляла собой длительность, умноженную на 2
• Правильность - 1, если все 4 задания были сделаны верно и 0, в противном случае. Решения проверялись двумя независимыми экспертами, а также специальными тестами, которые сравнивали результат выполнения программ с заранее изаготовленным правильным результатом.
• Факторы, влияющие на результат (факторы, которые рассматривались исследователями при анализе)
  
• Парное или соло программирование
• Сложность системы - некоторым программистам выдавалась программа написанная более "сложно", а некоторым "менее сложно"
• Уровень программистов - Junior, Intermediate, Senior
• Проверяемые гипотезы
  Изначально экспериментаторы поставили цель проверить следующие гипотезы (замечу, что каждая из гипотез - это некотрое предположение о том как один из факторов влияет на одну из оценок - то есть количество гипотез = кол-во факторов*кол-во оценок = 9):
• H01 - влияние парного программирования на длительность: парам и соло требуется одинаковое время для выполнения заданий
• H02 - влияние сложности системы на длительность: разница во времени, нужном для выполнения заданий парам и соло не зависит от сложности системы
• H03 - влияние опытности программистов на длительность: разница во времени, нужном для выполнения заданий парам и соло не зависит от опытности программистов
  
• H04 - влияние парного программирования на "цену": цена одинакова для пар и для соло
  
• H05 -влияние сложности системы на "цену": Разница в цене между парами и соло, не зависит от сложности системы
• H06 -влияние опытности программистов на "цену": Разница в цене между парами и соло не зависит от опытности программистов
• H07 -влияние парного программирования на правильность: Правильность одинакова для пар и соло
• H08 -влияние сложности системы на правильность: Разница в правильности между парами и соло не зависит от сложности системы
• H09 -влияние опытности программистов на правильность: Разница в правильности между парами и соло не зависит от опытности программистов.
• Результаты
  Подробные результаты в процентах, а также допущения и статистические погрешности эксперимента можно увидеть в статье авторов. Я же здесь приведу лишь сами выводы.
  
• H01 - достоверна
  
• H02 - не достоверна
• H03 - достоверна
• H04 - не достоверна
• H05 - не достоверна
• H06 - достоверна
• H07 - достоверна
• H08 - не достоверна
• H09 - достоверна
• Выводы
  
• Основной вывод, который делают авторы состоит в том, что на соновании их эксперимента можно считать, что junior-программистов, при работе со сложными системами выгоднее объединять в пары. При этом можно добиться существенного увеличения качества результатов. Этот вывод, кстати близок к выводам авторов четвёртого исследования из моего предыдущего поста, о том что парное программирование лучше работает в, так сказать, "неизведанных" областях.

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

Обсуждение

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

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

Собственный опыт

У меня есть и собственный опыт парного программирования, о котором хотелось бы кратко рассказать. Мне приходилось программировать в парах с несколькими людьми и на разных уровнях собственного "развития". То есть я ощущал себя в парах и "новичком", который сидит рядом с "гуру" и "гуру" который сидит рядом с новичком. Было и программирование в парах с равными. Какие впечатления?

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

Про парное программирование - часть 1

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

Поводом для данного поста послужило наверное первое серьёзное исследование посвящённое производительности парного программирования.

Но начнём сначала.

Кратко про парное программирование

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

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

Что об этом думают люди

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

Но с 2000-го года (когда была опубликована книга Бека:Extreme Programming Explained: Embrace Change) многие стали говорить о парном программировании. Высказывались как положительные отзывы и мысли (подобные приведённым выше), так и отрицательные. К основным недостаткам парного программирования обычно относят:

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

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

Эксперименты

Люди начали ставить эксперименты над людях :-) Некоторое время назад в журнале International Journal of Human Computer Studies была опубликована статья Pair programming productivity: Novice–novice vs. expert–expert. Статья рассказывает о четырёх различных исследованиях, проведённых с 1998 года, в которых учёные пытались сравнить производительность парного и соло программирования.


Исследования были такие.

1. В первом исследовании, проведенном в 1998 году 15 опытных программистов, из которых сформировали 5 пар, и пять соло программистов должны были написать некоторый UNIX скрипт. Результаты оценивались двумя независимыми проверяющими. Оценивались функциональность скрипта (насколько он решал поставленную задачу) и "читаемость" кода. Оценка за качество выставлялась по шкале от 0 до 6 (0 - скрипт не работает, 6 - делает все что нужно). Оценка за "читаемость" выставлялась по шкале от 0 до 2 (0 - невозможно читать, 2 - отличная читаемость). Результаты таковы:
   
   

   	соло	пары
   читаемость	1.40	2.00
   функциональность	4.20	5.60

   
   
2. В другом исследовании, которое было проведено в 2000 году, участвовал 41 человек,
   из которых было сформировано 14 пар и 13 соло программистов. Участвующие были студентами и пары были сформированы так, чтобы в парах обязательно оказывалиь разные по уровню студенты. Задача была в том чтобы написать некое e-commerce приложение. Задачи были несложные и студентам было выдано по 4 задачи. Оценка качества выполнения проводилась при помощи набора тестов. С выполнением первой задачи пары справились на 40 процентов быстрее чем соло. К третьей задаче задачи пары справилялись на 85 процентов быстрее. С точки зрения качества - у пар проходило примерно 90% тестов, а у соло 74%. Надо также сказать, что данный эксперимент проходил без надлежащего контроля со стороны экпериментаторов - участники работали дома и невозможно точно сказать действительно ли работа велась согласно условиям эксперимента.
   
   
3. В 2001 году было проведено третье исследование, в процессе которого студенты, в количестве 21 человек, были разделены на три группы. Каждая группа получила одно и тоже задание и должна была решить его либо при помощи соло программирования либо при помощи парного программирования. Задача состояла в том чтобы подсчитать некоторые стандартные статистические формулы в массиве числовых данных (среднее, медиану), а также подсчитать количество строк кода в заданной программе. Пары и соло потратили практически одно и тоже время на решение задач и поэтому исследователи заключили, что предыдущие оценки продуктивности парного программирования сильно преувеличены.
   
   
4. Все описанные три исследования были проведены разными авторами, и как мы заметили достигли разных и не очень достоверных результатов. Кроме того результаты очень трудно сравнить друг с другом из-за слишком разнеых условий экспериментов и критериев качества результирующих программ. Это же заметили и авторы статьи Pair programming productivity: Novice–novice vs. expert–expert. Они подготовили и провели свой собственный, четвёртый эксперимент. Эксперимент заключался в том, что люди должны были писать одну и ту же программу несколько раз подряд, имитируя таким образом рост профессионального мастерства. Программисты писали одну и ту же программу, каждый раз сначала, 4 раза подряд. Вот график результатов:
   
   

   	1 итер.	2 итер.	3 итер.	4 итер.
   Соло (потраченное время, мин.)	635	407	334	285
   Пары (потраченное время, мин.)	410	320	281	272

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

Вот такие были эксперименты. Все они, однако, не идут ни в какое сравнение с экспериментом, который произвели недавно сотрудники Simula Research Laboratory.
В февральском номере журнала IEEE Transactions on Software Engineering опубликована статья Erik Arisholm, Hans Gallis, Tore Dyba и Dag I.K. Sjøberg посвящённая этому исследованию.

О ней, выводах, и моем собственном мнении по всем изложенным и ещё не изложенным поводам - в следующий раз.

Моя компания - Большой Брат?

Учёт времени сотрудников. Хорошая ли это вещь? У меня есть мнение...

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

Вот несколько примеров того, как система может быть устроена (примеры взяты отсюда):

• Задержка утреннего прибытия в офис на одну минуту карается написанием объяснительной записки с указанием причины опоздания.
  
• Три опоздания на одну минуту за месяц караются вычитанием оплаты за один полный рабочий день.
• У всех сотрудников каждые 15 секунд тайно делается снимок с экрана компьютера. Он сохраняется на сервере для просмотра руководством. Этот процесс невозможно прервать: компьютерная программа слежки, если ее отключить, запускается самостоятельно.
• Все присланное или отправленное с вашего компьютера по электронной почте сохраняется и полностью доступно для просмотра начальством. То же касается и пейджеров. Печатная корреспонденция вся просматривается руководством. Прочитав, начальник, если посчитает нужным, передаст ее тебе.
• Телефонные разговоры записываются и прослушиваются.
• Если в течение дня ты зафиксирован в столовой более чем два раза, тебя уже внесли в особый список, который докладывается наверх.
• Если работнику нужно покинуть офис более чем на час, необходимо заблаговременно, минимум за 2-3 дня, написать заявление и получить одобрение руководства.

Вот примерно такие системы. Вот и вопрос - оправдано ли введение таких систем, а если оправдано, то когда и в каких масштабах?

За

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

• Можно предположить что с введением системы штрафов за опоздания будет меньше опозданий
• Люди в рабочее время будут заниматься исключительно рабочими делами, поскольку они знают что бездельничать им не позволят
• Бесконечное время, которое можно было бы провести в "курилке" будет израсходовано на что-то нужное для компании
• Дисциплина - сама по себе вещь хорошая, а подобная система помогает воспитывать дисциплинированные кадры - любые указания всегда будут выполняться точно и в срок
  

Против

Против доводов не меньше. И это конечно в основном доводы сотрудников.

• Работники "творческих" профессий утверждают что они могут работать только тогда когда им творчество в голову ударяет :-), а не по расписанию
• Врачи утверждают что полноценно работать 8 часов подряд совершенно невозможно и так или иначе но человеку нужен отдых
• Иногда поесть ... или наоборот может захотеться лишний раз, совершенно не сообразуясь с расписанием компании
• Многим не нравится что им не доверяют на работе ( а что иное есть слежка, как не недоверие?)
• Люди часто считают, что нет смысла сидеть на работе если работа уже сделана - что если человеку хватает меньшего времени?
• Система тотального слежения слишком напоминает ужасные антиутопии типа "1984" или "Мы", в том числе и отношением к людям в этих антиутопиях. А к людям там относились как к материалу.
  

Выводы

Выводы трудно делать... Дело в том, что на самом деле, также как и во всех остальных случаях все слишком сильно зависит от ситуации.

Нужно ли в МакДональдсе поощрять "творческое" мышление сотрудников и разрешать им опаздывать на работу? Думаю не нужно. И честно говоря, думаю что и сотрудники МакДональдса (даже рядовые) с этим легко согласятся.

А правильно ли компании, производящей программное обеспечение пытаться построить из себя МакДональдс? Это большой вопрос. Пока что опыт известных мне компаний показывает, что из "конвейерной" системы хорошие люди очень быстро уходят, причём именно из-за некомфортных условий, связанных со слишком суровыми правилами. Самые успешные компании на рынке программного обеспечения - Microsoft и Google исповедуют совершенно другие принципы (можно почитать тут и тут) - и как видно у них неплохо получается.

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

MyLifeBits - уже реальность?

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

Проект

Недавно я узнал о проекте MyLifeBits. MyLifeBits - проект, которым занимается исследовательское отделение компании Microsoft - Microsoft Research. В чем идея? Идея в том, чтобы записывать ВСЮ жизнь человека в некую базу данных, называемую цифровой памятью. Под всей жизнью понимается, что будет записано:

• Все телефонные звонки
• Программы, передаваемые по радио и телевидению, которые человек смотрит
• В процессе работы на компьютере записывается:
• Каждая посещаемая web-страница
• Каждое полученное или отправленное сообщение по MSN, ICQ или другому интернет-пейджеру
• Открываемые файлы
• Проигрываемая музыка
• Все производимые поисковые запросы
• Окна являющиеся в данный момент активными
• Все действия клавиатурой и мышью
• В процессе передвижения человека также записывается
• Информация о местонахождении (при помощи портативного GPS устройства, передающего информацию прямо в базу данных по беспроводной связи)
• Специальная камера SenseCam, разработанная Microsoft Research автоматически производит фотографию в случаях:
• появления рядом человека (инфракрасный датчик отмечает появление тёплого тела неподалёку)
• существенного изменения освещённости, что может свидетельствовать о смене местоположения (человек вошёл куда-то или вышел откуда-то)
• Помимо всего вышеперечисленного, предполагается также запись биологических параметров (пульс, давление и тому подобное) при помощи специальных датчиков.

Ну понятное дело, что к приведённому списку можно добавить ещё что-то. Тем не менее для понимания общей идеи я думаю списка вполне достаточно.

В недавней статье в Scientific American, основной разработчик всего этого безобразия, Gordon Bell, рассказывает как в 1998 году ему пришла в голову идея, что нужно наконец начать жить по "безбумажной технологии". Человек он, по всей видимости, очень упорный и упёртый, поэтому раз уж он "чего решил, то выпьет обязательно". Короче говоря, он нанял специального секретаря, который немного ни мало за несколько лет умудрился оцифровать все, что нашему герою пришло в голову оцифровать. А пришло ему в голову много чего: все документы, фотографии, видеозаписи были отсканированы и оцифрованы. Сколько денег было заплачено секретарю не раскрывается, но полагаю что немало. И вот в этот момент, когда все уже было оцифровано, Gordon осознал тот факт, что воспользоваться всей этой ценнейшей, по его мнению, информацией чрезвычайно сложно ...

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

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

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

Естественно, что сотрудники Microsoft Research, смотрят в будущее и уже сейчас, как и любые приличные научные деятели, отметили в своих собственных работах некоторые недостатки. В частности, речь идет о возможных проблемах связанных с вторжением частную жизнь, возможной "автоматической" записью секретных данных (торговых, коммерчески и научных, с которыми человек сталкивается по работе). Есть конечно и технические проблемы - хранение огромных объёмов информации, резервное копирование, потенциальное устаревание форматов данных - ведь предполагается хранить данные всю человеческую жизнь, а вероятно и дольше. Ну конечно же тут примешиваются и проблемы морально-этического плана, о которых наверное лучше всего рассказывается в фильме Final Cut.

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

Реальность

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

А так ли далеко?

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

В 1998 году ещё не было Google ... Вот в чем дело. А сейчас Google есть. И очень интересно посмотреть на мир именно глазами этих ребят.

Уже сейчас Google имеет возможность записывать про нас очень многое. Зависит конечно от человека, но про меня лично Google вполне может знать:

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

Как вам этот список? Ничего не напоминает? По-моему очень даже похож на список того, что записывается в проекте MyLifeBits. И самое главное, что количество видов информации, которыми может обладать Google обо мне, с каждым наверное днем расширяется. Ведь помимо всего этого Google ещё знает или может знать:

• Какие RSS feed-ы и блоги я читаю (Google Reader)
• На какие сайт я "люблю" ходить (bookmarks)
• Информацию о моих покупках (Google Checkout)
• Информацию о моих сайтах в интернет (Google Analytics)
  
• Даже содержимое этого блога, который вы сейчас читаете (ведь я же пользуюсь blogger)

Я не пытаюсь нарисовать Google, как страшного большого брата, следящего за всеми и стремящегося к мировому господству (как например делается здесь).

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

Пока что Google не знает что у нас завтра на обед - но возможно что-то вроде Google Food Delivery уже на подходе?

d3c01991-6913-44cd-afda-12562c9b9d33