Вначале неплохая рекламная кампания продукта IBM Watson. Пересадили систему с суперкомпьютера на обычные мэйнстримные сервера, и отправили IBM Watson побеждать мировых чемпионов игры Jeopardy!

Затем пошли продаваться в медицину. Watson уже помогает онкологам в постановке диагнозов и выборе лечения.

http://gigaom.com/2013/02/08/watson-now-officially-fighting-cancer-in-hospitals-from-the-cloud/

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

См видео о том, как это может работать в медицине: http://www.youtube.com/watch?v=HZsPc0h_mtM&feature=player_embedded

Дальше Watson может заняться кулинарией:

http://www.nytimes.com/2013/02/28/technology/ibm-exploring-new-feats-for-watson.html?pagewanted=2

In San Jose, I.B.M. plans to serve the assembled analysts a breakfast pastry devised by Watson, called a “Spanish crescent.” It is a collaboration of Watson’s software and James Briscione, a chef instructor at the Institute of Culinary Education in Manhattan.

I.B.M. researchers have watched and talked to Mr. Briscione as he works, selecting ingredients and building out dishes. Watson has read those notes, 20,000 recipes, data on the chemistry of food ingredients, and measured ratings of flavors people like in categories like “olfactory pleasantness.”

Watson’s assignment has been to come up with recipes that are both novel and taste good. In the case of the breakfast pastry, Watson was told to come up with something inspired by Spanish cuisine, but unusual and healthy. The computer-ordered ingredients include cocoa, saffron, black pepper, almonds and honey — but no butter, Watson’s apparent nod to healthier eating.

Then, Mr. Briscione, working with those ingredients, had to adjust portions and make the pastry.

“If I could have used butter, it would have been a lot easier,” said the chef, who used vegetable oil instead.

Michael Karasick, director of I.B.M.’s Almaden lab, had one of the Spanish crescents for breakfast recently. “Pretty good” was his scientific judgment.

В каких отраслях его еще можно применить? Финансы? Инженерия? Mining?

Официальная страничка, там много материалов о Watson’е: http://www.ibm.com/innovation/us/watson/

IBM Watson Progress and 2013 Roadmap:

http://www.slideshare.net/manojsaxena2/ibm-watson-progress-and-roadmap-saxena

–

Павел Сурменок

http://surmenok.ru/

http://pavel.surmenok.com/

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

Блог на русском: http://surmenok.ru/. Stand-alone блог на WordPress, размещаю на своем сервере (Linux).

Настроена автоматическая трансляция в ЖЖ: http://surmenok.livejournal.com/.

Блог на английском: http://pavel.surmenok.com/. Stand-alone блог на Kentico CMS, размещаю на своем сервере (Windows).

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

Проблемы:

1. Не хочется самому саппортить блоги. Выясняется, например, что надо периодически обновлять CMS и плагины, настраивать их как-то.

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

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

3. Неудобные редакторы текста в CMS. Поэтому приходится использовать предварительно Word для написания текстов. Потом из Word очень криво копипастится в блог.

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

Наверное идеальное конечное решение – постить в единственный (англоязычный) блог, оттуда транслировать во все значимые соцсети. Вот только какой сервис (или хотя бы какой движок) использовать для блога?

–

Павел Сурменок

https://surmenok.ru/

http://pavel.surmenok.com/

Недавно в одной дискуссии мне задали вопрос, касательно выбора между развитием технической экспертизы и навыков менеджмента. И я, похоже, на него неверно ответил, так как термины очень мутные. Попробуем разобраться в дихотомии technical expertise vs. management.

Гуглить «техническую экспертизу» не советую, потому что, скорее всего, найдете определения из криминалистики. Но под technical expertise похоже понимаются hard skills – владение инструментами, технологиями. В общем, умение гнать самогон с помощью самогонного аппарата – это техническая экспертиза. Умение забивать гвозди молотком – тоже.

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

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

