четверг, 30 июля 2009 г.

[comp; life] Мысля вслух: что-то мне не верится в коллективное творчество

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

Так вот, по моим субъективным впечатлениям, коллективный дизайн гораздо хуже. Как по получаемым результатам, так и по затраченным усилиям. Поэтому я считаю, что вместо совместных попыток родить что-нибудь стоящее (что сопровождается бесконечными разговорами типа “Как нам сделать вот это?” – “Например, вот так…” – “Мне не нравится…” – “Тогда вот так…” – “А так мне не нравится…” – “Лучше тогда так…” – …) нужно дать какому-то одному человеку полную свободу. А потом оценить его достижения. И заставить переделать какие-то моменты (объяснив, почему они не подходят). Можно дать такое задание сразу нескольким людям, а потом сравнить их результаты. С тем, чтобы кто-то из них (но один) добавил в свой проект самые удачные штуки из чужих проектов.

Правда, есть еще такая штука, как “мозговой штурм”. Но я не думаю, что методом мозгового штурма можно разработать проект архитектуры приложения. Решить какую-то проблему – да, можно. Но при разработке дизайна, скажем, библиотеки, будет не одна-две большие проблемы, требующие мозгового штурма (точнее говоря, они могут быть, а могут и не быть), а множество мелких проблемок, шероховатостей и нестыковочек. Которые нужно разрешить, отшлифовать и подогнать решения друг к другу. И одному человеку сделать это, имхо, гораздо проще. Поскольку он борется только с этими проблемами (ну иногда еще с собственной ленью). Тогда как во время коллективного обсуждения кроме решаемой задачи есть масса других раздражителей, включая личные отношения между участниками процесса.

PS. Еще больше я укрепился в этой мысли после активизировавшегося на днях обсуждения в группе SObjectizer. Много сил тратится без ощутимого результата. Грустно.

среда, 29 июля 2009 г.

[comp.concurrency] Интересная презентация: A Survey of Concurrency Constructs

PS. Какое жуткое засилье managed-кода! Надо будет заняться продвижением SObjectizer в англоязычные массы обязательно. Покажем проклятым буржуинам, что actor model в C++ жила, живет и жить будет! :))

[life] Примеры человеческой креативности – удивительные, забавные и не очень

Для начала пара подборок достижений рекламщиков. Хоть они и не новые, но многих я не видел.

Часть первая: Deceiving Billboard Ads - Part I. Например:

Или вот еще:

Часть вторая: Deceiving Billboard Ads - Part II. Например:

или вот

Update. Здесь были ссылки еще на несколько фотографий, но после возникновения некоторых странностей, эти ссылки пришлось убрать.

Предупреждение. На сайтах, ссылки на которые я привел, есть еще много чего интересного. Так что будьте осторожны – это настоящие, суровые и беспощадные time killer-ы. Я предупредил ;)

вторник, 28 июля 2009 г.

[comp.tech] Bokode: интересно, что из этого получится

В MIT’s Media Lab разработали новый тип штрих-кодов: Bokode. Небольшой кружочек, информация с которого может считываться обычными камерами. Даже с большого расстояния (по сравнению с обычными лазерными считывателями). При этом можно не только считать с Bokode информацию, но еще и определить, под каким углом к наблюдателю находится метка Bokode. Что, по мнению авторов разработки, может существенно помочь в Motion Capture технологиях.

Небольшая видеопрезентация Bokode:

И небольшой обзорный рассказ о Bokode в Dr.Dobb.

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