Software development – сложная дисциплина, люди создают очень сложные системы, и поэтому доля менеджмента здесь особенно велика. Если посмотреть на SCRUM, то там мы видим, что вся команда вовлечена в менеджмент. Jeff Sutherland в книге “SCRUM Handbook” (http://jeffsutherland.com/scrumhandbook.pdf) пишет, что митинг по планированию спринта занимает 2 часа для 2-недельной итерации. Backlog grooming (уточнение требований в sprint backlog) занимает 5-10% общего времени спринта. Еще нужно не забыть проведение митингов Sprint Review (то, что, по словам Jeff’а, некоторые ошибочно называют демонстрацией) и Sprint Retrospective.

Итого более 10% времени уходит на формальные мероприятия по методологии SCRUM. А ведь помимо еще часто проводятся митинги по согласованию дизайна разрабатываемой системы, обсуждение мелких технических проблем, согласование изменений требований при возникновении коллизий. Пожалуй, даже code review – это менеджмент.

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

С чем я попутал эту ситуацию? С дихотомией technology vs. business. Здесь я предполагаю, что есть две стороны деятельности организации: продажи и производство. И одни менеджеры больше озабочены продажами, маркетингом, связями с внешним миром. А другие – тем, чтобы построить то, что первые продали. Обычно это разные менеджеры. Редко навыки продаж и навыки производства сочетаются в одном и том же человеке. Я, похоже, тот человек, который делает (или менеджит делание). Продавать я умею хуже.

–

Павел Сурменок

http://surmenok.ru/

http://pavel.sumenok.com/

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

Немного писал в недавно созданный англоязычный блог: http://pavel.surmenok.com/. Со временем больше моей активности будет перетекать туда. Ведь надо же не только черпать из мирового бульона, но и самому туда что-то вкидывать.

Летом женился. Церемонию провели на горе Ловчен в Черногории. Фото, кому интересно, есть где-то на моей странице в фэйсбуке и/или вконтакте. Видео на vimeo: https://vimeo.com/48157567 Свадебная церемония по факту выглядела как 6-часовая фотосессия. Ездили по красивым местам, а за нами ходили 3 веселых человека с чемоданом аппаратуры.

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

Почти год успел поработать в компании Астерос Лабс. Интересный опыт, с разных точек зрения.

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

Год назад я активно интересовался темой Business Intelligence. И даже немного смог в этом году попрактиковаться, чему очень рад: проектировал простенькую систему генерации отчетов и расчета KPI на основе логов выполнения workflow.

Coursera http://www.coursera.org/ набирает обороты, чему я несказанно рад. Качество курсов американских университетов на голову выше российских. Успешно прошел легендарный курс Andrew Ng по Machine Learning. Теперь пытаюсь практиковаться на задачах с http://www.kaggle.com/. За ML видится будущее. А может уже и настоящее. Нужно успеть.

Там же на Coursera освежил знания по дизайну алгоритмов (курс Tim Roughgarden, Stanford University).

Углубил знания и прокачал умения по многим другим вещам: архитектура, инженерные практики, методологии разработки, всякие технологии/фрэймворки.

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

Обычно мои верхнеуровневые цели достигаются, хотя и не всегда в намеченные сроки. Одной из таких целей у меня давно был переезд в место, где приложение моих сил будет более эффективным. Несколько лет назад я еще выбирал между Швейцарией и США. Потом я понял, что единственный нормальный вариант – это США, и лучше даже долина. Осенью планирую переехать в San Francisco Bay Area. Надеюсь, что всё у нас получится, и в Калифорнии мы останемся надолго.

–

Павел Сурменок

http://pavel.surmenok.com/

http://surmenok.ru/

Я недавно писал о том, как пользоваться отчетом Burndown and Burn Rate в TFS.

Сейчас хочу рассказать немного про внутреннюю кухню. Как же данные из issue tracker, например значения полей remaining work и completed work у элементов task, превращаются красивую картинку отчета?

На самом деле, никакой магии здесь нет. Всё предельно просто.

Данные issue tracker хранятся в обычной БД SQL Server с именем TFS_имяколлекциипроектов. Обычная такая транзакционная БД. С немного страшной структурой, ну с кем не бывает, и в MS страшные вещи проектируют.

Например work items скорее всего лежат в какой-то из этих таблиц (а может и во всех сразу): WorkItemsAre, WorkItemsWere, WorkItemsLatest, WorkItemsDestroyed, с любопытными полями вроде “Not A Field” и “Fld10013”.

Нет, данные из этих таблиц не идут напрямую на картинку отчета.

Раз в 2 минуты (по умолчанию) TFS перекидывает данные в data warehouse (склад данных). БД TFS_Warehouse. Обычный такой data warehouse, с таблицами фактов, таблицами измерений. Зачем это делается? Профиль нагрузки на транзакционную БД и на data warehouse очень разный. Транзакционная БД должна хранить только текущее состояние данных, и обеспечивать обработку большого количества запросов чтения/записи. Data warehouse должен хранить огромные объемы (в идеале – всю историю изменений рабочих элементов TFS), при этом данные там не изменяются и не удаляются, только добавляются. Структура базы данных оптимизирована для использования в отчетах и аналитике.

Далее раз в 2 часа (по умолчанию) данные попадают в OLAP-кубы SQL Server Analysis Services (база данных Tfs_Analysis в SSAS). При этом там производятся всякие расчеты хитрые, например предварительный расчет различных агрегированных показателей, для того чтобы потом быстро отвечать на аналитические запросы.

И только после этого, SQL Server Reporting Services на основе данных из SQL Server Analysis Services строит отчеты. Они строятся тоже не в real-time по запросу пользователя, а периодически обновляются в фоновом режиме. Как часто – уже не помню, но чаще чем 1 раз в час.

Время последнего обновления данных в SSAS обычно указывается в отчете снизу справа с подписью “Data updated”. Время последнего обновления отчета в SQL Server Reporting Services – там же, с подписью “Generated”.

В разработке собственных отчетов (или правке стандартных) тоже нет никакой магии. Это обычные отчеты SQL Server Reporting Services.

Если зайти в веб-интерфейс SQL Server Reporting Services, найти там список отчетов, у каждого отчета в контекстном меню есть пункт “Edit in report builder”.

Он открывает report builder – GUI-приложение, которое инсталлируется через Click once, и позволяет полноценно редактировать отчет.

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

Посмотрим на то, откуда берутся данные для отчета Burn Rate. Он строится на основе набора данных dsVelocity, который берет данные из SSAS с помощью вот такого MDX-запроса:

WITH
	MEMBER [Measures].[Remaining Work] AS [Measures].[FactCurrentWorkItem Microsoft_VSTS_Scheduling_RemainingWork]
	MEMBER [Measures].[Completed Work] AS [Measures].[FactCurrentWorkItem Microsoft_VSTS_Scheduling_CompletedWork]
SELECT
{
	[Measures].[Work Item Count],
	[Measures].[Remaining Work],
	[Measures].[Completed Work]
} ON COLUMNS,
{
	NonEmpty(
		[Work Item].[System_State].[System_State],
		[Measures].[Work Item Count]
	)
} ON ROWS
FROM
(
	SELECT
		CrossJoin(
			StrToMember("[Team Project].[Project Node GUID].&[{" + @ProjectGuid + "}]"),
			StrToSet(@StateParam),
			StrToSet(@AreaParam),
			StrToSet(@IterationParam),
			Except(
				Descendants(StrToSet(@WorkItemTypeParam)),
				[Work Item].[System_WorkItemType].[All] + StrToSet(@WorkItemsToExclude)
			)
		) ON COLUMNS
	FROM [Team System]
)

Просто взяли данные по рабочим элементам, отфильтровали по параметрам, из мер (measure) нас интересуют количество рабочих элементов, оставшаяся и выполненная работа. Я не до конца этот запрос понимаю, но при желании разобраться можно.

Дальше для вычисления собственно current velocity и required velocity используются вот такие нехитрые выражения:

CurrentVelocity =IIF(
	Parameters!YAxis.Value = "hours",
	Fields!Completed_Work.Value,
	IIF(
		Fields!System_State.Value=Parameters!ClosedName.Value,
		Fields!Cumulative_Count.Value,
		0
		)
	) / Code.DaysCompleted(Parameters!StartDateParam.Value, Parameters!EndDateParam.Value, Parameters!NonWorkDays.Value)

RequiredVelocity =IIF(
	Parameters!YAxis.Value = "hours",
	Fields!Remaining_Work.Value,
	IIF(
		Fields!System_State.Value<>Parameters!ClosedName.Value,
		Fields!Cumulative_Count.Value,
		0
		)
	) / Code.DaysRemaining(Parameters!StartDateParam.Value, Parameters!EndDateParam.Value, Parameters!NonWorkDays.Value)

Если отбросить кучерявые конструкции IIF, видно, что здесь работа делится на рабочие дни. Нерабочие дни при этом вычисляются с использованием параметра “NonWorkDays”, значение по умолчанию у которого равно “0,6” – подозреваю, что это индексы воскресенья и субботы соответственно.

Домашнее задание: отредактируйте график Burndown так, чтобы в нём не было выходных дней. И еще придумайте, как нам быть с тем, что сейчас в России заканчиваются 3-дневные выходные, а значит, график Burn Rate будет врать.

–

Павел Сурменок

http://surmenok.ru/

http://pavel.surmenok.com/

Те, кто использует TFS в качестве issue tracker, наверняка знают, что он предоставляет богатые возможности для построения отчетов. С ним также поставляется несколько предустановленных отчетов. И наиболее популярный из них – это, пожалуй, отчет Burndown and burn rate, показывающий прогресс по «сжиганию работы».

Выглядит он примерно так:

Большой график сверху – это burndown chart. По горизонтали календарные дни, по вертикали обычно выводят объем работ в часах, хотя можно показать и количество рабочих элементов (задач) вместо часов. Синяя зона – оставшаяся (remaining) работа, зеленая – выполненная (completed) работа. Две прямых линии: черная – идеальный тренд, красная – актуальный тренд.

Идеальный тренд строится от уровня remaining work на момент начала периода, до нуля в конце периода.

Как строится актуальный тренд?.. Я честно пытался понять expression, который это вычисляет, но упёрся в итоге в вызов магической функции “Code.Burndown”. Однако мои наблюдения показывают, что это линейная регрессия значений remaining work за предыдущие дни.

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

Во-первых, он не учитывает выходные. Поэтому при двухнедельных итерациях в пятницу первой недели вечером burndown показывает, что всё замечательно, а в понедельник утром – уже всё плохо. Чтобы понять, что собственно происходит, иногда приходится делать скриншот и в Paint’е вырезать выходные J

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

А если в первый день перепланировали, а на второй день часть работ выкинули из итерации, burndown может выглядеть так:

В результате линии трэнда уже ничего не говорят, да и линии remaining/completed work уже не столь хорошо показывают, насколько всё плохо.

Снизу слева виден скромный график Burn Rate, который показывает два значения: Actual hours/day, Required hours/day. И вот этот график, хоть и не так красив на большом экране, но гораздо информативней. Просто смотрим на эти два числа, и сравниваем. Actual больше чем required – хорошо, высока вероятность успеть сделать всё задуманное. Actual меньше – всё плохо, придётся перепланировать, выкидывать наименее нужное с итерации.

Считаются эти значения просто. Для Actual hours/day берется объем всей выполненной за период работы, и делится на количество прошедших рабочих дней. Для Required – объем всей оставшейся работы делится на количество оставшихся рабочих дней.

Здесь используются именно рабочие дни, а значит картина в пятницу вечером и в понедельник утром будет примерно одинаковая.

А т.к. в расчете не участвуют значения remaining work за прошедшие дни, то перепланирование объема работ во время итерации не ломает показатели.

Хотя и у этого графика есть один неприятный нюанс. Actual hours – это часы, реально потраченные на выполнение задач. А Required hours – часы, планируемые. И поэтому здесь отражаются ошибки планирования. Но если обычно у вас задачи реально выполняются дольше плана, то при совпадении на графике показателей Actual и Required на самом деле всё плохо. Значит, при анализе этого графика нужно держать в уме среднюю ошибку оценки.

А знаете ли вы еще какие-то метрики или отчеты, позволяющие понять статус итерации?

–

Павел Сурменок

http://surmenok.ru/

http://pavel.surmenok.com/

Agile методологии, как правило, предполагают итеративную разработку. Что это значит?

Это конечно не эджайлисты придумали. Термин существует еще с мохнатых 60-х годов (http://www.craiglarman.com/wiki/downloads/misc/history-of-iterative-larman-and-basili-ieee-computer.pdf).

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

In 1975, Vic Basili and Joe Turner published a paper about iterative enhancement that clearly described classic IID:

“The basic idea behind iterative enhancement is to develop a software system incrementally, allowing the developer to take advantage of what was being learned during the development of earlier, incremental, deliverable versions of the system. Learning comes from both the development and use of the system, where possible. Key steps in the process were to start with a simple implementation of a subset of the software requirements and iteratively enhance the evolving sequence of versions until the full system is implemented. At each iteration, design modifications are made along with adding new functional capabilities.”

Замечательно. Когда в обществе витает здоровое недоверие к секте agile – приятно осознавать, что бородатые инженеры NASA еще полвека назад думали примерно так же.

Идём дальше. Откуда итерации взялись в Agile? Видимо из вот этих принципов Agile Manifesto (http://agilemanifesto.org/principles.html):

“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.“

“Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.”

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

Из этого (и из здравого смысла) можно сделать вывод, что итерации полезно было бы совместить с релизами. Зачем нам итерация, в конце которой нет delivery? Такая итерация гораздо менее полезна для валидации функционала и для обучения, да и клиенту такая итерация совершенно неинтересна. Если релизить каждую итерацию – то итеративная разработка обретает смысл.

Дальше возникает вопрос, а как часто нужно релизить? И здесь, наверное, ответ нужно искать в разрезе денег.

С одной стороны, чем реже релизы, тем ниже затраты, как у разработчика, так и у клиента. С другой стороны, и разработчику, и клиенту могут быть выгодны частые релизы.

Сравним две ситуации (цифры приведены условные, сильно не смейтесь).

Ситуация A. Компания-разработчик делает 1 релиз за месяц, релиз сразу же внедряется у клиента.

Затраты на ручное тестирование релиза и на выпуск – 2000 долларов.

Затраты клиента на внедрение новой версии – 15000 долларов (сюда входит upgrade лицензии на продукт, работы по upgrade ПО, переобучение пользователей и админов и т.п.).

Ситуация B. Компания-разработчик делает 2 релиза за месяц, релизы сразу же внедряются у клиента.

Затраты на ручное тестирование релизов и на выпуск – 2 * 2000 = 4000 долларов.

Затраты клиента на внедрение – 2 * 15000 долларов (на самом деле меньше наверное, но для простоты модели пусть будет так).

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

А разработчик имеет возможность на 2 недели раньше провалидировать этот функционал. Какова ценность этого факта, выраженная в долларах? Допустим, это позволит скорректировать планы на вторую половину месяца, выкинув половину работ, оказавшихся ненужными, а значит сэкономить на разработке 10000 долларов.

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

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

–

Павел Сурменок

http://surmenok.ru/

http://pavel.surmenok.com/

Давненько не писал в блог. И, кажется, никогда еще такие годовые посты не писал.

Год был интересный и продуктивный

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

В этом году также я защитил магистерскую диссертацию, об автоматизации общего проектирования космических аппаратов. Практически generative design получился Но до практического применения далековато. Да и нет смысла. На российский космос работать нет никакого желания, ибо состояние отрасли ужасное, почитайте хотя бы ленты новостей. А в штатовский/европейский космос влезть сложнее.

Ну и, пожалуй, главная новость года – в ноябре мы с Машей переехали в Москву. Тут (чисто субъективное мнение конечно, как и всё, что я говорю) круче. Удобней и интересней.

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

И, пожалуй, за этот год я понял, что уже устал от разработки интернет-проектов и скучного однотипного кровавого энтерпрайза. Да и специфика этого рынка такова, что знаний много не требуется, конкуренция высока: за любой такой проект с радостью возьмутся миллионы индусов. Нужно двигаться дальше. Меня на данный момент очень интересует Business Intelligence. В рабочих планах на следующий год стоит развитие этого направления – в проектах нашей компании и/или в США. А может и в рамках наших проектов для заказчиков из США Как пойдёт.

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

Поздравляю с наступающим!

–

Павел Сурменок

http://surmenok.ru/

http://pavel.surmenok.com/

Один из наиболее популярных видов генерируемого пользователями контента – оценки различных материалов. Рейтинги есть практически везде: на новостных сайтах, в блогах, социальных сетях, интернет-магазинах.

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

Иногда предлагается только два варианта: плюс и минус. По факту правда получается не два, а три: можно не голосовать вообще.

А иногда и такого разнообразия нет. В Facebook, к примеру, есть только кнопочки Like. То есть остается два варианта: нажать Like или не нажать.

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

Здесь на помощь приходит статистика. Сотрудники YouTube проанализировали, как люди оценивают видео. Пользователи оценивали материалы по шкале от 1 до 5. И, как оказалось, подавляющее большинство оценок – это 1 и 5. Причем оценок 5 в разы больше, чем оценок 1.

Вобщем-то причины понятны. Люди ставят оценки в основном только если видео очень хорошее или очень плохое. Кроме того, суть оценок 1 и 5 хорошо понятна. А вот как понимать промежуточные оценки? Чем 4 отличается от 5 или от 3?

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

А учитывая, что оценок 5 в разы больше – то может сгодиться и 1-балльная, как на Facebook. Но тут уже важно оценить, насколько понизится точность рейтинга.

Точность оценок становится особенно важна, когда речь заходит об использовании их для прогнозирования. Так, к примеру, Amazon использует оценки пользователей для системы рекомендаций товаров. А компания Netflix придает вопросам рейтингов настолько большое значение, что объявило приз 1 миллион долларов за алгоритм, который сможет повысить точность их прогнозов на 10%.

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

–

Павел Сурменок

http://surmenok.ru/

http://pavel.surmenok.com/